by Buginator » 18 Apr 2011, 00:11
Brent wrote: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.
[quote="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.
[/quote]
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 ?
[quote]
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[/quote]
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. :stressed:
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.