• 9
• 9
• 10
• 9
• 10

# SDL+Qt for a devoloping a game engine

This topic is 674 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Since i learned and used SDL to make a game last months, I've been trying to develop a game engine using what I've learned. I thought about mixing SDL and Qt for doing that. Qt will handle the GUI part and SDL the core of the engine. So since I'm an amateur and it's my first time mixing two libraraires, I thought I can use some advice. On of my questions is this : Do I combine the two libraries or not ? I mean for example, when using the game engine, after finishing, the game engine will generate an SDL code that will be compiled externally and launched . Is that a code idea ?

##### Share on other sites

I don't think you'll be able to mix SDL and Qt in the same window, and there may be other complications from using two major libraries together. I think you'd be better off writing your own rudimentary GUI toolkit on top of SDL (or try to find an existing one with an appropriate licence). It's equivalent to what most games do.

##### Share on other sites

Sorry for dup, the site doesn't seem to work well with the current version of Chrome.

Edited by realh

##### Share on other sites

When you say "Qt will handle the GUI part" what do you mean?

##### Share on other sites

When you say "Qt will handle the GUI part" what do you mean?

I mean the interface of the game engine will be based on Qt.

I don't think you'll be able to mix SDL and Qt in the same window, and there may be other complications from using two major libraries together. I think you'd be better off writing your own rudimentary GUI toolkit on top of SDL (or try to find an existing one with an appropriate licence). It's equivalent to what most games do.

I don"t intend to mix them in the same window. I thought of letting Qt handle the interface of the engine which ,depending on the modifciations done by the user, will generate an SDL code which will be compiled and executed externally (not in the same window as the engine). I hope it's clear

##### Share on other sites

Qt can be used to make tools as part of your game's editor.

You can even embed SFML or SDL screens into Qt's stuff.

I have several suggestions that'll make your life easier:

• Don't use Qt in any of your game's released code.
• Don't use Qt for any in-game UI stuff - don't use Qt to draw over your SDL embedded screen, not even in the editor. Put widgets alongside, not drawn over.
• Share as much code as possible between the editor and the game.
• Don't generate code and compile it. Instead, just generate files that the game loads.
• Design the editor for a specific game you are trying to make. Don't design 'generic' engines.

##### Share on other sites

I don"t intend to mix them in the same window. I thought of letting Qt handle the interface of the engine which ,depending on the modifciations done by the user, will generate an SDL code which will be compiled and executed externally (not in the same window as the engine). I hope it's clear

Not clear at all unfortunately..

When you say "the interface of the engine", do you maybe mean an editor, like Unity and Unreal Engine has?

If you do, I think that is the source of the confusion. I think most here assumed you meant the game's UI would be Qt based.

The editor is just an editor. It might use the engine to show a preview of the content, but it isn't the interface of the engine.

It's a tool to build games that are using the engine.

Technically, the interface of the engine would be the programming API.

And the user interface (of the game) might be part of the engine, or use the engine, but the engine could also not bother about UI at all, and you build the UI using separate tools.

##### Share on other sites

I would suggest first adding controls to the game using an immediate mode gui, and see where that takes you.  Just stick with SDL for now.

https://github.com/ocornut/imgui

##### Share on other sites

I don"t intend to mix them in the same window. I thought of letting Qt handle the interface of the engine which ,depending on the modifciations done by the user, will generate an SDL code which will be compiled and executed externally (not in the same window as the engine). I hope it's clear

Not clear at all unfortunately..

When you say "the interface of the engine", do you maybe mean an editor, like Unity and Unreal Engine has?

If you do, I think that is the source of the confusion. I think most here assumed you meant the game's UI would be Qt based.

The editor is just an editor. It might use the engine to show a preview of the content, but it isn't the interface of the engine.

It's a tool to build games that are using the engine.

Technically, the interface of the engine would be the programming API.

And the user interface (of the game) might be part of the engine, or use the engine, but the engine could also not bother about UI at all, and you build the UI using separate tools.

That's what I mean, the editor like this    ,not the game interface ( sorry for the confusion).

Qt can be used to make tools as part of your game's editor.

You can even embed SFML or SDL screens into Qt's stuff.

I have several suggestions that'll make your life easier:

• Don't use Qt in any of your game's released code.
• Don't use Qt for any in-game UI stuff - don't use Qt to draw over your SDL embedded screen, not even in the editor. Put widgets alongside, not drawn over.
• Share as much code as possible between the editor and the game.
• Don't generate code and compile it. Instead, just generate files that the game loads.
• Design the editor for a specific game you are trying to make. Don't design 'generic' engines.

Thank you very much for these tips, I'll keep them in mind. But can you explain me more what do you exactly mean about generating files that the game loads ? What kind of files  ?

One more thing, about sharing the code between the editor and the game, I'm a bit confused about that, could you give some examples. Thanks again .

##### Share on other sites

Thank you very much for these tips, I'll keep them in mind. But can you explain me more what do you exactly mean about generating files that the game loads ? What kind of files  ?
One more thing, about sharing the code between the editor and the game, I'm a bit confused about that, could you give some examples. Thanks again .

In my own project, I have two different sub-projects: The game, and the editor. The game is one .exe the editor is another .exe, but 80% of the code is shared between both of them (as part of static libraries).

I don't copy and paste the code (that'd be bad - they'd accidentally get out of sync!) - I just make both sub-projects know of the location of the shared code (which is a separate subproject), so they can both treat it as their own.

My project is structured like this:

../Common/                     General non-game-specific non-engine-specific code in 'Common::' namespace     [static library]
../Engine/                     Engine-specific and game-specific code in 'Engine::' and 'Game::' namespaces   [static library]
../Platforms/DesktopEditor/    The game's editor                                                              [executable(s)]
../Platforms/Desktop/          The game's executables for Windows/Mac/Linux (still in development)            [executable(s)]
../Platforms/Mobile/           (iOS and Android versions of the game are not yet made)                        [executable(s)]
../Platforms/Console/          (console versions are not yet made)                                            [executable(s)]

Examples of "shared" code would be things like loading and saving parts of the world, displaying areas, loading resources, etc...

The editor creates and edits files like maps, dialogue, scripts, and other resources, and when the game is ran, it loads those resources and uses them.

No code is generated in my project - anything I want to be changeable, I separate out as files that can be loaded - whether event scripts, images, areas, enemies, items, whatever... the Editor writes (and reads) them, the Game reads them and uses them in the game.

There's still alot of work to be done on my project, so I don't want to give the wrong impression - for example, scripting isn't implemented yet. But this concept of making anything that you want changeable be something your executable can load is a very critical game-development concept to understand.