01455: lghost, lghostu: Problem with crosshair

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
01455	DIP/Input	Major	Always	Mar 2, 2008, 13:30	Aug 29, 2016, 09:29

Tester	Scagazza	View Status	Public	Platform	MAME (Self-compiled)
Assigned To		Resolution	Fixed	OS
Status [?]	Resolved			Driver	sega/segas18.cpp
Version	0.123u3	Fixed in Version	0.177	Build	Other
		Fixed in Git Commit		Github Pull Request #

Summary	01455: lghost, lghostu: Problem with crosshair
Description	There is a noticeble offset on the left in the crosshair that makes hard playing this game, tried to calibrate it by test mode but the problem persist.
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version	< 0.120
Affected Sets / Systems	lghost, lghostu

Attached Files	lghost.png (494,861 bytes) Mar 2, 2008, 15:54
	disasm_rom.zip (914,551 bytes) Aug 15, 2016, 12:42 Uploaded by Pitou
	segas18.cpp.diff.zip (1,300 bytes) Aug 22, 2016, 16:55 Uploaded by Pitou

No.00037 etabeta Developer Mar 2, 2008, 15:55	issue confirmed: notice, on the right, where the shoot is compared to the blue crosshair the problem dates back at least to MAME 0.120
No.04180 derrickr Developer Apr 10, 2009, 19:38	I belive this is just a hardware issue. The guns on the left/right have a different angle then the center. The game code compensates for this physical offset. So someone would have to reverse engineer the game code, then apply reverse compensation to the MAME port. There are other games that do this but I can't remember which ones. I have no proof for this theory other then the fact that the center gun is fine and the tracking on the left gun is the reverse of the right gun.
No.13052 Pitou Tester Aug 15, 2016, 12:41 edited on: Aug 22, 2016, 21:38	Hello, Reviving this issue! I made a lot of research about this issue and I need some advices/directions to work on a proper solution from the start. Here are the steps I've taken so far and my results. - I merged the even (bootleg_epr-13429.a4) and odd (bootleg_epr-13430.a6) roms, to form a complete merged 512k rom. I used the lghostd bootleg roms because they are aready decrypted and easier to work with. - I disassembled the rom (see attached file, rom_disasm.zip, if not permitted, please delete) - The coordinates for the crosshair are mapped this way: bottom left corner is (0,0) and top right corner is (255,255). Compared to how Mame reports them, the driver already compensate for this. From segas18.cpp: Line 400: m_lghost_value = 255 - ioport("GUNY1")->read(); <----------- Notice the "255 -" here Line 408: m_lghost_value = 255 - ioport(m_lghost_select ? "GUNY3" : "GUNY2")->read(); <------------- Notice the "255 -" here In fact, only the Y axis needs calculation. (this axis is reversed, top is 0 and bottom is 255). Again it's already taken care and the X axis is already fine. - Found out that the offset calculation routine probably starts at offset $94be - What this subroutine does is calculate the actual explosion/hit position on screen. This goes from ~$1400 to ~$E0C8 for the Y axis. You can take a look at the values in the debugger memory range "memory/:maincpu/0/00500000-0050ffff" (or ffff0000-ffffffff, if you use watchpoints) at offset $600-$601. For the X axis it goes from ~$AF to ~$1D8 offset $602-$603. - Also, the game can have up to 4 hits/explosions on screen. You can see the coordinate values of all 4, when you look in ram "memory/:maincpu/0/00100000-0010ffff", starting offsets $7b0, $7c0, $7d0, $7e0. Solutions: 0- We cannot modify the rom itself to modify the subroutine. That breaks Mame rule, because the rom is not original anymore. 1- I can probably calculate a compensation offset based on trial and error depending on the crosshair position. That would be implemented in the Mame driver segas18.cpp. Would that be accepted? 2- I can probably use the cheats system to "temporary" patch the subroutine behavior, either by patching the rom code or patch in ram. Is that possible? My guess is that I think solution #1 could be the best. What do you think? What would be best and accepted by the Mame developpers? Thank you. Pitou!
No.13053 Osso Moderator Aug 16, 2016, 06:04	Probably n. 1, as you guessed.
No.13060 haynor666 Tester Aug 21, 2016, 10:00	The same problem is with Sharp Shooter.
No.13061 Pitou Tester Aug 21, 2016, 16:15 edited on: Aug 21, 2016, 17:09	ok I'll take a look after. Could you open a new bugid for this one? I'm almost done calculating offsets for player 1. So far it works fine for P1. Still need to do Player 2 and 3. :)
No.13064 Pitou Tester Aug 22, 2016, 04:10 edited on: Aug 22, 2016, 16:55	Fix committed. commit e2825227e6c8bae8a58bda7a09889f55fe197494 Pull request #1289 Edit: Added diff file.
No.13065 Pitou Tester Aug 25, 2016, 15:57 edited on: Aug 26, 2016, 20:07	Hello, Just to give you an update on this issue. My fix will not make it's way to the master branch source code. After discussion with Mamehaze, it's not a good way to fix this bug because If someone builds a real arcade machine with Mame fixing the Guns in their originals positions, applying offsets will cause problems as the current code take that into account already. We need a way to make both worlds happy, i.e. playing on a PC and a "real" machine. A new type of gun input might be needed that take into account offsets and that can be enabled or disabled on user preference. @haynor666, Sharp Shooter works perfectly when calibrated properly using the in-game calibration menu. No fix needed for this one. Pitou! Edit: Spoke too soon, the code has been merged with an option to disable offsets corrections! Great! :)
No.13066 abelardator2 Tester Aug 25, 2016, 18:58	I have this original PCB, you need some testing? but I do not have guns. There is a small board added on the System18 base to use the guns controls.
No.13085 Osso Moderator Aug 29, 2016, 09:29	Fixed by Pitou.