Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
06071 Documentation Trivial N/A Nov 11, 2015, 07:52 Nov 14, 2015, 15:38
Tester Arkhound View Status Public Platform MAME (Official Binary)
Assigned To Haze Resolution Fixed OS Windows Vista/7/8 (64-bit)
Status [?] Resolved Driver shadfrce.cpp
Version 0.167 Fixed in Version 0.168 Build Normal
Summary 06071: shadfrcej: Shadow Force (Japan Version 3) might be misnamed. Version is actually in English, not Japanese.
Description I suspect that ROM set known as "shadfrcej", which is currently labelled "Shadow Force (Japan Version 3)", is not actually a Japanese release for a couple of reasons.

1) "Japan Version 2" (shadfrcejv2) has Japanese text during cutscenes and conversations, whereas "Japan Version 3" is entirely in English.
2) shadfrcejv2 uses solely "32j" roms (e.g. 32j12-01.34, ect.), whereas shadfrcej has three "32a" roms. The parent shadfrce has five "32a" roms. The naming of 32a12-011.34 seems to imply that it's an updated version of 32a12-01.34.

It's possible that shadfrcej is actually an updated version for the U.S., or maybe a World version (due to the lack of the FBI warning screen), not necessarily a revision of the Japanese version.
Steps To Reproduce
Additional Information
Regression Version
Affected Sets / Systems shadfrcej
Attached Files
png file icon shadfrce0000.png (25,233 bytes) Nov 14, 2015, 15:38 Uploaded by haynor666
There are no relationsihp linked to this issue.
User avatar
Senior Tester
Nov 11, 2015, 17:18
edited on: Nov 11, 2015, 17:23
I'm inclined to agree.. and I doubt it only applies to Shadow Force. There are several games which have been picked up in Japan and therefore automatically been labelled as Japan sets

in this case it's a weird one, it ends up corrupting the high score table in one of the attract modes because it triggers the display of some text during the attract, maybe it's region hacked somehow.. I do find it weird that it uses a rom from the Japan version 2 too..
User avatar
Nov 11, 2015, 19:07
I'll mark this possible for now, but it is likely a correct assumption that this is some WORLD or ASIA version. When the rom was supplied, it was taken at the Dumper's word that it was "ShadowForce(Japan_Version_3)". The PCB layout in the driver was also with the submission might seems to suggest that even if the board was a japanese board, the rom letters would match non-japanese supporting some level of HACK.
User avatar
Nov 11, 2015, 20:29
edited on: Nov 11, 2015, 20:29
I noticed the glitched table score myself too, but I don't think it's a hacked version at all. "Japan Version 3" has all the 2P endings translated (such as that weird Blunet/Tengu wedding ending), which are impossible to get in "US Version 2" due to its forced Vs. Matches (which could be turned off in the other versions). The only things missing are the opening story sequence and the character bios during attract mode.

On a related note, the dip switch settings for all versions of Shadow Force still need to be corrected.
User avatar
Senior Tester
Nov 11, 2015, 22:16
edited on: Nov 11, 2015, 22:16
I've rearranged the sets.

dipswitch changes are pretty easy for an end user to do if you want to make a submisison to correct them for the various sets?
User avatar
Nov 11, 2015, 23:20
I've posted my observations of the DIP switches in a previous report.
User avatar
Senior Tester
Nov 12, 2015, 20:25
edited on: Nov 12, 2015, 20:26
No time to take a snapshot but.... shouldn't be the legs of characters in the water level (noticeable in attract mode) hidden by water and not visible like now? This looks to me a priority bug and I'm pretty sure it was not so last time I played the game two years ago.
User avatar
Senior Tester
Nov 13, 2015, 12:22
edited on: Nov 13, 2015, 12:44
I agree, it looks wrong, can you find out if it ever did work?

*edit* yeah it's definitely a bug

shows real hardware.

the only way I can see it being pulled off is with masking sprites (a solid sprite with higher sprite priority being drawn under the tilemaps) however it isn't drawing any such sprites..

they could also be using the raster irq to turn off sprites, but that seems very unlikely as evidence suggests the raster irq does not apply to sprites here.

so yeah, if it did work in an older version of MAME I'll need to check what was different, the code has been refactored a bit since then.
User avatar
Senior Tester
Nov 13, 2015, 12:47
edited on: Nov 13, 2015, 12:49
It works before 0.164. I'm not able to access history on GitHub but I believe it's this recent commit (dated around 0.163-0.164 cycle):
User avatar
Senior Tester
Nov 13, 2015, 13:01
edited on: Nov 13, 2015, 13:07
yeah, looks like that wasn't a safe optimization, I'll revert it. Thinking about it it's kinda obvious, they do the masking with wrapped around sprites, which is something I hadn't considered.

I was trying to do an early exit out of the draw function if the sprite would be clipped entirely, so dividing it into two calls, one for the wraparound case made that calculation easier, however since I failed to consider the possibility that a wrapped around sprite could be doing a priority effect it broke.
User avatar
Senior Tester
Nov 13, 2015, 13:56
Great, thank you. It's one of my favourites.