Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Qt\QtQuick Tutorial

J1M

Arcane
Joined
May 14, 2008
Messages
14,606
But another question, did I understand it correctly that when I use a Q_OBJECT there is no need to delete the object? Take for example all these qt widgets that are created with new Qxxxx(). I must simply assume this, because in none of the examples destructors are used, so it must be handled automatically or the programs would leak badly.
Are you talking about the Q_OBJECT macro or just things like QImage?
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
But another question, did I understand it correctly that when I use a Q_OBJECT there is no need to delete the object? Take for example all these qt widgets that are created with new Qxxxx(). I must simply assume this, because in none of the examples destructors are used, so it must be handled automatically or the programs would leak badly.
Are you talking about the Q_OBJECT macro or just things like QImage?

When I use widgets or derive them with Q_OBJECT macro. But I thought all Qxx objects also use that.

Of course when I create a new object that is not using Q_OBJECT I destroy it.
 

J1M

Arcane
Joined
May 14, 2008
Messages
14,606
If they are created correctly and have a parent, they are deleted when the parent is deleted.
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
I can confirm that, when I created a widget and forgot to assign a parent, I sometimes got heap corruption errors.

Is it still allright if I delete widgets when I want? For example I often need to get rid of buttons which I have dynamically created, and delete them in a SLOT. I assume there is no problem with that?
 

J1M

Arcane
Joined
May 14, 2008
Messages
14,606
It should be fine, but you might want to explicitly remove them from the parent first. If their parent object goes to delete them later and they aren't there it could cause an issue. What? I cannot say.
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
Yes, I should have thought of that. And simply calling delete was certainly not the safest way.

But I assume the QObject::deleteLater() method should do all that's required? At least I feel a lot safer now when I use it instead of delete ..
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
Qt is nice, but most things that I use can be done just as well with Winforms in C#.

Which leads me to the question, what do you think is actually the biggest strength of Qt?
 

J1M

Arcane
Joined
May 14, 2008
Messages
14,606
Some people would say signals and slots.

I'm not a proponent of Qt, so I'd say compared with WinForms it is multi-platform?
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
From what I know, correct me if necessary.

Compared to Winforms Qt is:

generally faster
has better image quality
much better options to adapt visual appearance
much better performance with GLWidget
platforms

advantages of Winforms, mainly due to C#:

