Qt

[Styx]

I'd like to know why exactly the devs decided to switch to QT instead of SDL. SDL is perfectly adequate for almost all situations, so why go through the trouble of replacing it? Also, why QT? QT is meant specifically for GUIs, and not for games at all. It seems like it would add a lot of bulk to the binaries and the executable in memory, with little gain.

[Rman Virgil]

.

Did you catch this recent discussion (a week ago) with a detailed post by one of the devs ?:

Basis for using Qt

- Rman
.

[Zarel]

The comment you link to explains why the flaws of Qt aren't really that much of a problem for us. It doesn't mention why we use Qt, though.

[Rman Virgil]

The comment you link to explains why the flaws of Qt aren't really that much of a problem for us. It doesn't mention why we use Qt, though.

True enough.

And I am sure there is more to the "Why" of Qt than the response of mountaineers when asked why they climb Mount Everest - "Because it's there !"

The question of "Why ?" also came up in another thread a couple weeks back HERE:

viewtopic.php?f=2&t=7694&p=78916#p78916

Interesting. It wasn't specially addressed in that thread either but there is some info from which a "Why" can be inferred - maybe....

- Rman
.

[Zarel]

Personally, I like these things about Qt:

- Support for hardware-accelerated colored cursors and anti-aliased cursors
- Text rendering that doesn't look ridiculously blurry
- Support for windowed-fullscreen

I dislike these things about Qt:

- No support for true-fullscreen

I'm sure none of the three reasons I gave was the actual reason we moved to Qt, though.

[Rman Virgil]

.

In the first link I provided here the last post in that thread was:

.

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

.

The Pandora game devs in that link provided some interesting reasons for WHY they chose Qt.

- Rman

.

[Per]

Why can mean two different things. First, there is the reason why the port was started in the first place. That was because we needed some way to draw SVG for betawidget (new GUI layer), and the alternatives were horrible. It was also because I was intrigued by the question "could it be done?" That was an open question, since running the game inside the main loop of a library that was not designed for games seemed intuitively problematic. However, testing showed that this did not impact speed in any measurable way.

Then second, there is the reason why it should be completed/accepted, which is a different why. Using SVG is still a quite a way off. Qt text rendering is extremely slow. There are other issues. However, we get access to a huge library of useful methods that means we can achieve what we want faster and cleaner. It gives us more portability with less work. It gives a solid platform to rebuild the GUI on one day. Its implementation of javascript (QtScript) was extremely easy to deploy. Personally, I strongly prefer the Qt way of doing fullscreen, which allows alt-tab out, and means that if the game locks up, you do not have to reboot your PC. And Qt is a really nice API to work with.

[lav_coyote25]

Why can mean two different things. First, there is the reason why the port was started in the first place. That was because we needed some way to draw SVG for betawidget (new GUI layer), and the alternatives were horrible. It was also because I was intrigued by the question "could it be done?" That was an open question, since running the game inside the main loop of a library that was not designed for games seemed intuitively problematic. However, testing showed that this did not impact speed in any measurable way.

Then second, there is the reason why it should be completed/accepted, which is a different why. Using SVG is still a quite a way off. Qt text rendering is extremely slow. There are other issues. However, we get access to a huge library of useful methods that means we can achieve what we want faster and cleaner. It gives us more portability with less work. It gives a solid platform to rebuild the GUI on one day. Its implementation of javascript (QtScript) was extremely easy to deploy. Personally, I strongly prefer the Qt way of doing fullscreen, which allows alt-tab out, and means that if the game locks up, you do not have to reboot your PC. And Qt is a really nice API to work with.

now there ya go. thankyou per.

[milo christiansen]

And you get access to the QT container classes (QString, QList, QVector, ...) A lot of my programs are linked to QTCore4 just to get these. So much easer to use than stl.

[lav_coyote25]

so basically - it works for what we want, until we can go ahead with something better. neat.

[Zarel]

Personally, I strongly prefer the Qt way of doing fullscreen, which allows alt-tab out, and means that if the game locks up, you do not have to reboot your PC.

Windowed-fullscreen and true-fullscreen have their advantages and disadvantages. Here are some disadvantages of windowed-fullscreen:

- WM intercepts a lot more mouse movement, clicks, and keypresses
- Worse performance
- Graphics mode must match desktop: screen resolution, gamma settings, etc cannot be changed

Also, note that the inability to alt+tab out is a flaw of your operating system: Windows can alt+tab out of fullscreen no problem. Also, note that if you're using Linux, you can always alt+enter to switch out of fullscreen, and then alt+tab out.

(Of course, all my computers are fast enough that I prefer native screen resolution and the performance impact isn't noticeable, so I personally prefer windowed-fullscreen, but it would be nice to have a choice.)

[Safety0ff]

I thought the option of true fullscreen was going to be implemented...

[Per]

"True fullscreen" is just a concept somebody invented that has no correlate with reality on the OS level, at least not cross-platform. Making wide claims on its behalf is just wrong. On each OS you have multiple options you can turn on/off to make your fullscreen window behave differently, but there is no "turn true fullscreen on" option anywhere to be found. Performance is affected by options dictating how/whether drawing contexts may be shared, or not. Other options dictate how resolution is restored on application switching or exit, which may affect performance. And so on.

I started working on improved fullscreen support for Qt in the QtGame library, which would support resolution switching and setting some flags that would improve certain aspects of the fullscreen experience. It has support for Linux and Windows, but not Mac yet. I also plan to look at adding some extra support for Nvidia proprietary drivers and multiple monitors on Linux, which is tricky with plain X11 calls, because this is something I have to learn to handle anyway for reasons not related to Warzone.

note that if you're using Linux, you can always alt+enter to switch out of fullscreen, and then alt+tab out.

Not if the application hangs, no you can't.

[NoQ]

Of course, all my computers are fast enough that I prefer native screen resolution

One of the reasons to prefer small resolution over native is bigger widgets and font size (good for eyes); i was playing at 640x480 for quite some time in the beginning, but now i got used to 1280x1024 somehow (still, i'm looking forward to try vector widgets ).

[effigy]

I aslo prefer playing in a smaller window (1024x768) due to the GUI. The interface buttons are just too spread out when larger.

As for alt+tab out of full screen in Linux, I thought this was a Warzone issue, vs. SDL.