New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Who Wants to Be a Millionaire (USA) flickering screens #259

Open
benderscruffy opened this Issue Oct 27, 2018 · 10 comments

Comments

Projects
None yet
3 participants
@benderscruffy

benderscruffy commented Oct 27, 2018

during the videos the bottom screen keeps flickering

@zeromus

This comment has been minimized.

zeromus commented Oct 30, 2018

please cross reference TASVideos/desmume#210 your issues

@StapleButter

This comment has been minimized.

Owner

StapleButter commented Nov 5, 2018

not quite the same deal here tho. tweaking DMA timing doesn't affect it.

but, it goes away if you disable threaded 3D.

this is some assfucking mindboggling issue where the VRAM mapping is being changed while the threaded renderer is still rendering.

@StapleButter

This comment has been minimized.

Owner

StapleButter commented Nov 5, 2018

VBLANK
[215] threaded render start
[243] MAP VRAM B. 8B->80
ARM9 DMA3 84003000 00 020691C4->06825980 49152 bytes 32bit
[261] threaded render done
VBLANK END
ARM9 DMA3 over
[003] MAP VRAM B. 80->8B

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)

@zeromus

This comment has been minimized.

zeromus commented Nov 5, 2018

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

@StapleButter

This comment has been minimized.

Owner

StapleButter commented Nov 5, 2018

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.

@zeromus

This comment has been minimized.

zeromus commented Nov 5, 2018

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).

@StapleButter

This comment has been minimized.

Owner

StapleButter commented Nov 5, 2018

that might do it, yeah, but it's kind of a hack. the whole "unmap texture VRAM at scanline 243" isn't normal behavior. I quickly tested the same thing on hardware and it results in a big nice black line, so it's not something you should attempt doing.

@zeromus

This comment has been minimized.

zeromus commented Nov 5, 2018

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

@StapleButter

This comment has been minimized.

Owner

StapleButter commented Nov 5, 2018

indeed, noting that the timing in melonDS is still pretty much utter shit

anyway, progress!

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)

@zeromus

This comment has been minimized.

zeromus commented Nov 5, 2018

☑️ HLE the decoding, make it take 0 ticks, call it a day

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment