Default Backgrounds

[duanemoody]

Will backgrounds that do not exactly match window dimensions continue to leave ghosts, or will the new code actually clean up after itself?

[PyTom]

The behavior of an unfilled screen is undefined. Ren'Py is free to do anything in that case, including making demons fly out of your nose.

[Jake]

The behavior of an unfilled screen is undefined. Ren'Py is free to do anything in that case, including making demons fly out of your nose.

As amusing as the thought is, wouldn't it be a more-useful thing to do to fill with black unless specifically instructed not to? Have a "config.backdrop" setting or something which defaults to "Solid('#000')"?

People who really care about performance that much could set it to None and switch it off to save the clock cycles, and the 99% of Ren'Py users who have never done any computer graphics programming can have an engine that does what they expect when they don't put anything on the screen...

Maybe even have it as a suggestion alongside disabling developer mode. Hell, if you were feeling adventurous it wouldn't be impossible for Lint to check everything is preceeded by a scene statement and that all the Displayables used in scene statements are entirely opaque! (In fact, on second thought, just the first part of that would probably be useful.)

[Wintermoon]

There is no excuse for C-style undefined behavior in a high-level scripting language like Ren'Py. At the very least Ren'Py should guarantee that an unfilled screen won't have any negative consequences other than garbage on the screen, since making this guarantee costs nothing. That's unspecified rather than undefined behavior in C lingo.

I find Jake's suggestions entirely reasonable here. An unfilled screen is dirt cheap to detect, either offline (e.g. with lint) or at runtime, and even conservatively filling the screen with black is fairly cheap.

[PyTom]

even conservatively filling the screen with black is fairly cheap.

Have you measured this? Because it's not when using software rendering.

[Counter Arts]

even conservatively filling the screen with black is fairly cheap.

Have you measured this? Because it's not when using software rendering.

Only in hardware rendering this applies. In software rendering this implies drawing every pixel on the screen at least twice in normal cases.

[Wintermoon]

Have you measured this? Because it's not when using software rendering.

Yes. Relevant code:

Code: Select all

      SDL_SetVideoMode(800, 600, 32, 0);
      Uint32 time = SDL_GetTicks();
      for (int i = 0; i < 1000; ++i) {
        SDL_FillRect(SDL_GetVideoSurface(), 0, 0);
      }
      printf("1000 fills in %d ms.", SDL_GetTicks() - time);

Result:

1000 fills in 2873 ms.

That's slightly less than 3 milliseconds per frame on my old, outdated computer. If you're aiming at 60 fps, you have almost 17 millisecond per frame. Filling the screen with black apparently uses around 17 percent of that, which is not insignificant, but not necessarily big deal either. If the frame rate drops below 60 fps, the percentage of time spent blanking the screen will likewise drop.

[Counter Arts]

Keep in mind with the new ATL language more people will have moving, rotating, zoomed images in software rendering. I think having it undefined for performance reasons would be a good idea if you want new users to start adopting ATL.

[Wintermoon]

The more stuff is happening on the screen and the more computationally expensive it is, the smaller the percentage of time used for clearing the screen.

[Jake]

Alternate, not-so-good-but-still-probably-easier-than-today's-behaviour-for-newbies option:

- draw graphics for 'scene' without alpha (less expensive!) and fill in any letterboxing space with black yourself (no more expensive than a full-screen image).
- have Ren'Py throw a descriptive error when someone tries to call 'show' or dialogue of any kind without a preceeding 'scene' (something like "You must have a 'scene' statement before you can 'show' anything" or "...before you can include dialogue".
- again, have config options which which override this behaviour. For extra credit default them to on (overriding) but explicitly set them to off in new options.rpy files, so as to maintain backwards compatibility with older scripts.

Kind of like the Ren'Py-Script equivalent of a "treat warnings as errors" compiler switch.

Keep in mind with the new ATL language more people will have moving, rotating, zoomed images in software rendering. I think having it undefined for performance reasons would be a good idea if you want new users to start adopting ATL.

To be perfectly frank, anybody whose computer takes so long to blank the screen that it's noticeable to the user that Ren'Py's taking longer to draw frames than usual, their computer will also take so long to draw anything else that Ren'Py games are very unlikely to run smoothly in the first place, and the introduction of ATL and subsequent encouragement to use more animation and transformation stuff in Ren'Py games will likely be much more of a problem to them. But that didn't stop PyTom implementing ATL!

[PyTom]

Wintermoon, a couple of points:

The first is that it's not enough to measure the time spent filling. You also need to measure the time spent filling and flipping the screen. The flip takes a substantial amount of time (since sending data from system to video memory is _slow_), and it eats substantially into the amount of time you have to actually render the frame.

The more stuff is happening on the screen and the more computationally expensive it is, the smaller the percentage of time used for clearing the screen.

This is the wrong way to think about it. The percentage of time it takes to clear the screen is unimportant, as that that number is just scorekeeping. I could make the percentage of time spent clearing the screen drop to 0 by simply sleeping each frame - but that would drop the framerate to nothing, and would be totally unacceptable.

The right way to do is to pick a target framerate, and say that we have to fit all the operations required to render a frame into the amount of time given to us by that framerate. When you think about it that way, it's obvious that eliminating a fill operation will help us meet our goal. The more work we do, the closer we get to overrunning the time allotted to us, and having a loss of framerate. You can think of each operation as taking a percentage of the frame render time - if the percentages sum to more than 100%, we won't be able to render the frame fast enough.

FYI:

