I was recently reading a game programming book which came out around 2001 and a certain section caught my eye.
The section spoke about event driven programming and poll based game engines.
It stated that event driven programming is easier and faster than polling inside your program.
Events have to be polled internally anyway, so in C++ I can see that there is a performance benefit from moving the polling to a lower level; the windows message queue.
However, does the same apply to Java?
Is event driven coding for games(not GUIs or office apps) faster than poll driven coding?
Yes, I have searched from information about Java and how it handles a generic event system. That’s the problem, all I find is AWT based info when I really want to know is how Java delegates it’s events, does it poll internally in the JVM or does it do what C/C++ does, delegate the responsibility to a lower level; the kernal?
Whether or not some of you are interested I’ve basically been creating my framework and it’s completely based on a message queue and events.
So far I found out that event driven programs create far less garbage than poll based programs.
In fact, while nothing’s occuring no garbage is being created full stop.
In poll based engines I’ve made, small amounts of garbage was being created every frame.
This is no longer the case under an event driven model.
You can have an event driven model in a real time application, it works quite well.
It also simplifies the code quite a bit.
It seems quite obvious, performance wise an event driven architecture is the only way to go.
Nothing else I know will suffice.
All of my stuff is polled and generates no garbage at all. Not really sure what the issue is between one or the other. In fact I find event driven programming harder to cope with when it comes to realtime graphics.
: Did you bother to find out why garbage was created with your poll based games. I’ll bet it was a newbie mistake like enumerating the entity list. There is nothing that would make a poll based system create more garbage.
[quote]You can have an event driven model in a real time application, it works quite well.
It also simplifies the code quite a bit.
It seems quite obvious, performance wise an event driven architecture is the only way to go.
Nothing else I know will suffice.
[/quote]
Can you explain why an event driven game will have better performance?
I think it depends on the game. If there are few enties, or all the entities needs to be updated every frame, then there is no real benefit. I could be wrong, but I’d like to see some proof.
Event-based is always as fast as you can possibly get, assuming 0 overhead for detection compared to the poll overhead for detection (usually fair assumption) whereas polling usually adds some overhead because of unnecessary polls unless the poll frequency is precisely the same as the incoming event frequency, and the incoming frequency is constant/deterministic - which it practically never is.
I agree that GC shouldn’t be an issue in either case, however events are inherently more efficient, since they only do work when work needs to be done.
Then again, a lot of people who use poll make up for it’s shortcomings by batching, whereas a lot of people who use events don’t think of doing so, and batching is, of course, a major saving in many places, since it inherently cuts the per-poll / per-event overhead into a constant amortized over many instances. So, you see cases where polling appears more efficient because it was easier to batch, for instance.
Personally, I prefer events. But they are definitely harder on standard API’s to batch up; if you get your hands on better API’s, e.g. stuff designed properly for async execution, events can be easy to batch, even trivial (just don’t read the queue when it’s ready, and it will “back up” with extra events, that you can then batch process a little later).
But then you’re making them behave like a poll :), which is cheating, no?
This is the “input frequency and spacing exactyl matches the poll f and spacing” situation, which is the “ideal” for a polling system.
Except…if every entity always needs to be updated, at the same interval, it’s really neither polling nor events, it’s just plain deterministic iteration, which cuts out the overhead of both the other methods?
Updating the game world using events and listeners is definitely more complex than a periodic update process. Events can also cause performance problems if you don’t watch out. For example, multiple events might be posted that each causes an update of an object when only one update would be sufficient. This causes a lot of unnecessary work to be performed.
If you use listeners you can easily run into memory leak problems. This is a problem in all more complex Swing applications. Weak references can help you here.
IMHO, a good solution for a game is to have versioned objects and some periodic update process. For example, let’s say you have a model object and some graphical object that renders the model object state (typical Swing design). When the model object is changed it increases its version (a long int). The graphical object that needs to be updated then checks if the last used version is the same as the current model object version, and if that’s not the case the graphical object is updated.
Listeners alone can’t cause memory leaks. At least I haven’t had any.
I guess you can have an abstract entity class to implement this, add a single listener to detect if the version has changed and if a version has changed then send a message which would execute in your main game loop.
You’re a genius.
I’m going to try that.
Thank you.
Depends on how you define “alone”. Each call to addListener can potentially cause a memory leak and should be reviewed carefully. Adding a listener to a locally referenced button is no problem, but in a more complex object structure you can run into problems.
Actually, to prevent memory leaks I would say all listeners should be weakly referenced. The object you’re listening to should never prevent garbage collection and removal of the listener (it’s really one way coupling). This would of course cause problems with listener objects not referenced anywhere else (typically anonymous inner classes), but that can be solved by keeping the listener reference in an object field.
I’m not sure what your talking about here, but if it works for you that’s great.
Listeners don’t cause memory leaks directly, but it is easy to miss cleaning them up when you no longer want to listen. If object A is listening to B in game C and B is removed from C, but not from A, you have a leak which is hard to see because B is never producing events.
That said, I use events and polling together. If ojbect A dies it sends an event to any listeners. Object C might be polling position/orientention information from D,E,E,F, etc.
In the traditional single processor/single-process/mono-threaded one-game-loopworld of game developoment polling is both the msot efficient and the most controllable approach.
You dont care about events at any other time then the poll-point so event-driven woudl just mean queing and polling the queue anyway. Pollign ina tight loop wil lalways use 100% of your system CPu resources but again thats what games have tarditionalyl doen and make no apologies for it.
In a multi-processor world, it gets more complex. You start wanting to do thinsg in parallel. As this becomes more common we may see some thinsg shifting to more event-driven models. However there are stil lpretty big issue with regard to frame synchronizatio nand contro lthat need to be solved.
I know Prof. Kendall has been thinkign a lot lately about multi-processor based game engines. Maybe he’ll weigh in with some wisdom…
[quote] Pollign ina tight loop wil lalways use 100% of your system CPu resources but again thats what games have tarditionalyl doen and make no apologies for it.
[/quote]
It is a right pain when they continue to use 100% CPU when the user is no longer the active user — as when swapping users on XP. Eg.
“Why is my machine so slow, I’m only trying to edit a file in word” … “Because Daniel is still logged on and running a ‘nasty’ game”.
While I agree that “poker” or somr similar card game Or other “mini-game” like minesweeper) shouldnt need to burn all the system resources, serioud games are always trying to deliver the maximal experience the hadwdare can give, which means using all of the hardware and using it as efficiently as possible.
Care to justify your position, rather than make silly sweeping statements? It’s obviously not a de facto, so…
I think you should think before you reply ;). Let’s look at what you’re really trying to do:
Finish the game
Finish on a schedule (usually; especially so for commercial games)
Deliver a fun game
Run fast enough to be enjoyable on your target consumer systems
(optional) include some special new feature (but: only if you’re a well-funded studio: as noted in the IGF this year, indies don’t win if they try to out-graphic id Software)
Include graphics, sound effects, level designs etc that are consistent with each other and the style of game and audience you’re aiming at
Not only does that NOT include “run as fast as possible” but it definitely doesn’t include “using all of the hardware”. You only worry about the latter when you know you’re not going to achieve 3 and 4 on the target hardware using “plain” programming techniques.
Now, for an actual example, there are plenty of games that I’ve fired up and within 1 minute decided never to play again. Apparently this is quite usual in the indie market (where indie certainly doesn’t mean inferior or amateurish, just focussed on doing more with less). But in each of these cases the main reason I got fed up so fast was that they slowed my system to a crawl to do relatively pathetic things (e.g. nothing even close to pixel shaders) that really didn’t need much more than a tenth of the power of my system. OR they soaked up so much RAM (totally unnecessarily) that not only did they run very slowly but they also condemned the rest of my system to run slowly for the next 5 minutes whilst everything gradually swapped back in again. Or they overloaded in taking up system resoureces, and crashed the OS.
Some of those would have been solved by “more efficient” use of the hardware, as you advocate, but mostly they suffered from making the assumption that they could crap all over the user’s machine and not bother to fit themselves to the available resource (the opposite of what you advocate).
I’m not saying that “serious” games don’t use a lot of resource, or as much as they can get their hands on, but there’s a huge gulf between that and saying that games that do not greedily guzzle everything (including tonnes of processor time they don’t need - or, in many cases, will never use) are not serious.
Rubbish! There is no reason why games can’t run this way when in active use, all I am asking is that they detect when the user has been swapped and then go to some quiescent state. There is little point in continuing to generate frames when no one is looking.
If Windows XP was new there would be some excuse for this behaviour, but it has been out for quite a few years now.
All of my games switch to idle when they lose focus… not hard to do… 100% CPU is fine, when that’s what you’re using you computer for! (Although with the new sleep(1) loops it seems they’re using quite a lot less)
at the beginning I was using event driven model in my applet game. I used it for quite long time and it worked really very well - untill I needed to post my own custom events into the queue. (I mean AWT event queue). And this is simply impossible (in applet), because security manager prevents it.
I spent some time trying to workaround it, (best way is to create own queue, and redirect there all incoming awt evens, along with own custom events), but I somehow wasn’t very happy with it. In the end I trashed all the code and switched to polling - and I had no problem since then.
But in many other situations , event driven approach can be better.
input polling should be done at most at 1 kHz. Doing considerably more is bit silly. over 1 kHz is just neccessary for flight simulations with specialized devices to get the right feeling. (Or so was said by profisional pilots.)
I often use 100 UPS, this means updates per second for input, and 30 FPS, the rest of the CPU power is reserved for AI, precalculations, and background rendering if someone is doing theirs work and playing game at the same time.
