I have been using my own state switching solution in my game project, the thing is that switching between two menus is fast, I rarely find and issue. The story gets a horrible twist whenever the map spriteset is involved, it freezes for a few seconds and then continues loading the new map or menu depending on the case. My transition state draws simple rectangles and waterdrops on screen, plus setups the new state then. It first displays the previous state and then lets it get replaced by the second state. At some point all black rectangles and waterdrops freeze abruptly for over 15 seconds before finishing and letting the player walk all around the current map or navigate through the current menu. I thought I had to make the setup and drawing run in a parallel process... so I used a new Thread only to find out that concurrence was a wacky idea after all.
What should I do then?
15 seconds? How big is your map? I never had to load anything longer than few seconds, so maybe your code can be optimized somehow. Drawing in parallel thread doesn't work AFAIK, however you can do some important calculations if you do anything other than drawing. And make sure that you don't do any redundant calls, to speed up loading. Caching things helps too.
You could try using a profiler to see what it is that keeps Ruby busy.
Rendering can only ever happen on the main thread. Even image loading is limited to the main thread right now: https://github.com/gosu/gosu/issues/294.
It could be the garbage collector. If you create lots of temporary objects (usually tiny arrays and hashes) there might be stutter, but usually only a few 100 milliseconds.
I tried to cache sprites by creating hashes to store them in order to avoid loading them every single time I needed them so I thought it would help improve my game's response but... My map aren't really large, one is only a bit larger than a 800x600 window, 960 pixels wide at most... It only sports 4 events on map plus the player's sprite and its four companions...
Hard to tell without seeing the code then. Maybe there's some nasty loop that takes too many iterations. Or you are doing too many operations (e.g. you use auto-tiles and check each tile too many times). Or you load tile graphics from file for each tile. Or you load map inside a loop and it loads multiple times due to missing break. There's something definitely wrong, because such map as you said should load in few milliseconds.
Well, this time I'll show you the code concerning the logic update stuff, the most basic part, just in case you may found out why it's been so head-breaking lately...
* Removed the code to help readers find my latest post here *
Well, this time I will attach a few Ruby files in case anybody can point out what's the actual root cause for my project's slowdown.
Since it is evident that this topic does not catch people's attention, I request a moderator to close it. I do not think it should be deleted so closing sounds like a better choice, or it could be moved to some forgotten or old topics hidden subforum.
I'm not a fan of looking at bare code and figuring out what might be wrong. If you'd care to post whole your game, so I could run it and test myself, it would be easier to see what's wrong.
btw, this forum is supposed to be dead XD You might have more luck on reddit
The reddit is newer, but I don't think it really succeeded in replacing this forum. Some people seem to prefer message boards (me included), some people prefer subreddits, but neither is active enough that I feel like shutting down the other. There's actually a third place :D - StackOverflow, sometimes I see some Gosu questions over there.
Anyway, I'm closing this thread per kyonides' request. If you change your mind and want to post your full game or a minimal version that exhibits the problem, PM me and I'll unlock it.
The game have been uploaded months ago, it was named KUnits Gosu...
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill