Ren'Py Development Thread

[PyTom]

Here's a thread where I will post ongoing discussion about changes in Ren'Py that will be showing up in future versions, so I can get feedback from people.

Today I implemented some support for widescreen computers and games. This was done by changing the "Display" preference to have four options:

- Window
- Fullscreen (4:3)
- Fullscreen (16:9)
- Fullscreen (16:10)

Choosing one of the fullscreen options will display the game in a fullscreen window having that aspect ratio. If necessary, black bars will be placed around the window to enforce the aspect ratio, ensuring that the game looks correct on a widescreen monitor.

[Jake]

Today I implemented some support for widescreen computers and games.

Well, if you really want feedback, I have mixed feelings about this.

On one hand, it's great news - I've had to play more or less all non-professional games in windowed mode since getting my new PC, 'cause having everything stretched out across a 16:9 monitor is quite bad. Especially for the 2D curtain-fire shooters I spend a lot of my gaming time on. So I certainly appreciate someone taking the time to 'fix' this problem! (Theoretically my graphics card drivers should do it, but I get the idea SDL in particular tries to be clever in this respect. I've only seen it working with DirectX programs.)

On the other hand, it just reminds me that I still haven't fixed up fullscreen mode in my own project.

[monele]

Sounds good . A lot of people already have problems with this, and I'm sure it'll get worse as time goes by.

[PyTom]

One thing that's still kind of bugging me is the names of the buttons. A problem is that "Fullscreen (16:10)" displays a 4:3 image, letterboxed to fill a 16:10 area. It doesn't display a fullscreen 16:10 image, which is what some people might expect.

One constraint is that I don't want to make the preferences buttons much bigger (I already had to expand them a bit to fit 16:10 in there.)

One idea might be to use Fullscreen for the native resolution, and Letterbox for additional resolutions. So for an 800x600 game, we'd have:

Display
- Window
- Fullscreen (4:3)
- Letterbox (16:9)
- Letterbox (16:10)

And for a 16:10 widescreen game (say, 960x600) we would have:

- Window
- Letterbox (4:3)
- Letterbox (16:9)
- Fullscreen (16:10)

I'm also wondering if we can live without 16:9. As best as I can tell, the majority of monitors are 16:10. And I'm not sure the distortion will be worse than what I get when I run a 4:3 game on my 1280x1024 (5:4) monitor.

[Jake]

One idea might be to use Fullscreen for the native resolution, and Letterbox for additional resolutions.

Sounds reasonable to me.

I'm also wondering if we can live without 16:9. As best as I can tell, the majority of monitors are 16:10. And I'm not sure the distortion will be worse than what I get when I run a 4:3 game on my 1280x1024 (5:4) monitor.

Well, on one hand, while most widescreen monitors (1680x1050) are 16:10, most widescreen TVs are 16:9. And since DVI can be hard-connected to HDMI, with the increase in proliferation of flatpanel digital-connector TVs, I'd expect an increase in people outputting a computer's video to a TV. I know at least one guy who uses a 38" LCD TV for a computer monitor...

On the other hand, I expect you're right, and the distortion won't be noticable anyway. I certainly didn't have any real problem with my old 5:4 monitor running 4:3 fullscreen stretched, and really - if you're going to notice issues, you're going to notice issues with 2d curtain-fire shooters.

On the third hand, each VN has a native aspect, why not bypass the whole issue by detecting the native resolution of the screen, discovering whether it's the same or not as the aspect of the VN, and present just three buttons - one of which is 'Windowed', one 'Fullscreen (stretched)', and the other one of 'Fullscreen', 'Fullscreen (letterboxed)' or 'Fullscreen (sidebars)' depending on the native res. of the display device?

[monele]

I like the difference between Fullscreen and Letterbox. I didn't understand it would become buttons in the Preferences screen though, but that's better than my idea (some config variable) ^^

[delta]

On the third hand, each VN has a native aspect, why not bypass the whole issue by detecting the native resolution of the screen, discovering whether it's the same or not as the aspect of the VN, and present just three buttons - one of which is 'Windowed', one 'Fullscreen (stretched)', and the other one of 'Fullscreen', 'Fullscreen (letterboxed)' or 'Fullscreen (sidebars)' depending on the native res. of the display device?

