Snip
Snip
Snip
SaltFW is not affiliated with the SALT team. "Salt" in SaltFW stands for "Slim Alternative".
Snip
Snip
Snip
Ah okay, I understandSaltFW is not affiliated with the SALT team. "Salt" in SaltFW stands for "Slim Alternative".
Oh, oopsSaltFW is not affiliated with the SALT team. "Salt" in SaltFW stands for "Slim Alternative".

I don't know whether changing the polling of inputs would be a realistic change to the ROM. If it is then sure, you could adjust the polling rate. If not, then you would have to poll the network port at the rate the game is polling the hardware inputs. This could well introduce lag. Even a few ms delay can make a game feel sluggish compared to the instant response of physical buttons.Network input isn't all that laggy at all, as long as you poll sockets fast enough. At most you're sending like, 0x10 bytes per input poll, and you can keep updating as fast as your computer can send.
That wouldn't necessarily work. If pressing a key triggered a specific function then you could in theory trigger that function another way to simulate the keypress. But what if the input polling happens part way through a function or somewhere in the main loop? It would be much more difficult to trigger that event directly in this situation. It is more realistic to hook into the system functions which report the button state and replace them with ones which determine the state from data received over the network. That way it doesn't matter where in the game the inputs are checked.Sure, but you wouldn't have to reach the part of the game which waits for button inputs. Thats what i ment.
That's why the input redirection requires a separate service, so that polling for input over the network doesn't impact the actual game. I think what you may not realize is that there's already a long process to get input in the first place, they don't just grab stuff from registers and write it straight to HID shared mem, they also have to deal with GPIO registers and i2c which takes time as well, but input is definitely not as instant as it *could* be. As long as you're smart with threading your network input, receiving it doesn't add that much, but if you threw network input in your main threads you'd end up with some laggy input.I don't know whether changing the polling of inputs would be a realistic change to the ROM. If it is then sure, you could adjust the polling rate. If not, then you would have to poll the network port at the rate the game is polling the hardware inputs. This could well introduce lag. Even a few ms delay can make a game feel sluggish compared to the instant response of physical buttons.
--------------------- MERGED ---------------------------
That wouldn't necessarily work. If pressing a key triggered a specific function then you could in theory trigger that function another way to simulate the keypress. But what if the input polling happens part way through a function or somewhere in the main loop? It would be much more difficult to trigger that event directly in this situation. It is more realistic to hook into the system functions which report the button state and replace them with ones which determine the state from data received over the network. That way it doesn't matter where in the game the inputs are checked.

No I didn't realise that - I assumed it was read directly from the input device. Ok, so a service in the background buffering the input commands from a network port which could then be polled might make things better. But, is it even feasible with the current level of rom hacking we are able to do?That's why the input redirection requires a separate service, so that polling for input over the network doesn't impact the actual game. I think what you may not realize is that there's already a long process to get input in the first place, they don't just grab stuff from registers and write it straight to HID shared mem, they also have to deal with GPIO registers and i2c which takes time as well, but input is definitely not as instant as it *could* be. As long as you're smart with threading your network input, receiving it doesn't add that much, but if you threw network input in your main threads you'd end up with some laggy input.

I wonder if this could be adapted to read the in network port. It would be fairly trivial to write the client side acts as the controller once that's running.some guy already made ntr plugin code to inject inputs into the 3ds http://pastebin.com/GXyKmU23