Ren'Py Development Thread

[PyTom]

I think one of the big advantages to Ren'Py is that it runs everywhere, with no dependencies beyond the OS. I'm loathe to give that up, and I'm not sure it's worth it, for features that probably won't be used very often by games.

Novelty's release kinda spooked me, with the number of people who had to post on the forum to ask about how to get the game working. And people who are working with a pre-release game engine are probably more sophisticated than the average user. So I decided to cut back on plans for more advanced features that could risk compatibility.

There was also the sense with OpenGL that I could:

- Use 1.x and , which is relatively widely supported, and spend my time fighting to make some of Ren'Py's primitives work everywhere.
- Use 2.x and fragment shaders, and have games not work on a lot of hardware.

The fact that OpenGL 3.0 deprecates 1.x kinda turned me off to the whole thing, since it means I won't be able able to write games that run on 1.x and some future version of OpenGL. So I'll stick with software rendering... which looks like it will be the future of computers after all, albeit on many-core processors.

[delta]

Well, it's your choice, but you should be willing to live with the fact that Ren'Py's performance is less than stellar. Yes, it's easily enough for the "one dissolve every three pages of text" the stock engine suggests, fast enough for most people not to notice, but it's by no means hard to get framerate drops even on a 2GHz+ dual core if you let fly with a couple of the more complicated effects stacked. I find that pretty lame for late 2008 when you realize that you're still doing only a couple of bitmap blitting operations.

So, how hard would it be to implement, for example, blur in Ren'Py, and would the performance be acceptable?

[PyTom]

I'm hoping the config.framerate will deal with framerate drops.

Assuming we can live with a rectangular blur, I should be able to write an incremental version and get quite good performance. (Linear in the size of the surface, and only a couple of operations per pixel.) I'm not going to try to deal with gaussian kernels, but gaussian kernels are something I believe would be difficult to do in opengl.

Actually, the first academic paper I was ever involved with had an algorithm for doing such a blur. Small universe.

[jack_norton]

Hmm I noticed slowdowns only on the mac, and when a music was playing. Beside that I don't think is particularly slow. Anyway if the GL renderer was an extra option (like a choice on startup, or a config flag), surely would be welcome. But replacing the software one? no way thanks

[000]

I just saw ooo working hard on a russian version - how's he doing it? (Don't know if he's reading this thread ).

(I do. Just not really on consistent basis.)
I wouldn't call it "hard work" as only things I do is whine here about somethings stopped working copy my config.translation lists where they needed, copy template, TheQuestion and Demo files what are not changed, replace on per-line basis text in changed Demo script files, archieve now-localized distributive and upload it on my page. This way end-user does not need to download a separate patches and do additional work to have a localized version (s)he desires.
PyTom was kind enough to give me a permission to use a corner of http://www.renpy.org/ for a quick'n'dirty Russian Page and host the localized distributives, so I place my works there.

And, just to note, my nickname consists of zeroes, not 'o's.

The problem with esub/esubtitle is that the SFont used doesn't contain an umlaut in its character set. (This code has somewhat changed in 6.8.0.)

Does that mean it would be able to show russan text normally then?

[Cato]

archieve now-localized distributive and upload it on my page. This way end-user does not need to download a separate patches and do additional work to have a localized version (s)he desires.

I was just about to ask this.
For convenience's sake, would you (@PyTom) mind if I were to offer prepacked Versions on my site?
However, I do see the necessity for these stand-alone patch-sets, as they make it more transparent what the translators are doing and impatient people can apply them themselves if the packagers are lagging behind. So I'll definitly try to provide the patch-sets on a regular base.

Does that mean it would be able to show russan text normally then?

From my understanding, "no" for both of us. It seems that SFont itself does only support the Ascii-Characters 33-127, so there's probably not much one can do about that.
It would be nice to have a fallback-solution instead of the program crashing, though.

[Counter Arts]

I do remember that Direct X9 truetype font support doesn't work for some old intel integrated graphics cards. Why? Intel doesn't feel like updating them.

So yeah... one example of pain.

[PyTom]