Only reasonable way to do it, in my opinion. If it's possible, that is. I would also disable the "Stretch" option in my game (leaving only window and a correct aspect ratio fullscreen option), but that's just me. The correct term for the vertical equivalent of a letterbox is "pillarbox", by the way.

P.S. D'oh. It makes no sense to detect the "native" resolution of the display, mostly because CRT monitors don't have one. The best way would be to detect and use the resolution the OS runs at. Yes, users might configure that wrong, but then it's really their own fault.

[PyTom]

The problem with this is that I don't have a good way of detecting what resolution the user's screen is running at. For example, on my computer, I get:

Code: Select all

In [1]: import pygame

In [2]: pygame.display.init()

In [3]: pygame.display.list_modes()
Out[3]: [(2560, 1024), (1024, 768), (800, 600), (640, 480)]

The first one is absurd, since it's the resolution of two monitors running at 1280x1024. The rest of them are wrong, since they're not the 5:4 aspect ratio of my main display.

So I think having the user specify the aspect ratio by hand is the best way to go. I've been playing some of the orange box games (I've beaten Portal, and Half-Life 2, and am in the middle of Episode One), and that's the solution they use.

[DaFool]

Um, my game is set already to 800 x 450.

I use 16:9 and not 16:10 because I draw originally for 720p HD resolution.

How will this affect my game? (Do I need to set black bars permanently?)

[PyTom]

With the new one, not much. It will automatically add the black bars necessary for fullscreen mode.

[PyTom]

Okay, now to talk about the next big change to Ren'Py, which I want to hash out in public before implementing it in the code. This will probably be the highlight of the next release, and I think important as we move forward. What I plan to do is to:

- Modify the style hierarchy.
- Define what themes and layouts are.
- Implement backwards compatible themes and layouts.
- Create at least 1 new theme.
- Create at least 1 new layout.

Let me first begin by reaffirming my commitment to backwards compatibility. If a game has config.script_versions set to (6, 5, 0) or less, a backwards compatibility mode will kick in that makes Ren'Py 100% identical with today's version. I will also include a way of enabling this backwards compatibility mode, so that people with games in development will not have to re-theme their games.

Note, however, that new features may not be supported in the backwards compatibility mode.

The style hierarchy is the list of which style inherits from which. While not terribly broken right now, there are a few changes I'd like to make. A big one is that I'd like to be sure that all labels inherit from a base label class. I'd also like to make this like button, where you have kind_label and kind_label_text.

The reason for this is that I'd like labels to be a special type of window, with text contained inside the window. Making labels a type of window (but note, not inheriting from the window or frame styles) will give us a lot more control over label styles. We can easily add margins to each label, or add background/foreground images.

I'd also like the style hierarchy to have a few well-defined roots that everything inherits from. Right now, I'm looking at:

style.frame - Frames (out-of-game windows containing buttons/etc of the other styles).

style.button/style.button_text - Average buttons, generally used for navigation or other activities requiring buttons.

style.small_button/style.small_button_text - A smaller-than-average button, also used for navigation. While style.button may have a minimum width, this should be made as small as possible.

style.radio_button/style.radio_button_text - These should be used for groups of related buttons that do not cause navigation to occur. For example, groups of preferences should be radio_buttons.

style.check_button/style.check_button_text - This should be used for a single button that may be selected or not. (For example, and alternate view of preferences.)

