2D Graphics animation

[Bart]

It's probably a sync issue. The 3d runs independently in it's own thread. The powerpc just queries the registers when it feels like it. The line of sight registers get automatically reset at the beginning of the frame. Just need some way of syncing them better

You're referring to the lens flare effect right? If so, it should work when -no-threads is used but it seems not to be the case. The missing 2D animation is interesting (I assume it was done with the 2D layers and not 3D graphics). Definitely seems to be timing related.

[Bart]

I wonder if this could shed some light on the Rolling Start bug. I just checked and am pretty sure the effect is created simply by scrolling the layers at the appropriate time.

[Bart]

I think I found the specific change that causes the 2D animation to fail:

Code: Select all

TileGen.BeginVBlank();
GPU.BeginVBlank(statusCycles);  // Games poll the ping_pong at startup. Values aren't 100% accurate so we stretch the frame a bit to ensure writes happen in the correct frame

ppc_execute(offsetCycles);
IRQ.Assert(0x02);               // start at 33% of the frame
ppc_execute(gapCycles);         // need a gap between asserting irqs


Removing ppc_execute(offsetCycles) or having it occur after the IRQ almost fixes the animation (I say almost because it introduces some crazy flicker). I know it's completely wrong and makes no sense (plus it slows the game down dramatically). I wonder if this has to do with the relative ordering of the ping pong bit flip and the IRQ? As Supermodel currently operates, the ping pong bit flip will occur very quickly within the ppc_execute(offsetCycles) block (it is set to fire after 0.5% of a frame's worth of cycles have executed). I wonder if the animation update logic gets confused about which frame it is on, failing to update the scroll registers in the process.

This is a tricky one to test because you have to sit through the entire initial attract mode loop (all four cars) before the animations occur (they happen on every other attract mode loop). Save states aren't too helpful because the game samples its timing at the beginning, so you can't trust what you see after loading a state if you've made changes to Model3.cpp.

[Ian]

Yeah the lense flare effect probably only really works with threading disabled. I figured if I double buffered the line of sight values and added a mutex it would probably fix it for when threading is enabled. Might be a 1 frame delay with regards to emulation but that is not a deal breaker.

I know about the 2d car animation in scud but never really looked into it but I know the problem exists. I'd say most of the remaining bugs relate to the tilegen. Like if you look at the post in dev forum about the Japanese version of scud. For whatever reason it just never updates the palette. There is be something we are missing with regards to the tilegen. Maybe missing irq or something

[Ian]

I had a debug of the 2d scrolling car thing.
The per line scroll values are written as expected to the hardware, only the bit in the register is never set that says "use line scroll values". So instead it uses the regular scroll value for the whole window, which is just set to 0.

[Bart]

I had a debug of the 2d scrolling car thing.
The per line scroll values are written as expected to the hardware, only the bit in the register is never set that says "use line scroll values". So instead it uses the regular scroll value for the whole window, which is just set to 0.

That's odd. When the timing is reverted to the old version, are there then two writes per frame (a second that enables the bit) or is the value of this bit determined somehow by the timing before being committed just once per frame?
I'm quite surprised by the complexity and timing sensitivity of the 2D updates. It should be a straightforward manner: update tiles and scroll values during VBL. That's how most 2D tile-based systems work.

[Ian]

Well I found the issue. Nothing too crazy although really not sure how best to fix it.
Basically it writes to the registers twice in a frame.

First one happens after the real3d status bit flips.
Second time happens during v-blank or when IRQ2 is fired.

Looks like this

swap buffers
Tile generator registers 2
tile gen 64 = 80008000 <-- first write turns on line scrolling
Tile generator registers 2
tile gen 68 = 80008000
Tile generator registers 33
tile gen 60 = 80000000
Tile generator registers 33
tile gen 64 = 80000000 <-- second write turns it off
Tile generator registers 33
tile gen 68 = 80000000
Tile generator registers 33
tile gen 6C = 80000000
Tile generator registers 33
tile gen 10 = 00000002
Tile generator registers 35
tile gen 10 = 00000004
Tile generator registers 35
tile gen 10 = 00000008
WritePolygonRAM 38
WriteHighCullingRAM 46
flush 46
Tile generator registers 46
tile gen 0C = 00000003
swap buffers

The numbers at the end indicate at what % of the frame they were written at. So 33 is 33% of the frame time. Also irq2 fires at that point ..

Anyway we use the number that is written during v-blank, since that is the last value written. The first value is essentially written at 66% of the time after v-blank, so really in the middle of the frame somewhere. The gfx are at the bottom so changes probably show up mid frame.

Maybe the only way to emulate that is to draw a line of the tilegen for every time slice, instead of just at the end of the frame. Not sure I care to emulate at this level but I guess it would fix this particular issue.

[Bart]

Well I found the issue. Nothing too crazy although really not sure how best to fix it.
Basically it writes to the registers twice in a frame.

First one happens after the real3d status bit flips.
Second time happens during v-blank or when IRQ2 is fired.

Looks like this

swap buffers
Tile generator registers 2
tile gen 64 = 80008000 <-- first write turns on line scrolling
Tile generator registers 2
tile gen 68 = 80008000
Tile generator registers 33
tile gen 60 = 80000000
Tile generator registers 33
tile gen 64 = 80000000 <-- second write turns it off
Tile generator registers 33
tile gen 68 = 80000000
Tile generator registers 33
tile gen 6C = 80000000
Tile generator registers 33
tile gen 10 = 00000002
Tile generator registers 35
tile gen 10 = 00000004
Tile generator registers 35
tile gen 10 = 00000008
WritePolygonRAM 38
WriteHighCullingRAM 46
flush 46
Tile generator registers 46
tile gen 0C = 00000003
swap buffers

The numbers at the end indicate at what % of the frame they were written at. So 33 is 33% of the frame time. Also irq2 fires at that point ..

Anyway we use the number that is written during v-blank, since that is the last value written. The first value is essentially written at 66% of the time after v-blank, so really in the middle of the frame somewhere. The gfx are at the bottom so changes probably show up mid frame.

Maybe the only way to emulate that is to draw a line of the tilegen for every time slice, instead of just at the end of the frame. Not sure I care to emulate at this level but I guess it would fix this particular issue.

I haven't studied the timing values you posted but read your message and I think I get what you're saying: the game is carefully timing itself to enable line scrolling for only the part of the visible frame that these animations exist on.

This is an *insane* way to do it. What were the programmers thinking? lol. This sort of approach is required for 8- and 16-bit systems, which heavily employed all kinds of timing tricks (e.g., underwater stages in Sonic the Hedgehog, which swap the palette at the scan line of the water level) but completely unnecessary here. They should have just used line scrolling across the board and just updated the values as needed once per frame.

I'll try to find some time this week to do it. Right now, rendering does basically operate on a per-line basis to support line scrolling, but we process all the lines at once. It won't be hard to just do a line at a time. I just hope the timing works out perfectly to encompass those offending lines.

[Ian]

I don't think it's carefully timed. It writes to the registers a 2nd time immediately after the real3d status bit flips. Scud does exactly the same with the scroll values for the rolling start. Not sure why it updates the tilgen here, it doesn't make sense.

If we generated the 2d gfx immediately before irq2 is fired it would fix it. But at the same time it couldn't hurt to draw the scanlines when they are meant to be drawn.