koobas.hobune.stream
Does unity have functionality similar interrupts?
Coming from PIC microcontroller background I generally like to do things using interrupts. For example: when an event occurs (eg. button press to move left) an interrupt is generated and the program enters a interrupt service routine which tells the program to do something(move the player left). The interrupt stops whatever the program was doing and processes the interrupt and then returns back to where the program was.
I was wondering if unity had a similar functionality so I can instantly process user inputs to move my character as soon as the key is pressed rather than having to use the update function (polling if I am correct?). The keypress will essentially work as a trigger that stops the script and processes the user input and then returns to running through the script.
Would coroutines somehow be able to help me be able to do this?
Curious as to why you would want this. Is it just to be using a familiar program$$anonymous$$g model, or do you think you really need to suspend the game to process an input? Or need the speed that polling might not allow?
i was just thinking that if my game is running at say 60fps then i will be checking for inputs every 16.67ms. this means the user could experience up to 16.67ms delay on top network latency(multiplayer game) which is really not optimal. this will get worse with lower framerates but i dont think my game will drop below 60fps since it is a 2d game.
would it be ok to let my game run past 60fps? will the user experience $$anonymous$$ring?
either way i really dont like this method of polling for user input and then having that polling rate set to the frame rate. is there at least someway i can poll faster independently of frame rate?
wait should this mean i SHOULD be involved in game engine development ?
hey @rish - pls tick an answer to help keep the board tidy. Cheers
In PCs almost everything works with polling. Things like hardware interupts (there are no "software" interupts anyway) belong totally to the inner core of your operating system. They are like 2 - X times abstracted / buffered / prehandled by device drivers, virtual device drivers, the messaging system and that's just the OS part. You really never work with "interupts" when you program at application level.
I like PICs too, i've done a lot funny things, but this is something completely different.
Games are almost always processed in frames. A frame is one complete iteration of the main gameloop. In Unity you don't have direct access to the gameloop, but Unity will invoke callbacks in your scripts when it's time to. An important thing is reliability. Unity provides states which are ensured that they stay constant during a frame. Interupts or threads can lead to unpredictable results since you can't determine when a change happens.
So for example when a keydown occures Unity will "detect" the keydown event at the beginning of a frame. Unity sets the keydown state for this key until the next frame. So no matter where within the current frame you check the state it will be constant.
I've never had any problems with such a small input delay. I'm a quite advanced Quake3 / live player and i've never had experienced any visual lag from input delays. Quake actually works like this: At beginning of frame read inputs. Buffer or queue the input until the next network update. Send the input to the server. The server buffers the input again until the next server physics frame. The server processes the input, moves the player calculates physics and prepares a snapshot of the current "situation" (all movable items including players that are visible) and buffer the snapshot. According to the configured sendrate the server sends the snapshot to the player. The player buffers the snapshot. Now, maybe some frames later on the client, at the middle of a frame the client takes the last 2 snapshots and interpolating the position of all items at the "virtual time". This time is actually lagging behind on purpose to provide fluid motions on the client.
I would consider Quake as one of the fastest (and best) FPS games out there. You're moving at around 600 units per sec. and you don't "feel" any delay at least when you have a moderate network connection / distance to the server.
If you watch a recorded demo in ultra slowmotion you can see that the major part of the player reaction time to a visual / auditive event is the player itself. Under "normal" conditions you usually calculate with a reaction time of 1 sec. In quake, due to the fast gameplay, you reach far better values, but nothing even close to 16ms.
If you watch "real" pro players it seems they react way faster, but that's just practise and mainly prediction.
so i just went exploring on the internet and had a look at XNA. XNA similarly has an update() method which is used for calculating things that need to be calculating. XNA also has a draw() method which is used for rendering frames. the great thing about XNA is that you can set update() to be called at a fixed rate and draw() will be called whenever possible. I am fairly saddened update() in unity is tied to framerate (ive spend quite a while learning it) and i think XNA is probably the best choice for me at the moment. I think the game I have in $$anonymous$$d has e-sport potential and AAA quality and feel is really important to me.
I also had a look at making my own 2D c++ game engine and it seems fairly doable except for the networking part. I cant seem to find any tutorials/resources/help on implementing multiplayer in a c++ game engine. if knows where i can get more info regarding c++ networking please link away.
I'd watch that too though - a game can take a lot of time in its main loop that is nothing whatsoever to do with drawing and so nothing can guarantee a regular call at a period of time. In a 2D game with atlased sprites it is unlikely that the drawing will actually be your largest period of time in any case. Also games that run their main loop "at rate x" can often appear visually slower its pretty irrelevant to the user when their button press is recognised if they cannot see the result - and the result may be delayed further by running the game loop with priority over drawing - there needs to be a balance. PhysX in Unity and the time management functions deal well with the potentially variable time step.
Were you to write a game using something like 2D toolkit + Unity you will find a massive amount of supporting functionality for things like collision detection, atlasing textures etc etc
Yeah Unity supports a fixed time step for physics (internally and to your code through FixedUpdate), though of course it isn't actually "real time" and the input is not sampled at that point, it is used for all interpolation and smoothing of physical movements.
$$anonymous$$ultiplayer in Unity is implemented through RakNet which is an open source C++ networking engine. You could check that out. The huge latencies associated with communicating across a network will of course nullify a lot of the benefits of having interrupts in the first place.
$$anonymous$$y guess is that you are building something super complicated if you need to go down this route though - the complexities of interrupts/game loop is, as Bunny says, a very large source of potential faults - but if your game demands it, then go that way.
Polling is the way to go. Most Unity API calls must happen on the same thread, so interrupts wouldn't work anyway without some scheme to marshal the processing onto the main Unity thread.
If you really want to use an event/interrupt structure, you could write an input handler to simulate that. Register event handlers with the system, call a polling method in Update, and the system would call out to your code in an interrupt-like manner.
Really though, polling input is such a trivial thing, do you really want to make it more complex than it needs to be?
i was just thinking that if my game is running at say 60fps then i will be checking for inputs every 16.67ms. this means the user could experience from 0-16.67ms delay on top network latency(multiplayer game) which is really not optimal. i would really like if i can at least poll independently of frame rate.
do you have any other info/links on that even handler stuff you explained. Im pretty new to unity and c#.
I would feel comfortable stating that nearly every single game on the market uses polling for input.
For the event handler, look up C# info about events and delegates. Basically you would add a key code, and tie it to a method. Your input manager would poll for a key, find the key code in the registered handlers, and execute the method.
I'll stress that this is still polling, but it could hide that fact from the rest of your app.
ahh i thought so. is there anyway to poll for user input independant of frame rate? id really like to be able to be able to control polling rate for user input because i have no idea what frame rates people will get on different hardware etc.
I worked on a mobile game where we wanted to get touch inputs faster than the unity framerate, to get a swipe path with as high temporal resolution as possible and hence give the user better control when swiping at speed. We did it with native plugins (ie different for ios and android), which passed a list of touches (position + time) to the main unity thread. Of course that thread could only process those touches one frame at at time, but each frame had a list of touches to process ins$$anonymous$$d of just one. $$anonymous$$aybe something like that could work for you..?
You can use Start a coroutine. Then do something like this.
StartCoroutine(Interrupt());
private IEnumerator Interrupt() { while(true) { if(Input.GetKey(KeyCode.Escape)){ // Some interrupting action } yield return null; } }