very robust, hardly any bugs
large user/development base
better development environment (debugging with Visual C# is a breeze)
easier to program
better OO Language (c#)
free license

disadvantages of .NET:

performance
dlls / deployment


I expect that developing with Qt would take me much more time, therefore I currently tend towards C#/Winforms as long as performance is not an issue. One remaining problem is that skinning Winforms is still an enigma to me.
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
Any opinions on the available alternatives? I am really interested in establishing the best environment for the development of a visually attractive 2D game.

Does anyone work with WPF? My verdict after 1 day: Terrible shit! At first I was very satisfied, because I could make some very good looking forms in no time, but once I wanted to change the look of it .. oh boy. 90% of the examples are in fucking XAML. Having to use XAML instead C# does feel like giving up programming for good. It also feels like going back to school where they want you to learn tons of useless stuff by heart. Of course you can still create controls programmatically, but I did not manage such trivial tasks as making my buttons appear flat style. That's a very bad experience if you come from WinForms. For example if I do not want buttons to have orange border or whatever I have to write my own style which requires XAML or learn to do create styles programmatically? WTF? It should be just 1 fucking property, not a whole mountain of XML code.

Someone wrote very much to the point: "WPF makes the hard trivial and the trivial hard".

Compared to that, I can generally live with the old WinForms, but MS has decided them to die. For game development I also don't like the doublebuffering / flickering problems (which cannot be solved by the way). It may not be obvious when you run a .NET program the first time, but after a while you will notice the screen updates, if have a lot of controls it looks more like a web page is loaded, not like in Qt where the whole screen content appears in one instant.

I may eventually switch to Qt, where there are none of these problems. It was by far the hardest to use, but at least I can also learn something useful and the end results are the best.
 

J1M

Arcane
Joined
May 14, 2008
Messages
14,606
It would be helpful to understand what you are trying to do. If it is a game, why do you want to use WPF instead of rolling your own button? Which platforms do you need support for?
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
It would be helpful to understand what you are trying to do. If it is a game, why do you want to use WPF instead of rolling your own button? Which platforms do you need support for?

A strategy game with very little animation but a lot of menus and 2D graphics. WPF only because it looks better and more modern than Dotnet 2.0 - but I don't like XAML one bit. Otherwise Visual C# 2005 is still the easiest to develop with, but as long as I cannot solve problems with flickering, it does not look as good as Qt or WPF.

Concerning platforms, I don't yet develop for Mac / Linux, but it is nice that Qt can theoretically do it.

Perhaps my problem is that I am not that good in C++, and I ran into problems with polymorphism / casts. I also find it hard to try out stuff, always having to write .h and .cpp simultaneously, and the compiling and debugging is terribly slow compared to C#. Probably I need to practice more of the advanced problems in C++ before I begin full development.
 

EG

Nullified
Joined
Oct 12, 2011
Messages
4,264
. I also find it hard to try out stuff, always having to write .h and .cpp simultaneously

It's not mandatory. It's just a convenience (compile time) for larger projects.

Usually I write the C++ files first, including namespaces, then move everything into the whole header/cpp file duet once I like how it works.

How does Qt go for debugger-ques graphics? (working on the turn based portion of a LotR2 clone, currently all console. I wouldn't mind having some 2D primitives to represent everything. Though I might still go through the trouble of rolling them in OpenGL -- the math is just frightening.
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
. I also find it hard to try out stuff, always having to write .h and .cpp simultaneously

It's not mandatory. It's just a convenience (compile time) for larger projects.

I am trying out some stuff like stubgen / lazy cpp, it helps a little.

But I would be carefully with putting code in the .h, I had to find at some points that e.g. static variables are copied with every include, especially if you just put "global" varibales in a namespace.
 

crojipjip

Developer
Übermensch
Joined
Jan 11, 2012
Messages
4,253
Burning Bridges As you may know sources and headers amount to the same code. For proper workflow just program the header and the source directly into main.cpp. It saves a lot of time.

Code:
// Fine to put in main.cpp source
class CMen {
void Yell();
void Golf();
void BeLogical();
};
 
// Also fine to put in main.cpp source
void CMen::Yell()
{
}
 
void CMen::Golf()
{
}
 
void CMen::BeLogical()
{
}
 
 
int main()
{
return 0;
}

Then separate the code into header/footer. Should be as simple as cut and paste, unless you have a shitty IDE like I use. Anyway you know the drill, paste shit into their respective places.
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
As I said, I had some nasty surprises with .h's, so I always do it the recommended way.

Think of forward declarations and mutual includes.
 

J1M

Arcane
Joined
May 14, 2008
Messages
14,606
Burning Bridges it sounds like you don't want to use C++. In your situation I would just roll my own UI components in XNA, but I'm sure there are some decent ones available for free. Obviously, I'm biased, since I like working on UI and think workflow and tools are king.
 

crojipjip

Developer
Übermensch
Joined
Jan 11, 2012
Messages
4,253
As I said, I had some nasty surprises with .h's, so I always do it the recommended way.

Think of forward declarations and mutual includes.
I think of nothing but the the initial design. That is the frustrating thing to type up across two files. I also don't like the class creator in code::blocks, it is too hands on restrictive and ugly. The most dangerous thing is the beginning. Hell I even experiment in my main.cpp. Because of how desperate I am for pizza, i am open to doing a shit-productive job in pure console. even if no ide allowed. i would do it. i want pizza so damn bad. i lose over 100 USD in the first week.
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
Burning Bridges it sounds like you don't want to use C++. In your situation I would just roll my own UI components in XNA, but I'm sure there are some decent ones available for free. Obviously, I'm biased, since I like working on UI and think workflow and tools are king.

Why XNA? As I said don't need an engine that can draw lots of explosions, but really good UI and quality 2D graphics. And I think from all options this has the worst support for 2D UI. Feel free to correct me if it is not true.
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
Another question, do you think it is necessary to switch to Qt5?

I just read some things about it which I don't like at all ( QML becoming the main focus, and QWidget, QPainter becoming replaced by QML ), and I would like to go on with QWidget derived classes.

I would also like to point out that Qt5 is a major release and there is no compatibility promise between Qt releases. As I heard Qt 4.0 created massive source code compatibility problems. This fact, combined with a paradigm change that I don't need (declarative UI), will be a major problem deciding for Qt.
 

J1M

Arcane
Joined
May 14, 2008
Messages
14,606
Burning Bridges it sounds like you don't want to use C++. In your situation I would just roll my own UI components in XNA, but I'm sure there are some decent ones available for free. Obviously, I'm biased, since I like working on UI and think workflow and tools are king.

Why XNA? As I said don't need an engine that can draw lots of explosions, but really good UI and quality 2D graphics. And I think from all options this has the worst support for 2D UI. Feel free to correct me if it is not true.
  1. It is designed for games. All of the tutorials, libraries, tools, and discussion about it online focus on game projects.
  2. The biggest problems you were having with Qt, that is putting things where you want them, making them look exactly how you want, and object clean-up are extremely easy in XNA.
  3. I'm biased. I think writing UI controls is fun and easy. It sounds like you have other strengths, so here's a list of UI frameworks for XNA: http://forums.create.msdn.com/forums/p/15274/79912.aspx
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
Do you have a screenshot of XNA apps with good 2D UI? It would make it easier to use yet another environment.

By the way I am making progress with my dotNet prototype, it looks like using the default layout managers + transparency were the culprits for flickering. If I program my own layout managers I can prevent flickering, and it looks very nice now.
 

J1M

Arcane
Joined
May 14, 2008
Messages
14,606
Do you have a screenshot of XNA apps with good 2D UI? It would make it easier to use yet another environment.

By the way I am making progress with my dotNet prototype, it looks like using the default layout managers + transparency were the culprits for flickering. If I program my own layout managers I can prevent flickering, and it looks very nice now.
What do you mean by good? The level editors out there for XNA are usually built with XNA + WPF, and just look like any other windows application. If you want to customize things they can look like anything you want.
 

tiagocc0

Arcane
Joined
Jun 29, 2007
Messages
2,056
Location
Brazil
Shit, I kinda missed more than half of this thread, I didn't receive any email about the new posts.
:necro:

I came back here because I'm planning on making a new tutorial for QtQuick/QML using Qt 5.2 .
I started a little application that given a script generates the .pro/.h/.cpp files making a class that is already exposed and ready to be used inside QML.

For example a class named Test with the width/height/title variables.

So you can instantiate it inside QML, for example:

import QtQuick.Controls 1.0
import Test 1.0

ApplicationWindow
{
title: testObject.title
width: testObject.width
height: testObject.height

Test
{
id: testObject
}
}

This is really useful when using Lists of objects.
This way you can keep your code on the C++ side and use QML just for UI as it's intended.

Is anyone interested in this code generator and new tutorial?
 

Burning Bridges

Enviado de meu SM-G3502T usando Tapatalk
Joined
Apr 21, 2006
Messages
27,561
Location
Tampon Bay
I'm reviving this excellent thread. Thanks agaion for tiagocc0 for introducing me to this excellent framework :love:

I have a very interesting task for a program that is supposed to be usable on smartphones, and since I generally like Qt's design and features, and want it to run on Windows as well I have dug out my old code from 5 years ago. The executables still run and work, and I am just about to disseminate them.

So the question is if there are still any Qt developers here or developers interesting in starting on it with me? In 2012 I've written some Qt prototypes with menus, some graphics and sound and must now see what new developments have stacked up.

I will start next week.

Atm I'm not trying to rely on QML but want to build from the ground up. The application is basically a 2D Canvas, we want to render technical 2D drawings in a Qt window. I would ideally want it to use hardware acceleration but that depends on the performance that the unaccelerated canvas shows. For now let's say I prefer it to run without OpenGL, because that will be less work. Once that takes a clearer picture, 3d can always be added later.
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom