Recent Posts

By the way, thanks for that reply ThatOneSeong. It was enlightening. I think choices like this get made earlier on in making a program and then get harder and harder to fix later on. So it just becomes the way it is.

Right.
Keep in mind that I'm not trying to be too harsh (even though I did just call it "dumb") - all the lightgun emulation code was, in all likelihood, developed all the way back in the mid-2000's - when most people already were running 4:3 displays/didn't have a PC lightgun solution at all at the time, so the issue wasn't as prevalent for the person implementing it to take action. I wouldn't be surprised to hear if there's some underlying tech debt left in MAME's code that makes it difficult to resolve--and/or just not enough interested persons around to fix the issue, probably from complacency in the PC light gun community... coughGun4irCough.

Regardless, glad to hear that RetroArch's been working for y'all!

(And for those of you who haven't used DemulShooter yet, yes, it relies on hooking directly into the individual mouse object - that's how it gets multi mice to work after all. So I'm guessing you'll want to load it up while your software is running? The -useSingleMouse option effectively just has DS use the general Windows cursor. I only know this because of having to use it as a workaround on Linux, since Wine currently does not expose individual mouse devices yet.)

Hi Yolo!

Well, I’m convinced after much testing Airborne’s steering re-centering is entirely different to hard/race/street drivin’. The centering encoder signals are completely ignored. For Airborne, when your car re-spawns after crashing, whatever the wheel position your steering wheel is in at that time becomes the new center (regardless of angle). The center position can also self adjust during play should you oversteer (Say that you rotate the wheel 3 times clockwise to go round a tight turn. You’ll only need to do roughly one anit-clockwise rotation for the car to go in a straight line again).

I came to the conclusion that this game can only really be enjoyed with a mouse/spinner. Even then it would need force feedback so you had a feeling of where the steering center is.

Then I had a thought which was followed by a hack which might help...

I modified hdc68k_wheel_r() for airborne. I took out the steering latching stuff. I’ve added a key ‘S’ that can hold to adjust your steering wheel back to center during play. Here’s how it works:

Say that you are playing the game, you want the car to go straight, your steering wheel is in its central position but the car is pulling to the right.  To fix this you need to turn your steering wheel left (Until the car is moving in a straight line), then press and hold the ‘S’ key,  then turn your steering wheel to its central position, and release the ‘S’ key. That’s it.

I know its not really an ideal solution, but it might improve the game experience and help us get better laps times

In hardriv.cpp, in the "static INPUT_PORTS_START( hdrivair )" section, I've changed this line:-

Code: [Select]

PORT_BIT(0xfff, 0x200, IPT_PADDLE) PORT_MINMAX(0x000, 0x3ff) PORT_SENSITIVITY(100) PORT_KEYDELTA(5) PORT_REVERSE PORT_NAME("Steering Wheel")
to this...

Code: [Select]

PORT_BIT( 0xfff, 0x000, IPT_POSITIONAL ) PORT_POSITIONS(0xfff) PORT_WRAPS PORT_SENSITIVITY(50) PORT_KEYDELTA(1) PORT_REVERSE PORT_NAME("Steering Wheel")

Then in harddriv_m.cpp, replace the hdc68k_wheel_r() function with this...

Code: [Select]

uint16_t harddriv_state::hdc68k_wheel_r()
{
// grab the new wheel value
uint16_t new_wheel, raw_wheel = m_12badc[0].read_safe(0xffff);
int wheel_diff = 0;
bool is_wheel_increasing = false;
static uint8_t wheel_snapshot = 0;
static uint8_t wheel_offset = 0;
static bool steering_enabled = true;

if (machine().input().code_pressed(KEYCODE_S))
{
if (steering_enabled)
{
popmessage("Steering disabled (Re-center your wheel now...)");
steering_enabled = false;
wheel_snapshot = (m_hdc68k_last_wheel+wheel_offset)&0xff;
}

return ((wheel_snapshot << 8) | 0xff);
}
else
{
if (!steering_enabled)
{
popmessage("Steering enabled");
steering_enabled = true;
wheel_offset = (wheel_snapshot - raw_wheel)&0xff;
m_hdc68k_last_wheel = raw_wheel;
}
}

// Work out which way the wheel is spinning
if((m_hdc68k_last_wheel < 0x400) && (raw_wheel > 0xC00))        is_wheel_increasing = false;    //Wrapped from bottom to top
else if ((m_hdc68k_last_wheel > 0xC00) && (raw_wheel < 0x400))  is_wheel_increasing = true;     //Wrapped from top to bottom
else if(m_hdc68k_last_wheel > raw_wheel)                        is_wheel_increasing = false;
else if(m_hdc68k_last_wheel < raw_wheel)                        is_wheel_increasing = true;

//Steering damping:
//Ensure we don't jump from one encoder value to another too quickly confusing the game
//The game is aware only of changes to m_12badc's lower byte. This means the game can get easily confused if you where to move
//the wheel very quickly from say position 0x800 to 0xC12 in one cycle (Which was perhaps physically impossible using the
//actual arcade encoder). The game would be under the impression the wheel has moved only 0x12 values, rather than 0x412 values.
//If we detect a large change, slowly feed that information back to the game in managemtble amounts.
new_wheel = m_hdc68k_last_wheel;
while(new_wheel != raw_wheel)
{
if (is_wheel_increasing)
{
if (new_wheel >= 0xFFF) new_wheel = 0x000;
else new_wheel++;
}
else
{
if (new_wheel <= 0x000) new_wheel = 0xFFF;
else new_wheel--;
}

//Lets say the encoder can't move more that 32 teeth per cycle...
if (wheel_diff++ > 0x10) break;
}

if (machine().input().code_pressed(KEYCODE_LSHIFT))
{
popmessage("wheel=0x%04X", new_wheel);
}

m_hdc68k_last_wheel = new_wheel;
return ((new_wheel+wheel_offset) << 8) | 0xff;
}


Hi Geecab,that is a really good solution for the Hard Drivin' Airborne off center bug. I'll need to try it out and see! I'm thinking it would be more responsive when turning the wheel compared to the EMA buffering code I'm currently using to stop it going off center because it adds a very slight latency to the wheel.

Just thought I'd mention this because you seem to be confused about Street Drivin's steering wheel behaviour. Street Drivin's steering is different from Race Drivin' Compact, Hard Drivin' Compact, the cockpit versions AND different from Airborne.

Street Drivin' doesn't have the "steering going off-center bug" when you crash or when you go offroad or even if you turn the wheel too fast etc, it never goes out of alignment. Only the compact versions have that and Airborne. The only reason it seemed to be happening in Street Drivin' before is because the steering range was the same as the others (0x010, 0xff0), when it was changed it to 0x000, 0x3ff it completely fixed the steering, it stops the bug that happens when you steer to the maximum left or right. The change of the PORT_MINMAX to (0x000, 0x3ff) fixed that bug for Airborne too but Airborne has the same bugs that the compact versions have but unfortunately your solution for the compact versions doesn't fix it for Airborne.

BTW I'm now sure that Street Drivin's ROM is actually a cockpit version and I'm even more certain of that now because if you look at the ROM's that get loaded into the main program memory it shares ROM's with Race Drivin' Panorama which on MAME is a cockpit ROM and not a compact. None of the cockpit ROMs are compatible with the compact except the sound ROM's and Jed Margolin even mentions that fact on his website. You can try it for yourself, Street Drivin' already plays perfectly!

Just thought I'd mention it because it could help narrow down the problem Airborne is having because they both have the same steering wheel range in common but Street Drivin' doesn't do the wheel edge/centering stuff the same as any of the others and that is why it doesn't have the bug you were experiencing on the compact versions or Airborne.

I noticed the first set of ROM's in the main program seem to be the ones that contain the test menu code. I was able to load up the Race Drivin Panorama version of the test menu in Street Drivin' by swapping the ROM's over but it made the screen garbled too. It was all readable and seemed to work but had strange values and the writing just looked weird like the resolution is set wrong or something.

I've gave up on my mission of trying to make Street Drivin' have gears by fiddling with the ROM's because today I found out that the Race Drivin' Panorama has the extra stock car track and even has the drone cars from Street Drivin' on it. The only problem i noticed with it was the frame rate even when using my overclock. I fixed this by loading up only the main PCB ROM's and not the left and right PCB ROM's using the Race Drivin' cockpit machine configuration and now the game plays smooth. I think it's because there is a hack in the MAME source code that's used to get the 3 screens in sync and even when you choose 1 screen only in the MAME video options it still seems to be using that hack and using the side PCB's.

Now, I've been using this for a while and have a few callouts to anyone who is thinking about designing a similar one.

1. If you're going to build a 4-player cab like mine, then 1 big mistake I made is with how the display is inset. This is more of a 3-player build now even though it supports 4 players. If you look closely, the display is about 4 inches into the cabinet. The IR LEDs then surround the screen. Well, the lightguns can only see all 4 IR LEDS if relatively in front of the screen. The ~4-inch inset of the display causes the sides to act like flaps that block the IR. So if you are too far off to the side, then only 3 sensors will be visible. Only 3 people can visibly stand in front of the screen and see all 4 LEDs.

I should have cut the sides in more so that they're flush with the edge of the screen.

2. soldering the gx16 was pretty tight since it needed to accommodate wire that was thick enough to handle 24v at ~3amps. Between the sockets, cables, and lightgun, it means that you're going to be soldering 16 tiny ends that barely fit into the casings, and then make sure that there are no shorts. I'd still do it again because I think it's worth it, but it's probably the most tedious part of the build. I'm looking to limit mine to 2 people only, but that's still something for me to consider If I ever wanted to add additional guns it's definitely something I should plan for on the front end of things.

3. I got the Streamdeck partially because I thought that I could use it for keyboard events as well. I.e., have all of the Dreamcast buttons available to navigate game menus and whatnot. Unfortunately, the thing does not support raw keyboard events. It sends system events. This means that emulators which rely on raw input (such as Flycast) cannot use the Streamdeck to send keys because it either support SDL or raw input, but not both. Emulators that support SDL are ok though.

Not too much, but I mostly wanted to call out #1 since it's a pretty important defect.
 
FINALLY, I've attached my sketchup plans to the original post in case anyone wants to use them as a base.

Thank you for taking the time to share and be so detailed with how your process went. I imagine I'm far from the only person who has been considering such a similar build and your sketchup file really breaks it down ( I had started doing something similar with graph paper and you just saved me probably weeks of time!) Additionally, I was curious about how the stream deck fit into your overall build. Finally, just want to say the finished product is truly a piece of art

Awesome, glad to hear it works.


I was anticipating a problem like that. But it would've been when clicking in off-screen and re-entering screen area before releasing the click could've caused reload to be stuck on.

But I figured out a way to handle that by releasing both left and right click. Which was a better way than how I first planned to handle it.

I didn't think of what you found but I agree probably not worth fixing atm.

Any more things to fix while I'm on a roll? lol 😆

Works great, I upped the X borders to 480 so shots in the black borders at 4:3 would be counted as off-screen too and that works fine. The only edge case issue I could find is if you hold down the trigger, enter the border/exit the screen, then return to the screen, it'll send a reload. But this is so minor it isn't even worth fixing, I doubt anyone would run into it and it doesn't cause any problems. No issues with forced scaling, maybe I'll wind up using DS more now, I think HotD3 might have some slight control issues for route selection without it.

Hi Yolo!

Well, I’m convinced after much testing Airborne’s steering re-centering is entirely different to hard/race/street drivin’. The centering encoder signals are completely ignored. For Airborne, when your car re-spawns after crashing, whatever the wheel position your steering wheel is in at that time becomes the new center (regardless of angle). The center position can also self adjust during play should you oversteer (Say that you rotate the wheel 3 times clockwise to go round a tight turn. You’ll only need to do roughly one anit-clockwise rotation for the car to go in a straight line again).

I came to the conclusion that this game can only really be enjoyed with a mouse/spinner. Even then it would need force feedback so you had a feeling of where the steering center is.

Then I had a thought which was followed by a hack which might help...

I modified hdc68k_wheel_r() for airborne. I took out the steering latching stuff. I’ve added a key ‘S’ that can hold to adjust your steering wheel back to center during play. Here’s how it works:

Say that you are playing the game, you want the car to go straight, your steering wheel is in its central position but the car is pulling to the right.  To fix this you need to turn your steering wheel left (Until the car is moving in a straight line), then press and hold the ‘S’ key,  then turn your steering wheel to its central position, and release the ‘S’ key. That’s it.

I know its not really an ideal solution, but it might improve the game experience and help us get better laps times

In hardriv.cpp, in the "static INPUT_PORTS_START( hdrivair )" section, I've changed this line:-

Code: [Select]

PORT_BIT(0xfff, 0x200, IPT_PADDLE) PORT_MINMAX(0x000, 0x3ff) PORT_SENSITIVITY(100) PORT_KEYDELTA(5) PORT_REVERSE PORT_NAME("Steering Wheel")
to this...

Code: [Select]

PORT_BIT( 0xfff, 0x000, IPT_POSITIONAL ) PORT_POSITIONS(0xfff) PORT_WRAPS PORT_SENSITIVITY(50) PORT_KEYDELTA(1) PORT_REVERSE PORT_NAME("Steering Wheel")

