Jump to content

elfprince13

Members
  • Posts

    24
  • Joined

  • Last visited

Posts posted by elfprince13

  1. Now that Visual Studio supports alternate compilers (i.e. Clang), I think it would be in everyone's best interest to drop the VC++ compiler (I don't care for the VS IDE either, but that's personal preference - the VC++ compiler is objectively bad).

  2. I just use a Windows VM, but there are tutorials out there for cross compilation and I'm sure CMake makes it easier now. I'm curious if anyone has verified if the Windows build of Torque is MinGW / Cygwin compatible, because if you are going to cross compile you might as well get the benefit of a modern compiler like GCC or Clang.


    You might also look into compiling and linking with MSVC running under Wine which is something that's been done before.

  3. Custom skyboxes out of Terragen are wonderful and can match HD photography when done right. They can function as a distant terrain AND skybox all in one.

     


    Ditto on this, though at least last time I looked there was no push-button solution to get skyboxes out, and it required a little fiddling.

  4. Is there any documentation on the TAML module system? The wiki is suspiciously empty (or at least the search function isn't turning anything up), and it's been a few years since I did any TorqueScripting so I haven't been keeping up with the modern way of doing things.

  5. We really ought to kill the carbon dependencies. CountMenuItems seems to be completely deprecated at this point.


    [edit]


    Alternatively, just make TORQUE_SDL default to ON. I'm assuming this is how you guys have been working, and I just found it. There's still some weird bits that I had to comment out between the SDL and Mac layers to get everyone on the same page about where Platform:: implementations were coming from.


    [edit 2]


    There are some really severe buffer overruns in macCarbFileIO.mm. I opened a PR for Jeff's repo to include these fixes.

  6. 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

  7. I'm apparently behind the times on SDL, but QT has:

    • Immense cross-platform support
    • GPL, LGPL, and commercial licensing options
    • Support 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

  8. 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).

  9. 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.

  10. 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.

  11. 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/Torque3D


    I'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.

×
×
  • Create New...