Can anyone compile this steering fix mame to a newer mame version? Mame steering fix

[Martin0037]

Hi all.   So I’ve found this version of mame 0.148 on arcade controls forum. It’s an old thread but this version of mame was hacked to fix the steering problem that mame has. Basically in a 270 degree wheel game (outrun, chase hq) using a 360 wheel (continuous spin such as a spinner or a 360 optical wheel) the problem is that oversteering causes problems when playing these games with this type of optical steering wheel.  

For example in outrun...  if you oversteer past the point of where a normal 270 degree arcade steering wheel would stop,  any more “turn” of the wheel data is thrown away and ignored by mame,   Then when you steer in the opasite direction you only have to turn the wheel slightly and the car straightens up, but the steering wheel is now way off centre.  This is confusing for any guests playing that aren’t use to this and it’s basically utter crap if your using a proper 360 degree optical steering wheel.  

In this hacked version of mame (download and thread from arcade controls below)  the steering has been hacked so that mame actually remembers where the centre point of the steering is so that when you oversteer by say for example 3 turns to the right,  you have to turn the steering wheel 3 turns to the left to get their car going straight again.  The central point is set when the rom starts. I’ve tried it and it’s brilliant.  It works for all the games I’ve tried so far such as outrun, pole position, chase hq etc     BUT...  this is an old 0.148 version and I can’t get ridge racer, rave racer or even hard driving to run.  

This would be awesome if someone could compile a new raw input version of mame (as this hacked version is raw input) and compile it using the hacks mentioned in the thread below.  I’ve never compiled mame and wouldn’t have a clue where to start with including this hack.  It also has a hack for the gears in hard driving and race drivin although I can’t get these games to run so may have the wrong roms for this version, not sure.  

Thread here- 

http://forum.arcadecontrols.com/index.php/topic,130956.0.html 

download here- 

http://www.mediafire.com/file/ytny3pbql7odn2u/mame_0148_geecab_hack_v1_0.zip

 

Theres other ways to fix this problem with software such as PPjoy with PPmouse to latch on the steering and keep the centre point.  But this version of mame is utter brilliant for racing games and there’s no messing with any other software running in the background.   It’s basicslly a MUST for a driving mame version so I’m sure other people will benefit too.   I think the author (geecab) even submitted this to the mame devs but they haven’t added this as yet as far as I’m aware. I don’t know why as it’s brilliant. Just could with all the features of this version in a newer version that will run more modern mid 90s racers.

 

hope someone can help...

thanks. 

[Martin0037]

...or does anyone have a compiled version of mame with this fix?

[thatman84]

I'm not sure there are many people compiling mame here but someone may drop in for you.

Prob best to give it a shot. We have a guide here

 

[dougan78]

Found this interesting

https://forums.arcade-museum.com/archive/index.php/t-160424.html

Maybe you can turn on free spin for outrun in mame or other games that are 270 only. Just an idea. Good luck!

[Martin0037]

Thanks thatman84 I’ll give it a shot...  never compiled before but what’s the worse that can happen lol

 

Yeah that is interesting dougan78... I’ve never heard of that before. Defo gonna give that a go.  

Nice one chaps cheers for that ?

[Martin0037]

yeah it looks like the dipswitch setting is unique to Chase HQ    

It changes the cabinet type,  some cabs they made must have had 360 wheels instead of 270 ones

cant find anything for others like OutRun

[Martin0037]

Had a go at compiling the steering hack into the source code for the version in the link 0.177.   No idea what I’m doing wrong but it’s having none of it. 

 

[thatman84]

12 minutes ago, Martin0037 said:

Had a go at compiling the steering hack into the source code for the version in the link 0.177.   No idea what I’m doing wrong but it’s having none of it. 

 

Sounds like me and compiling apk's ! Compiling anything is pretty foreign to most 

have you succeeded compiling .177 on its own with no edits?

[Martin0037]

Not tried...  I’m pretty sure it would have worked but it error half way through when it got the hacked file...  so I’ve obviously done a crap job of pasting the hack into the file where I thought it should be.  I’ve tried to contact the guy (geecab) on the arcade controls forum but no answer as the thread is also years old.  

 

[phulshof]

I wonder if there's even anything left of that code in the latest MAME version. I might have a quick look one of these days; the fix itself doesn't appear to be too complicated.

[Martin0037]

Basically I’m building a 3 player driving cab with 3x 360 spinning wheels for games like super sprint,  but the centre steering wheel will be used for games like outrun, chase hq, ridge racer etc which use 270 wheels,  so I’m trying to find a way where I can play these games with a 360 wheel, but a way that makes it act like a 270 wheel.   the hacked version in the download does exactly this but won’t run ridge racer as it’s quite old  

There’s also this method in the link below....

http://forum.arcadecontrols.com/index.php/topic,92363.0.html

but this is all set up for use with GameEx,  although he does say in the thread it will easily work with other front ends but no idea how to implement this into hyperspin.  Must be a way....   this method is better as it works (I think) for other emulators such as model 2 which would be much better as then I could run sega rally and Daytona.     This this is gonna be the way forward if I can get it to work with hyperspin...  unless anyone has managed  to do what Im trying to do a different way. 

