NMK Sprite Priority Fixes

[trap15]

I recently fixed the NMK sprite priorities in MAME. You can get the fixed src/mame/video/nmk16.c from our blog post: http://www.raidenii.net/2012/01/nmk-priority-fixes/.

If people would like to supply builds, I'd imagine most people would appreciate it

[IseeThings]

I recently fixed the NMK sprite priorities in MAME. You can get the fixed src/mame/video/nmk16.c from our blog post: http://www.raidenii.net/2012/01/nmk-priority-fixes/.

If people would like to supply builds, I'd imagine most people would appreciate it

'Magic' tables? Looks like a hack to me, I'd say it works more by chance than because it's correct.

Try to derive the data from the PROMs instead of hardcoding such tables, there are PROMs on all these boards, chances are if you feel you need per-game hacks as you have now then such data should be derived from them, it's basically the same collection of chips in all games (maybe 2 chip revs) except the ones on 'bootleg' hardware like Manybloc.

[trap15]

The 'magic' table was derived from the game code itself, and I'm fairly sure it's the same in PROMs on-board. I don't have a board, and unless someone else wants to check the values on the PROMs for me, I don't think I can really change it.

If I had renamed it from magic to priority_table, would that have made it sound less hacky?

It's also not really a hack when it works and makes sense.

[emphatic]

This is excellent. Will this affect enemy speed/placement in Hacha Mecha Fighter so that it'll be playable in MAME?

[trap15]

The only thing these fixes affect are sprite drawing priority. I'm unaware of such an issue with hachamf, but I may look into it later if I can get a description of what is different between PCB and MAME.

[IseeThings]

The 'magic' table was derived from the game code itself, and I'm fairly sure it's the same in PROMs on-board. I don't have a board, and unless someone else wants to check the values on the PROMs for me, I don't think I can really change it.

If I had renamed it from magic to priority_table, would that have made it sound less hacky?

It's also not really a hack when it works and makes sense.

The proms are in the sets (at least most of them, in cases where they're missing they should be marked as such)

Hardcoding magic value tables into a driver, when the data is potentially there is a hack, and results in far more code than necessary being in the driver.

The HMF issues are protection related, decapping the chips responsible would be the ultimate solution, but it should be possible to figure out anyway. AFAIK for all the bitching that goes on about it nobody has made a concise report on Mametesters showing the exact differences with video evidence yet.

[austere]

It's just a bit swap of bits 0 and 3. I know nothing about this board, but it could be done without a gate, just a twist on the traces flowing into the VDP.

Should be labelled as a bit-swap table rather than a "magic" table, however.

[trap15]

I have updated the posted source, renaming 'magic' to 'swaptbl', and reverting the incorrect tables to use straight-through values (no swaps). These are still incorrect though, unfortunately. I'll need to wait for Dave_K or someone else with these boards to come online so I can get them to tell me some priorities that real boards use.

[emphatic]

I meant to shoot a video of Hacha Mecha Fighter's demo sequence for a while now, but I've forgotten. And now I'm too busy elsewhere.

[Dave_K.]

I'm happy to help verify bugs/fixes for the following NMK games:

USAAF Mustang
Black Heart
Hacha Mecha Fighter
Macross
Gunnail
Thunder Dragon 2
Bombjack Twin
Macross II
Rapid Hero
Zed Blade
P47 Aces
Desert War

[IseeThings]

It's just a bit swap of bits 0 and 3. I know nothing about this board, but it could be done without a gate, just a twist on the traces flowing into the VDP.

Should be labelled as a bit-swap table rather than a "magic" table, however.

If it's just a swapping of lines on the board it should be done somewhere with the BITSWAP macro tho...

really, I'm just dubious about it tho, while it clearly appears to work, it could just be coded around game specific behavior, rather than 'how the hardware works', hence it not working correctly with other games.

Ideally the sprite chip should be identified, and it should be checked if any lines are going through the proms. Having to do multiple pass drawing is odd in itself, although clearly neccessary with these games because there IS something a bit odd going on with the priorities. Given the way the sprites reside in main RAM it's possible that some device (possible the video controller) is DMAing them to private buffers, with an element of priority based sorting separate to the actual render stage. There almost certainly is *some* kind of private buffer to do such because all games need the sprites buffered / delayed by at least one frame, some appear to need it by 2, although I do wonder if those don't just suffer from sprite desyncs on the original HW. I'd guess actually there is no pre-sorting, but writing and checking of sprite priority data in a linebuffer when rendering, because actual sorting would be more expensive in terms of hardware IMHO.

[trap15]

I used a table instead because it should be a deal faster than BITSWAPping a bunch. I don't mind if you go ahead and switch it to use BITSWAP, it was just a speed concern.

[IseeThings]

I used a table instead because it should be a deal faster than BITSWAPping a bunch. I don't mind if you go ahead and switch it to use BITSWAP, it was just a speed concern.

Speed is only a concern if it causes noteworthy issues on a system which could be considered 'current'. I can't imagine a few BITSWAP calls for each sprite causing it to be pulled below 100% even on a previous generation PC

Looking at the proms in the sets they don't really seem to represent anything that resembles such, so it's possible they're unrelated to the sprites and it is just a few lines swapped around somewhere, still, it would be nice to know what's going on from a hardware perspective, because the inconsistency across games does concern me.

[IseeThings]

Well given the lack of other progress / findings on this the work that was done has been applied.

I'm not sure it's correct tho? Are the medals REALLY meant to go over the clouds in Thunder Dragon 2? I've used the version of the fix that was included in MAMEFX (due to the original not being posted as a diff, and thus no longer compiling) but that looks.. odd.

[Dave_K.]

Yes, this is how the PCB plays. If you played Rapid Hero you'd see medals that swing left to right going behind objects in stage 3, and this fixes that as well, so I didn't understand your previous comment about the fix being game specific.

[IseeThings]

Yes, this is how the PCB plays. If you played Rapid Hero you'd see medals that swing left to right going behind objects in stage 3, and this fixes that as well, so I didn't understand your previous comment about the fix being game specific.

by their own admission the code doesn't work for all the games, and still looks a bit suspicious, but if it works I'm not ruling it out, the whole hardware platform is a bit of a hack in the first place. Their coding style actually makes it look worse because they have the magic table duplicated in each video update, making it look like a game specific hack, when really most games have the same setup, and as discussed above it's effectively just a lineswap. It's possible the ones that it doesn't work for are using a different revision of the sprite chip, we've already seen some games don't have sprite flip support and some do.

Interesting that it's correct behavior anyway, IIRC it was *fixed* so that they went under them before based on somebody adamant that the behavior we had was wrong. Several videos on Nicovideo and the like had them going under the clouds too, but I guess they must have been created with other emulators then.

It looks ugly and wrong, but it's good to know it's right. Shame there are no original videos to point people at when they suggest it to be a bug in future.