R-Type II sprite background error

Alessandro1970 commented 5 years ago

R-Type II intro does not work and after press LMB vAmiga hangs.

Game: R-Type II (1991)(Activision)[cr SKR][t +6 LGD].adf.zip

Crash Report: report.txt

Intro screen before pressing LMB:

dirkwhoffmann commented 5 years ago

vAmiga is improving slowly, but steadily...

dirkwhoffmann commented 5 years ago

Issue in the middle has been fixed (was a shift register issue that came up when the number of enabled bitplanes got reduced):

Remaining issue is a color problem in the ticker line at the bottom:

Reference:

vAmiga:

I expect Copper timing to get out of sync when switching over to the next scan line.

TODO: Add a color test to vAmigaTS repo that lets Copper cross the HSYNC boundary.

dirkwhoffmann commented 5 years ago

Two issues identified:

[569] ( 96,212)  070020 BCB-D- 606C 0000 [0701FA] Copper: COPPC: 701FA move(COLOR00, $FFF) (4095)
[569] ( 96,214)  070020 BCB-D- 606C 0000 [0701FA] Agnus: Copper blocked by bitplane DMA
[569] ( 96,218)  070020 BCB-D- 606C 0000 [0701FE] Copper: COPPC: 701FE move(COLOR00, $4F4) (1268)
[569] ( 96,222)  070020 BCB-D- 606C 0000 [070202] Copper: COPPC: 70202 move(COLOR00, $0) (0)
[569] ( 96,226)  070020 BCB-D- 606C 0000 [070206] Copper: COPPC: 70206 move(COLOR00, $FFF) (4095)
[569] ( 97,  3)  070020 BCB-D- 606C 0000 [07020A] Copper: COPPC: 7020A move(COLOR00, $4F4) (1268)
[569] ( 97,  7)  070020 BCB-D- 606C 0000 [07020E] Copper: COPPC: 7020E move(COLOR00, $F00) (3840)

Copper is granted bus access in the last DMA cycle (226, $E2). It has to be denied.
When crossing the HSYNC boundary, Copper starts to use the odd DMA cycles which is totally wrong.

dirkwhoffmann commented 5 years ago

😎

dirkwhoffmann commented 5 years ago

Let's see how this intro continues...

Oh no 🙈:

dirkwhoffmann commented 5 years ago

Graphics error was due to a dual playfield bug. Now it rocks:

Time to bring the game on 😎... click ... damn 😖.

Assertion failed: (isDue<REG_CPU_SLOT>(amiga->masterClock)), 
function scheduleRegEvent, file EventHandler.cpp, line 832.

No need to panic though, I expected this to happen eventually. I need a more sophisticated REG_CPU_SLOT handler (which is responsible to delay register writes triggered by the CPU).

dirkwhoffmann commented 5 years ago

😎

There might be an issue with the CIAA shift register though (which is connected to the keyboard). The game queries the interrupt bit in CIAA::ICR explicitly and the game recognised a key press only when the key is held down for about half a second. TODO: Check if the IRQ bit gets deleted by the keyboard if a key is released.

dirkwhoffmann commented 5 years ago

Keyboard issue is fixed (was a subtle bug in CIA::peek() that also affects VirtualC64).

If somebody wants to give R-Type II a try in vAmiga, please download the latest alpha version:

http://www.dirkwhoffmann.de/vAmiga/vAmiga_0.29.zip

It's playable until the cave (or spaceship?) comes up... this is where graphics glitches begin to appear...

dirkwhoffmann commented 5 years ago

The DMA inspector shows sprite activity exactly in those line where the graphics errors happen.

I therefore conclude that the dark erroneous parts are sprites and they are supposed to be there. They are just not supposed to be in the foreground, but in the background. vAmiga always draws sprites in the foreground at the moment 🙄.

I guess the issue goes away once the sprite code has been refined.

BTW, this game is the winner w.r.t. DMA activity (Copper is on fire 🤯).

dirkwhoffmann commented 5 years ago

Intro is broken in the current built:

Last verified working version: V029.1

dirkwhoffmann commented 5 years ago

Intro broke with commit 05bb30b. It's working again.

Still working on sprite / bitplane priorities. It turned out to be harder than expected, because I need to rework vAmiga's graphics pipeline (again). The former 2-pass process had to be replaced my 3-pass process:

Pass 1: Capture bitplane data
Pass 2: Translate bitplane data to color register indices and build a zBuffer.

Translation is needed for dual-playfield mode, z buffering is needed for proper sprite handling.
Pass 3: Translate the result into RGBA values and write them into the screen buffer that is later read by the GPU.

Pass 1 is done by Agnus during emulation. Pass 2 and pass 3 are performed by Denise in the hSync handler.

dirkwhoffmann commented 5 years ago

With the new z buffer, it's now possible to draw sprites in the background.

TODO: Add some sprite tests to vAmigaTS repo.

dirkwhoffmann commented 5 years ago

Now it looks like this (haven't verified yet how it is supposed to look):

dirkwhoffmann commented 5 years ago

Just played it on the real device 😎. The darker background image is supposed to be there and it's really supposed to look like in vAmiga. On a real Amiga, however, it spans over the whole screen.

Need to play the game a little further. Unfortunately, I usually get killed before reaching the interior of the space ship.

Alessandro1970 commented 5 years ago

Now the intro works, this can be closed.

dirkwhoffmann commented 4 years ago

R-Type II uses horizontal sprite multiplexing as explained here:

https://codetapper.com/amiga/sprite-tricks/r-type-2/

Now it's perfectly clear why vAmiga doesn't draw the background correctly. Need to think about an efficient solution how to implement this...

dirkwhoffmann commented 4 years ago

Horizontal sprite multiplexing in action 😎:

dirkwhoffmann / vAmiga

R-Type II sprite background error #86