Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

Recent Posts

Pages: [1] 2 3 ... 10

Started by Toasty833 - Last post by Toasty833

So I had a look at OpenVR2Key, I hadn't seen it before and I didn't realise it was open source. I setup my vive controller but thought I was going to have an issue as you said it needed an Index controller to map and he mentions that's what he has.
Ah, maybe I didn't make it clear, I was talking about Virtual Desktop when it came to remapping, it has a bindings page. OpenVR2Key works fine with my Vive controller/tracker even on the newest release.

I dug around a bit in the code and figured I could probably make mouse clicks work but would need to hijack some keyboard keys to test it quickly and not bother with the user interface side of that.

So I've mapped F1 to left mouse, F2 to right mouse and F3 to middle mouse.

I'm attaching my build of the exe and the source code.
But this is pretty handy anyway. The only issue is there's no repeating function which I think is a limitation of the program to begin with, if you hold a button down it only sends the input once, which means it's not very useful for games with machine guns. I found that by adjusting the click detection threshold to 1 (might not be necessary) and the dragging threshold to 10 in the Vive Mouse config, the trigger is a lot more responsive, there's no weird delay. You could probably go even lower than 10ms, I think the code just waits for whatever the dragging threshold is before it actually sends a click which is why it's so slow by default.


The other day I had demulshooter running with VD, but now I can't figure out how to get it to respond to clicks with vive mouse or VD anymore. Might have to restart and see if that fixes it, maybe the blocker stuff for vive mouse affected VD somehow, it might use user32 too to send fake mouse inputs to games. In testing I also think VD just responds better than vive mouse. Virtual Desktop is right in line, there's very little delay between moving the gun and the mouse following. With vive mouse it's like there's maybe a 50-100ms latency, if I waggle it back and forth I can see it lagging behind. I have stabilization in the config set to off and the average set to 1 in case that applies anyway, but it doesn't seem to make an impact. If it were possible to get Virtual Desktop to remember the last window position to essentially save the calibration, it'd just be superior.

Started by ThatOneSeong - Last post by Matuca1849

Is there any known reason the IR camera in a Top Shot wouldn't work?

Started by Toasty833 - Last post by greymatr

Basically every game works with it. The number of games that don't have an off-screen function is less common, and right click is the standard
I had no idea this is how they worked, I thought it was all up to the game to know when it was off screen. Well I certainly learned something and the guns are smarter than I thought!

With trigger, grip and trackpad that's still 3 usable buttons I can remap through OpenVR2Key because SteamVR still sees them fine.
So I had a look at OpenVR2Key, I hadn't seen it before and I didn't realise it was open source. I setup my vive controller but thought I was going to have an issue as you said it needed an Index controller to map and he mentions that's what he has.

But I found he did try to support Vive at one point but the releases page is a very old build. So I compiled the code and was surprised to see it was working now.

I dug around a bit in the code and figured I could probably make mouse clicks work but would need to hijack some keyboard keys to test it quickly and not bother with the user interface side of that.

So I've mapped F1 to left mouse, F2 to right mouse and F3 to middle mouse.

I'm attaching my build of the exe and the source code.

4   Main Forum / Re: thin client pcon Today at 12:55:51 pm

Started by daywane - Last post by daywane

If I remember correctly any video showing Rom play is a no no.
so here is a video showing just the thi client specks.

5   Main Forum / Re: thin client pcon Today at 12:23:42 pm

Started by daywane - Last post by daywane

Yes it is a PC. 10 years old new in box. very Limited. 16 gig m.2 drive, 4 gig of memory. all can be upgraded. I just won the auction and never seen one as of yet. TechDocUK o YouTube shows playing N64 games with Android. It is more powerful than a Raspberry 3 and the Pi3 will run 90s arcades.
The videos I have seen it running Batocera.linux were of console games.
I have multiple raspberry Pi's but during the cough cough  Raspberry PI corp dropped the home market. I am done with them

6   Main Forum / Re: thin client pcon Today at 11:45:12 am

Started by daywane - Last post by javeryh

Is it just a PC? What kind of performance can you expect out of something like this? Would MAME run games up to early 90s? Because if yes, $32 seems like the way to go...

Started by geecab - Last post by geecab

