Yeah, that's an option, but RAM isn't a very abundant resource on the NES. Also, even though the PAL VBlank is longer, the rendered frame is shorter (in CPU cycles of course, it is the same as the NTSC one visually), so the fact that you'll have to fill more buffers during that time is more likely to cause slowdown.tepples wrote:But PAL's vblank is over three times as long. So if you have the RAM to spare for a bigger transfer buffer, and you have some CPU time to spare, you could design the engine so that the PAL version's camera can move faster.
Controlling Play Speed
Moderator: Moderators
I'm not sure I understood what you meant. Did you mean something like this?tokumaru wrote:Tom, you might be able to deal with these problems by using a flag system similar to the one used for PPU stuff
Code: Select all
start_sound_effect:
; ProtectionFlag should be 0 here
inc ProtectionFlag
; change sound engine memory
; check if nmi interrupted us
lda ProtectionFlag
bne skip
; nmi happened, and skipped update, so do it now
jsr update_sound_engine
skip:
lda #0
sta ProtectionFlag
rts
nmi:
lda ProtectionFlag
beq nmi_update_music
; in middle of critical code, delay update until after it's done
lda #0
sta ProtectionFlag
rti
nmi_update_music:
jsr update_sound_engine
rti
Interesting. My sound engine doesn't distinguish music and sound effects, so I hadn't thought of that. Still, I think the problem is theoretical; I can't think of any existing game where the sound effects need to be synchronized with the animation. It still bugs me a little.tokumaru wrote:As for the sound effects, remember that the NMI routine has ways to know if a frame was missed or not, so as long as your sound engine knows the difference between music and sound effects it can delay the sound effects in case of lag frames.
True, these types of games require synchronization. But I was thinking more generally. For instance, consider a FPS, which has a machine gun. If the animation for firing the gun includes showing shell casings, you'll want to make sure the sound of the shell casing happens in sync with the animation. But on the NES, both animations and sound effects are lot simpler, so I can't think of existing NES games where this would matter (D+Pad Hero excluded).tepples wrote:Parappa. Beatmania. Frequency. Amplitude. Guitar Hero. DJ Hero. D+Pad Hero.Tom wrote:I think the problem is theoretical; I can't think of any existing game where the sound effects need to be synchronized with the animation.
Then the shell casing should be a separate sound effect that starts when the animation starts.Tom wrote:For instance, consider a FPS, which has a machine gun. If the animation for firing the gun includes showing shell casings, you'll want to make sure the sound of the shell casing happens in sync with the animation.
Yup, exactly that! =)Tom wrote:Did you mean something like this?
Well, to be fair, stretching them by skipping updates will probably just make them sound wrong, so it's not really a good solution.I can't think of any existing game where the sound effects need to be synchronized with the animation. It still bugs me a little.
In every game I can think of, it's important that sound effects begin at the correct time, but if by any chance the video lags that doesn't really result in any weirdness.
As for the games tepples listed, I wouldn't expect those kinds of games to drop frames, since they aren't very CPU-intensive. I mean, how complicated is it to move a few graphics around and match input to internal tables?