Timing renovation, ep 4: world of shit
Took a while, but I have finally implemented the new memory timings, atleast CPU-side. DMA is not done yet, but will be quick to do.

Noting that these timings, atleast ARM9-side, would still be faster than the real thing, mostly due to not emulating cache misses and a lot of other little things. But it should be a lot closer.

And, how does that fare?

So much for that.

For now it's a total fucking trainwreck. Everything is running too slow and there are quite a few issues with it. For example, Rayman DS is slow as shit.

And even worse, the Millionaire FMV bug.

As it still happened, I extracted the FMV decoder code to run it within a test app. So it runs within the same conditions: code in ITCM, data it accesses in mainRAM, cache enabled over similar regions, etc.

What's the result? On hardware, the decoder is taking ~724 scanlines to run. Which means it actually spans over several frames, and, since it's set to start upon VCount=20, by the time it would be done, VCount would be 218. Which is past scanline 214, so under these conditions, we would be getting glitches on hardware too. And yet, the thing runs fine on hardware.

I don't fucking understand it.

I fail to see how all that is possible.

Unless libnds is changing some setting that radically affects timings.
extherian says:
Dec 7th 2018
Sounds like a job for JMC47. You definitely need another pair of eyes on these issues.

Do you have any idea why Who Wants To Be A Millionaire works properly without threading enabled? As you said, the way the decoder works should break it on both real hardware and the single-threaded renderer, yet it's fine on both. You've made a faulty assumption somewhere about why the decoder works at all.

I notice you've got a few pull requests from various people, but you don't have any serious brains on this project aside from your own. These timing issues are something that you could spend months on and have nothing to show for it. Have you considered asking any of the DeSmuME contributers (aside from Zeromus obviously) for their thoughts? You seem to be on reasonably good terms with Rogerman at least.

I wouldn't worry too much about performance. Once everything is working correctly, you can include a few tickboxes to disable certain things so that melonDS can run on something slower than a 10 GHz CPU. Accurately emulating anything faster than a SNES is futile with today's processors, but most games won't need "extreme accuracy mode" on all the time. As much as it goes against your philosophy of an accurate, hack-free emulator, there's just no getting around these issues for a modern console.
StapleButter says:
Dec 7th 2018
I posted an update to this, I was wrong about the FMV decoder timings.

As for the pull requests, need to review them. I'm always wary of third-party code. Last time I did merge a pull request, it ended up not working as intended and causing random crashes because it hadn't been tested thoroughly, so I had to fix it. Not to say they're all like that, but... yeah.

As for DeSmuME, its history is interesting for knowing which games cause problems, but... that's about it. Their approach to most game issues seems to be "throw together a hack that will make it work", or at best implementing assumptions without taking the time to do some hardware tests. Like how they dealt with GX timings: they made it artificially fast until their problem games weren't problematic anymore, all while still holding the old assumption that GX operations were entirely serial.

Post a comment