Then in harddriv_m.cpp, replace the hdc68k_wheel_r() function with this...

Code: [Select]

uint16_t harddriv_state::hdc68k_wheel_r()
{
// grab the new wheel value
uint16_t new_wheel, raw_wheel = m_12badc[0].read_safe(0xffff);
int wheel_diff = 0;
bool is_wheel_increasing = false;
static uint8_t wheel_snapshot = 0;
static uint8_t wheel_offset = 0;
static bool steering_enabled = true;

if (machine().input().code_pressed(KEYCODE_S))
{
if (steering_enabled)
{
popmessage("Steering disabled (Re-center your wheel now...)");
steering_enabled = false;
wheel_snapshot = (m_hdc68k_last_wheel+wheel_offset)&0xff;
}

return ((wheel_snapshot << 8) | 0xff);
}
else
{
if (!steering_enabled)
{
popmessage("Steering enabled");
steering_enabled = true;
wheel_offset = (wheel_snapshot - raw_wheel)&0xff;
m_hdc68k_last_wheel = raw_wheel;
}
}

// Work out which way the wheel is spinning
if((m_hdc68k_last_wheel < 0x400) && (raw_wheel > 0xC00))        is_wheel_increasing = false;    //Wrapped from bottom to top
else if ((m_hdc68k_last_wheel > 0xC00) && (raw_wheel < 0x400))  is_wheel_increasing = true;     //Wrapped from top to bottom
else if(m_hdc68k_last_wheel > raw_wheel)                        is_wheel_increasing = false;
else if(m_hdc68k_last_wheel < raw_wheel)                        is_wheel_increasing = true;

//Steering damping:
//Ensure we don't jump from one encoder value to another too quickly confusing the game
//The game is aware only of changes to m_12badc's lower byte. This means the game can get easily confused if you where to move
//the wheel very quickly from say position 0x800 to 0xC12 in one cycle (Which was perhaps physically impossible using the
//actual arcade encoder). The game would be under the impression the wheel has moved only 0x12 values, rather than 0x412 values.
//If we detect a large change, slowly feed that information back to the game in managemtble amounts.
new_wheel = m_hdc68k_last_wheel;
while(new_wheel != raw_wheel)
{
if (is_wheel_increasing)
{
if (new_wheel >= 0xFFF) new_wheel = 0x000;
else new_wheel++;
}
else
{
if (new_wheel <= 0x000) new_wheel = 0xFFF;
else new_wheel--;
}

//Lets say the encoder can't move more that 32 teeth per cycle...
if (wheel_diff++ > 0x10) break;
}

if (machine().input().code_pressed(KEYCODE_LSHIFT))
{
popmessage("wheel=0x%04X", new_wheel);
}

m_hdc68k_last_wheel = new_wheel;
return ((new_wheel+wheel_offset) << 8) | 0xff;
}


I've got a new DemulShooter mod to test. This adds offscreen reload along the borders like the AHK does.