Cato, I don't mind you offering prepacked versions on your site, provided you link back to renpy.org as well.

Ren'Py does implement an extension to sfont. The renpy.register_sfont function takes a charset parameter, that gives the characters in the font. So if people want ü or д or even n̈, you can add that in.

[Aenakume]

GL Ren'Py isn't a huge priority at the moment, as I'm a bit worried that some peoples' computers still won't be able to run it. I'm not currently convinced that the benefits outweigh the risks of it.

Depends, if you just surface acellerate the existing feature set, the benefits would be negligible, but if you add things like shear, skew, pinch, ripple or blur on bitmaps it's more than worth it. Then again, you could just do those things in software as well.

You don't need OpenGL or any kind of hardware acceleration for any of this. Even a software renderer could do them in real time on a low-end computer without that big a slowdown. If you think about it, programs like Gimp and Photoshop don't do this in hardware, and they don't use "cheat" algorithms (basically algorithms that fudge things so they sorta-kinda look right, but aren't really - if you're gonna transform an image in real-time, you don't need an exact transform like they use), and they're pretty fast.

i've been experimenting with this kind of stuff off-and-on in RenPy (right now, off, because i'm workin on the walkabout engine, and even that i'm takin a little break from). For reasons i don't quite understand, it's very slow to do per-pixel math on the pixel data from a surface. Like... mind-numbingly slow. Python code is compiled, not interpreted, so it shouldn't be... so i haven't figured it out yet, but i am lookin into it. Or at least, i will be. Eventually.

i'm doing nothing about this now, waiting on when i start toying with config.framerate to see if that helps things (and concentrating on the walkabout engine, too). But eventually i'll focus on this again. There are two prongs i want to attack this on: a non-realtime(ish) static image version - basically another one of the im.* functions that transforms an image immediately and just stores it ready until display time - and a realtime dynamic version that transforms the internal render surface on each render call - so you can even have blurred/skewed/rotated animations. Just how much will be possible, it's too early to say.

For the record, even if i can't figure out a way to do this fast enough in pure Python, all is not lost. In the absolute worst case, i'd write a shared library in C or C++ that the RenPy engine can use just for the hardcore number crunching (portability won't be an issue, because it's just math - compiling three different versions for LinWinMac is no big deal). i hope it won't come to that, but... if it really can't be made fast enough in Python, i think that's a better option than goin OpenGL.

Anyway, the moral of the story is that you don't need to give up on these kinds of image manipulations just because RenPy doesn't (and probly won't) support OpenGL hardware acceleration.

[PyTom]

You don't need OpenGL or any kind of hardware acceleration for any of this. Even a software renderer could do them in real time on a low-end computer without that big a slowdown. If you think about it, programs like Gimp and Photoshop don't do this in hardware, and they don't use "cheat" algorithms (basically algorithms that fudge things so they sorta-kinda look right, but aren't really - if you're gonna transform an image in real-time, you don't need an exact transform like they use), and they're pretty fast.

There's fast, and then there's fast. I mean, say we want to process an 800x600 image at 60 frames per second. That means we need to process 800 * 600 * 60 pixels per second. 28 million pixels per second. If a pixel has 4 channels (RGBA), then that's 115 million pixels-channels per second. If we assume a processor can do 1.5 gigaops/s, that's only 13 ops per pixel-channel per frame. Not many, when you realize there may be other things going on eating into that. (MMX helps a lot, doing 4 ops in parallel.)

On Ren'Py, I try to divide operations into two kinds: Stuff like you describe above is fast enough for image manipulators, which can take a quarter-second or so. But realtime stuff needs to take less than 10ms, which isn't very long at all.

Python code is compiled, not interpreted, so it shouldn't be... so i haven't figured it out yet, but i am lookin into it. Or at least, i will be. Eventually.

Python code is interpreted bytecode.

[Aenakume]

You don't need OpenGL or any kind of hardware acceleration for any of this. Even a software renderer could do them in real time on a low-end computer without that big a slowdown. If you think about it, programs like Gimp and Photoshop don't do this in hardware, and they don't use "cheat" algorithms (basically algorithms that fudge things so they sorta-kinda look right, but aren't really - if you're gonna transform an image in real-time, you don't need an exact transform like they use), and they're pretty fast.

