Basis for using Qt

Post a reply


In an effort to prevent automatic submissions, we require that you complete the following challenge.
Smilies
:| :? :) :wink: :D XD :3 :( :lol2: :o :shock: O_o :x :stressed: :P :oops: :cry: :evil: :twisted: 8) :augh: :stare: :roll: :annoyed: :hmm: :geek: :lecture: :ninja: :!: :?: :idea: :arrow: :!!!: :...: :zZz:
View more smilies

BBCode is ON
[img] is OFF
[flash] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Basis for using Qt

Re: Basis for using Qt

by moltengear » 25 Nov 2018, 08:43

Ezio wrote:
20 Dec 2011, 07:55
zany wrote:
Cyp wrote:
zany wrote: 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!!?!?!? :dash1: :Gigakach_01:
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.
:lol2: The topic is certainly old, but still relevant. It was just funny to read. I think it is possible at the moment to use a simpler javascript engine.

Re: Basis for using Qt

by NoQ » 20 Dec 2011, 17:22

IgorBrehm wrote:Master is working very well for me the only thing is that the my units keep getting stuck on the mountains and there is no way of getting them out of there only if you build a repair tower near it and order the unit to recycle I think it is a problem with the terrain :3 :3 :3
That is certainly not related to Qt.
This problem was around long before we had a switch to Qt.

Re: Basis for using Qt

by IgorBrehm » 20 Dec 2011, 17:19

Master is working very well for me the only thing is that the my units keep getting stuck on the mountains and there is no way of getting them out of there only if you build a repair tower near it and order the unit to recycle I think it is a problem with the terrain :3 :3 :3

Re: Basis for using Qt

by Ezio » 20 Dec 2011, 07:55

zany wrote:
Cyp wrote:
zany wrote:
Brent wrote:...
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!!?!?!? :dash1: :Gigakach_01:
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.

Re: Basis for using Qt

by zany » 19 Dec 2011, 22:57

Cyp wrote:
zany wrote:
Brent wrote:...
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!!?!?!? :dash1: :Gigakach_01:
Well, since you asked nicely, we'll try to do the next release without Qt.
srsly?

Re: Basis for using Qt

by Cyp » 18 Dec 2011, 00:47

zany wrote:
Brent wrote:...
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!!?!?!? :dash1: :Gigakach_01:
Well, since you asked nicely, we'll try to do the next release without Qt.

Re: Basis for using Qt

by zany » 17 Dec 2011, 22:48

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.

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!!?!?!? :dash1: :Gigakach_01:

Re: Basis for using Qt

by Buginator » 19 Apr 2011, 03:31

macuser wrote: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. :stressed:

:hmm:

Re: Basis for using Qt

by lav_coyote25 » 18 Apr 2011, 19:03

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

Re: Basis for using Qt

by macuser » 18 Apr 2011, 14:14

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.

Re: Basis for using Qt

by Safety0ff » 18 Apr 2011, 09:40

Zarel wrote: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.

Re: Basis for using Qt

by Zarel » 18 Apr 2011, 06:09

Buginator wrote: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.

Re: Basis for using Qt

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. :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.

Re: Basis for using Qt

by Rman Virgil » 04 Apr 2011, 10:57

.

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 :hmm:

.

Re: Basis for using Qt

by Per » 04 Apr 2011, 09:47

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.

Top