So to use it, again paste the exe files into DemulShooter v12.2 ( https://github.com/argonlefou/DemulShooter/releases/tag/v12.2 ) use DemulShooter_GUI.exe etc.
and run the command line like e.g.:

demulshooter -target=chihiro -rom=vcop3 -usesinglemouse -offx=20 -offy=30

This means that the first left 20 pixels and the last right 20 pixels will change the left click (shoot) to right click (reload).
And the top 30 pixels and bottom 30 pixels will do the same. A value a 0 will have no reload effect or leaving either -offx or -offy from the commandline.

I've put the changes again in a txt file in a directory should it need to be changed with a new version of DemulShooter.

I don't think the -ForceScalingX=4/3 option would affect anything for the reload. I tried to use it but seemed like it was more inaccurate for me when I did. But then I don't have a calibrated Virtual Desktop going. I'm using it more like a mouse atm.

I also didn't realise I could run the game in 4:3 res, I was using 16:9. So I found that there is the two options, change the video mode res or turn on/off Maintain Aspect Ratio but any combo I tried didn't seem to need the ForceScalingX option.

If it's a problem then let me know. Hopefully this means you won't need to run the AHK script with DS

The 3rd and 4th roms* in the mainpcb:maincpu on street drivin' are the test menu roms that are both interleaved so technically it's 1 rom.

Hi Yolo!

Thought I'd post my hack of the  hd68k_wr2_write() to read steering wheel force feedback. If you're interested, just replace the existing hd68k_wr2_write()  function with this one, and when holding the 'F' key in-game you can see the feedback trying to do its thing. Something that is pretty cool is watching the attract mode and viewing the force feedback, you can see how the game is trying to rotate the wheel when it hits the corners (You do need to enable the Steering During Attract Mode option for that though, I explain how to do that in the massive comment in the function).

Code: [Select]

void harddriv_state::hd68k_wr2_write(offs_t offset, uint16_t data)
{
    /*
    Observations
    ============

    The 'data' repeats every 4 times this function is called.
    Offset always seems to be zero.
    Combining the 1st and 3rd byte of data gives you the steering
    wheel force feedback.

    When the game does not want to rotate the wheel in any direction,
    0xE000 is read.

    When the game wants the wheel to rotate clockwise, you see this:
        0xE000 increment to 0xE01F,
        then jumps to 0xE100 which increments to 0xE11F,
        then jumps to 0xE200 which increments to 0xE21F,
        then jumps to 0xE300 which increments to 0xE31F,
        etc...

    When the game wants the wheel to rotate anticlockwise, you see this:
        0xE000 jumps to 0xFF1F which decrements to 0xFF00,
        then jumps to 0xFE1F which decrements to 0xFE00,
        then jumps to 0xFD1F which decrements to 0xFD00,
        then jumps to 0xFC1F which decrements to 0xFC00,
        etc...

    Bits 0 to 7 never go above 32 (0x1f). Thus Bits 5 to 7 are unused.

    If bits 12 to 15 are 0xE this indicates the game is trying to turn
    the wheel clockwise. If they are 0xF, it is trying to turn the
    wheel anticlockwise.

    Shifting bits 8 to 11 right 3 places, gives you a value that
    increments/decrements logically.

    Testing
    =======

    In service mode, view the OPERATOR SCREENS and go to the 2nd page
    where there are 2 interesting options:
        Steering During Attract Mode
        Steering Wheel Force

    When Steering During Attract Mode is enabled, when you watch the
    attract mode, you'll see the the m_wheel_force change value as the
    game attempts to move the steering wheel while the car is moving around
    the track.

    When Steering Wheel Force is set to 'Very light' you'll see
    m_wheel_force in the range -70 to 70. When set to 'Stiff' you'll see
    m_wheel_force in the range -127 to 127.
    */

    static unsigned int static_count = 0;
    static uint8_t static_data[4];

    //printf("wr2 offset=%04X data=%04X\n", offset, data);

    //Store the data in this array (Must be a better way to do read this stuff...)
    static_data[static_count] = data;
    static_count++;
    if (static_count > 3)
    {
        uint16_t force_combined, force_shifted;
        int m_wheel_force;

        static_count = 0;

        //Combine the force (1st and 3rd byte)
        force_combined = ((static_data[2]<<8)&0xff00) | (static_data[0]&0x00ff);

        //Shift the force so that it logically increments/decrements
        force_shifted = (((force_combined)>>3)&0x01f0) | (force_combined&0xf01f);

        //Use the force
        if ((force_shifted&0xf000) == 0xe000)
        {
            m_wheel_force = int(force_shifted&0x0fff);          //Clockwise force (+ive number)
        }
        else
        {
            m_wheel_force = int(force_shifted&0x0fff) - 511;    //Anticlockwise force (-ive number)
        }


        if (machine().input().code_pressed(KEYCODE_F))
        {
            popmessage("wr2 wheel=0x%04X force=%d", m_hdc68k_last_wheel, m_wheel_force);
        }
    }
}


Very cool and great work! If force feedback could become a native thing in mame for these games it would make life a lot easier as when i tried the force feedback plugin thats out there i never figured out how to get it to work for these games. Obviously i was doing something wrong on my end. I just found out that Race Drivin Panorama has the extra stock car track from Street Drivin' so i was thinking maybe i could swap the roms from that version into the Street Drivin' hardware driver in mame and get to play with the gear shifter and have the less glitchy audio and maybe run faster?  I almost had the Race Drivin' compact working on that hardware but some of the files were not compatible. I did manage to get the Race Drivin logo and credits to appear. I wish they never gave up on this game and made more of them with the same graphics style.

Sure, what you said is correct, but using 3.3V at the spinner is worth a try

Probably not.  The typical IR LED operates at 1.7v (with many operating below this value).  The voltage differential between 5v and 3.3v (1.7v), with the resistor intended for 5v operation, is the same as the forward voltage of the LED, essentially nullifying everything which would allow it to function if given only 3.3v.