style.large_button - The style of a large button that may contain arbitrary information (such as a file picker entry.

style.label/style.label_text - These are labels indicating where the user is.

style.bar/style.vbar - These are bars/sliders that indicate values and optionally allow the user to change their value. (horizontal and vertical)

style.scrollbar/style.vscrollbar - These are bars/sliders that allow the user to scroll around. (horizontal and vertical)

style.prompt/style.prompt_text - The style of text that prompts the user to do something. This is treated as a big label, but doesn't inherit from label because we may want to render it differently.

style.text - The style of other text displayed by the interface. (This might be used inside the style inspector, for example.)

A quick count of this shows that this makes up 18 styles, with about half of them being the different variants of button and button_text. (In the current roundrect design, many of these variants are identical, or at least are trivial variations of one another.)


So the question is now: what is a theme, and what is a layout? Right now, the two are fairly conflated, which makes answering that question hard. In 6.6, we'll be breaking them apart.

A theme is responsible for controlling the look of the various displayables. It does this by setting appropriate values for those 18 styles given above. Themes should generally leave styles other than these 18 alone. Themes are responsible for setting the minimum size of the various styled displayables, and the look, and that's about it.

Layouts control how these styled displayables are placed into the main and game menus. Layout functions are responsible for the organization of the various screens, as well as the maximum size and spacing of displayables.

There will probably be several kinds of layout functions, classified by what they do. For example, a main_menu layout function will be responsible for supplying a main menu. A navigation layout function will be responsible for supplying the game menu navigation box. A load_save layout function supplies the load save screen, a preferences function supplies the preferences screen and so on.

You'll be able to mix and match the various functions to customize how your menus look. Some variants I'm considering are a load/save screen with a big preview image, and check-button based preferences. To implement this, one might write:

Code: Select all

init -1 python:
    config.screen_width = 800
    config.screen_height = 600

    layout.classic_main_menu()
    layout.classic_navigation()
    layout.big_preview_loadsave()
    layout.checkbox_preferences()
    theme.roundrect()

The layout calls needs to be placed before the theme call. If one of the kinds of layout functions is not called, the classic variant will be called when the theme is specified. So the above code could be written as:

Code: Select all

init -1 python:
    config.screen_width = 800
    config.screen_height = 600

    layout.big_preview_loadsave()
    layout.checkbox_preferences()
    theme.roundrect()

If we wanted to simply use the classic layouts everywhere, you could just write:

Code: Select all

init -1 python:
    config.screen_width = 800
    config.screen_height = 600

    theme.roundrect()

which is exactly what we have today.

Of course, people will be able to contribute their own themes and layout functions, provided they conform to certain standards. And (depending on the layouts used) you will still be able to style the displayables.

Anyway, I'm curious what people think of these plans.

[Jake]

Hmm.

I'm not entirely convinced by the nomenclature - probably because the programming world I'm used to uses the term 'layout' usually to mean the kind of 'layout manager' concept exemplified by Ren'Py's "Multiple-Child Widgets" like ui.hbox. If anything, I'd expect the 'layout' namespace to contain things like that, rather than screen layouts.

Not that it's not a good name, I guess I'd just expect that name to mean something else. I suppose it depends who you're aiming it at as much as anything.


I certainly like the idea of having themes and layouts separated - even leaving aside that they're conceptually different things anyway, the fact that there's so much to do currently is one of the daunting parts about creating new themes. I know I could much more readily knock up a few graphics and colour schemes than set up everything that could possibly be considered a theme, and even then that 'everything' doesn't seem to be particularly clearly-defined.

One question, and one suggestion, then.

The question: when you talk about layouts modifying the existing screen designs, would this include things like the effects that introduce those screens, a la Ori, Ochi, Onoe's rotating-in main menu, or Tying Threads' fading-in buttons? I can't see it being under the purview of themes, but it'd certainly be nice to be able to introduce that kind of thing as a discrete module. Of course, I don't know how those examples are done currently, but I kind of suspect custom dynamic displayables. Will these layout functions [be able to] alter the components of each screen, or just reposition and resize the components which are already defined?

Suggestion-wise: from the point of view of making it easier for theme developers, I'd suggest a restructuring of the roundrect theme's (or the default's) code. Of course, for all I know you're doing this already. Currently, RoundRect just seems to consist of a function which runs through and defines all the various style properties one after another, which is a little daunting to look at. At the very least, some comments as to exactly what each set of things applies to and where they go would be useful. What would be particularly nice, though, would be to be able to create some object and set properties for the frame, button etc. graphics, and a couple of colours for a scheme, and have the rest of the work rely on defaults. It obviously wouldn't cater for every single case, but it'd be convinient to be able to just set up two or three colours (a bit like the red alternate roundrect does, for example), a couple of graphics and spacings, and have the theme code work the rest out and come up with sensible-ish defaults.

RoundRect already does half of that, but doesn't make it accessible to the outside, just people willing to copy/paste chunks of its code. I'd consider doing something like this myself if I ever wanted to design a theme, and I'd happily donate code, but unfortunately right now my time is taken by two or three other projects...

[PyTom]

I'm not entirely convinced by the nomenclature - probably because the programming world I'm used to uses the term 'layout' usually to mean the kind of 'layout manager' concept exemplified by Ren'Py's "Multiple-Child Widgets" like ui.hbox. If anything, I'd expect the 'layout' namespace to contain things like that, rather than screen layouts.

Not that it's not a good name, I guess I'd just expect that name to mean something else. I suppose it depends who you're aiming it at as much as anything.

You make some good points. Maybe "design" is a better name for this? I'd appreciate any suggestions people have... it's easy to change this before 6.6 comes out, and after that it will be very hard.

The question: when you talk about layouts modifying the existing screen designs, would this include things like the effects that introduce those screens, a la Ori, Ochi, Onoe's rotating-in main menu, or Tying Threads' fading-in buttons? I can't see it being under the purview of themes, but it'd certainly be nice to be able to introduce that kind of thing as a discrete module. Of course, I don't know how those examples are done currently, but I kind of suspect custom dynamic displayables. Will these layout functions [be able to] alter the components of each screen, or just reposition and resize the components which are already defined?

The O3 effect was done in 2 parts:

1) We set things up so that each button was placed independently on the screen.
2) We used (the equivalent of, since it didn't exist yet) a MoveTransition to actually revolve the buttons around.

Layouts (or designs) will be able to do 1, while 2 can be done with the various config.*_transition variables.

Suggestion-wise: from the point of view of making it easier for theme developers, I'd suggest a restructuring of the roundrect theme's (or the default's) code.

That's a good idea, I'll keep it in mind while rewriting.

[monele]

I like "layout" myself ^^;... But I'm no native speaker so...

For the rest, I'm having a hard time grasping what it will change in the end. I'd have to try it out to be sure it's user-friendly. But I'm sure the separation of look & position is a good thing, especially for the sharing of themes.

I keep thinking that what people need is more of a visual help while modifying styles. It's hard for most people to make a link between some code and what it'll end up being on the screen (with all the padding, margin, min/max sizes, etc...). Sadly, I don't think it'd be easy to provide even just a simple inline style editor.
One thing that might be possible, though, is to have Ren'Py display a chart of all the basic interfaces and widgets. Wether this is an RPY script or an actual Ren'Py feature (like all the Shift+ key shortcuts), I think it would help to see what *every* parts of the interface look like after modifying the style code. Plus, such charts could be published along with theme scripts and ensure that nothing has been forgotten.

[Jake]

Maybe "design" is a better name for this? I'd appreciate any suggestions people have... it's easy to change this before 6.6 comes out, and after that it will be very hard.

I'm not sure I really have any better suggestions, myself - I'm terrible about naming classes, I'll sometimes waste thirty minutes of coding time trying to think of a good name for something, and I'm not even writing stuff other people are that likely to use!

"Layout" is certainly a reasonable name for it in isolation, I only find it a bit confusing 'cause I'm used to that word applying to a different concept. That said, 'Design' doesn't sound bad.

One thing that might be possible, though, is to have Ren'Py display a chart of all the basic interfaces and widgets. Wether this is an RPY script or an actual Ren'Py feature (like all the Shift+ key shortcuts), I think it would help to see what *every* parts of the interface look like after modifying the style code. Plus, such charts could be published along with theme scripts and ensure that nothing has been forgotten.

Mmm. Perhaps even some kind of lint for themes? Instead of telling you how many lines of dialogue you've got, it could tell you what percentage of styles your theme overrides and give you a list of the ones you're leaving at the defaults just in case it was accidental?