Main > Driving & Racing Cabinets
Mame hacks that make driving games play better with mouse/spinner/360wheel
geecab:
Cool, I'll try the IP_ACTIVE_HIGH things and see what happens.
>>I now reckon from checking out the compact versioin that airborne might use the same hardware for the wheel but just implements it differently if that makes sense.
Agreed.
One thing I forgot to mention. I started looking at the void harddriv_state::hd68k_wr2_write(offs_t offset, uint16_t data) function. I thought it could be used to retrieve the steering wheel value (the one that you see in the service menu) during the actual game. I thought if we could do that, we'd be able to see exactly where the game thinks the steering centre is after crashing the car. Then maybe following a crash, when you're turning your key to start (and your physical wheel would be centred at that point), you'd be able to set a really accurate offset at that point. That probably doesn't make any sense... Anyways, I'm not really sure what calling hd68k_wr2_write gives you. Its values do change based on steering position though (but only during the game, It never gets called during the service menu).
I'm not sure if this is helpful or not, but here's some hacky code I added to see if I could work out what's going on...
--- Code: ---void harddriv_state::hd68k_wr2_write(offs_t offset, uint16_t data)
{
static unsigned int static_count = 0;
static uint8_t static_data[4];
static_data[static_count] = data >> 8;
static_count++;
if (static_count > 3) static_count = 0;
if (offset == 0)
{
// logerror("Steering Wheel Latch = %02X\n", data);
m_wheel = data >> 8;
}
else
logerror("/WR2(%04X)=%02X\n", offset, data);
// The 'data' repeats every 4 times this function is called.
// You should see the data repeating in this debug output...
printf("wr2 offset=%04X data=%04X\n", offset, data);
// Try to put the data together (we must be writing 16bits somewhere?) to see what's going on...
if (machine().input().code_pressed(KEYCODE_RSHIFT))
{
popmessage("wr2 [%02X] [%02X] [%02X] [%02X]", static_data[0], static_data[1], static_data[2], static_data[3]);
}
}
--- End code ---
Yolo_Swaggins:
--- Quote from: geecab on April 20, 2024, 12:34:36 pm ---I concluded that CNTSPTRN is the amount of steering wheel values for 1 complete turn. I was clearly wrong about my 72 theory. I’m not sure where the actual arcade value of 1110 comes from
--- End quote ---
I'm sure i saw somebody on youtube or some other forum saying they had a 1100 degree wheel in the arcade. I don't know if it's true or not but it matches exactly what you said here?
geecab:
Still no joy my end...
I've just done a bit more investigation regarding the values I'm seeing in hd68k_wr2_write().
The range of values it reports is different depending on if you are watching the attract mode, or are viewing the "choose manual or auto transmission screen", or actually driving the car. I have been focusing on the values it reports whilst driving the car during the game.
Here's my latest hack:-
--- Code: ---void harddriv_state::hd68k_wr2_write(offs_t offset, uint16_t data)
{
static unsigned int static_count = 0;
static uint8_t static_data[4];
static bool seeing_e000 = false;
static_data[static_count] = data >> 8;
static_count++;
if (static_count > 3) static_count = 0;
if (offset == 0)
{
// logerror("Steering Wheel Latch = %02X\n", data);
m_wheel = data >> 8;
}
else
logerror("/WR2(%04X)=%02X\n", offset, data);
if ((static_data[2] == 0xE0) && (static_data[0] == 0x00))
{
if(!seeing_e000)
{
popmessage("wr2 MIDDLE");
seeing_e000 = true;
}
}
else
{
seeing_e000 = false;
}
// The 'data' repeats every 4 times this function is called.
// You should see the data repeating in this debug output...
//printf("wr2 offset=%04X data=%04X\n", offset, data);
// Try to put the data together (we must be writing 16bits somewhere?) to see what's going on...
if (machine().input().code_pressed(KEYCODE_RSHIFT))
{
popmessage("wr2 [%02X%02X]", static_data[2], static_data[0]);
}
}
--- End code ---
I noticed that combining the 1st and the 3rd byte showed me a range of values where the middle point is 0xE000.
From middle, if I turn the wheel fully left the value changes from 0xE000, 0xE001, 0xE002, ... up to 0xE112 (Thus 274 possible values)
From middle, if I turn the wheel fully right the value changes from 0xE000, 0xFF1F, 0xFF1E, ... down to 0xFE0D (Thus, also 274 possible values)
Giving an overall range of 548 values.
No matter what I calibrated the the wheel to in the system settings, this range remained the same (Always 548 values, left limit 0xE112, mid point=0xE000, right limit=0xFE0D).
I also noticed that when you crash with the wheel substantially turned, the value is reset back to 0xE000 when the car re-spawns. If you crash during soft turn, the value remains the same as whatever the value was when you crashed.
I not sure this helps us but thought it was worth a mention :)
Yolo_Swaggins:
--- Quote from: geecab on April 21, 2024, 01:33:40 pm ---Still no joy my end...
I've just done a bit more investigation regarding the values I'm seeing in hd68k_wr2_write().
The range of values it reports is different depending on if you are watching the attract mode, or are viewing the "choose manual or auto transmission screen", or actually driving the car. I have been focusing on the values it reports whilst driving the car during the game.
Here's my latest hack:-
--- Code: ---void harddriv_state::hd68k_wr2_write(offs_t offset, uint16_t data)
{
static unsigned int static_count = 0;
static uint8_t static_data[4];
static bool seeing_e000 = false;
static_data[static_count] = data >> 8;
static_count++;
if (static_count > 3) static_count = 0;
if (offset == 0)
{
// logerror("Steering Wheel Latch = %02X\n", data);
m_wheel = data >> 8;
}
else
logerror("/WR2(%04X)=%02X\n", offset, data);
if ((static_data[2] == 0xE0) && (static_data[0] == 0x00))
{
if(!seeing_e000)
{
popmessage("wr2 MIDDLE");
seeing_e000 = true;
}
}
else
{
seeing_e000 = false;
}
// The 'data' repeats every 4 times this function is called.
// You should see the data repeating in this debug output...
//printf("wr2 offset=%04X data=%04X\n", offset, data);
// Try to put the data together (we must be writing 16bits somewhere?) to see what's going on...
if (machine().input().code_pressed(KEYCODE_RSHIFT))
{
popmessage("wr2 [%02X%02X]", static_data[2], static_data[0]);
}
}
--- End code ---
I noticed that combining the 1st and the 3rd byte showed me a range of values where the middle point is 0xE000.
From middle, if I turn the wheel fully left the value changes from 0xE000, 0xE001, 0xE002, ... up to 0xE112 (Thus 274 possible values)
From middle, if I turn the wheel fully right the value changes from 0xE000, 0xFF1F, 0xFF1E, ... down to 0xFE0D (Thus, also 274 possible values)
Giving an overall range of 548 values.
No matter what I calibrated the the wheel to in the system settings, this range remained the same (Always 548 values, left limit 0xE112, mid point=0xE000, right limit=0xFE0D).
I also noticed that when you crash with the wheel substantially turned, the value is reset back to 0xE000 when the car re-spawns. If you crash during soft turn, the value remains the same as whatever the value was when you crashed.
I not sure this helps us but thought it was worth a mention :)
--- End quote ---
I was experimenting with the << 4 lower 8 bit thing etc and found i can give myself a 4 digit port_minmax on the 12 bit ADC and the wheel will use the whole 4 digits of it. Surely if we just get the wheel input to match 1-1 with what the game expects we could use those values to apply and subtract offsets to the wheel to keep it in exact or almost exact alignment live as we are playing? I had it showing the same values in the test menu as it did from my raw wheel input. The code i had that worked the most for offset adjustment would work for small turns when you crashed.......as soon as the offset exceeded 127 or went below -128 (uint8_t?) the offset being applied wouldnt match what was happening behind the scenes with the game.......you could make several crashes with the wheel turned a bit and it would stop it pulling to the one side which was better than nothing but with the new code i made that stops the wheel going out of alignment whilst driving and moving the wheel very fast seems to gimp my offset alignment procedure so it doesn't even work at all but that code to stop it happening when your not even crashing and just moving the wheel quick is more valuable to the gameplay and lets me get a much higher score and a longer play session. it used to happen to me on the 2nd last checkpoint in the mountain track and i assumed it was a trigger set by the checkpoint to reset the wheel but i found out the other day it's just because the wheel value changes so fast when your making quick sharp turns on that part of the track it sends it out of synch with the wheel or something. I created a code that buffers the wheel input with EMA algorithm which introduces a tiny bit of latency but stops the wheel ever going out of alignment when you move it fast from left to right etc. I messed around with the values and the port_minmax and got a good wheel sensitivity and responsiveness but stil mitigated the glitch that happens when you move it too fast. My method is a way too complex solution the fix could be much more simply those values you have found must be the key to keeping everything in synch and alignment! :dunno
I'm talking about airborne and i assume your still talking about the compact version of race drivin'? it's slightly different behaviour between the 2 games but i reckon the solution for one will fix the other.
Yolo_Swaggins:
I got the steering to work on race drivin' compact. I'm going to have a quick once over of the code and i'll stick it up here and put it on github as a commit to the mamedev/master.
I can get past the wheel calibration but it involves pressing a button when you reach the far right to register the turn and the values that show up arent accurate or inline with what should appear on the real machine but when you start the game it just behaves the same as the other Race Drivin' and Hard Drivin'. ;D
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version