search

iminurnamez / pyroller

pygame casino
65 stars 29 forks source link

Implementing a State Stack #179

Closed MarquisLP closed 9 years ago

MarquisLP commented 9 years ago

Given how many states comprise the game, I think it'd be better to have states loaded sequentially based on when they're needed to be shown, rather than loading them all at once into memory. Also, when the player leaves a state, ideally that state object would also be discarded to free up some memory.

The best solution would involve a stack for pushing and popping the currently-active state, though that would require some threading to have new states load smoothly in the background.

If this sounds like a good idea, I'd be more than happy to start laying the groundwork.

bitcraft commented 9 years ago

I'm not sure threading is the right thing to do now, as it could require changes over the entire project. I think that first the state loader/manager should be changed to allow states to be loaded on demand (plugin), then we can figure out if a threaded resource loader is needed or not. As is, it is not optimal that all states are loaded, instantiated, and requesting resources, using memory, and so on but that is a problem that can be fixed later, IMO.

On Wed, Jul 8, 2015 at 12:53 PM, Mark Padilla notifications@github.com wrote:

Given how many states comprise the game, I think it'd be better to have states loaded sequentially based on when they're needed to be shown, rather than loading them all at once into memory.

The best solution would involve a stack for pushing and popping the currently-active state, though that would require some threading to have new states load smoothly in the background.

If this sounds like a good idea, I'd be more than happy to start laying the groundwork.

— Reply to this email directly or view it on GitHub https://github.com/iminurnamez/pyroller/issues/179.

MarquisLP commented 9 years ago

I see. Optimization is the real reason I bring this up, as CPU usage and frame rate seem to be taking a big hit at present. But I agree -- the loading and handling of states should be sorted out before tackling this issue.

bitcraft commented 9 years ago

I'm happy you are thinking about performance, but reducing memory consumption or threading isn't going to fix the high CPU use. It's due to the game architecture. All states are rendered to a large off-screen surface, then that surface is scaled to the screen. That constitutes about 25% cpu time (on my last benchmark). The rest is likely due to overdraw (writing pixels many times each frame) in each state. It would be best to tackle overdraw on a state-by-state basis.

MarquisLP commented 9 years ago

Well, the former can't really be helped if we're to allow various resolutions, but minimizing overdraw is definitely something that should be looked into in the future.

bitcraft commented 9 years ago

I've implemented states being instanced on demand, but not a stack, as it was deemed too complex for the scope of the project, and what we have is working well enough. Any other comments, or shall we close this issue?

Mekire commented 9 years ago

I'll close this for now. We can reopen it in the future if people feel it is needed.

MarquisLP commented 9 years ago

Yes, that should do for the time being. I'll tinker around with implementing with a stack on my end, just to quell a bit of curiosity, but the current system should be suitable for the scope of the project.