Page 2 of 2

Re: 6.11 Development

Posted: Sat May 01, 2010 5:02 am
by Wintermoon
Jake wrote: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.
Even for programmers, uninitialized variables often cause problems. There's a reason why most modern programming languages initialize variables to a default value, and there's a reason why they generally pick a default that's useful (e.g. 0) instead of one that draws attention to itself (e.g. 0xdeadbeef).

Re: Default Backgrounds

Posted: Sat May 01, 2010 11:09 am
by Counter Arts
The major case that would have to be dealt with would be eepc/netbook hardware. 1.6 GHz CPU and integrated graphics that may or may not work. There's going to be so much of them running around.

So if anyone has information on that then that would be very useful.

Re: Default Backgrounds

Posted: Sat May 01, 2010 11:51 am
by Jake
Counter Arts wrote:1.6 GHz CPU and integrated graphics that may or may not work.
If the integrated graphics don't work, the user isn't going to be able to see enough to notice the slow-down from blanking the screen at the beginning of each draw cycle... :3

Re: 6.11 Development

Posted: Sat May 01, 2010 1:27 pm
by PyTom
Jake wrote: 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?
Sure. But it means I now have 8.1 ms to draw a frame, rather than 10. And hence makes the cost of a fill that much worse, as a percentage of the time I have to draw a frame.
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.
I think the most important questions are, "What is the underlying problem that the user is having?" and "How should they solve the problem?". Generally, when the user comes to us with this problem, the right solution isn't to put a black image behind what they're showing on the screen. That's because the actual problem is that the background image is too small for the screen. The right solution in the vast majority of cases is to scale up the image so that it fills the screen, _not_ to put a black background behind the image.

Now there are a couple of good answers to this. Probably the best would be to somehow figure out that this is going on the screen, and warn the user. But that's not an easy task, so I haven't done that yet. Another solution could be to automatically scale the background image, but scaling is difficult, and not something I want to do automatically.The current solution, where the user goes to the forum and is given help, is not ideal, but it works surprisingly well in practice. Ignoring this thread, we're not swamped with posts on this topic, and people seem to be getting the help they need.

But I don't see putting up a background as actually solving the problem. While it might be the "easy" thing, it's likely the wrong answer - and I don't think that making it easy to get the wrong answer is something we want. Especially when it could harm performance.

(I'm spending way too much time on this thread.)

Re: Default Backgrounds

Posted: Sat May 01, 2010 2:03 pm
by Counter Arts
Just a question to Tom. How did you fix that issue when I was complaining about a sliding UI button not being slick anymore? Did you do something like a software rendering back-buffer with dirty rectangles? It involved the vertical sync.

It was very noticeable for just a sliding button across the screen on a 1.5 GHz processor. Had a background, large logo with alpha and the UI. I think there is going to be a lot more moving UIs.

Re: Default Backgrounds

Posted: Sat May 01, 2010 4:27 pm
by PyTom
Counter Arts wrote:Just a question to Tom. How did you fix that issue when I was complaining about a sliding UI button not being slick anymore? Did you do something like a software rendering back-buffer with dirty rectangles? It involved the vertical sync.
Which OS was it on? I don't recall explicitly fixing this - but general speedups might have helped a lot. The hardware renderers will sync to vblank unless that is explicitly disabled through an environment variable.

Re: Default Backgrounds

Posted: Sat May 01, 2010 8:04 pm
by Counter Arts
It was Ubuntu.

Re: 6.11 Development

Posted: Sun May 02, 2010 7:09 am
by Jake
PyTom wrote: I think the most important questions are, "What is the underlying problem that the user is having?" and "How should they solve the problem?".
The underlying problem is that the user doesn't understand enough in the way of progamming and computer concepts to make the program do what they want. But Ren'Py is supposedly doing this part for them, otherwise the solution would be to provide a training course on programming Python so that they could write their own VN engine.
PyTom wrote: Generally, when the user comes to us with this problem, the right solution isn't to put a black image behind what they're showing on the screen. That's because the actual problem is that the background image is too small for the screen. The right solution in the vast majority of cases is to scale up the image so that it fills the screen, _not_ to put a black background behind the image.
You're beginning to sound dangerously socialist... :3

If the user thought that the fact that there are black borders around their background was the problem, then we would have a lot of questions saying "why is it that there's a black background around my picture?" or "how can I make my picture fill the whole screen?". We do get questions like that, but they don't talk about seeing previous lines of dialogue the vast majority of the time. If the user only asks about the left-over images of previous screens, we can presume that they don't necessarily think that the size of their images is a problem, or maybe they actually want them to show up with black borders.

A good, usable piece of software won't presume to know better than the user what the user wants to do, but also won't bloody-mindedly do unexpected stupid stuff just because the user didn't say otherwise. Automatically stretching the background (for example) would presume to know better than the user, and thus would be a bad solution usability-wise; leaving the contents of the previous screen just because the newbie user didn't specify a background is unexpected stupid stuff, so it's presently in a bad state usability-wise. I really have genuine trouble understanding why you think it's not so bad as it is. I'm not saying that putting a black BG in first will magically solve all problems related to backgrounds - I'm just saying that the way Ren'Py works now is pretty stupid, from a newbie-user's point of view, and it's a simple thing to make it work as people would expect, which will save such users some trouble.

I know I have had more than one conversation in which I was trying to help someone who just wanted a black background, and didn't understand why - since Ren'Py shows a black screen right at the beginning before you draw anything - they couldn't just leave it there and use that as their black background. For example.
PyTom wrote: Now there are a couple of good answers to this. Probably the best would be to somehow figure out that this is going on the screen, and warn the user. But that's not an easy task, so I haven't done that yet.
Well, this is essentially the kind of thing I was proposing with the make-scene-draw-without-alpha, error-on-no-scene idea. It doesn't help people who've made their background too small for the screen and actually wanted it to be bigger, but if that's their problem then it's a lot easier to explain to them why they need to scale the image (either in Ren'Py or their graphics package) than it is trying to explain to them why they also see ghosts of frames past.
PyTom wrote: The current solution, where the user goes to the forum and is given help, is not ideal, but it works surprisingly well in practice.
I know of at least one case where someone released a game with this kind of problem in, so it's apparently not really that good a solution at all. And again, you're presuming that everybody is like you, and will actually ask when they encounter problems; I can assure you that a large number of people - some of them very competent artists or writers - will try on their own, and if they can't figure out (for example) why they're getting their dialogue stacking up unreadably will simply shrug, say "programming's too hard" and give up. And you'll never see those people on the forum because they're too embarrassed to ask for help on something they presume is so simple, or they presume that if they can't do this, then there'll be lots of other, harder things later that they can't cope with so there's no point trying, or something similar. Not to mention that coming across such a problem very early on and having to wait for someone on the forum to bother to answer it will risk them just losing interest in the whole VN idea while they're waiting for an answer, before they've made enough progress to have some project momentum going.

Re: Default Backgrounds

Posted: Sun May 02, 2010 1:50 pm
by Wintermoon
At least one highly acclaimed visual novel intentionally uses a letterbox effect, that visual novel being Narcissu. And I have to say, I really like that visual effect.

There are two ways Ren'Py can be used:
1. Opaque full-size background picture.
2. Letter-boxed full-size background picture or black background.

The current behavior has optimal performance for case 1, but extra work for the user and suboptimal performance in case 2.

Always blanking the screen has suboptimal performance in case 1 and fails to improve the performance of case 2, but eliminates the extra work for the user. I consider that a net win over the current situation. Correctness and predictability over performance.

Auto-letterboxing has optimal performance in case 1, optimal performance in case 2, and no extra work for the user. It is clearly strictly superior to both other approaches.

Re: Default Backgrounds

Posted: Sun May 02, 2010 2:40 pm
by PyTom
Apart from the performance reasons - which I might be able to fix - the reason why I'm so opposed to putting a black background on the display is that I personally find an image bordered on three sides by black to be a quite ugly and off-putting thing, to the point where I don't think that anyone should release a game like that. At the same time, it's close enough to acceptable that I can see some people actually choosing to release a game like that, which is something that I wish to discourage, at least without them explicitly deciding that is what they want.

At the same time, I have to admit that the current situation is hard to diagnose.

I'm currently leaning towards putting up a grid pattern, like the one that's used in Photoshop and Gimp to indicate alpha transparency, when config.developer == True. I think that this communicates fairly well what the real problem is - portions of the background are transparent or undefined. It's then up to the game-maker to decide what the right way of resolving this issue is.

A nice benefit of this is that it doesn't push the user in any one direction. The best solution is (usually) to scale the image up, while putting borders around the image is another solution. I like it because we're not guessing what the user wants.

... Implement ... Implement ...

Here's an example of the first thing people will see when they create a new game in the current development version of Ren'Py.
'Py Game.png
Say we add an image that's too small for the screen. Here's what we get:
'Py Game-1.png
I think this is for the best. We're not guessing what the user wants, and we're conveying using a standard technique why Ren'Py is displaying the image as it is.

Re: Default Backgrounds

Posted: Sun May 02, 2010 11:19 pm
by Wintermoon
Do you really dislike the visual style of Narcissu that much? Because I much prefer it over the traditional NVL presentation. Text should not cover the picture. A semi-transparent text box over the picture is even worse.

A checkerboard pattern is predictable and easy to understand. However, it doesn't remove the need for an explicit black layer. It is therefore a great improvement over the current situation, but still not quite optimal.

Re: Default Backgrounds

Posted: Mon May 03, 2010 1:00 am
by PyTom
Wintermoon wrote:Do you really dislike the visual style of Narcissu that much? Because I much prefer it over the traditional NVL presentation. Text should not cover the picture. A semi-transparent text box over the picture is even worse.
I don't mind it, although I consider it a bit minimalistic, and often a substitute for fullscreen art. But if you simply show a picture without a position, you don't get Narcissu. In Ren'Py, by default, images are placed at the bottom-center of the screen. Even if you were to place a black background behind the image, you'll wind up with an image like the one I have above, except with black borders rather than the checkerboard pattern. I don't think having the image placed at the bottom of the screen is ideal, but anything else would require explicit positioning.
A checkerboard pattern is predictable and easy to understand. However, it doesn't remove the need for an explicit black layer. It is therefore a great improvement over the current situation, but still not quite optimal.
It's always been easy to have a black layer. For something like Narcissu:

Code: Select all

# Declare a background layer we can set to all black.
init python:
    config.layers.insert(0, 'background')

# Declare the background image. There are a few ways to give the necessary position, this is using ATL.
image bg beach:
    "beach.jpg", ypos 150

label start:
    # This needs to be done once per game.
    scene black onlayer background
   
    # Now show the background. 
    scene bg beach
We can't do it automatically, because we need the positioning information as to where to place the various pictures. Also, while I don't mind Narcissu, its style is one of many, and It's not my favorite. (In general, I prefer the ADV style - mostly because ADV games are usually the most fun and least pretentious.)

Re: Default Backgrounds

Posted: Mon May 03, 2010 2:10 am
by Wintermoon
PyTom wrote:It's always been easy to have a black layer.
Easy for you and me, but maybe a bit less easy for a non-programmer looking at Ren'Py for the first time.

Also, correct me if I'm wrong, but I don't think Ren'Py currently performs the optimization that Jake suggested earlier of only drawing a black border around the background image instead of blanking the whole screen. It's certainly possible to perform this optimization with an explicit black layer, but maybe a bit more difficult. (Also, as I have pointed out earlier, probably unnecessary. Filling the screen with black is a fairly fast operation.)

All of the above is really just the perfectionist in me speaking. A checkerboard pattern fixes the most important problem, which is the current undefined behavior.

Re: Default Backgrounds

Posted: Mon May 03, 2010 3:56 am
by Jake
Wintermoon wrote:A checkerboard pattern fixes the most important problem, which is the current undefined behavior.
Agreed - it's not what I'd have preferred myself, but it should definitely be more understandable for newbie users, which is the important thing.