Frame timing

[Bart]

How does Fighting Vipers 2 run in-game and does it fix the timing of the music and the intro?

Note the way we do VBL is totally wrong: the cycle times are computed empirically to make the games work and there's a lot of hackiness in there. It's very wrong. There should be a consistent timing. The ratio of VBL to frame time ought to be fixed.

It's definitely possible that interrupts are triggered at different times, although I know many of them really are triggered per-frame (I saw this when I was running code on the actual board but didn't dig any deeper).

[Ian]

I'll try it

[Ian]

seems to be okay
fighting vipers is not really a game i've ever played

[Bart]

If you look at RunFrame(), Nik put in quite a hack to make it run full speed. It's a Step 2.x game but uses Step 1.5 frame timing. Also, try sitting through the introductory cinematic sequence. The music ends way too early. Granted, timing of the music is off anyway, but I don't think the error is that large (or maybe it is). It looks to me like the sequence periodically speeds up and slows down.

[Ian]

I'm going to have a tinker with those when i have a few
it's pretty hard working this stuff out by guess work

[Bart]

Feel free to give it a go The end result should be consistent if it's correct. I still think that the rendering is triggered on a write to the flush port (and perhaps the hardware is smart enough to know not to do anything if it's already busy).

[Ian]

Bart, we need some mechanism to drop frames if the database is not complete. I guess the hw won't always hit 60 fps. Ie in-between 0x88 calls

[Ian]

Would it make sense to just ignore 3d timing for a bit and maybe look at the 2d timing?
The tilegen I guess isn't double buffered at all, there is no front/back buffer for it?
So all the data for it is probably uploaded in the vblank period

Scud has many of these

[Bart]

Bart, we need some mechanism to drop frames if the database is not complete. I guess the hw won't always hit 60 fps. Ie in-between 0x88 calls

I don't have a reliable example of your engine crashing. Can you produce a save state? I'm thinking it should be as simple as setting a flag (cleared every frame) that indicates whether 0x88 has been written by the time that the render call is made?

[Bart]

Would it make sense to just ignore 3d timing for a bit and maybe look at the 2d timing?
The tilegen I guess isn't double buffered at all, there is no front/back buffer for it?
So all the data for it is probably uploaded in the vblank period

Scud has many of these

I can't view imgur links at work so I'll check out the image tonight from home but I can confirm with 99.9999999% certainty that the tile generator uses no buffering of any kind and draws in sync with the raster beam. You are absolutely correct that the data for the tile gen should be uploaded during the VBL period. This is how it was done on every other tilegen-based system from the 80's and 90's that I've looked at (with the exception of intentionally updating mid-frame during HBL in order to create fancy effects; not applicable here).

I've made the most progress with Scud Plus's inner loop but that's not saying much: I haven't translated most of it. I may not need to. When I get some time, I'll try to piece together roughly the order in which things are done.

Fighting Vipers 2 would require a deeper dive because it seems to be doing something more complicated with respect to timing.