elfprince13 Posted March 10, 2015 Share Posted March 10, 2015 It's unification day, time to find your neighborhood alliance-friendly bar ;)I just created a branch and deleted all of the existing platform* implementations, with the ambitious goal of creating a unified platform layer on top of Qt. https://github.com/elfprince13/Torque3DI'll probably be taking it slow for now as I have a lot of other stuff going on, but this seems like a good experiment, and simplifying the codebase can only be a good thing. Quote Link to comment Share on other sites More sharing options...
buckmaster Posted March 10, 2015 Share Posted March 10, 2015 Oh wow. Ambition! I have to say my brief experience with Qt wasn't thrilling, but I'm interested to see where this goes! Quote Link to comment Share on other sites More sharing options...
Timmy Posted March 10, 2015 Share Posted March 10, 2015 Having used Qt with a former project (GUI based OpenGL app), i'm a massive fan of Qt (IMHO it's the best cross platform GUI API bar none). I am not 100% sure using it for T3D windowing/input is a great idea though (a world editor written in Qt would be awesome). Anyways not trying to knock your work, best of luck with it :mrgreen: Quote Link to comment Share on other sites More sharing options...
elfprince13 Posted March 10, 2015 Author Share Posted March 10, 2015 The thing is - it's not just a sweet cross-platform GUI library, it also handles threading / sockets / file-system abstraction. Switching all of that stuff over to use Qt is a huge reduction in the number of code paths to be maintained, and drastically reduces the risk of individual platforms falling unsupported again. Using SDL or whatever else as a window manager should still be fine, but there's really no reason in the modern era for us to use a homebrewed wrapper around sockets or mutexes, for example. Quote Link to comment Share on other sites More sharing options...
buckmaster Posted March 10, 2015 Share Posted March 10, 2015 Definitely, that seems very reasonable. In that light, how does Qt differ from something like Boost? I'm not extremely familiar with the C++ ecosystem at this level :/. Something I didn't like about Qt was how it's not a library, but brings along a whole baggage of additional compile steps and so on - though to be fair CMake isn't exactly a walk in the park either. Quote Link to comment Share on other sites More sharing options...
elfprince13 Posted March 10, 2015 Author Share Posted March 10, 2015 The ridiculous amount of metaprogramming in boost makes compiling take way too long. So far I haven't had to add any additional compile steps for Qt - just download it and link. It even seems to play nicely with CMake. Right now I'm basically just scrolling through the linking errors to find what platform functions are missing, and adding Qt based implementations one at a time. Anyone else who thinks this is interesting is welcome to join in. Right now it looks like there's about 150ish functions to go. I expect most of this stuff will have straightforward mappings into Qt, so if we knock them off a few at a time we should be in good shape. Quote Link to comment Share on other sites More sharing options...
JeffH Posted March 11, 2015 Share Posted March 11, 2015 yall do realize SDL2 has threading and stuff right? ...Also, not to start a licensing war, but, I do have to mention that QT is under GPL/LGPL. :[ (Can't use lgpl code on ios if you guys ever decide to target it, as you have to static link on ios) Quote Link to comment Share on other sites More sharing options...
elfprince13 Posted March 11, 2015 Author Share Posted March 11, 2015 yall do realize SDL2 has threading and stuff right? ...Wait, really? When did it get all the goodies? Last time I looked at using SDL it was still only input/sound/graphics context. Also, not to start a licensing war, but, I do have to mention that QT is under GPL/LGPL. :[ (Can't use lgpl code on ios if you guys ever decide to target it, as you have to static link on ios)This is a fair point, though those of us who are planning on developing open source stuff don't care, and those of us who aren't can probably afford to pay for a commercial license for Qt (which is available). Quote Link to comment Share on other sites More sharing options...
JeffR Posted March 12, 2015 Share Posted March 12, 2015 I've barely done anything with either SDL or Qt.Can anyone throw down a pro/con for each for the less-than-informed on the subject? All this talk has made me curious ;) Quote Link to comment Share on other sites More sharing options...
elfprince13 Posted March 12, 2015 Author Share Posted March 12, 2015 I'm apparently behind the times on SDL, but QT has:Immense cross-platform supportGPL, LGPL, and commercial licensing optionsSupport for networking, file system abstractions, threading, native UI development (including OpenGL components, and D3D, afaik), a string class with good support for different encodings. Also has support for multimedia using native codec libraries, and WebKit.The libraries are well modularized, so you don't have to link the whole thing to use some of them - e.g. you can use all of the low-level goodies for your dedicated server without needing to take the GUI stuff along for the ride Quote Link to comment Share on other sites More sharing options...
buckmaster Posted March 13, 2015 Share Posted March 13, 2015 How are static builds on various platforms? I confess it may be just me, but the process of trying to link anything in statically seems arcane. I haven't even begun to consider the licensing questions that arise between different forms of linking. But I do dislike having to plonk six different DLLs next to an executable, which is the current state of the Project Manager. Quote Link to comment Share on other sites More sharing options...
JeffH Posted March 13, 2015 Share Posted March 13, 2015 How are static builds on various platforms? I confess it may be just me, but the process of trying to link anything in statically seems arcane. I haven't even begun to consider the licensing questions that arise between different forms of linking. But I do dislike having to plonk six different DLLs next to an executable, which is the current state of the Project Manager. From what I can tell from reading the LGPL, you have to keep them as DLL/Dylib/SO. :) Unfortunatly, the LGPL requires you to dynamically link if your program isn't GPL or LGPL. I find embedded platforms to be a gray area in LGPL. apple makes it pretty clear you can't use it because, well...you have to static link on ios, but what about say andriod?Here's a quick rundown of SDL2 from my knowledge:- Backed by Valve and others- It does not have networking, but whyyyyyy would you want to replace that anyways? That boggles my mind. (And there is always raknet too..)*******- Officially supports Windows, OSX, Linux, Andriod, and iOS. There are unofficial platforms supported as well.- It supports contexts for OpenGL and Direct3D.- Has Input, Joystick, ect support- Has Low level audio support- Threading with Mutex, Semaphores, Condition Vars, Atomics, ect- Video playback- ZLib license.****** I believe there is actually a networking library that goes with SDL under the zlib Quote Link to comment Share on other sites More sharing options...
LuisAntonRebollo Posted March 13, 2015 Share Posted March 13, 2015 Qt is a very good library but i dont like ... use a preprocesor pass for extend c++ language and i think is too much big for us.SDL2 is a more small library we use for window and input, is used by Valve on all his Linux ports. With SDL and c++ library we have all we need. Permisive ZLIB license.I want to clean platform code and improve SDL2 support for next release.This is only my opinion :P@buckmaster, static linking is only a good option for small/simple libraries... more big projects some times need some custom memory allocators, compilers flags... this is a hell to handle. Quote Link to comment Share on other sites More sharing options...
elfprince13 Posted March 15, 2015 Author Share Posted March 15, 2015 From what I can tell from reading the LGPL, you have to keep them as DLL/Dylib/SO. :) Unfortunatly, the LGPL requires you to dynamically link if your program isn't GPL or LGPL. I find embedded platforms to be a gray area in LGPL. apple makes it pretty clear you can't use it because, well...you have to static link on ios, but what about say andriod?This isn't really true. The LGPL requires that you provide a way to relink your binaries. So if you want to (a) static link, and (b) be closed source (GPL vs non-GPL isn't an issue here, if the source is open), you have to provide an unlinked-object file with your release so that others can choose to relink. See section 4: https://www.gnu.org/copyleft/lesser.html#section4 - It does not have networking, but whyyyyyy would you want to replace that anyways? That boggles my mind. (And there is always raknet too..)*******The point wouldn't be to "replace networking", it would be to have a unified code base for the socket-level stuff.@LuisAntonRebollo: We also really ought to clean up file-system access. Torque has a history of writing to badly behaved locations (assuming a program can write to the directory the executable is stored in as a really bad model.....), and Qt provides a nice abstraction for finding platform specific user-data locations, and the like. If you want to stick with something light-weight though, I have a project for the same purpose that has better directory-purpose coverage than SDL: https://github.com/elfprince13/libcrane Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.