Instead of asking about what I immediately need, let me first state what I want to actually do.
-
Throughout the game’s runtime, I want to have data in RAM, written by other than the game thread, that is accessed by the game thread (read only).
-
The data is a schedule of input values of the game pad along with time stamps of when the OS received those inputs.
-
Writing of the input data should be invoked by OS as a result of IRQ or whatever relevant abstraction of that behavior.
-
In other words, the game needs to know when the OS knew about each input, rather than knowing what is the value of the last input at hand.
-
What is UE4’s perspective of doing that inside of its running game? in terms of UE4’s input handling abstraction classes (abstraction from different operating systems and from different I/O devices) and in terms of UE4’s runnable threads handling scheme(if applicable in the first place)!
Side note: if you think this is an unneeded complication, or an overkill for input uptake in a game, please note that I know that it is a common sense to think that it is indeed an overkill, but note as well that I need to actually test the entire idea to know how much it is actually needed, because from where I stand now, it is legitimately needed, and please remember that runtime applications are very case-by-case sensitive.
cheers,
If you want to talk between processes, you can look at something called “Named Pipes” which basically constructs a socket connection between processes. UE’s Shader Compiler actually does that.
The rest of your post is very OS specific and if you’re dealing with custom controllers or something that requires IRQ level code - then you’d need to look at low level OS message pumps and such. UE4 is meant to abstract that so you don’t need to write all that code, so it’s not really extendable for you to hook into those things.
I think you’re likely overthinking things unless you’re dealing with custom hardware - but if you want to go through with things, then start digging through the engine code and find out where you would need to modify things.
Thanks for your reply Matt.
I actually (by mere mentioning of IRQ) caused unneeded misconception. For whatever reason I planted a mind-mine.
Let me will rephrase stuff in a better way:
-The exact required behavior is making specific thread of the game such that the operating system doesn’t run the thread unless i/o update happened.
-The operating system will still choose to run the thread as it sees fit, however the thread mentioned will have highest priority compared to other threads of the game.
-That is what I misleadingly called that the thread or process will be “invoked” by an i/o driver. It meant technically that thread’s priority will be related to i/o updates (loose but generally reliable and safe one directional relation from i/o driver to the that thread that is fully done by OS default logic).
I really hope there is something close to this that I just described.
cheers,
Something has to check that hardware for updates. You can have thread event where a thread sleeps until that event goes active, but you would need to allocate that event when you start your game up and then pass it to the hardware or whatever is looping to poll for updates.
A lot of this is outside of UE4 and just comes down to custom hardware APIs. How I would approach this is get this working with whatever custom API you are creating, then just make a Plugin in UE4 that deals with your custom hardware. Pretty much how UE4 handles custom HW like Occulus, any of the Consoles, MagicLeap, etc.