TA3D 0.7 Qt5 port progress

Everything related to the code /
Tout ce qui touche au code
Post Reply
User avatar
zuzuf
Administrateur - Site Admin
Posts: 3278
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

TA3D 0.7 Qt5 port progress

Post by zuzuf » Tue Apr 04, 2017 9:33 pm

This thread will be dedicated to the progress of the ongoing port to Qt5. The first changes are quite visible (many dependencies have been removed and Qt5 is the only big dependency left) but because lots of code still rely on OpenGL API, very few parts of the code are running through the Qt5 OpenGL wrapper. This wrapper is the key to portability.

This is the list of dependencies which have been removed from the 0.7 branch:
- Yuni was completely removed and replaced with functions from Qt (the VFS module which used lots of functions from the file system API was converted to the QIODevice, QDir and QFile interfaces)
- SDL (and its child libraries such as SDL_image, SDL_net, SDL_mixer, smpeg) which is basically replaced with Qt5
- SDL_mixer has no equivalent in Qt5 so I had to write a Qt5 based mixer but music is not implemented yet
- SDL_net is replaced with Qt5Network, however it is still largely untested
- SDL_sgui is not used any more, we rely on Qt for warning, error, critical messages, and the configuration interface
- smpeg (used for optional intro video) code is commented out (so intro video won't work for now)
- GLEW is not needed anymore since we use Qt5OpenGL module as a replacement
- FTGL has been replaced with a basic renderer which uses a wrapper above QFont to generate glyph textures (should also make embedding fonts useless because we can use system fonts now)

a few things still have to be removed:
- GLU which is used only for OpenGL 1.x legacy matrix stack helper functions. This is to be replaced with a QMatrix4x4 based stack which will interact with shaders.

big changes have been made to key components:
- strings are stored as QString objects (which uses wide chars, not UTF8)
- textures are no more stored as GLuint handles but as smart pointers to an object (basically an QOpenGLTexture)
- images were stored in SDL_Surface structs, now we use QImage objects, several drawing functions had to be rewritten
- smart pointers use a custom implementation which relies on an embedded reference counter (safer if we have to pass values as weak pointers, for instance in a Lua/script context, and it uses only 1 pointer instead of 2)
- many regular pointers were replaced with smart pointers
- regular threads are implemented on top of QThread
- OpenMP was replaced with parallel loops implemented on top of QThreadPool (which I hope to use to replace all threads which are not dedicated to asynchronous work)

The Qt5 port is not finished yet, but it mostly works so feel free to test it.
=>;-D Penguin Powered

DOT
Posts: 147
Joined: Sat Sep 19, 2009 11:56 am

Re: TA3D 0.7 Qt5 port progress

Post by DOT » Sat Apr 08, 2017 1:06 pm

So the reason porting TA3D to Qt5 instead of SDL is just for the increased portability between different platforms or does it also provide other advances that SDL cannot provide per default? I am just wondering since this is quite a overhaul.

User avatar
zuzuf
Administrateur - Site Admin
Posts: 3278
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

Re: TA3D 0.7 Qt5 port progress

Post by zuzuf » Sat Apr 08, 2017 8:01 pm

Qt5 is much bigger framework than SDL. SDL is only for graphics, audio, basic networking and basic user inputs whereas Qt5 brings many APIs, to access files, network, complex user inputs, threads, bluetooth, graphical interface with look and feel integrated to the target platform, ... Qt5 APIs are higher level than SDL ones and designed for portability. For instance if you write an application using Qt5's OpenGL wrappers, it will run in OpenGL on Linux, OpenGL ES on Android, OpenGL or DirectX at your convenience on windows. You can push system integration very far without sacrificing portability.

Because Qt5 does many things we have to do ourselves with SDL, code will also be small and easier to maintain.

So short answer: portability is indeed a key feature but that's not the only one :)
=>;-D Penguin Powered

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest