1
\$\begingroup\$

As old and as standard as Linux/C++ is now, I would imagine there's an efficient method, even a library or three, for something as elementary as catching system events.

The types of events I need are things like:

  • GUI: Window resizing, moving, ...
  • IRQ: Inputs (Keyboard/Mouse), USB, ...
  • FS: Node operations, r/w, ...
  • Anything similar, Shutdown, log out, ...

I know:

  • /dev/input/* can be polled
  • Udev ...
  • Xorg can be polled
  • IRQ Handlers ...

Most of these are either inefficient and/or require certain environments, (Xorg, Udev, etc.) IRQ Handlers are efficient, but are good for only one type of event.

Game engines have to be especially efficient with these, in particular inputs, for the sake of FPS loops. If anyone can provide implementation details for inputs, that would suffice and be appreciated.

What is the efficient method I'm looking for? What is commonplace? If I have to build it myself, where do you suggest I start? What tools would I need?

So, to clarify, applications have always had to do this one way or another right? Web browsers, game engines, desktop environments, etc, have all had to gather input and other events efficiently. "How is that?" I'm asking. Is it unreasonable to expect an established OS/PL for practical API(s)? Of course not!

\$\endgroup\$
1
\$\begingroup\$

Game engines have to be especially efficient with these, in particular inputs, for the sake of FPS loops. If anyone can provide implementation details for inputs, that would suffice and be appreciated.

In fact, receipt of the events you're talking about is generally nowhere near the bottleneck for a game. So we generally do not need to do anything particular clever or special or low-level to handle them. Generally, in fact, we just use whatever mechanism is provided for us on whatever platforms we're building for. This is fairly straightforward on Windows and macOS, which have standard GUI APIs that provide ways to listen for nearly all of the event types you listed.

For Linux, which does not have a hard standard GUI library, it's somewhat more complicated, but only by virtue of having potentially many APIs to choose from. One could directly write against Xlib, if one chose, although I'd venture to guess that most people would rather write against the APIs provided by Qt or GTK these days instead. The ease-of-use provided by the higher-level abstractions offered by the likes of Qt vastly overpower the insignificant "perf cost" of using such an abstraction, because (again) handling events is not a bottleneck for most games.

Certainly these days very games bother directly concerning themselves with IRQs or any other driver-level interrupt event. It's not worth the price of admission.

What is the efficient method I'm looking for? What is commonplace? If I have to build it myself, where do you suggest I start? What tools would I need?

Fundamentally you need to simply need to choose which GUI system you're going to use to build your game. SDL? Qt? GTK? There are many choices available and providing guidance as to which you should choose is out-of-scope for this site. They can all fulfill the basic task of giving you a window onto which you can paint your game graphics (with OpenGL or the like) and hook up the receipt of any sort of input event you might want.

Pick one that seems to work with your engineering style and go for it; this will cover most of your listed types of events (window-related ones and input-related ones). It's not necessarily true that a GUI API will also provide filesystem access APIs, but many do. If not you can simply pick an appropriate API according to your needs. For example if all you need is basic file IO, the C++ standard library will suffice. If you want something that leverages the OS's asynchronous file IO capability, you will need to use the OS's API or some wrapper around it. Similarly if you need filesystem-watch events (which isn't super common), you may need to use something like the inotify API.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ Thank you. I am surprised to hear that. QT and GTK are great, but a lot of irrelevant overhead for certain applications that just need inputs. XLib uses polling, which I find to be a waste since IRQs are specifically hardware-implemented for efficiency. I know first-person shooters make a big deal out of FPS logic, so is that really commonplace for them as well? \$\endgroup\$ – HTDE Jan 3 '17 at 20:15
  • \$\begingroup\$ Yes, it's really commonplace. Effectively obody talks to the hardware directly any longer, it's just too expensive to be worth it. Certainly Qt and GTK are huge APIs, but if you just use them to hoist up a window and listen for input you're paying the bare minimum in performance-related overhead and it won't even show up on any of your profiling. In fact if it does, you can rest assured you are likely in excellent shape, perf-wise. \$\endgroup\$ – user1430 Jan 3 '17 at 20:18
  • \$\begingroup\$ Ok. Thanks, Josh! I don't quite understand what makes IRQ handling expensive, but I'll have to find a library or three to get my events done. (I appreciate your point about QT, but it's just too much for my use case, and I don't like getting in the habit of doing things that way.) The problem for me is I am trying to syndicate all events into a single, simple listener service, and it felt to me like the complication would be polling with Xlib on one hand while doing 3 other things and then joining them. \$\endgroup\$ – HTDE Jan 3 '17 at 20:25
  • \$\begingroup\$ "Expensive" means in terms of programmer time, not run time. It is messy and complicated to write, an the "benefit" of doing so is almost nonexistence because it's unlikely you'll actually end up with code that is faster for the purposes you want anyhow. It benefits "regular" applications to be responsive to input as well, so any higher-level abstraction that sits on top of hardware interrupts -- at the OS level or above -- is going to tuned to be as fast as is reasonable already. \$\endgroup\$ – user1430 Jan 3 '17 at 20:29
  • \$\begingroup\$ Alright, well that answers my question wonderfully, so thank you for pointing me in the right direction! \$\endgroup\$ – HTDE Jan 3 '17 at 20:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for?Browse other questions tagged or ask your own question.