-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Load spritesheets concurrently #68
Conversation
Hey, thanks for the PR. I think we'd have to test if this works with the switch version or not. It seems to be crashing when I try to emulate the release from this branch at least. if std::async doesn't work then it might be necessary to use SDL_Threads kinda like how WorkerQueue does it. |
Are there any resources on how to setup the dev environment for switch so I can hack away at it? |
I don't think we have any, you'll probably need devkitpro, try taking a look at the pipeline for the switch build to see how that works. As for running it on the switch itself, you'll just need to put the runtime files (profiles, shaders, profile.txt, games) on the root of the SD card. |
I guess you could also just use the pipeline as a build environment |
Thanks, I'll have look tomorrow! |
It might also not be limited to just switch, I need to setup a Linux environment to test things as well, but the crash could just also be an implementation thing between gcc and msvc, so if Linux also crashes, then fixing that crash will probably fix it on switch as well |
I'll try that, otherwise I'm gonna go off the assumption that getting it working through SDL threads will solve the problem. Will probably try to implement some generic threadpool. |
Sorry, ignore everything i just said... I just didn't copy the latest profile. Switch build runs fine |
Once i merge fstream changes as well, you should see a significant improvement in loading times |
This PR loads Spritesheets in parallel on different threads using
std::async
.I was annoyed by the slow startup times when testing things, especially in debug mode.
After some profiling I found that ~40% of the time was spent in stb_image.
By splitting this work over multiple threads the time-to-menu is significantly faster with a relatively simple change.
Loading sprite sheets for CC;LCC in Debug mode went from ~22s to ~13s for me (Ryzen 7 5800X)
There are no doubt more optimal ways to squeeze out more performance but my main goal was to speed up iteration time during development by picking up some low hanging fruit, and this seems to be a good start.
CPU utilization before:
CPU utilization after: