Viewing Issue Advanced Details
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 segas18.cpp
Version 0.123u3 Fixed in Version 0.177 Build Other
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
Regression Version < 0.120
Affected Sets / Systems lghost, lghostu
Attached Files
png file icon lghost.png (494,861 bytes) Mar 2, 2008, 15:54
zip file icon (914,551 bytes) Aug 15, 2016, 12:42 Uploaded by Pitou
zip file icon (1,300 bytes) Aug 22, 2016, 16:55 Uploaded by Pitou
There are no relationship linked to this issue.
User avatar
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
User avatar
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.
User avatar
Aug 15, 2016, 12:41
edited on: Aug 22, 2016, 21:38

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,, 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.


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.

User avatar
Aug 16, 2016, 06:04
Probably n. 1, as you guessed.
User avatar
Aug 21, 2016, 10:00
The same problem is with Sharp Shooter.
User avatar
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. :)
User avatar
Aug 22, 2016, 04:10
edited on: Aug 22, 2016, 16:55
Fix committed.

commit e2825227e6c8bae8a58bda7a09889f55fe197494

Pull request #1289

Edit: Added diff file.
User avatar
Aug 25, 2016, 15:57
edited on: Aug 26, 2016, 20:07

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.


Sharp Shooter works perfectly when calibrated properly using the in-game calibration menu. No fix needed for this one.


Edit: Spoke too soon, the code has been merged with an option to disable offsets corrections! Great! :)
User avatar
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.
User avatar
Aug 29, 2016, 09:29
Fixed by Pitou.