2D layer bitmap corruption

[HarryTuttle]

Bart, Ian I forward this to you:

lostw_01.png (152.71 KiB) Viewed 7517 times

It happens in Lost World (maybe others?). Save state here

[Ian]

I only have a limited understanding about how the tilegen works

[Bart]

That's bizarre. Nothing obvious as far as I can tell. The layer set up here is strange from initial inspection. Half of the layer is in the alt map and the other half is in the primary map. Why not just make it one single layer? I haven't actually dumped the name table values for layers 3 and 2 (the offending layer is layer 3) to see why one of them has garbage and the other doesn't. They must be different somehow.

I played all the way through Lost World back in the 0.2a days and I don't recall seeing this corruption. Are you using your timing changes? Also, I think returning incorrect values from certain tile gen registers can cause bizarre behavior and different tiles being written. For example, the Scud Race boot screen ends up having an aqua green color and even pattern corruption if a particular value is read back from one of the tile gen registers. I wonder if I screwed something up when I fixed Star Wars and added 16-bit accesses.

The corruption could have occurred when the pattern table was first loaded, so the save state might not mean much. I'll have to play through the game at some point and save before that level. This could be a tough one to track down.

If you see any other games with similar corruption, please let me know!

[HarryTuttle]

I've tested that with my build so, yes, timing patch applied. But the original tester, YoYo09 who posted in The Catwalk, probably is using the official build. Honestly I didn't ask him this detail.

However you're right on the fact that a saved state from someone else who, for whatever reason, got something corrupt in the middle of gameplay doesn't help a lot.

Once I downloaded a save state of Sega Rally 2 from someone reporting a gfx bug showing up at the very start of the championship first race; needless to say it was running the same (bad) with my build, however if I started from scratch or reset the emulator everything returned fine and I never knew what was wrong in his version.

[Ian]

Scudj still looks like this ..

[Bart]

That's a weird one, Ian, and it's always puzzled me but I haven't looked too deeply into it. If I remember correctly, what's going on there is that the layers are configured with the wrong color depth. Each layer's tiles can be interpreted as either 4-bit or 8-bit. My guess is that something happens during boot-up that causes it to program the registers incorrectly. Either that or the palette is screwed up. It's really weird because you'd think it would be as simple as writing a fixed set of values to the registers but in fact, the games read something from one of the registers that affects how they write to the tile gen. I don't understand why this is -- it's a very straightforward chip to program. In LA Machineguns, if you don't return a 0 from one of the registers, the game thinks the pitch of the layers is twice as big, and the 2D layer layout gets completely messed up.

[Bart]

By the way, Harry, I just had a go at Lost World and I think I got to the point where the corrupted tiles appear but in my game, they look fine. Here's the save state file for save slot 6. Can the person who submitted this try it out and see if the problem persists? I don't think it will but I just want to rule out an older version of the emulator as being the problem.

Is it just me or is Lost World the most disturbing arcade game ever? Like, why are we killing all these dinosaurs? And why do Ian and Sarah go through so much trouble to save the baby T. rex only to kill its parents as soon as they hand it over to them? WTF?

[HarryTuttle]

By the way, Harry, I just had a go at Lost World and I think I got to the point where the corrupted tiles appear but in my game, they look fine

Just checked and it's fine for me too. Well, good news at last. I suppose you're using the official build. Don't know why some people have all this gfx corruption going on (like Sega Rally 2 case mentioned before), I think that it'd be useful to write a simple testing guideline, few rules like clear nvram, use a specific gpu cycle, etc.

I'll tell the bug reporter to recheck.

Now a silly question: are we sure that all used roms, which are circulating since years, are/were checked as good dumps? Also in-game rom test usually fails some test, even for not patched games, is it an emulation issue?

[Bart]

If the game is unpatched, the CROM check should never fail. Do you have an example of this behavior? It would likely be an indication that the dump is bad. I'm not aware of any bad dumps, though.

Now, the VROM check is another matter. It always fails. The reason is that the PowerPC doesn't have direct access to VROM and uses some JTAG-based method of validating the VROMs. This will probably never be emulated, although if someone is a masochist, they can try to figure it out

[HarryTuttle]

Now, the VROM check is another matter. It always fails.

Ah, Ok! I was a bit vague with my question, infact the CROM never fails on unpatched games, VROM instead (and in some games the "boundary check", which I don't know what's about) fails. Thanks for the explanation.

This will probably never be emulated, although if someone is a masochist, they can try to figure it out

Not me... This is the kind of things that usually MAME dev are onto for emulation accuracy, maybe one day it'll be possible to port the code, who knows?

Also, somewhat related, I've seen that in the last months, if I recall, they've added some network board emulation code for the various Model hardware.