Ren'Py Development Thread

[jack_norton]

Well you should leave both options, fullscreen with / without borders, so user can select what he wants. The default one should be the 1st (as it is now). User would use the one with borders only in the case his widescreen monitor doesn't detect/support a 4:3 display for fullscreen (mine does but seems to work randomly lol).

About RenpyGL, a very important thing: leave both renderers in the engine (software/GL), because there are still TONs of problems using GL on PCs. In my C engine I was using only openGL for both Pc/Mac, but the day I added DX, game sales increased by 30% so unfortunately on Pc will probably better default the game in software (if you don't plan to use DX).

[Aenakume]

About RenpyGL, a very important thing: leave both renderers in the engine (software/GL), because there are still TONs of problems using GL on PCs. In my C engine I was using only openGL for both Pc/Mac, but the day I added DX, game sales increased by 30% so unfortunately on Pc will probably better default the game in software (if you don't plan to use DX).

Shouldn't this be something handled by SDL and not Ren'Py? Doesn't SDL come with an OpenGL software renderer? If so, Ren'Py games can just select with a switch whether to use the software renderer or hardware (if available).

i do agree that the default should be software, though.

[PyTom]

SDL will use the windows software renderer. The problem is, the techniques you use for software rendering are a bit different than what you use for hardware rendering. So GLRen'Py + Hardware Rendering == Slow.

I'm sort of hoping that in a year or so, computers will have advanced to the point where OpenGL is reliably available. (Or someone releases a Direct3D-based pygame.)

[Hentai Senshi]

Shouldn't this be something handled by SDL and not Ren'Py? Doesn't SDL come with an OpenGL software renderer? If so, Ren'Py games can just select with a switch whether to use the software renderer or hardware (if available).

i do agree that the default should be software, though.

The times I've encountered OpenGL software rendering, performance has been abysmal - while I'm sure 2D software OpenGL can be optimized more readily than 3D,
I suspect software OpenGL will still be slower than just plain software rendering.

[PyTom]

The annoying thing about OpenGL is there's no way to just ask it "Hey, OpenGL? What are you fast at?"

I have to say that it really sucks that there's not a hardware acceleration API that is:

1) Fast.
2) Cross-platform.
3) Well-supported.

I'll have to see how fast my new subpixel blitter will be. I suspect it will be okay on MMX computers, but I'm seriously considering disabling the functionality on PowerPCs and other non-intel platforms.
(They'll just support the current, relatively jerky, movements.)

Oh, and my life would be a lot better if a computer's MMX unit had a few more registers.

[Hentai Senshi]

Well, it seems to be not particularly difficult to get the framerate for GL - so one could do a handful of GL ops on the presplash, maybe, time them, and if they take too long automatically fallback to software rendering?

Also, on video modes

SDL gives us a limited pool of modes it can switch to. On my laptop, these are:

1680x1050 - 16:10
1440x900 - 16:10
1280x1024 - 5:4
1280x800 - 16:10
1280x720 - 16:9
1024x768 - 4:3
800x600 - 4:3
720x480 - 15:10
640x480 - 4:3

And a bunch of uselessly small modes.
Hm... how about this algorithm?

(1) Find the largest mode with a reasonable aspect ratio. In this case, "reasonable" is defined as less than 20:10 . Anything larger than that is probably a mode that spans multiple monitors.

(2) Find the smallest video mode matching that aspect ratio that is larger than the screen size of the game.

(3) Display the game centered with black borders.

(4) If we can't accomplish (2), display the game in windowed mode.


So if we have a 1024x768 game on my laptop, it will pick the 1280x800 mode and display the game centered inside that mode. An 800x600 game will also use that same mode, unfortunately, as there aren't any smaller widescreen modes to display at.

Annoyingly, this prevents me from using my nvidia card's aspect scaling mode, which can properly bring 800x600 up to fullscreen.

I'd expect LCD screens to usually display things badly at non-native resolutions regardless of whether or not the aspect ratio is preserved - I'd rather have Windowed/Fullscreen/Letterbox, where 'Fullscreen' is the smallest resolution that the game will fit on, with black bars if needed, and 'Letterbox' is the default (as set by the user, where available), resolution of the screen if the game will fit on it; otherwise, try higher resolutions until you find one that fits, with any necessary black bars added. With an 'Advanced' button as well, to permit users to manually force their preferred video mode if they feel like it, and possibly toggle things like software scaling.

[PyTom]

It's been my experience that while older LCDs/video cards behaved poorly when it came to scaling, modern LCD and video cards are actually quite good at it, doing a bilinear interpolation that looks fairly reasonable.

The big problem is that some video cards (ATI) don't support an aspect-preserving scaling mode, and AFAIK nobody is sane enough to enable this mode by default.

I'll note that none of the recent Japanese games I've played even try to deal with this problem. For example, Princess Waltz shows this aspect ratio problem on my box.

I'm really not sure what the solution is. Showing an 800x600 game on a 1280x800 screen isn't really fullscreen in a meaningful sense... a full 53% of the pixels are left blank. (Compared to 16% in a 960*600 letterboxed version.) But the possible screen resolutions we can use are fixed by the video card and monitor....

Code: Select all

                    ### 
                 #########
               ############     #### 
               #############   #######
              ####       ####   ###### 
              ###         ###        ##
               ##         ##         ##
               ##        ###        ###
                ###     ###       #### 
               #######################
              ###################### 
              #####################
              ###
              # 
               
                    ### 
                 #########
               ############     #### 
               #############   #######
              ####       ####   ###### 
              ###         ###        ##
               ##         ##         ##
               ##        ###        ###
                ###     ###       #### 
               #######################
              ###################### 
              #####################
              ###
              # 
               
                    ### 
                 #########
               ############     #### 
               #############   #######
              ####       ####   ###### 
              ###         ###        ##
               ##         ##         ##
               ##        ###        ###
                ###     ###       #### 
               #######################
              ###################### 
              #####################
              ###
              # 
               
              ##                     ##
              #########################
              #########################
              #########################
              #########################
              ##                ###
                                 ### 
                                  ### 
                                   ### 
                                #######
                              #########
                              ######## 
                              ########
                                ### 

      ####                 ##### 
    #########            ##########
  ###       #######    ############# 
 ###         #######  ############### 
 ###         ##############      ##### 
 ##         ######   ##             ###
 ##        ######    ##              ##
 ##        ######    ##              ##
 ###      ######     ###           ####
 ####     #####      ######      ##### 
  #############        ############## 
   ###########          ############ #  # 
     #######             #########   ##### 
                                      #### 
                                        # 
              ##                                      # 
              ######################################### 
              ######################################### 
              ######################################### 
              ######################################### 
              ##                  ## 
                                   ## 
                                   ### 
                                   ####
                                   ####
              #########################
              ######################## 
              ####################### 
              #####################
              ##


                ###                      #########
               #####          ########################
              ######     ##############################
               #####          ########################
                ###                      #########

[jack_norton]

I have to say that it really sucks that there's not a hardware acceleration API that is:

1) Fast.
2) Cross-platform.
3) Well-supported.

Yes it's hard... you could interface to a C library from python? I use PTK and is very well tested (literally on millions of different pc/mac systems), but at the moment is Pc / Mac only (even if there are the sources, and I know a guy that managed to do an unofficial port to Linux). You could add that on top of your actual software renderer. It uses DX7/DX9 on Pc and GL on Mac.
Don't know, maybe could be worth investigating. If you want to know more, I know personally the programmer behind it

[PyTom]

Keeping Ren'Py open source is relatively important to me, so a commercially licensed renderer isn't something I'd consider.

