I have recently started using Nintendulator to assist in debugging my emulator, but out of nowhere it started running really fast (170fps) instead of 60fps. I cannot see what might be causing this issue. I have tried completely deleting all the files and then unzipping them again, but I run into the same issues. If I choose 1/2 speed or something similar, it behaves as you'd expect by running at half speed, but as soon as I try and return to normal speed, it jumps back up to 170fps.
I am using the latest stable version of Nintendulator 0.970.
Any help would be appreciated.
It does that if you disable sound.
Did you disable sound perhaps? (Ctrl+s)
Nintendulator moves way too fast on my computer when I do this.
edit: ninja'd
thefox wrote:
It does that if you disable sound.
Wow. Thanks. Who would have known?!
Is there any reasoning for this?
I actually once sent Quietust email about this and he said it was "by design"... it's still pretty stupid and makes the whole option of disabling sound almost useless. Fortunately Windows Vista and Windows 7 has separate audio volume controls for each application.
Timers on a PC tend to be inaccurate, achieving exact timing is hard.
However, a sound card is usually the most accurate timer available. This is because your ears notice differences more than your eyes. If it drifted as much as other timers things would sound too fast or too slow.
Rendering a frame of sound and playing it back is an easy way to achieve accurate timing and avoid choppy sound.
Disabling sound playback would mean the program finishes playing sounds immediately. It would render the next frame immediately, instead of waiting.
I have no idea if this is the case here, but that would be my guess.
Hamburgler wrote:
Disabling sound playback would mean the program finishes playing sounds immediately. It would render the next frame immediately, instead of waiting.
Then why can't it switch to waiting for PC vertical blank, doing some sort of Bresenham state machine to compensate for (say) a 75 Hz PC emulating a 50 Hz NES, instead of waiting for the empty audio buffer?
Because everyone uses different refresh rates?
EDIT: You modified your post to include the bresenham idea. It could work I guess.
Because implementing a separate timing system just so you could disable audio wasn't worth the work? It'd be simpler to just send silence to the sound card than implement that.
The biggest reason to use audio for timing is that if you use video for timing, then audio will have buffer over/underruns. You can only have one master timebase.
Hamburgler wrote:
However, a sound card is usually the most accurate timer available.
Hardly. Multiple clock timers exist on x86 architecture, and all have variance in their accuracy. ACPI, HPET, i8254, and TSC are four common ones which I can name, in order of preference/accurancy. HPET should be more than sufficient under Windows.
How do you interface with these under Windows? I've no idea, but I'm absolutely certain there's Win32 calls for setting up such.