Event Driven Framework
BlitzMax Forums/BlitzMax Beginners Area/Event Driven Framework
| ||
| I'm looking for a Game Framework that minimizes on CPU usage by being event driven and not polling but using sleep or wait between events. Events can be immediate or timed. Is there such a thing? Thanks. |
| ||
| Is your application really that cpu intensive? Normally it should be enough if restrict your game loop with a timer. I don't know of such a framework btw. |
| ||
| My current framework is quite old now. It eats a full CPU core at 100% because it is just a constant loop. I'll investigate the timer method. Thanks. |
| ||
You can also simply limit the hertz by setting it with the Graphics command (at the beginning):Graphics width, height, depth, hertz, flags So you could do: Graphics 800,600,0,60 |
| ||
| Put a Delay 1 at the end of your main game loop. It will give control back to the OS. Works best with limiting the frame rate also. |
| ||
| I use a Event loop framework, which uses my timer function http://www.blitzbasic.com/codearcs/codearcs.php?code=1721 and a (optional, but most times) full screen boarder-less window with a message loop for the GUI. The question is why do you want less than 100% cpu use? If it is because your game isn't fast enough so you want more than 100% speed (if you know what I mean) then I don't think event driven would be any faster. The main point of event driven is so that the computer OS can run other things, that is your game logic and screen update would still be as slow or fast, and most ppl tend to "Over imagine" what their "Game needs" and tend to be pushing the limit of whatever machine they are using. (Not everyone, and I would say the main exceptions to this are the people who actually finish games quite regularly) If you do simply want your OS to have some time then as Czar said just a Delay 1 would be enough. EDit. The link example does run at 100%, but that's just cos its an example Last edited 2011 |
| ||
| I use a Event loop framework, which uses my timer function http://www.blitzbasic.com/codearcs/codearcs.php?code=1721 and a (optional, but most times) full screen boarder-less window with a message loop for the GUI. The question is why do you want less than 100% cpu use? If it is because your game isn't fast enough so you want more than 100% speed (if you know what I mean) then I don't think event driven would be any faster. The main point of event driven is so that the computer OS can run other things, that is your game logic and screen update would still be as slow or fast, and most ppl tend to "Over imagine" what their "Game needs" and tend to be pushing the limit of whatever machine they are using. (Not everyone, and I would say the main exceptions to this are the people who actually finish games quite regularly) If you do simply want your OS to have some time then as Czar said just a Delay 1 would be enough. EDit. Removed Last edited 2011 |
| ||
| It's more of a personal experiment. It isn't about speed or letting my OS have its share of the CPU but reduction in energy consumption and heat generation. It is a known fact that the CPU is the largest consumer of energy on a laptop and a large generator of heat (GPU as well). If you can code a game in such a way that it reduces the amount of CPU use, then it will impact battery life. Thus, the game can be played longer for laptop users. I would just like to see if an Event Driven program will reduce the amount of CPU use to a degree that it would be worthwhile. If you could reduce the amount of drawing and only use CPU when necessary, I think it might be worth it. After all, why should the CPU be at 100% when you have the game on pause because the phone rang or nature is calling. Of course, certain genres would be impossible to reduce consumption but I think a lot of casual games do not need to keep the CPU so high all of the time. I thought it might be a good experiment to find out though. |
| ||
| By giving the CPU back to the OS, it can realize there is nothing else going on and idle it. Otherwise your exe will constantly take 100% processor time in task manager. It might reduce the energy consumption of the processor. Last edited 2011 |
| ||
| Checkout BRL.EventQueue. You should be able to easily build what you need. |
| ||
| I wrote a small app that simply clears the screen and draws a rectangle where the mouse is. With a standard game loop and no VSync, my CPU sits at a constant 75%. With VSync it falls to a constant 3.5%. With an Event Driven approach that waits for events and only draws when something has changed, the CPU fluctuated between 2 and 3%. When the game was at rest it was at 2% and when the mouse was moving it was 3%. Of course, once you add particles and more complex game logic, that CPU will raise. However, I think with this approach it will allow the CPU to have lots of breathing room to cool down and conserve energy. At the same time, it does complicate the game programming. It would be interesting to see if there would be more or less savings than the VSync method when the game logic gets more complicated. |
| ||
| I don't really understand this. First of all, what game has such a static screen that it's worth this effort? Won't the screen be changing all the time? If nothing is going on, who wants to play it? Secondly, CPU and GPU are different things. Drawing uses up GPU, updating uses CPU. If nothing is drawing, a lot of stuff could still be updating and so you won't save any CPU, although you might save some GPU. You want to sleep between events, but where are these events coming from? Something has to be generating them and updating the game. It's easier and probably better to update with a fixed update rate, such as 20 frames per second. If a frame is updated in 25 milliseconds, then you can idle the CPU for the remaining milliseconds until you reach the 50 point. |
| ||
| If your game was not on a fixed rate logic, how many times do you think it would execute the game loop and nothing really changes from the game's perspective? The CPU would be at 90 - 100% executing nothing really useful. Using a fixed rate logic works but I'm just curious if there might be a way to achieve the same thing but have a logic loop that only executes when needed. Events are generated by the game loop and by the system. So there is always some CPU eaten as I wrote in my prior post. But the idea is to keep the CPU resting as often as is possible. As I stated before, this idea wont matter to certain games such as action games. The only time it would matter in those cases would be when you pause the game for a bio break. Then the CPU would fall to something like 5% since it doesn't have much to do and your machine would start to cool off some but probably not enough to be useful. However, casual games such as in hidden object, there is no need to waste CPU or GPU when you don't have to. Those types of games should not wear your system out by depleting the battery and generating so much heat. Like I said, this is just an experimental idea and I may be completely wasting my time but it's my time to waste. ;) Besides, I will learn something one way or the other. :) |
| ||
| Red, just point to a game such as "Freecell" or "minesweeper". These I think make your point exactly, You dont want freecell running at 100% cos lets face it most ppl (well me) only play it when they are waiting for something else to finish. I would say tho that with multiple cores, and with the fake multitasking PC had/have a low priority possibly is enough. But, its why I do it. Last edited 2011 |
| ||
| Ok for those games it's an interesting prospect! As for pausing an action game, I would have thought there was CPU reduction as less things are being updated. |
| ||
| H&K exactly. Those kind of games don't need constant CPU use and don't because they are purely event driven. I think other games (casual games in particular) would benefit from a similar structure. I've played too many casual games that my Mac is smoking hot afterwards and I can't believe that something like a hidden object would cause that. World of Warcraft, I expect that kind of thing. Where is Waldo? ... No. :) Czar, you're right that pausing should reduce the CPU quite a bit because it isn't really doing anything -- especially with fix rate logic. But I think if your pause screen has no animation to it, the CPU/GPU should only have to execute the draw once and never change it again until there is input from the user or a system issued redraw. That would allow the CPU and GPU to cool down much faster. Of course, that part can be done without an Even Driven framework. You could implement that in any framework to save your GPU some work. |
   |