[Ren'Py] Too many screens?

[AdventAnyx]

Hey, everyone! Good day to you.
I'm a super newb when it comes to programming, but I've stumbled at some issue that I'm not sure is my fault.

So. I have a pretty simple interface in my game:
- There are a bunch of image-buttons at the top, and some of them can open additional screens
- This screen is a window with a 1-3 .webm video-file playing on repeat. Something like an idle animation of a character
- Player can click several of those buttons and basically flood his screen with these video-loops for different stats
- There are more buttons in some rooms, to open more of such screens with more videos. If the player wishes to open all of them, they get on top of each other

The problem I ran into is:
once there are 3-4-5 of these videos opened simultaneously the game just crashes with no log at all.

Every video is a 1920*1080 .webm of around 5-10 Mb size. Resized using RenPy Zoom command, you can fit lots of them in one screen.

So, my question is:
Is there something I can do to my code? Is there a limit at how much RenPy can handle?


Here's an example:

Spoiler

You don't have permission to view the spoiler content. Log in or register now.

Three video-files playing. Actually it's 4 (the background is a movie too). Plus some of the buttons are animated using the (image:...repeat method).
If I open another screen with another Video-loop, it might be fine. But the 5th will crash, and not even update the log-file (the one RenPy creates when you start a game).
And I had players report they can't even open this one, it'll crash with only 3 4 videos.

(also: can't add a RenPy tag to the topic for some reason...Not my day)

 

[Saki_Sliz]

From what I understand, Renpy runs on python. Python doesn't technically have an upper memory limit. Python is executed by an interpreter that runs on C code, which has to request more memory as needed, and how well this works depends on how well the python interpreter you are using is coded.

As far as I know, renpy is pretty fancy, I assume you are using it to do the work of loading up the videos. If it is crashing without even leaving a log, my guess as an old fashion code person (I know more about c than I do about python) is that you hit some sort of critical fault that the operating system had to kill before the program could be allowed to react. Most of the log reports would probably be caught by the game engine and reported. If there is an issue with the engine, then python would try to report the issue, but if there is an issue with the interpreter, then the C code would try to catch the issue. There are 3 levels that can be the source of issues and will try to log errors. But when it comes to memory-related things, there is another level, the operating system. It too will try to catch issues, report them and safely close the program. If you are getting no error logs, then it probably means that the OS hard killed the game before it could report an issue. This is actually not that surprising if you are running a C based python interpreter engine since the C language is a fairly dangerous and risky language and has a very hard time with managing memory since programmers have to manually code in a memory manager. Since the interpreter itself is not being run in a console, you probably won't get to see what the issue was (such as a segmentation fault, when your program tries to access memory that does not or no longer belongs to the program, if you load to much, the computer will have to virtualize data, aka move it around, and as a result it may no longer be in the same location, thus causing issues). What you could try, I don't know if this is possible, but switch your python interpreter to be based on a memory safe language, such as Rust (RustPython), which not only has a garbage collector program that automatically handles memory better than C (ignoring hiccups) but has the safest memory system and multithreading system.

not sure if this is really the problem or the solution however, consider this a last-ditch effort.

 

[recreation]

It's a renpy problem, it doesn't handle video files very well, it even struggles with images if you use too many effects. It's not really hardware dependant, though better hardware can help. Solution: don't play more than one video at the same time unless it's super small and crunched videos.

 

[AdventAnyx]

...

Hey, thanks!
I'll be pretty honest here. I have no idea how to do any of that. When I said newb, I meant it. I can't even write a class, I use the most basic functions the RenPy has...

That being said. I have a second pack, with compressed files of my game. I just ran it, and even though all the video files are like 3-10 times smaller, it crashed all the same.

But!

It leaves a log! Here you go:

Spoiler

You don't have permission to view the spoiler content. Log in or register now.

Memory error, eh? And nothing after that.
So I guess nothing I can do, really...With my level of "skill".

It's a renpy problem, it doesn't handle video files very well, it even struggles with images if you use too many effects. It's not really hardware dependant, though better hardware can help. Solution: don't play more than one video at the same time unless it's super small and crunched videos.

Yeah, looks like I need to somehow stop people from opening too many windows, and limit my stats screens to 1 video.

 

[Saki_Sliz]

If you close and open more windows, never going beyond the 3 with the 4th background one, is it stable? I ask because this should be a sanity check. It doesn't help if you figure out how to code, add in a limitation where only 3 windows can be open (maybe automatically close the oldest or most recent window to make room), only for your game to still crash if closing windows doesn't remove them from memory. simply manually closing them could be a simple test to see if closing them is enough to clear up memory.

 

[AdventAnyx]

If you close and open more windows, never going beyond the 3 with the 4th background one, is it stable? I ask because this should be a sanity check. It doesn't help if you figure out how to code, add in a limitation where only 3 windows can be open (maybe automatically close the oldest or most recent window to make room), only for your game to still crash if closing windows doesn't remove them from memory. simply manually closing them could be a simple test to see if closing them is enough to clear up memory.

Yes. Closing them is fine. I can open 1-2, then close, walk somewhere, open 1-2 other ones, close them and it's all fine.
It only crashes when you open everything at once (or at least 4 videos, sometimes 5 is fine).
The only thing I don't get is why changing the size of said videos does nothing. We are talking about 30-40 Mb of videos vs. ~3-5 Mb for compressed. The number of screens it crashes at is the same.


Edit: probably something to do with them overlapping. Maybe RenPy tries some mubmo-jumbo, I have no understanding of, to calculate something when said videos are on top of each other.
I'll do a test later: resize and put them in a way they don't overlap and see how many I can fit in before it crashes.

 

[Saki_Sliz]

The only thing I don't get is why changing size of said videos does nothing. We are talking about 30-40 Mb of videos vs. 5 Mb for compressed.

Simple. Compression only helps non-volatile memory, the memory size when you save the game to your computer, or when you transfer the game files over the internet. However, computers can not work with compress data types, nothing can (depending on your definitions). What has to happen is when you game loads up, and starts asking for files, these files have to be 'streamed' in, decompressed into a readable file format (hence no memory savings for when the game actually runs, aka the source of your issues) (can cause more memory issues as for a moment you need to hold two copies of the file, the compressed and decompressed version), and sometimes even converted again to other data/file types or into raw data to be used and manipulated.

For example, videos like mp4 (after initial decompression) is a file type that compresses videos into a series of 2D waves of different amplitude, How many waves in each dimension is related to memory size and video quality, but when it comes time to render the image, these waves eventually need to be converted to an image to be saved in memory and later displayed on screen. so even the video in its natural state (.mp4) still needs to be decompressed again into another format (a raw image of pixel values).

 

[AdventAnyx]

...

Interesting...
I'm using VP9 format for my .webms. Can it help if I use another one? I can go for VP8, or make them mp4 of both h.264, h.265 type.
This all needs testing...

 

[Saki_Sliz]

You can experiment, since I don't know how renpy may handle things. I am a fan of H.264 myself since it has one of the best compression techniques with the least amount of quality loss I've seen. H.265 is just the same thing as H.264, but H.264 is software, and H.265 is hardware, typically on your gpu. so maybe it will save memory if it is directly on the gpu, solving the issue, but only for those with graphic cards. That, and I don't think renpy can handle gpu commands since that is pretty advance stuff and would require a different library for that. Renpy probably doesn't handle graphics, but uses some other library already.

 

[AdventAnyx]

You can experiment, since I don't know how renpy may handle things. I am a fan of H.264 myself since it has one of the best compression techniques with the least amount of quality loss I've seen. H.265 is just the same thing as H.264, but H.264 is software, and H.265 is hardware, typically on your gpu. so maybe it will save memory if it is directly on the gpu, solving the issue, but only for those with graphic cards. That, and I don't think renpy can handle gpu commands since that is pretty advance stuff and would require a different library for that. Renpy probably doesn't handle graphics, but uses some other library already.

Hmmm. So, potentially h.265 could be better, but won't work on many devices (if at all with RenPy)...

Thanks a lot for the insight. I wouldn't even think about this stuff.
I'll try different types, and make windows not overlap and see how it goes.

 

[Saki_Sliz]

What you could try is, if you can set the shape of the windows, and if the windows are the important thing about your game, you could have like a side menu bar, like small little windows. They could hole an image or a preview of the video, or maybe the video is small and fits in this sidebar. What you can do is have a sidebar, and it can have empty slots, and only room for 3 videos. So if players want to open u another image, the sidebar could flash red or something, letting players know that videos are only opened up and limited by the sidebar, and space must first be cleared before they can open up a new window.

 

[AdventAnyx]

What you could try is, if you can set the shape of the windows, and if the windows are the important thing about your game, you could have like a side menu bar, like small little windows. They could hole an image or a preview of the video, or maybe the video is small and fits in this sidebar. What you can do is have a sidebar, and it can have empty slots, and only room for 3 videos. So if players want to open u another image, the sidebar could flash red or something, letting players know that videos are only opened up and limited by the sidebar, and space must first be cleared before they can open up a new window.

They are all just for the flavor. Not connected to the direct gameplay, just a fun way to see how some characters changed. You open it once in a while and that's it.
So, I don't think I'll need something you're suggesting. More likely I'll just make it so when you open one stat-window, everything else closes.

 

[Saki_Sliz]

that'll do!

 

[anne O'nymous]

From what I understand, Renpy runs on python. Python doesn't technically have an upper memory limit.

For historical reason, Ren'py use a 32bits version of Python 2.7 that have a memory limit of 2GB .

 

[Saki_Sliz]

That's great to know, also surprising, 2.7, really!?
And here I was thinking 3.5 was considered old.

 

[DuniX]

I am not sure if I understand this correctly but can't you use something like Tag to replace the videos?

You must be registered to see the links

Every video is a 1920*1080 .webm of around 5-10 Mb size. Resized using RenPy Zoom command, you can fit lots of them in one screen.

If the videos are meant to be smaller why not resize them properly first? Or make them a spritesheet?

 

[AdventAnyx]

I am not sure if I understand this correctly but can't you use something like Tag to replace the videos?

You must be registered to see the links

If the videos are meant to be smaller why not resize them properly first? Or make them a spritesheet?

Several reasons.
30% lazy
60% I'm a noob, and it's my 1st game. So if I want to suddenly change my whole interface, I can just use Zoom again
10% turns out lowering their size doesn't help anyway
...
..
.
Damn. That tag thing looks relevant. Wish I saw it earlier...
Now I need to figure out how to apply it.
I was already thinking about how I need to put additional "hide screen" for every screen on every button. Being a noob sucks tbh.

 

[Saki_Sliz]

hey, its my personal philosophy that the best way to learn is by doing projects, having to research dumb questions and learning things along the way.

 

[79flavors]

Hmmm. So, potentially h.265 could be better, but won't work on many devices (if at all with RenPy)...

Nooo!!!! (imo)

h.265 is considerably better compression than h.264... and therefore the resulting file will be smaller.

However, that compression comes with a cost... more CPU time to decompress it on the fly. Most modern computers will be just fine with it, but others it will be adding unnecessary strain onto a system that already sounds like it's struggling a bit.

h.264 will result in a bigger file that is easier for most computers to play (and therefore play multiple instances of).

I recently had need to recode a lot of kids cartoons to run on an in-car entertainment system using an under-powered Android system. The best solution turned out to be to use older codecs to make the videos easier for the system to play. Straight up MP4/h.264 with AAC encoded audio.

I can only offer the same advice here, since your goal is multiple active videos rather than reduced disk space.

 

[Saki_Sliz]

Nooo!!!! (imo)

h.265 is considerably better compression than h.264... and therefore the resulting file will be smaller.

However, that compression comes with a cost... more CPU time to decompress it on the fly. Most modern computers will be just fine with it, but others it will be adding unnecessary strain onto a system that already sounds like it's struggling a bit.

h.264 will result in a bigger file that is easier for most computers to play (and therefore play multiple instances of).

I recently had need to recode a lot of kids cartoons to run on an in-car entertainment system using an under-powered Android system. The best solution turned out to be to use older codecs to make the videos easier for the system to play. Straight up MP4/h.264 with AAC encoded audio.

I can only offer the same advice here, since your goal is multiple active videos rather than reduced disk space.

everything I read said hardware acceleration was required, are you saying that it can also be run on the CPU without acceleration too?