|
|
Post by eider on Mar 9, 2016 7:15:17 GMT -8
There are numerous performance issues, most of them likely caused by Ren'Py limitations (i didn't take a look at battle code yet), however i found it that i can improve gameplay experience by manipulating some of Ren'Py config variables - config.framerate (default 100)
- config.image_cache_size (default 8)
Please consider changing (adding) them in options.rpy to values similar to these:
config.framerate = 30
config.image_cache_size = 24
I performed my test on a machine with 16GB of DDR3 RAM and Intel Pentium G2130 (2x3.20 Ghz) with no changes to Ren'Py renderer settings (set as automatic). Test subject was battle 'mission9'. I found it that settings i provided above helped in a much smoother gameplay compared to when they were left default.
|
|
|
|
Post by vaendryl on Mar 9, 2016 7:35:38 GMT -8
we've been having some serious 'out of memory' errors of late. I'm wary possibly making them worse by messing with these settings. There've been quite a number of updates to ren'py since I last messed with these though. probably worth it to check it out again. Thanks for the suggestion  |
|
|
|
Post by eider on Mar 9, 2016 7:53:18 GMT -8
|
|
|
|
Post by vaendryl on Mar 9, 2016 9:44:36 GMT -8
I assure you I'm aware of the image_cache_size setting and have experimented with it a lot in the past, with few positive results and a possibility of increasing memory issues.
as the documentation you linked to mentions setting the framerate in config only does anything when rendering in software mode, which I hope to god nobody even tries.
I think trying it once more is worth the effort though, but even if it causes more memory issues it'll be hard to prove this is the cause which is always annoying.
|
|
|
|
Post by eider on Mar 9, 2016 23:08:44 GMT -8
What about running www.renpy.org/wiki/renpy/doc/reference/functions/renpy.free_memory before starting battle? Also, i have no idea what's the deal with out of memory issue, the memory usage for me when it happened wasn't very big, in fact i'm pretty sure it was below 1GB - no sane program should throw such errors when i have 10GB of free memory available. EDIT: label battle_start:
[...]
$ renpy.free_memory()
[...] |
|
|
|
Post by bigfoot on Mar 10, 2016 0:02:53 GMT -8
When I was modding MoA I sometimes had the out of memory problem and actually did use free_memory before battles, it cut down crashes by about 80% and the pause was barely noticeable (This was when I was doing crazy things with the battle_screen that took a lot out of it)
|
|
|
|
Post by vaendryl on Mar 10, 2016 2:12:40 GMT -8
What about running www.renpy.org/wiki/renpy/doc/reference/functions/renpy.free_memory before starting battle? Also, i have no idea what's the deal with out of memory issue, the memory usage for me when it happened wasn't very big, in fact i'm pretty sure it was below 1GB - no sane program should throw such errors when i have 10GB of free memory available. EDIT: label battle_start:
[...]
$ renpy.free_memory()
[...]god damn I was sure that was already part of the battlemode function but it's not there >.> thanks for the suggestion |
|
|
|
Post by eider on Mar 10, 2016 3:05:39 GMT -8
Just played game again with all battles and never got out of memory issue with game using at peak little over 800MB of RAM. I've used 'renpy.free_memory()' as suggested above and config variables from first post.
|
|
|
|
Post by limith on Feb 4, 2018 1:39:36 GMT -8
Has ren'py stopped using reflection for its code? Cause cutting that out will surely increase performance. All I remember is seeing it use reflection back in the day. Literal code eval will probably have higher performance than reflection.
____
That aside on the topic of python memory management: python doesn't seem to actually actually ever 'free' up the memory used on a system level even if you import the garbage collector and tell it to clean up. That is to say if you start a program and end up using 2GB of memory for 1 second python won't release that memory back to the system even if you only used it for 1 second. Python internally has its own tracking for memory and it may only use say 30 MB of memory even though it has latched onto 2GB of memory. What the gc call is doing most likely is making sure the internal memory cleans itself up so it doesn't have to alloc() anymore system memory.
This is why for certain occasional memory heavy jobs at work (on machines which are also running other jobs) which take a long time (but most of the time uses very little memory) we use subprocesses in python. A subprocess may eat up say 2GB of memory but when it is done it will free up the system memory.
|
|
Hot singles in your local solar system! 
