Ren'Py 6.10.2 Released

[PyTom]

Ren'Py 6.10.2 is the second stability release of the Ren'Py 6.10 series. It primarily fixes bugs that were reported, found through testing, and detected using static analysis. It also includes few changes and new features that were added to address issues people encountered while making games.

Downloads of 6.10.2 and a full release announcement can be found at:

http://www.renpy.org/wiki/renpy/releases/6.10.2

[Samu-kun]

I knew Afternoon Tea Time stood no chance... =_=

[ksotaku100]

Downloading now....

I will reply shortly...

[mugenjohncel]

>renpy.cache_pin (lol ... green text)
This is it!... The day I've been waiting for so long...

YES!!! YES!!! YES!!! YES!!!... time to test that long awaited feature!...

Imagemaps will someday take over the world... THE WORLD!!!

I knew Afternoon Tea Time stood no chance... =_=

I personally, prefer "Hot Coffee" if you know what I mean... (winks!)

"POOF" (Disappears)

[mugenjohncel]

OK... I decided to put renpy.cache_pin to the EXTREME test by loading 77 images (yep!... full image-map based GUI at wide-screen sizes) all at the same time using three different computers (A standard crappy Eeepc, a not so new PC 2.5Ghz I normally use for accounting and bookkeeping with 1Gig memory and 256MB Video Memory Built-In and a Very Noisy Full Blast Overkill Quad Core PC with 4Gig Memory 1 Gig Video Memory)

Full Blast Overkill PC:
Initial loading is just barely a second... after that, going from menu to menu is way too smooth... first time I've seen imagemap based GUI behave this smoothly... I cried...

Not so new PC:
Same as above... Initial loading is just barely a second or two slower... after that, going from menu to menu is smooth... I cried...

Eeepc:
Initial loading is a drag. Took nearly 5 to 7 seconds as if it's loading something... after that, going from menu to menu is way too smooth... but once I entered the game, I can see quite a few err... twitches in speed... Even crashed twice... I cried...

I am happy to report that this new feature is working the way it should but must be used with caution. To deal with the initial delay in loading... I decided to add a splashscreen with pause (hard set to true) to mask the loading renpy is doing behind the scenes.

The age of the imagemaps has finally come!...

"POOF" (I cried...)

Edit:
In case you're wondering why 77 images... Besides the regular necessary image-map and GUI images, some of the elements are animated. Dialogue box alone needed 12 separate images.

[jack_norton]

Remember that normal OpenGL/DX games have several seconds of startup too (depending how much gfx they load on VRAM), so the initial wait isn't really a bad thing. I was surprised the first time I ran Renpy to see the loading was instant for example. I think the new pin function will be extremely useful if used correctly (ie if you know a big block of images is needed on line 100, put a "loading..." screen a few lines before to have a smooth animation).

[delta]

The age of the imagemaps has finally come!...

Did you miss the memo? Imagemaps = old and busted, Transform/event handler-based GUIs = new hotness.

That said, I have no problems with this release so far. Been a while since that last happened.

[mugenjohncel]

Did you miss the memo? Imagemaps = old and busted

Duh... OK fine, you win... but you can't deny how easy it is to use and abuse imagemaps... you know, less time programming, more time for "actual" content...

Transform/event handler-based GUIs = new hotness.

Maybe... but I still have to see a renpy VN making use of it. And even if one does exist (in case I missed it) I doubt the code (including the graphic resources) will be open and available for the average layman with huge ambitions... like me (insert wink here)...

Now, until someone makes a VN featuring those transform/handler thingy and made it openly available so I could steal study and learn from it... we, the average layman will have no choice but to use old and reliable imagemaps.

"POOF" (Disappears)

[delta]

I'd rather nail my foot to an elk than help you. But I have a sneaking suspicion that it will make its way into the Ren'Py defaults somehow before long.

[mugenjohncel]

I'd rather nail my foot to an elk than help you.

...I'm waiting

I have a sneaking suspicion that it will make its way into the Ren'Py defaults somehow before long.

Probably not in the near future... the renpy default GUI alone is very daunting for someone who is new to renpy. Now if someone made a sort of "tool" with a user and family friendly "GUI" to make those complex Renpy GUI's then perhaps...

"POOF" (What was I supposed to say again?)

[PyTom]

renpy.cache_pin has proven quite popular. I'm wondering if I should improve it a bit before 6.10.2 is officially released.

Right now, renpy.cache_pin has no way to unpin an image. I'm debating adding a renpy.cache_unpin function to a 6.10.2b, that will remove data from the pin cache.

[jack_norton]

I have some weird experiences with it, on my dev pc (who is a decent machine but still 2 years old) seems that the slowness/delay are most because I use big PNG for the character and scale them down (even by half). So for that specific case, the pin doesn't seem to help (but probably I'm the only one using sprites so big lol)
The background images loading is much faster though

[PyTom]

You can pin arbitrary image manipulators. So something like:

renpy.cache_pin(im.Scale("foo.png", 800, 600))

will work.

[jack_norton]

Ah no, I keep a big image (like 2000x1500 px) loaded, and then use Factorzoom to zoom/scale it to desired size, using your function (the one you made me for Heileen 1 lol):

Code: Select all

        def zoom(start, end, time):
            return FactorZoom(start, end, time, opaque=False)
        def scale(factor):
            return FactorZoom(factor, factor, 0, opaque=False)

I suppose there's no remedy for my bad behaviour (but this way I can have both detailed portrait and also nicely zoomed out waist-up / fullbody sprites)

[PyTom]

I've updated the pre-release. 6.10.2b allows renpy.cache_pin to be used outside of init code, and adds renpy.cache_unpin.

If people who plan to use cache pinning can test it again, I'd appreciate it. Allowing unpinning involved a bit of a rewrite.