Basis for using Qt

[Brent]

Greetings dev team,

I am a long time lurker--and RTS fanatic, and have recently noticed your decision to move the project to Qt.
While I appreciate the warnings about dropping macintosh support if you can't find a macintosh developer, I couldn't find a thread on the decision making process on the move to Qt from Simple Direct Library.

Qt is excellent for many things, but, it is very much not a good solid platform for real time games, nor was it ever meant to be.
When we went down this path for a commercial game, we found on average, that Qt entailed a pretty significant performance hit in many of the subsystems.
Profiling and debugging became a nightmare because the results were not deterministic, and varied greatly on different platforms and/or the hardware involved.

While it may seem like a logical choice because of the plethora of features that Qt has, tread very carefully. I would hate for you guys, with the limited manpower you have, to go down the same path as us and in the end, having to rewrite the back-end and all the subsystems (that were rewritten countless times trying to get solid deterministic behavior out of Qt) only to be reverted.
The modules we used were QtCore, QtGui, QtXml, QtMultimedia, QtNetwork, QtOpenGL, QtOpenVG, QtScript, QtSql, QtSvg, Phonom and I believe a few others, so as you can see, we went all in with Qt!
Besides the licensing costs, we lost over 4 months trying to deal with various modules.
It took us another 3 months to switch to Simple Direct Library and to get the other areas up to speed.
Thank God we had a team that already had prior industry standard experience with many of the sub-systems that we needed to
write (Networking, GUI, Lua, Svg and so on).
It also came as a surprised that during the rewrite, we gained up to a 40% gain in performance in certain sub-systems, and a whopping 35% lower memory footprint overall, and in one case, the memory footprint was 41% lower! We had team members doing cartwheels in the hallway when they found out they could do more with the new sub-systems than they could with the Qt modules. The biggest performance benefit was with Lua and our custom SVG, SQL, XML and core rendering routines.

It was a very expensive lesson to learn!

We are currently using the Unity engine, and if you guys can afford this path, it is a most excellent choice!

Sorry about the length of this post, but I feel this may help you get a better idea with what your team is getting into, and I am not sure if anyone on your team has industry experience or not.
I'll check back in a few months to see what you guys ended up with.

Regards,
Brent

[lav_coyote25]

brent: do us a favour and sign up for the forums - this way you can not only keep track but perhaps put in a word or two of how things are going with your own endevours... perhaps benefiting both teams. if not, no problem, and thanks for the advise.

[NoQ]

Profiling and debugging became a nightmare because the results were not deterministic, and varied greatly on different platforms and/or the hardware involved.

Since the latest Qt alpha doesn't work for me, this makes sense (:

[Per]

Thanks for your input.

I find it strange that a commercial game developer would use Qt. As for us, we are not aiming to push the envelope, we just need a library that saves us work. That said, we did test performance before starting to use Qt and found that the parts that we require do not become an unfixable bottleneck. We will of course do similar testing before putting other parts of Qt to work. The Qt main loop and events is fast enough. Qt font drawing abysmally slow, but we can work around it by caching it. QtScript is fast enough and very easy to work with, even compared with Lua.

As for determinism, that is a very odd thing to bring up. QtScript is highly unlikely to be deterministic, but we do not need it to be by design. Lua also has issue with determinism in corner cases of the language, as the Spring project discovered. We are not using Qt in ways that would affect determinism, nor do we plan to. I do not understand how that could even be much of a factor in Qt vs SDL, as neither toolkit is meant for computation, let alone deterministic computation.

[Rman Virgil]

.

There is a contingent in the Open Pandora game dev community that have embraced Qt 4.x and are evolving best practices of interest.

I found the following discussion from a few months back worth a gander:

http://boards.openpandora.org/index.php ... me-engine/

- RV

.

[Buginator]

Greetings dev team,

I am a long time lurker--and RTS fanatic, and have recently noticed your decision to move the project to Qt.
While I appreciate the warnings about dropping macintosh support if you can't find a macintosh developer, I couldn't find a thread on the decision making process on the move to Qt from Simple Direct Library.

Qt is excellent for many things, but, it is very much not a good solid platform for real time games, nor was it ever meant to be.
When we went down this path for a commercial game, we found on average, that Qt entailed a pretty significant performance hit in many of the subsystems.
Profiling and debugging became a nightmare because the results were not deterministic, and varied greatly on different platforms and/or the hardware involved.

Do you mean that you got different results depending on the platform you were using ?
Do you also recall which version of Qt it was ?

While it may seem like a logical choice because of the plethora of features that Qt has, tread very carefully. I would hate for you guys, with the limited manpower you have, to go down the same path as us and in the end, having to rewrite the back-end and all the subsystems (that were rewritten countless times trying to get solid deterministic behavior out of Qt) only to be reverted.
The modules we used were QtCore, QtGui, QtXml, QtMultimedia, QtNetwork, QtOpenGL, QtOpenVG, QtScript, QtSql, QtSvg, Phonom and I believe a few others, so as you can see, we went all in with Qt!
Besides the licensing costs, we lost over 4 months trying to deal with various modules.
It took us another 3 months to switch to Simple Direct Library and to get the other areas up to speed.
Thank God we had a team that already had prior industry standard experience with many of the sub-systems that we needed to
write (Networking, GUI, Lua, Svg and so on).
It also came as a surprised that during the rewrite, we gained up to a 40% gain in performance in certain sub-systems, and a whopping 35% lower memory footprint overall, and in one case, the memory footprint was 41% lower! We had team members doing cartwheels in the hallway when they found out they could do more with the new sub-systems than they could with the Qt modules. The biggest performance benefit was with Lua and our custom SVG, SQL, XML and core rendering routines.

It was a very expensive lesson to learn!

We are currently using the Unity engine, and if you guys can afford this path, it is a most excellent choice!

Sorry about the length of this post, but I feel this may help you get a better idea with what your team is getting into, and I am not sure if anyone on your team has industry experience or not.
I'll check back in a few months to see what you guys ended up with.

Regards,
Brent

Other thoughts on Qt, while it does have lots of things in it that we need, it is also easier to go with one library that is still being actively supported. The same can't be said with some of the other libraries that we use.
I know I haven't really had time to do any performance testing besides the basic things...there just isn't enough time to do everything.
I also don't know what kind of performance hits we will get with the new terrain engine, so it is also possible that we use parts of Qt, and go back to SDL. We do know that SDL is at a lower level than Qt, so we do lose performance, but how much is another story. Things are very fluid around here.

We did have a Lua branch, but nobody had the time to fix it.
If the Unity engine was available for us, that would really solve pretty much all our rendering issues, maybe in 10 years, they will release a GPL version.

Thanks again for your input.

[Zarel]

If the Unity engine was available for us, that would really solve pretty much all our rendering issues, maybe in 10 years, they will release a GPL version.

Hmm, what about Irrlicht? I've heard that's also a pretty good 3D engine.

[Safety0ff]

Hmm, what about Irrlicht? I've heard that's also a pretty good 3D engine.

I don't think we'd gain much by using it / that it would not be a good use of our time.

[macuser]

The irrlicht engine is not a replacement for QT it is a replacement for the games built in rendering engine. BTW I think it would be much faster to just convert to using it than to try to get the current one to have all the features we want a the fps we want.

[lav_coyote25]

did we not have this conversation about irrlicht engine before? as well as some other engines... i could have sworn we did...

[Buginator]

The irrlicht engine is not a replacement for QT it is a replacement for the games built in rendering engine. BTW I think it would be much faster to just convert to using it than to try to get the current one to have all the features we want a the fps we want.

We haved looked at this, and other engines, and it isn't easy to plug these in, especially with Qt.
There would need to be lots of changes with pretty much everything.

[zany]

Greetings dev team,

I am a long time lurker--and RTS fanatic, and have recently noticed your decision to move the project to Qt.
While I appreciate the warnings about dropping macintosh support if you can't find a macintosh developer, I couldn't find a thread on the decision making process on the move to Qt from Simple Direct Library.

Qt is excellent for many things, but, it is very much not a good solid platform for real time games, nor was it ever meant to be.
When we went down this path for a commercial game, we found on average, that Qt entailed a pretty significant performance hit in many of the subsystems.
Profiling and debugging became a nightmare because the results were not deterministic, and varied greatly on different platforms and/or the hardware involved.

While it may seem like a logical choice because of the plethora of features that Qt has, tread very carefully. I would hate for you guys, with the limited manpower you have, to go down the same path as us and in the end, having to rewrite the back-end and all the subsystems (that were rewritten countless times trying to get solid deterministic behavior out of Qt) only to be reverted.
The modules we used were QtCore, QtGui, QtXml, QtMultimedia, QtNetwork, QtOpenGL, QtOpenVG, QtScript, QtSql, QtSvg, Phonom and I believe a few others, so as you can see, we went all in with Qt!
Besides the licensing costs, we lost over 4 months trying to deal with various modules.
It took us another 3 months to switch to Simple Direct Library and to get the other areas up to speed.
Thank God we had a team that already had prior industry standard experience with many of the sub-systems that we needed to
write (Networking, GUI, Lua, Svg and so on).
It also came as a surprised that during the rewrite, we gained up to a 40% gain in performance in certain sub-systems, and a whopping 35% lower memory footprint overall, and in one case, the memory footprint was 41% lower! We had team members doing cartwheels in the hallway when they found out they could do more with the new sub-systems than they could with the Qt modules. The biggest performance benefit was with Lua and our custom SVG, SQL, XML and core rendering routines.

It was a very expensive lesson to learn!

We are currently using the Unity engine, and if you guys can afford this path, it is a most excellent choice!

Sorry about the length of this post, but I feel this may help you get a better idea with what your team is getting into, and I am not sure if anyone on your team has industry experience or not.
I'll check back in a few months to see what you guys ended up with.

Regards,
Brent

am I right to think that 2.3.9 don't use this qt bullshit?
IF THAT IS THE PROBLEM WITH MASTER RELEASE THEN WHY THE HELL DIDN'T ANYONE LISTEN TO THIS GUY!!?!?!?

[Cyp]

...

am I right to think that 2.3.9 don't use this qt crap?
IF THAT IS THE PROBLEM WITH MASTER RELEASE THEN WHY THE HELL DIDN'T ANYONE LISTEN TO THIS GUY!!?!?!?

Well, since you asked nicely, we'll try to do the next release without Qt.

[zany]

...

am I right to think that 2.3.9 don't use this qt crap?
IF THAT IS THE PROBLEM WITH MASTER RELEASE THEN WHY THE HELL DIDN'T ANYONE LISTEN TO THIS GUY!!?!?!?

Well, since you asked nicely, we'll try to do the next release without Qt.

srsly?

[Ezio]

...

am I right to think that 2.3.9 don't use this qt crap?
IF THAT IS THE PROBLEM WITH MASTER RELEASE THEN WHY THE HELL DIDN'T ANYONE LISTEN TO THIS GUY!!?!?!?

Well, since you asked nicely, we'll try to do the next release without Qt.

srsly?

dev always try to give whats best for project.