Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Who Wants to Be a Millionaire (USA) flickering screens #259
vcount=243 is quite early for unmapping VRAM, considering the renderer is running all the way to vcount=144 of the next frame.
I'd have to find out why the game is proceeding so early.
(note: VRAM bank B is used as texture memory, the 3D renderer is being used to display a fullscreen bitmap which is streamed from main RAM)
I don't remember it having anything to do with 3d. It's decoding videos, that should all be on the cpu. Note that dma is 48K (the 2nd half of a screen). It switches it to be displayed after the DMA is done, I guess from a CPU buffer (decode output) to a VRAM buffer. I would further guess that it's scanline 243 at which the decoding is done. It maps it to CPU immediately after that for DMAing to vram. But I didn't look up what those vram mappings mean right now, that's just matching your log to what I remember it doing + common sense
so, it's taking ~23 scanlines to do its DMA transfer. normally, it does so right upon VBlank, so it's done just before the 3D renderer starts drawing shit.
but, sometimes, it needs to take a shit or whatever, and it's delayed until scanline 243, which is bad.
I guess I'll have to crack open the game code to find out what it's doing.
Edit- oh, I was ninja'd
the relation with 3D is because it's using the 3D renderer to display its pictures, for whatever reason.
VRAM mapping 0x8B is texture memory. 0x80 is LCDC.
I guess that explains why it flakes out when so many other games don't, because that's a really weird and annoying thing to do.
I wonder if you could defer starting the 3d until any texture banks that would be needed are released back to the 3d unit. That might fix a number of games with races in the texture vram setup vs 3d texturing start (but I don't know what other games that is right now). You'd have to make a concise list of which banks are needed while assembling your vert list, then maybe evaluate the situation every scanline starting from when you'd like to begin the rendering.
Likewise, you could then 'lock' the texture memory until rendering is done (wait to rendezvous with the 3d thread any time the game tries to map vram in use back to cpu).
yeah, its a hack, but it's an accommodation for imperfect timing. the timing for any nds emulator is already hack city. Especially when it comes to timing big cache memory heavy cpu jobs, and....
...I guess in this case it's the cpu decode of the movie data that's taking too long? otherwise it should unmap the vram for dmaing to the vram before 3d rendering begins?
It's not too late for you to fiddle with your general cpu and memory timings, though. That ship has sailed with desmume
indeed, noting that the timing in melonDS is still pretty much utter shit
as far as melonDS is concerned, it appears that the video decoder (at 0x01FFD9E0) is taking too long to do its thing
which in turn causes the DMA to be delayed until scanline 243
I don't know what drives video decoding, doesn't seem to be a timer or any IRQ. but regardless, IRQs are kept disabled while it's running. (makes sense, you want it to finish asap)