There's fast, and then there's fast. I mean, say we want to process an 800x600 image at 60 frames per second. That means we need to process 800 * 600 * 60 pixels per second. 28 million pixels per second. If a pixel has 4 channels (RGBA), then that's 115 million pixels-channels per second. If we assume a processor can do 1.5 gigaops/s, that's only 13 ops per pixel-channel per frame. Not many, when you realize there may be other things going on eating into that. (MMX helps a lot, doing 4 ops in parallel.)

On Ren'Py, I try to divide operations into two kinds: Stuff like you describe above is fast enough for image manipulators, which can take a quarter-second or so. But realtime stuff needs to take less than 10ms, which isn't very long at all.

Well if you're going to want to transform the whole screen... every frame... ya, i'd expect you to really make your processor smoke. ^_^; But as you point out, even that is possible... if not particularly smooth (your frame rate would probly drop to single digits).

But transforming elements like sprites, which are significantly smaller, means much, much less work. Eileen is 266 * 600 for example, so if you want to process her in real time at 60 fps, that's 9.6 million pixels per second - and with 4 channels that's 38 million components per second, or about a third of the work as a full screen transform... and Eileen's still pretty big, more than 25% of a full frame.

Of course, there are a lot of other factors to take into account... like whether or not 60 fps is a worthwhile target when you're doin those kinds of large-scale transforms. If the frame rate drops to a quarter of that during a massive transform, but the transform is smooth (which it would be naturally with interpolation), who cares? ^_^; Will it still look good? It might. i'll have to try it and see. A full-screen transform at 60 fps might not even be a sensible upper limit - maybe a full screen transform at 30 fps is more reasonable.

Python code is compiled, not interpreted, so it shouldn't be... so i haven't figured it out yet, but i am lookin into it. Or at least, i will be. Eventually.

Python code is interpreted bytecode.

Well, shit, that explains that.

Eh, no big deal. There are still a ton of things i have to look into with this. Like how much power i can leverage from pygame and if it's worth it, etc. If it has to come down to extension shared libraries (using stuff like sse2 - mmx only if necessary, i suppose), then so be it.

But this is not something i'm workin on now. But if people are interested, i might make a project page on the wiki so that we can all share info.

[DaFool]

It's alright even if you start to impose size limits on the sprites that can be image-manipulated in real-time. I definitely do not want a repeat of the early versions of the tile engine -- things must be playable, if not at 60fps, than 30 or even 20. These posts are actually reminding me of some Japanese doujins that are 2D but still lag in framerate compared to 3D. Ah, the price paid for not using DirectX.

[Adorya]

If you think about it, programs like Gimp and Photoshop don't do this in hardware, and they don't use "cheat" algorithms (basically algorithms that fudge things so they sorta-kinda look right, but aren't really - if you're gonna transform an image in real-time, you don't need an exact transform like they use), and they're pretty fast.

Kinda sad but next version of Photoshop will need hardware acceleration, something like at least nvidia 8 series

[delta]

If you think about it, programs like Gimp and Photoshop don't do this in hardware, and they don't use "cheat" algorithms (basically algorithms that fudge things so they sorta-kinda look right, but aren't really - if you're gonna transform an image in real-time, you don't need an exact transform like they use), and they're pretty fast.

Kinda sad but next version of Photoshop will need hardware acceleration, something like at least nvidia 8 series

Explain to me how this is not an extremely good thing. If you're running a smart blur over a 5 Megapixel image, you are in for a noticably annoying wait time, while your superpowered graphics coprocessor twiddles its thumbs until you start Crysis again.

[Adorya]

The previous installment only needed cpu and lot of rams, now you will need a good cpu, a huge amount of rams and a big video card.

Oh, and sorry for not using Vista which need at least an nvidia 7 series for uber-mimic-mac-desktop-effects, and sorry for not playing 3d cards demo "game" like Crysis. Sorry for not working with a triple vertical 30'' screen, a glowing congratulated cooler and a computer that do 1 petaflop/s