melonDS
melonDS copied to clipboard
melonDS-emu
Spellbound (Europe) corrupt line on menu
using 0.7.2
on the create menu there is a corrupt line between the two question marks
can't you see it? the question marks are bound by the spell of crapoed graphics
they're spellbound
/me runs
ok, looking into this bug now
'ts a big fat stinky timing issue. somehow SWAP_BUFFERS is issued right in the middle of a polygon.
further information on this, and other issues I suspect to stem from the same thing:
the game uses a custom reimplementation of DMA mode 7, where it sends 118 words to the GXFIFO every time it's less than half-full.
it starts the DMA, and sets the DMA function as a callback for the GXFIFO IRQ, which is set to trigger when it's less than half-full.
except after launching the DMA, it doesn't wait for it to be complete before going and doing other things (including sending other commands).
so, each time a DMA transfer completes, the GXFIFO must be less than half-full or nearly, so the next one starts immediately.
obviously at some point in melonDS that stops happening and that's why it shits itself.
found this
This is a comment of zeromus from The Sims 2 apartment:
"spellbound is a mystery. not related to this problem, which i just fixed.
after it draws the letters, it begins using a quadstrip to draw the question marks. it dmas 118 words and then pops the matrix with an immediate command. then it dmas 118 words again to continue the question mark. that is, the pop comes in the middle of the display list for no apparent reason. i can see it in no$ and there is not supposed to be any popping nearby. it isnt polling dma or gxfifo registers to see if it is finished executing the 3d yet. i think it is supposed to be doing this pop eventually since the matrix stack appears to be managed correctly. it isnt using a gxfifo dma which is supposed to be autotriggering. (the matrix contains the translate for each of the question marks, that is why it teleports back to the origin when the erroneous pop happens). i'll have to trace the code to find out why its doing this."
that's odd because it seems to be working correctly in DeSmuME.
regardless:
the game uses its own software implementation of GXFIFO DMA. it's set to transfer 118 words every time the GXFIFO gets less than half-full. it basically kickstarts the first DMA after having set up an IRQ handler that will start further DMAs when appropriate.
except it doesn't wait for those DMAs to complete before going and doing other things (like popping matrices or, in the case of melonDS, flushing in the middle of a display list, which is bad bad bad).
for this to work correctly, each time a DMA transfer completes, the GXFIFO must immediately be less than half-full so that the next transfer starts immediately. if there is any gap, it will think the transfers are complete, and it will shit itself.
--
so far in melonDS: with a fix to GX timing, it got better, but it's still not perfect. something's still biting us there and it better not be ARM9 cache contention.
--
edit- well right, that comment was from 2009.
and I just repeated myself lol
neaaaaarly fixed in latest revision!
there's still like one or two dots blinking in the middle
Still present on 0.9. On software mode appears immediately, on OpenGL after 5-10 seconds at 1x resolution
The glitch's behaviour seems to have actually changed multiple times since Arisotura's partial fix in 0.7.3. 0.7.3: Just a blinking dot. It doesn't stay for long at all. There seems to be a pattern of it appearing three times successively and then a pause. 0.8-0.8.3 Still a blinking dot, but it stays on screen longer and appears less frequently. It also appears in a constant rythm. Every time it appears, the same corrupted line that can be seen in the first post appears, probably for no more than a frame or two. 0.9: Same as in 0.8 but the corrupted line doesn't always appear when the dot appears. This was all using the software renderer. The OpenGL renderer behaves slightly differently, as pointed out above.
problem here is the timings of GXFIFO vs DMA. GX timings are affected by whether polygons pass clipping/culling/etc, and I still need to work on it.