I’m starting to loose hair I know that!  Lol. 

Im basically what us English call  “pissing in the wind”  ?

[Martin0037]

Yes that’s what I’ve been thinking.  It looks completely different and I think 0.177 is a long way from 0.148.  

In the hacked file there’s  for example  INT32.    No idea what this is but in the 0.177 version it’s   s32

so I pasted the hack over the top of this but changed the INT32 in the hack for s32 wondering if it’d work but it just fails again.  Must be completely different. 

The other thing I thought about....  ridge racer I think works with 0.159 as I think that’s  when it came out on mame so I’m wondering if I downloaded the old 0.159 source and had a look to see if it’s similar in any way as it closer to 0.148    I’ll try that next.....

 

[Martin0037]

Also it needs to be raw input version of mame or all the wheels show up as the same mouse input...   the hacked version is raw input too...  it’s nearly there, would be perfect if it was 0.159 or newer as there’s quite a few more “mid 90s racers” that would work on it

[phulshof]

1 hour ago, Martin0037 said:

In the hacked file there’s  for example  INT32.    No idea what this is but in the 0.177 version it’s   s32

Both are probably meant to be machine independent signed 32 bit integers.

I recently did some work for MAME 0.194; I'll see if I can figure this one out. There's been some huge changes in the MAME code over the past years, so it's unlikely to be a direct copy, but implementing the intended behavior doesn't sound too complicated.

[thatman84]

If this becomes reality drop it in the 3rd party apps section of upload here like the no nag builds please  

[Martin0037]

Yeah that would be brilliant if you figure it out.  Yes a no nag version too,  I’d changed the code I was compiling to make it no nag and with the 0.177 version I didn’t need to alter the code to raw input as I think you can change it in the ini file. 

That would be fantastic phulshof if you could do it.  

Thanks for your help guys. ?

[Martin0037]

I was also trying to incorporate the hard driving hacks that he’d done, the steering and gear shift that makes 1st and 2nd gears select up and down gears, but this failed too.  It stopped compiling when it got to that part. 

Im really surprised this hasn’t ever been incorporated into the new versions of mame or at least the option to turn this on somehow in the ini. 

[Martin0037]

Thought I’d have a look at an older version so I downloaded source code for mame0,155 from mame website. 

The hacked file looks exactly the same.  So I’ve pasted the hack where it should go,  all good  

Trouble is when I try and compile it just fails and I get this message... 

no idea why

[Martin0037]

So I’ve follwed this guide for compiling.....  fails every time. Error 2

http://mrdo.mameworld.info/compile.php

tried with 0.155 and 0.158  - both of which have exactly the same files for the hack so I pasted it over so it’s exactly the same as in the original thread above   

Just cant compile for some reason  

 

[Martin0037]

Or.....    I’ve got the hacked source code version of mame0.155  and 0.158 if anyone would be good enough to compile it me please?

no matter what I do it doesn’t work so I’m lost.  I’m pretty sure it will work it just needs compiling. 

[phulshof]

Ok, I had a quick look at the MAME 0.195 code, and the entire setup is completely different from what it used to be, and a lot better written. Question is: what should the code do? You can very easily configure MAME to use the entire range of the steering wheel, but then it works like a 360 degree wheel rather than a 270 degree wheel, even for a game originally meant for a 270 degree wheel. If you want a dead zone, I'll have to take a look on how to best program this into the code. Unfortunately I don't own a steering wheel to test it with, so it'll be a bit of trial and error to get it right.

[Martin0037]

That’s great thanks for help.  

Taken from the original thread as it’s explained better.....  to make a 360 wheel play better for games that use a 270 wheel

The hack works so that the position of the wheel when the game starts up will always be its central position (players car will travel in a straight forward direction). If you then spin the wheel, say, 3 spins clockwise (hard right), you'll be required to spin the wheel back anti-clockwise 3 times in order to get the car going straight again. Spinning your mouse/spinner/360wheel beyond the limits of what the actual arcade game wheel would allow just means the game's maximum left turn or right turn value is applied.

basically in the original hacked version (0.148)   For example in outrun...  if you steer to the right, but oversteer with a 360 wheel past the point of where the original 270 arcade steering wheel would travel (you can try this with a mouse as it uses mouse input)     When you steer in the other direction the car goes hard left, but the steering wheel is now way off centre. 

...if all that makes sense. I tried it with a mouse, and you see straight away the difference compared to how it’s normally set up. 

It was posted to the mame devs here....  explains much better with a video also

http://forums.bannister.org//ubbthreads.php?ubb=showflat&Number=109129#Post109129

 

[Martin0037]

This is geecabs video that shows the problem better than I can explain it lol. 

 

[phulshof]

I understand that's how it used to be, but is it still the same with MAME 0.195? Here's the intro from that file from MAME 0.195:

****************************************************************************

    Theory of operation

    ------------
    OSD controls
    ------------

    There are three types of controls that the OSD can provide as potential
    input devices: digital controls, absolute analog controls, and relative
    analog controls.

    Digital controls have only two states: on or off. They are generally
    mapped to buttons and digital joystick directions (like a gamepad or a
    joystick hat). The OSD layer must return either 0 (off) or 1 (on) for
    these types of controls.

    Absolute analog controls are analog in the sense that they return a
    range of values depending on how much a given control is moved, but they
    are physically bounded. This means that there is a minimum and maximum
    limit to how far the control can be moved. They are generally mapped to
    analog joystick axes, lightguns, most PC steering wheels, and pedals.
    The OSD layer must determine the minimum and maximum range of each
    analog device and scale that to a value between -65536 and +65536
    representing the position of the control. -65536 generally refers to
    the topmost or leftmost position, while +65536 refers to the bottommost
    or rightmost position. Note that pedals are a special case here, the
    OSD layer needs to return half axis as full -65536 to + 65536 range.

    Relative analog controls are analog as well, but are not physically
    bounded. They can be moved continually in one direction without limit.
    They are generally mapped to trackballs and mice. Because they are
    unbounded, the OSD layer can only return delta values since the last
    read. Because of this, it is difficult to scale appropriately. For
    MAME's purposes, when mapping a mouse devices to a relative analog
    control, one pixel of movement should correspond to 512 units. Other
    analog control types should be scaled to return values of a similar
    magnitude. Like absolute analog controls, negative values refer to
    upward or leftward movement, while positive values refer to downward
    or rightward movement.

    -------------
    Game controls
    -------------

    Similarly, the types of controls used by arcade games fall into the same
    three categories: digital, absolute analog, and relative analog. The
    tricky part is how to map any arbitrary type of OSD control to an
    arbitrary type of game control.

    Digital controls: used for game buttons and standard 4/8-way joysticks,
    as well as many other types of game controls. Mapping an OSD digital
    control to a game's OSD control is trivial. For OSD analog controls,
    the MAME core does not directly support mapping any OSD analog devices
    to digital controls. However, the OSD layer is free to enumerate digital
    equivalents for analog devices. For example, each analog axis in the
    Windows OSD code enumerates to two digital controls, one for the
    negative direction (up/left) and one for the position direction
    (down/right). When these "digital" inputs are queried, the OSD layer
    checks the axis position against the center, adding in a dead zone,
    and returns 0 or 1 to indicate its position.

    Absolute analog controls: used for analog joysticks, lightguns, pedals,
    and wheel controls. Mapping an OSD absolute analog control to this type
    is easy. OSD relative analog controls can be mapped here as well by
    accumulating the deltas and bounding the results. OSD digital controls
    are mapped to these types of controls in pairs, one for a decrement and
    one for an increment, but apart from that, operate the same as the OSD
    relative analog controls by accumulating deltas and applying bounds.
    The speed of the digital delta is user-configurable per analog input.
    In addition, most absolute analog control types have an autocentering
    feature that is activated when using the digital increment/decrement
    sequences, which returns the control back to the center at a user-
    controllable speed if no digital sequences are pressed.

    Relative analog controls: used for trackballs and dial controls. Again,
    mapping an OSD relative analog control to this type is straightforward.
    OSD absolute analog controls can't map directly to these, but if the OSD
    layer provides a digital equivalent for each direction, it can be done.
    OSD digital controls map just like they do for absolute analog controls,
    except that the accumulated deltas are not bounded, but rather wrap.

***************************************************************************/

From what I read here, steering wheels should be using absolute analog controls, and should not have this issue anymore. Depending on how it's configured, you either control OutRun as if it had a 360 degree wheel all along or you should get some strange behavior when the steering wheel passes beyond the minimum and maximum value. It shouldn't cause an issue with the center position anymore though. As such, my question still stands:

In MAME 0.195, does your wheel steel act as a relative analog control? If so, then a similar fix could be worked out. If not, then perhaps a dead zone should be implemented to handle the steering beyond 270 degrees, but the center position should never be compromised.

 

As said: I don't have a steering wheel to test it with anymore, so I don't know what the current behavior is, especially for the steering wheel you have. Please let me know, and I will investigate what can be done. It's clear the code has completely changed, so I'd just take the idea behind the fix, and apply it to the current day code in stead of trying to port the old hack to current day MAME code.

[Martin0037]

Thanks again for your help. 

Yes I think it in my case it would be classed as “relative input” as the steering uses a mouse input with no limit to travel

Yes I think if the steering centre is fixed in newer mame that is going to solve is...   I think,  but it would need to remember the value of left or righ movement no matter how far...  that is what the hack does I think

I think the main thing is the value that’s after the limits of the 270 wheel,  so (from what I’ve read in other posts on this)  the data that is applied as the 360 steering wheel (mouse input) goes beyond the limits of travel that a 270 would have, this data is ignored so when the steering wheel is then turned in the opasite direction it’s picked up again and applied to the steering again but this results in the steering now being off centre.   

I think the hacked version remembers exactly where the centre point is no matter how far the wheel (mouse input) is moved,  so when it’s moved the other way it has to go all the way back the same amount of travel to regain the centre point again.  

If all that makes sense lol