Code: [Select]
PORT_BIT( 0x4000, IP_ACTIVE_HIGH, IPT_CUSTOM )  PORT_TOGGLE PORT_NAME("Center Wheel Edge")  /* center edge on steering wheel, IPT_ACTIVE_HIGH fixes the steering alignment in game! */

OMG lol! I didn't try IP_ACTIVE_HIGH on 0x4000, only on 0x8000. I didn't change it on 0x4000 because it looked like it was doing the right thing in the service menu :p I honestly can't wait to try this later, nice one Yolo and well found! :)

Started by geecab - Last post by Yolo_Swaggins

Wow! Well done Yolo, sounds like progress at last!! :) Can't wait to see the changes :)

I still haven't got round to using the info you gave me on Airborne im using my older hack to get that working and added differennt wheel sensitivities /port_minmax's through a dip switch menu that changes your wheel to a different calibration and goes through EMA filtering. The fix for the compact version of race drivin' was easier than i thought lol. The test menu calibration is still gimped but you can just skip it.

https://github.com/Madcadden/mame/tree/Madcadden-Hard-Drivin-Race-Drivin-MAME-Build

Code: [Select]
PORT_BIT( 0x4000, IP_ACTIVE_HIGH, IPT_CUSTOM )  PORT_TOGGLE PORT_NAME("Center Wheel Edge")  /* center edge on steering wheel, IPT_ACTIVE_HIGH fixes the steering alignment in game! */

Code: [Select]
#include <numeric>  // For std::accumulate

// Function to calculate the Exponential Moving Average (EMA)
uint16_t harddriv_state::calculate_ema(uint16_t new_value) {
    static float ema_wheel = 0.0;  // Persistent storage of EMA across calls
    static bool ema_initialized = false;  // To check if ema_wheel is initialized
    static const float alpha = 0.082;  // Smoothing constant

    if (!ema_initialized) {
        ema_wheel = new_value;  // Initialize EMA with the first raw value
        ema_initialized = true;
    } else {
        ema_wheel = alpha * new_value + (1 - alpha) * ema_wheel;
    }

    // Ensure the last digit of the EMA output is always zero
    return static_cast<uint16_t>(ema_wheel) & 0xFFF0;
}

// Main function to handle wheel input and apply adjustments
uint16_t harddriv_state::hdc68k_wheel_r() {
    static const uint16_t g_latchpoint = 0x8000;  // Center point for wheel edge detection
    static bool initialized = false;  // To ensure the initial setup is done only once
    static int16_t last_offset = 0;   // To store the last offset applied
    static int wheel_edge_zero_count = 0;  // Counter for how many times wheel edge has been set to 0
    static int resets_recorded = 0;   // Counter to delay offset recording

    // Initial setup
    if (!initialized) {
        m_hdc68k_wheel_edge = 1;  // Set the edge to 1 at the start of the game
        initialized = true;  // Prevent further initialization
    }

    uint16_t new_wheel_raw = m_12badc[0].read_safe(0xffff) << 4;
    uint16_t ema_wheel = calculate_ema(new_wheel_raw) << 3;

    // If the game has reset the wheel edge to 0, handle the deviation
    if (m_hdc68k_wheel_edge == 0) {
        wheel_edge_zero_count++;  // Increment the counter each time wheel edge is 0

        // Record adjustment only after the first reset is recorded
        if (resets_recorded > 0) {
            // Check for deviation from the center point
            if (ema_wheel != g_latchpoint) {
                int16_t adjustment = g_latchpoint - ema_wheel;  // Calculate the necessary adjustment
                ema_wheel += adjustment;  // Correct the EMA to the center point
                last_offset = adjustment;  // Store the last offset applied
            } else {
                last_offset = 0;  // No offset needed if already at center
            }
        }

        resets_recorded++;  // Increment resets recorded after processing
        m_hdc68k_wheel_edge = 1;  // Set the wheel edge back to 1 after handling the adjustment
    }

    // Debugging output
    popmessage("Wheel Raw: %04X, EMA Wheel: %04X, Last Offset: %d, Edge: %d, Edge 0 Count: %d, Resets Recorded: %d",
               new_wheel_raw, ema_wheel, last_offset, m_hdc68k_wheel_edge, wheel_edge_zero_count, resets_recorded);

    return ema_wheel;  // Use the adjusted EMA directly
}


