- Oct 18, 2020
- 10
- 9
Time to replace the 20yo potato if it can't even render prerendered AVNs. My old PC has a 3070 and does fine, but I would think even a cheap used GT 730 would be enough for AVN reading).
There's no problem with my 'potato' since it handles many AAA games with ease. This game is poorly coded I guess.Time to replace the 20yo potato if it can't even render prerendered AVNs. My old PC has a 3070 and does fine, but I would think even a cheap used GT 730 would be enough for AVN reading).
It's generally the CPU that's the issue in RenPy games. RenPy can display images with "show" or "scene". Scene clears everything and then displays the new image. Show displays the image but never actually gets rid of it unless it you also do a "hide" (or a later usage of "scene" clears everything). So if a dev forgets the "hide"s, all the images just end up getting layered on top of each other.There's no problem with my 'potato' since it handles many AAA games with ease. This game is poorly coded I guess.
I checked my task manager and my GPU memory was 95% used so It was taking a toll on my GPU.It's generally the CPU that's the issue in RenPy games. RenPy can display images with "show" or "scene". Scene clears everything and then displays the new image. Show displays the image but never actually gets rid of it unless it you also do a "hide" (or a later usage of "scene" clears everything). So if a dev forgets the "hide"s, all the images just end up getting layered on top of each other.
The usual culprit is videos that are called with "show". RenPy isn't all that great at video playback in the first place, and has quite high CPU usage when doing so. So call videos with "show" and forget to "hide" them, and now you've got 2+ videos playing at once. I used to have an i5 4690k and a single video would push it to 60%; a second would push it to 95% and things would get laggy; and a third would max it out and make the game pretty much unplayable.
And looking through the code, that's what seems to be the case here. Animations are usually cleared with a "hide", but not every time. And those "a couple hours/minutes later" screens? Videos, for some reason. And they never get hidden except by the occasional usage of "scene".
I didn’t think about hiding the video files. I was used to only having to use scene once in a while to clear images, so I carried that same practice over to videos without thinking twice. Thanks for bringing it to my attention, I’ll make sure to fix it and update the new links on here soon.It's generally the CPU that's the issue in RenPy games. RenPy can display images with "show" or "scene". Scene clears everything and then displays the new image. Show displays the image but never actually gets rid of it unless it you also do a "hide" (or a later usage of "scene" clears everything). So if a dev forgets the "hide"s, all the images just end up getting layered on top of each other.
The usual culprit is videos that are called with "show". RenPy isn't all that great at video playback in the first place, and has quite high CPU usage when doing so. So call videos with "show" and forget to "hide" them, and now you've got 2+ videos playing at once. I used to have an i5 4690k and a single video would push it to 60%; a second would push it to 95% and things would get laggy; and a third would max it out and make the game pretty much unplayable.
And looking through the code, that's what seems to be the case here. Animations are usually cleared with a "hide", but not every time. And those "a couple hours/minutes later" screens? Videos, for some reason. And they never get hidden except by the occasional usage of "scene".
Why not just use 'scene' instead of 'show'? What does 'show' does which scene can't do?I didn’t think about hiding the video files. I was used to only having to use scene once in a while to clear images, so I carried that same practice over to videos without thinking twice. Thanks for bringing it to my attention, I’ll make sure to fix it and update the new links on here soon.
I’m not sure. I think there was some sort of reason why I used show more often. Something I must’ve came across when doing my first research. But I’ve long forgotten by now. So I’ll look back into it, and see if using scene to display each image has any negative impact over using show. Otherwise I might make those changes as well, or at least do it that way moving forward.Why not just use 'scene' instead of 'show'? What does 'show' does which scene can't do?
The only use of show I can think of is when you have to use multiple images at the same time to overlap them.
Huh, I guess I never noticed, but the GPU is getting hit pretty hard as well. Seems to be only when the still images are getting stacked pretty high (as opposed to the CPU getting hit during videos).I checked my task manager and my GPU memory was 95% used so It was taking a toll on my GPU.
I haven't seen the code yet but your reason seems right since there are times when game would suddenly start working flawlessly and again starts taking too much GPU memory after some time.
Interesting, thanks for bringing that up. I’ll look at getting both the videos and image stack-ups optimized as soon as I get back to work. Just enjoying the last the few days of post release break, before getting back into the swing of things starting Monday.Huh, I guess I never noticed, but the GPU is getting hit pretty hard as well. Seems to be only when the still images are getting stacked pretty high (as opposed to the CPU getting hit during videos).
SerpentBreath3D as an example, I have an RX 6600 and noticed that GPU utilization got up to 74% by the end of 04_home_sweet_home.rpy. Then there's a "jump first_dinner" which has a "scene black" and it drops back down to 4%.
Show will display the image / animation on top of the previous "scene" that was displayed.. essentially adding layers and layers. Once you do a show for an image/animation you then need to hide it before doing another one, otherwise this will cause issues for people, or when you display other "shows" people may see the previous one still loaded up. Best thing to do is always use scene... unless you are wanting to add something on top of a scene... for example a phone... for this you would use "show" as it would be added on top of the current "scene" being displayed.I’m not sure. I think there was some sort of reason why I used show more often. Something I must’ve came across when doing my first research. But I’ve long forgotten by now. So I’ll look back into it, and see if using scene to display each image has any negative impact over using show. Otherwise I might make those changes as well, or at least do it that way moving forward.
No, this was just a one-off render I made to be used promotionally for my Itch and Patreon. It features a character I plan to include in the future of Fighting for Love (may look similar to Emma from this angle and lighting, but it’s not). It wasn’t really meant to be used as a preview image, but instead was just grabbed from my itch and put here when this thread was created. I kind of just left it, but I’ll get around to updating the preview images, especially with all the new renders now in v0.2.Is this scene in the game? It's one of the preview pics... Not sure if I missed it?
View attachment 3298673
I understand the distinctions. I used "show" because, if I recall correctly, "scene" cleared the textbox every time, which felt a bit jarring. I might be remembering it differently, but thanks for your input. Of course I have removed the textbox since then, but I guess the habit of using show stuck around.Show will display the image / animation on top of the previous "scene" that was displayed.. essentially adding layers and layers. Once you do a show for an image/animation you then need to hide it before doing another one, otherwise this will cause issues for people, or when you display other "shows" people may see the previous one still loaded up. Best thing to do is always use scene... unless you are wanting to add something on top of a scene... for example a phone... for this you would use "show" as it would be added on top of the current "scene" being displayed.