A proper game loop
I'd like to implement a proper (yes, this term is apropriate) game loop, like i do in WinAPI. This means that i want a loop that handles OS calls and then allows me to do my own thing. Now the way Qt is structured right now doesn't allow this. There's an infinite loop handling everything called exec(). Trying to use some sort of timer events or other tricks to invoke a step through my game loop is just out of the question, it's like trying to do game rendering inside of a WM_PAINT call.
I'd like to have an option to let Qt process everything it wants to process like moving widgets, button presses, calling my input handling function when a key is pressed, etc. and then return controll to me so i can do my own game logic and rendering.
Now i'd love to try using Qt for cross platform context creation, threading, file system, and most importantly in-game UI. Not looking at the source code, is there a way for me to do this easily? I'd rather ask, because i'm sure i'm not the only one who'd try doing this.
What is the difference between a proper game loop and a normal event loop?
Better to forget about the legacy Winblows crap already. The event model is how stuff works nowadays.
[quote author="Tobias Hunger" date="1342340532"]What is the difference between a proper game loop and a normal event loop?[/quote]
Timing. Events are useful, but not for everything. Letting something else decide when to call my code is just out of the question.
[quote author="matti-" date="1342347259"]Better to forget about the legacy Winblows crap already. The event model is how stuff works nowadays. [/quote]
No it doesn't. It's convenient, but it's just a layer on top of the OS calls, what kind of a comment is that. I'm not interested in using the signal and slot model for everything, it's way too slow.
Constructive responses are welcome.
Your statement does not compute.
Mouse movements are events in all the OSes I am familiar with. I admit that I am not really familiar with windows, but I doubt that id differs in something this fundamental. If it does and you need to do those stupid waitforobject calls, then you are basically implementing a event loop yourself. I doubt that this will be faster than Qts.
If you don't want to poll, then somebody else is deciding when to call your code, even if it is just the OS.
Qt's event system does not use signals and slots at all by the way. It does a bit of conversion from native to Qt events, but that's it.
If you'd focus on the post and not answers to unconstructive comments, you'd understand what i want.
I know what OS events are and how the OS sends events to your application. No, what i'll write probably won't be faster than Qt, this is why i'm considering using it.
[quote author="Tobias Hunger" date="1342463447"]If you don't want to poll, then somebody else is deciding when to call your code, even if it is just the OS.[/quote]
This just doesn't relate to anything i've said.
I know that Qt doesn't use signals and slots for events, but if i want to force Qt to let me execute anything then i have to use signals and slots, i don't want to do that. I want Qt to do it's own thing since it does it so well and let me do my own thing, can i do that with/without modifying the source code. That's all i'm asking since the beginning. I sincerely daubt this is a complicated question to anybody who's been working with Qt. Please try to be constructive.
[quote author="maciejbacal" date="1342465419"]
I know that Qt doesn't use signals and slots for events, but if i want to force Qt to let me execute anything then i have to use signals and slots, i don't want to do that[/quote]
That statement is wrong. You can for example reimplement Qt events, create your own ones and use it to communicate between objects instead of signals and slots. You'd miss a lot of cool features of Qt, but you can do that.
[quote author="maciejbacal" date="1342465419"]
I want Qt to do it’s own thing since it does it so well and let me do my own thing, can i do that with/without modifying the source code.[/quote]
You should be able to do that by not running exec(). Implement your own game loop and call QCoreApplication::processEvents(...) periodically to keep Qt's stuff running.
I really don't see what the problem with signals and slots is. If anything, I'd expect problems with the events, as these require the eventloop to run. Signals and slots are, in the basic use case, just method calls with a little syntactic suger on them. I doubt you're going to see speed increases for avoiding them.
[quote author="sidewinder" date="1342506972"]You should be able to do that by not running exec(). Implement your own game loop and call QCoreApplication::processEvents(...) periodically to keep Qt's stuff running.[/quote]
You do realize that by calling QCoreApplication::processEvents(…) you once again let other routines decide when your code is executed, as you seem to detest so much. processEvents delays whatever code you put in the lines below it to whenever it wants – just like when you have a 0-interval timer slot.
Sorry to say, but you're cargo-cult-programming. The way you probably do it now with processEvents is just a crippled verison of the proper way which makes you subjectively feel better.
That's fine, i just used it to benchmark Qt. Qt's horrible for anything besides I/O when it comes to games. If i let it render any GUI, it eats much more resources than my 3D rendering code. This library is obsolete for real-time games.
It was never meant for real time games: The rendering architecture is in no way suited for those. GUI rendering (in QWidgets and Qt Quick 1) does not use the graphics hardware much and even if it does it can't make very efficient use of it. So of course it uses more resources, assuming you are referring to CPU cycles here. For normal UIs that is just fine. For use in UIs overlayed on 3D scenes you will need to decouple the UI rendering from the 3D rendering.
Qt Quick 2 does use a architecture that lends itself much better to current 3D hardware by the way.
PS: Calling qprocessevents() is not what I meant by decoupling. Doing that is just stupid as already explained by DerManu.
I know it wasn't meant for real-time games, that's why i benchmarked it. I'll check Qt Quick though.