Next day loading several minutes (we should get 1k events at latter points of development), even if index loading is extremely fast afterwards is a deal breaker and kills the game. If next day is loaded in 3 secs, player can use filters (once we have now and we'll install more in the future), he/she will be able to actually read and view pics/stat increases and close the next day, going through with the game. There is no point in claiming that both take long time to the same effect, time it takes to load and view all events might be comparable, but the game play experience is perfectly acceptable in one case and absolutely sh#tty in the other.
I agree 100%. What is not true is your claim that the faster branch takes 49 seconds to load 106 acts while master branch takes 3 seconds to load 1000 acts
Your code actually cashes the images after you view them once, so you could have simply told us to go through a couple of images and revert to previous indexes to see the difference in speed
Yes, I should have done that, but I did not think of this easy solution at that time.
Like I've said, game experience, we're not coding some theoretical modeling software, last I've checked, we were working on a game.
Yes, we are. How does that make your claim that master takes less time to load acts any more true?
Again, I never said preloading all images for all acts before showing the next day screen is better for game experience.
My bad, my laptop is 5 years old, if not more, I've tested it there as well and did not notice anything I might have called a delay (not even mentioning how it runs on desktop).
Maybe you are more patient than I am. A reaction time of almost a second is a serious delay in my book and quite annoying while playing a game.
It does have dedicated Nvidia GPU (old one but maybe it makes it run faster or something).
GPUs should have no influence at all on the speed of our game. The IMHO singlemost important cause for the delay after clicking "Next Event" is loading the image from the harddisk. What's worse is that our image resize function does not use renpys image cache.
Possible ways to speed things up:
1) Find a way to resize images in renpy while using the image cache
2) instantiate a renpy Image when an event is created, so renpy has more time to preload and cache the picture
The approach could be permanent but it feels like select_image should handle all image selecting logic. I haven't traced the entire logical flow (was to tired). Maybe things are fine the way they're now.
I've NEVER said that (at least while I was sober).
You did not say it recently, but as far as I remember it took quite some convincing that it's not terribly slow when I first presented that idea to you. Back then we were still talking about Pytherworld. Anyway, maybe I just don't remember that right, it does not matter.
mijh definitely said its slow and is strongly opposed to this image selection strategy. Of course, he is right that pytfalls original approach is faster, but it does not matter if we spend 0.01% or 1% of our calculation time on image selection. Both numbers are small enough that they won't affect the game performace-wise.
But if you did actual profiling and those were the results, it's all good.
I did, using cProfile. I'm sure my results are accurate enough to say that select_image is no problem for game performance at this point.
I'll take another look to see if things can be farther improved, but I would still call it acceptable on Laptop and perfect on Desktop.
You can leave that to me if you want to. I spent some time reading renpys sparse documentation and nice source code in order to understand renpys image caching. As far as I can tell, renpy preloads images sometime between instantiating the renpy Image and displaying it on the screen. Instantiating a renpy image as soon as possible should improve our situation.
I also saw that the image cache seems to know the size of the image it holds, so if we can figure out a way to get our image from the cache, we should be able to resize it without using renpy.image_size.