-
Notifications
You must be signed in to change notification settings - Fork 6
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
Improve performance #5
Comments
Initial performance on my PC yielded ~4600 FPS before changes. After simple improvements, this jumped up to 6000 FPS. These numbers may be very much platform specific. The basic changes were to avoid trivial function calls, pull certain sections with redundant conditionals out of the CPU emulation body through goto's (gb_halt code), and to create an innermost loop that calculates the number of instructions before an interrupt will occur. Future improvements might be more difficult. One change could be creating a separate READ command for ROM reads with specific addresses (i.e. instructions) upon a closer look. Other places for improvement include pre-calculating values like address banks, using memcpy for DMA, and anything else. The target is a 10,000 FPS emulator, which should be possible. The theoretical best performance would be in the range of 60,000 frames per second when comparing the system clockrates, and potentially more when using advanced processing features, multiprocessing, and other tricks. |
VBA-M uses 2% CPU on my computer with sound on. This project (performance branch) uses 14% with sound off on Windows 8.1. |
Hm, fair point. When you started talking about performance I figured that meant in terms of maximum frame rate, so that's what this is optimized for. There are no delays or thread sleeps, everything is kept in a busy loop. So yes, it uses a high percentage of CPU time. It would make sense for the normal speeds (Normal, Fast, Faster) to have a sleep somewhere. I'm guessing it should only use about 1% then. Currently, I'm getting around 6,000 frames per second on the performance build with one core. With a little bit of threading the number might be able to go up. There's not a whole lot of purpose to building the fastest GameBoy emulator around, but it might be an interesting challenge. Any platform that this can be built for is probably already sufficient to run at full framerate. However, if the target platform were archaic enough, there might be a need to use more innovative techniques to get a game running. That's really beyond me. Also, I would say adding sound support would make no difference to performance. |
My own goal with this project is to get the CPU usage down as low as possible whilst still maintaining 60fps. :) |
So I tested the emulator on the Raspberry Pi (first generation) and I noticed that on some games the frame rate was only half the necessary 60-61 fps. However, when I turned full frameskip on, that number climbed back up to 240 frames per second. This leads me to believe that in general the emulator is GPU bound and that some optimizations to the framebuffer and rendering could be really useful. CPU optimizations might still be useful for targets with less processing power than the Raspberry Pi B. |
No description provided.
The text was updated successfully, but these errors were encountered: