06071: shadfrcej: Shadow Force (Japan Version 3) might be misnamed. Version is actually in English, not Japanese.

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	technos/shadfrce.cpp
Version	0.167	Fixed in Version	0.168	Build	Normal
		Fixed in Git Commit		Github Pull Request #

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
Github Commit

Flags
Regression Version
Affected Sets / Systems	shadfrcej

Attached Files	shadfrce0000.png (25,233 bytes) Nov 14, 2015, 15:38 Uploaded by haynor666

No.12158 Haze 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..
No.12159 Tafoid Administrator 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.
No.12161 Arkhound Tester 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.
No.12164 Haze 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?
No.12167 Arkhound Tester Nov 11, 2015, 23:20	I've posted my observations of the DIP switches in a previous report. http://mametesters.org/view.php?id=5557
No.12173 Mamesick 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.
No.12174 Haze 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.
No.12175 Mamesick 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): http://git.redump.net/mame/commit/?id=b67bb0afd7a8cec7cf785780ec0baebfc6cf775a
No.12176 Haze 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.
No.12177 Mamesick Senior Tester Nov 13, 2015, 13:56	Great, thank you. It's one of my favourites.