Code: [Select]
    // Handlers for the wheel and port inputs
    m_maincpu->space(AS_PROGRAM).install_read_handler(0x400000, 0x400001, read16smo_delegate(*this, FUNC(harddriv_state::hdc68k_wheel_r)));
    m_maincpu->space(AS_PROGRAM).install_write_handler(0x408000, 0x408001, write16smo_delegate(*this, FUNC(harddriv_state::hdc68k_wheel_edge_reset_w)));
    m_maincpu->space(AS_PROGRAM).install_read_handler(0xa80000, 0xafffff, read16smo_delegate(*this, FUNC(harddriv_state::hda68k_port1_r)));


Code: [Select]
class harddriv_state : public device_t
{
public:

void reset_wheel_offset();  // Function to reset the wheel offset


harddriv_state(const machine_config &mconfig, device_type type, const char *tag, device_t *owner, uint32_t clock);

void driver_msp(machine_config &config);
@@ -98,8 +102,21 @@ class harddriv_state : public device_t
void video_int_write_line(int state);
void sound_int_write_line(int state);

//New method declarations for steering logic
uint16_t hdc68k_wheel_r();  // Ensure this is declared only once
uint16_t custom_steering_logic();
uint16_t original_steering_logic();

// Add your EMA function declaration here
uint16_t calculate_ema(uint16_t new_value); // Corrected declaration


protected:

 int16_t wheel_offset = 0;  // Make wheel_offset a member variable

void init_video();

INTERRUPT_GEN_MEMBER(hd68k_irq_gen);
TIMER_CALLBACK_MEMBER(deferred_adsp_bank_switch);
TIMER_CALLBACK_MEMBER(rddsp32_sync_cb);
@@ -122,7 +139,7 @@ class harddriv_state : public device_t
uint16_t hd68k_adc12_r();
uint16_t hdc68k_port1_r();
uint16_t hda68k_port1_r();
// uint16_t hdc68k_wheel_r();
uint16_t hd68k_sound_reset_r();

void hd68k_adc_control_w(offs_t offset, uint16_t data, uint16_t mem_mask = ~0);

9   Driving & Racing Cabinets / Re: FFB Arcade Pluginon Today at 09:31:04 am

Started by Boomslang - Last post by Super-Becker

Last week I went to play California Speed (using the latest versions of MAME and FFB), I noticed that FFB gave some "hiccups" even when the cart wasn't touching anything. Doing some tests I saw that this problem originates in the FFB plugin version 2.0.0.34. I concluded that the last best combination for Cal Speed is MAME 0.257 and FFB 2.0.0.33. I think it's possible that this problem could also be present in some other game, but I'm not sure. I hope this information can help someone.

EDIT: In this test I used the Logitech G29 steering wheel. I will soon test the Thrustmaster T300.

Started by Toasty833 - Last post by Toasty833

Can I ask what game or emulator you are trying to get working that uses right click for off screen reload?
Basically every game works with it. The number of games that don't have an off-screen function is less common, and right click is the standard, basically every gun I've seen sends a right click instead of left click if you click outside of screen boundaries. Only titles like Time Crisis that use a pedal instead don't really have off-screen support. The few titles I've tried so far with just a left click gun would just fire at the edge of the screen if I tried to off-screen reload, but maybe there are a few that see "is gun at border? Then reload" rather than relying on the gun to say "I can't see the screen, send right click instead".

I think using the Inject DLL code I have it would also be able to not just turn off the clicks from Vive Mouse but also intercept them and resend them. It is probably also possible to get the x,y mouse co-ords and then change whether it is left or right click. That should also remove the need for the python code.
If something like that is possible it should be pretty useful.

If you have any problems compiling the Inject DLL code let me know
I used the pre-compiled version in the debug folders and it worked fine for disabling the vive buttons, with the exception of the menu button that still disables the cursor but that isn't really a big issue and I'm guessing it's hardcoded in vive mouse rather than something that's passed through and can be intercepted. With trigger, grip and trackpad that's still 3 usable buttons I can remap through OpenVR2Key because SteamVR still sees them fine.
Pages: [1] 2 3 ... 10