My target framerate is 100fps, which gives me 10ms to render each frame. On my system, it takes 1.9ms to send the screen to the video card. So that means I have 8.1 ms to render the frame. A fullscreen fill takes .95 ms, or about 12% of that. That seems a bit high of a penalty to me.

There's also the fact that when a game doesn't fill the screen with an image, that's a problem with the game. The user isn't specifying what parts of the screen should look like - so why should Ren'Py specify it for them? It seems kinda silly to jeopardize the performance of correct code to make incorrect code function differently.

I don't plan to address this in the 6.11 timeframe. As hardware acceleration support matures, I may reconsider this - but I'm not sure what the behavior should be. Should we fill with black? Or should we fill with Horrible Purple Color, so it's obvious there's a problem? Or something like the pattern used for images with alpha in image editors?

[Wintermoon]

Wintermoon, a couple of points:

The first is that it's not enough to measure the time spent filling. You also need to measure the time spent filling and flipping the screen. The flip takes a substantial amount of time (since sending data from system to video memory is _slow_), and it eats substantially into the amount of time you have to actually render the frame.

The question isn't how long it takes to render a blank screen, but how much longer it takes to update the screen if you blank it before rendering than if you don't. This is, on my computer, at 800x600x32 resolution, 3 milliseconds.

There is one flaw in my test, and that is that my test has better locality of reference than the same code in Ren'Py would, so it may make better use of the CPU cache.

The more stuff is happening on the screen and the more computationally expensive it is, the smaller the percentage of time used for clearing the screen.

This is the wrong way to think about it. The percentage of time it takes to clear the screen is unimportant, as that that number is just scorekeeping. I could make the percentage of time spent clearing the screen drop to 0 by simply sleeping each frame - but that would drop the framerate to nothing, and would be totally unacceptable.

Percentage of time used tells you where you need to optimize. If including screen blanking causes you to miss your target framerate but most of your execution time is spent elsewhere, then you should first optimize those other bits before dropping the screen blanking.

It just so happens that screen blanking is trivial to optimize, but that's only relevant if screen blanking is a performance bottleneck.

[luminarious]

As a user, not a programmer, it somehow makes sense to me that when no background was specified, it isn't very likely that there's much happening onscreen anyway that would hamper performance further. So I vote for a solid colour fill, the same colour that is set for main menu when you choose a colour theme.

[Jake]

The first is that it's not enough to measure the time spent filling. You also need to measure the time spent filling and flipping the screen. The flip takes a substantial amount of time (since sending data from system to video memory is _slow_), and it eats substantially into the amount of time you have to actually render the frame.

Without meaning to be facetious, weren't you going to do this flip anyway, regardless of whether you filled the screen before drawing everything else or not?

There's also the fact that when a game doesn't fill the screen with an image, that's a problem with the game. The user isn't specifying what parts of the screen should look like - so why should Ren'Py specify it for them? It seems kinda silly to jeopardize the performance of correct code to make incorrect code function differently.
...
I'm not sure what the behavior should be. Should we fill with black? Or should we fill with Horrible Purple Color, so it's obvious there's a problem? Or something like the pattern used for images with alpha in image editors?

This is a fine attitude when you're writing code for programmers to use, but it's not a good attitude when you're writing code for normal people. Ren'Py is supposed to be "easy" to script and to "[make] it possible for non-programmers to make visual novels", so it behooves the engine to do things to pander to those people without having to explain to them the complexities of buffered graphics programming.

The average user who doesn't understand buffered graphics programming (I would guess this is 95+% of Ren'Py users) will think of the graphics on the screen as if they were cellulose sheets with characters painted on them, held up in front of the blackness of a turned-off monitor - not as if they were being constantly painted and re-painted over the same re-used canvas, which is a much better analogy. If they remove one of those cellulose sheets, they expect it to disappear!

So the best behaviour for a piece of software allegedly written for these people - and those are your words, from the Ren'Py website - is to do what they expect, because the more you do what they expect the less complex stuff needs to be explained to them and the easier it is for them to create VNs. To answer your questions:

- Why should you jeopardise the performance of correct code to make incorrect code function differently? Because people who don't understand the problem expect Ren'Py to work like that - we've seen ample evidence of this in all the questions and confusion over the matter, including some games released with such problems - and people who do understand the problem can turn it off and get the relevant performance gains. Hell, you could even make it part of Developer Mode, and mention it in the documentation for that, if you're so worried about performance.

- Should you fill it with black or horrible purple? The answer to this is also pretty obvious - if you fill it with purple, then you'll just change the question from "I can see the first few characters of old dialogue at the left beside my BG image, what do I do?!" to "Ren'Py is drawing horrible purple bars down the side of my VN, what do I do?!". In other words, you wouldn't be helping at all, in most cases. If you make it black, people will think it's normal, so that's obviously the better idea.

It seems to me that this kind of decision really has one obvious direction to take in the case that you're genuinely writing a bit of software that fits the description you put on the renpy.org site in big letters right at the top of the page, and the direction you're talking about taking isn't it. You're making a decision with a for-programmers attitude, for people who see "this behaviour is undefined" and think "Oh, I shouldn't do that, then" instead of "why not?".

[Wintermoon]

- draw graphics for 'scene' without alpha (less expensive!) and fill in any letterboxing space with black yourself (no more expensive than a full-screen image).

The nice thing about this suggestion is that it actually increases performance over the status quo. Currently, in order to get the same effect, you would need two layers: one for the background image and one for the black behind the background image. Requiring the user to explicitly specify both layers does not solve the performance problem of rendering a lot of pixels twice. Auto-letterboxing avoids the overdraw completely.