Hello everyone,
As many before, I'm writting a NES emulator. That's a very cool adventure so far, and after many effort I have a working version. That's mainly because of all the valuable information I found here.
However, there is something that I absolutely don't understand.
My CPU implementation is executing instructions as fast as possible (but well it's not quite that fast by the way), and the PPU is rendering scanline 1 by 1 as fast as possible. I'm attributing ~114 cycles to the CPU, then render 1 scanline, then back to the CPU etc ...
For some reason, the games I'm able to start, and that run a demo (such a donkey kong, or mario bros) run at an "expected" speed. I was thinking that I had to implement some kind of speed adjustment to stick to the 6502 frequency, or that the games execution will be sloppy and changing: but it seems it's not the case.
Maybe the answer lies only in my code, but well, I was thinking that maybe there is an obvious explanation...
emulation speed
Moderator: Moderators
Re: emulation speed
Game logic pretty much always waits for NMI. If you emulate a bunch of extra scanlines, or extra cycles per scanline, normally those cycles will be spent simply waiting in the idle loop.
Re: emulation speed
It is also possible that your code is waiting for the frame buffer which refreshs at 60 fps.
Re: emulation speed
Direct3d present waits for a frame.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
-
nIghtorius
- Posts: 59
- Joined: Tue Apr 29, 2014 1:31 pm
Re: emulation speed
If above is the case (vsync). Please do not rely on it.
That are people with 120hz/144hz/240hz or even crazier refreshrates. Relying on 60hz refreshrate for you emulation speed WILL break pacing on those beforementioned setups.
My first emulator I used a high precision timer. First get the time before rendering a frame. And then after the frame get the next timeframe. is not "desired" framerate (it is always faster) then wait till the ~16ms has passed before putting the next frame on screen. You need EXACT precise timings other you get pops in your audio.
My second emulator uses the audio emulation. This way i can input the clockspeed of the 2a03. By resampling the audio stream with the amount of samples computed with the 2a03 clockspeed I can thottle/pause emulation till an audio frame has completed playing. (Buffer 3 frames in front of it to suppress stuttering)
Added benefit is when you want to speed up emulation you just give a higher clockspeed. The sound speed/pitch also increases when you do. Speed is 100% accurate on 60/120/144/240/360 or higher hz displays.
That are people with 120hz/144hz/240hz or even crazier refreshrates. Relying on 60hz refreshrate for you emulation speed WILL break pacing on those beforementioned setups.
My first emulator I used a high precision timer. First get the time before rendering a frame. And then after the frame get the next timeframe. is not "desired" framerate (it is always faster) then wait till the ~16ms has passed before putting the next frame on screen. You need EXACT precise timings other you get pops in your audio.
My second emulator uses the audio emulation. This way i can input the clockspeed of the 2a03. By resampling the audio stream with the amount of samples computed with the 2a03 clockspeed I can thottle/pause emulation till an audio frame has completed playing. (Buffer 3 frames in front of it to suppress stuttering)
Added benefit is when you want to speed up emulation you just give a higher clockspeed. The sound speed/pitch also increases when you do. Speed is 100% accurate on 60/120/144/240/360 or higher hz displays.