Edit: Looking into this, I'm really thinking that I'll hold off on a hardware accelerated Ren'Py for a few months and hope the situation improves. SDL 1.3 is eventually going to be released, so that should help some... and there are plenty of other improvements I can make in the meantime.

I still don't know a good way to handle the widescreen monitors. I'm really thinking of ripping out the new widescreen code, as the result (53% black) isn't particularly good.

[jack_norton]

Yes well, I notice slowdown only on the mac which is single core 1.2Ghz (pretty low-end system nowadays), and I use 1024x768 resolution and experience the slowdowns only if there's background music+moving big sprites... so should be fine for standard VN/dating games for now.

About the widescreen probably is better to remove that indeed. I just saw there's an "auto" button on my samsung screen so isn't a problem to see correctly the game, even if looks smaller and has lot of black space on the side.
Widescreen monitors are going to become a standard in few years, based on what I heard from people running the biggest games portals around, so... the problem will be solved automatically soon, and we'll be able to design games specifically for widescreen resolutions

[Jo'ogn]

I notice slowdown only on the mac which is single core 1.2Ghz (pretty low-end system nowadays)

This is when I go "Aaaargh!!!" 1,2GHz 'low end'? "Tokimeki Memorial" and "Metal Gear Solid" run on a Playstation 1: 33Mhz R3000 Risc CPU. Roughly 1MB of graphics RAM, 1,5MB program RAM and 512KB sound buffer...



@PyTom - is it possible to have a right/left panning option for all sound channels (0-7: sound, voice, music). Could be floats from -1.0 (left) to +1.0 (right). Would be nice if it would work as well for mono as stereo files. Perhaps there could also be an auto-pan option: Pan(from_value, to_value, time)

Is the sound driver capable of routing audio to 5.1 channel systems?

[jack_norton]

This is when I go "Aaaargh!!!" 1,2GHz 'low end'? "Tokimeki Memorial" and "Metal Gear Solid" run on a Playstation 1: 33Mhz R3000 Risc CPU. Roughly 1MB of graphics RAM, 1,5MB program RAM and 512KB sound buffer...

Yes but as you said playstation has dedicated chips for audio/video, while renpy does everything software. Also, my game res is 1024x768, while playstation 1 res I think is less than 640x480 ? anyway, sure the performances could be better, but for a simple VN is fine

[DaFool]

Adding to the Playstation comparison... it's an entirely different dynamic. You have full motion 3D games which don't look so bad until you manage to get a screenshot.

Whereas VNs are mostly static and full of prerendered objects so you want the resolution to be the optimum (usually higher) and beautiful.

edit: since it seems to not have been set already, why not announce a future standard resolution for all VN games?

640x480 and 800x600 are running close to the end of their respective eras.

If indeed the future features majority widescreen displays, perhaps we can set the next standard res to 1280x720, which is standard HD. Ideally it would be 1280x800 for 16:10 laptop LCDs, but then what if someone wanted to record their game in HD video? Using 720p would make it much easier. You can 'enforce' this new standard res by releasing future versions of Ren'Py in widescreen resolutions.

The reasoning behind this is sure, it would be GREAT if everyone can play their VN in their resolution of choice, but given constraints, its best to start a standard practice to minimize tech support problems down the line. At least with standard resolutions they will be guaranteed to work well in fullscreen most of the time.

[Jo'ogn]

I chose 1024 over 800 pixel as in fullscreen on my 19" CRT the fonts look smoother in the somewhat higher resolution. I considered HD resolution for the game I now work on, however ppl still seem to run their computers at 1024.

I don't know what a 1280 game looks like on a 1024 screen?

Sometimes I prefer windowed mode over full screen and even on 1600 1280 is too big. On a CRT I do not see much gain switching images and fronts from 1024 to 1280. But 1280x720 HD sounds like a reasonable resolution.

[Counter Arts]

Fullscreen should pick the closest screen size to the stated resolution and black bars the sides and the top and bottom as needed.