CRT in extreme slow motion
Moderator: Moderators
CRT in extreme slow motion
I saw this on reddit retrogaming.
They play SMB with a super slow motion camera. The NES relevant video is between 1 and 4 minutes.
https://youtu.be/3BJU2drrtCM
They play SMB with a super slow motion camera. The NES relevant video is between 1 and 4 minutes.
https://youtu.be/3BJU2drrtCM
nesdoug.com -- blog/tutorial on programming for the NES
Re: CRT in extreme slow motion
I thought it a little amusing that at the peak 380kfps, there's roughly about one instruction completing for each recorded frame.
Re: CRT in extreme slow motion
And here we see the 1 frame of input lag inherent to almost all NES games.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: CRT in extreme slow motion
Really? Can you elaborate?Dwedit wrote:And here we see the 1 frame of input lag inherent to almost all NES games.
- mikejmoffitt
- Posts: 1353
- Joined: Sun May 27, 2012 8:43 pm
Re: CRT in extreme slow motion
This depends on what you call a frame of lag. I don't think it's reasonable to poll for inputs in any game until an entire frame has been rendered; i.e. during vblank. Even modern displays still scan like the CRT does, and nothing here is intrinsic to NES games.Dwedit wrote:And here we see the 1 frame of input lag inherent to almost all NES games.
If you're polling inputs to process the logic for frame [n+1] at the end of frame [n], I would consider this zero frames of lag.
Re: CRT in extreme slow motion
NES games run the game logic during render time. So when the pixels are rendered, you get the game state of the last frame. So all NES games have a minimum of 1 frame of lag between your input and the output being reflected on the screen.
Compare this with the Atari 2600 - Games for that system run the game logic during vblank time, and the game races the beam to render the screen. No possible input lag at all.
NES Emulators could be made to compensate for the 1 frame of internal input lag by using time travel (savestates), but I don't know of any NES emulators that do this. I have seen Genesis emulators do this though.
Compare this with the Atari 2600 - Games for that system run the game logic during vblank time, and the game races the beam to render the screen. No possible input lag at all.
NES Emulators could be made to compensate for the 1 frame of internal input lag by using time travel (savestates), but I don't know of any NES emulators that do this. I have seen Genesis emulators do this though.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: CRT in extreme slow motion
I'm toyed with the idea of making a <1800 cycle thing in the vblank, then DMAing to get rid of the lag, for no other reason than just because.
Re: CRT in extreme slow motion
For what it's worth, my Simple button logger tool runs all logic and graphical updates within vblank.
The soon to be manufactured Action 53 volume 3 has the most up to date version of it.
The soon to be manufactured Action 53 volume 3 has the most up to date version of it.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: CRT in extreme slow motion
Wow, the NES has 10 times as much cycles in one frame than the Atari has during V-blank.
-
- Posts: 318
- Joined: Mon Jan 30, 2017 5:20 pm
- Location: Colorado USA
Re: CRT in extreme slow motion
But to be fair, most, if not all of the graphics rendering is done simultaneously with the TV scanning, so it’s able to do more game logic during V-blankpsycopathicteen wrote:Wow, the NES has 10 times as much cycles in one frame than the Atari has during V-blank.
Re: CRT in extreme slow motion
It's more like... 5 times, no?psycopathicteen wrote:Wow, the NES has 10 times as much cycles in one frame than the Atari has during V-blank.
Re: CRT in extreme slow motion
Most 2600 kernels seem to render 256x192, so that should be 228÷3×(262-192) = 5320 cy
I assume the 10x was assuming a full 224 scanlines rendered on the 2600 (leaving 2888cy during vblanking), but few games did that because it's just so little time.
I assume the 10x was assuming a full 224 scanlines rendered on the 2600 (leaving 2888cy during vblanking), but few games did that because it's just so little time.