Building in UNIX?

[Jookia]

I don't mean compile and make a working copy of the engine (I doubt there's enough UNIX code to do that), but as in get to the compile stage.

[brenttaylor]

That's a pretty massive undertaking, at least at the moment. I believe GG intends to merge in the OS X code base at some point and that will make things a lot easier. If they don't, a complete rewrite of the rendering system will be required.

It might be worth considering dropping something like OGRE in as the rendering engine as part of the process. There's a lot to say for using cross platform rendering engine that is being constantly maintained and updated with the latest tech. Not sure if we would want to go that route or not. In any case, the rendering engine is strictly DirectX at the moment.

In summary, the issues I see:

• We'd need an OpenGL rendering module (OGRE might be a good choice to kill two birds with one stone).
• 64-bit support. While technically not required, most Linux users are running under 64-bit at this point. This is all together a huge beast on it's own. Just getting a 32-bit version working would be an excellent start.
• We'd need a build system consistent with the Windows and OS X builds. Someone suggested CMake. SCons or shell scripts would also be an option. CMake and SCons would reduce the work down to one build system across all platforms. Something automated at any rate. This may tie into Issue Torque Toolbox Rewrite #17.
• And of course, all the platform specific code. I imagine a large chunk of this can be taken from the OS X code base if it gets merged in.

I would love to see Torque building and running properly under all three platforms. I think it's a requirement these days really. It's just going to take time.

[ghost]

Honestly I think the OGRE (or Irrlicht, for that matter) port would be the best thing for Torque. Its rendering performance is pretty horrid under Windows even with a fast video card. We're thinking of coming over from Cryengine and it's night and day, we'd have to seriously downgrade our art just to make it work on Torque. If you were able to hack together an OGRE based renderer that would give Torque a steady stream of graphical updates (and more solid performance) and a much larger developer base.

[dottools]

Currently you can build Torque 3D's dedicated server in Debian at least by following bank's Torque 3D 1.1 Beta 3 Linux Patch resource posting on GarageGames.com. In addition to that losinggeneration has been working in his gcc fixes branch to eventually get that pushed to this development repository.

Unfortunately I've been too busy with work recently to get my changes merged into my forked T3D repository and get a pull request sent of the work I did last December for T3D 1.2.

[brenttaylor]

@matt3
As much as I want to see OGRE integrated into Torque, until some benchmarks and profiling is done, I'm not going to be convinced that OGRE is really going to speed up rendering time. That could be another problem entirely. I agree with everything else however.

@dottools Looks like @just-bank got it working under Issue #19. Was the OS X code already merged?

[ChrisCalef]

I spent a couple of months getting into Ogre back when the future of Torque was in serious question, and I was absolutely floored by the performance. Can't say more than anecdotal evidence, but just in the basic demos it was quite easy to render a thousand characters playing skeletal animations - not with all the networking, game logic etc. that Torque provides, of course, but still, a fantastic number of characters all moving at once, which I couldn't even imagine doing in Torque. Just my two cents. I was highly impressed.

[eugene2k]

About the build system: personally I would vote for CMake (as much as I hate it's syntax). Aside from not having to depend on python for it to work, there's also Bullet in Torque's dependencies that uses it. Plus there's an additional advantage of a number of large projects using it, so you can probably bet on it being more scalable than others as well as less bug prone.

[jamesu]

@eugene2k Pull request #19 resolves this using the existing build system which generates normal Makefiles.

[eugene2k]

Which, personally, I think is a half measure. The existing build system is only used by Torque (to my knowledge), which means resources need to be wasted on supporting it (as well as learning it). Having CMake would rid you of the necessity of having to support generators for project files for example.

[losinggeneration]

I've started work on CMake support (which I had actually kind of planned on from the start when I saw the current way things are built.) I haven't got very far yet, but Full is building and some options are there for setting up torqueConfig.h. Hopefully I'll have some more time to work on it over the next few days, but it's currently 01:30 and I really should get to sleep.

Edit: Removed bit about just-bank as I overlooked that comment while reading through.

[eugene2k]

Heh, I just started working on cmake too. Good thing I read your message before getting anywhere with it. :)

[losinggeneration]

@eugene2k Feel free to check out my cmake branch and give some input and or help out. It will go much faster with more than one person working on it. It'll probably be 13 hours before I'll have time to really work on it anymore (with the exception of my hour lunch break.) So there's definitely some time if you want to work off of what I've started.

Some notes:

• I'm currently trying to mimic the Full, Full PhysX, Empty, & Empty PhysX build profiles currently available. I need to look closer to see what the actual differences are. I'm assuming currently that the PhysX builds pull in other source files, but I'm not 100% on that.
• There are quite a few stubbed options getting written to torqueConfig.h that should be exposed as options (and quite a few others that are just outright disabled.
• I think each subdirectory (T3D, core, gui, forest, etc) will build a static library which will then get put into a shared library at the end or optionally link the static libraries into the main application.
• Platform dependant options & checks still need to be put in. I'm currently assuming Linux. I think OS X & Windows could probably benefit from being able to use CMake too.
• For now I'd say avoid setting any target compiler properties directly if it can be helped. If such options are needed to be added directly to the compiler directly (for instance) make sure there are checks for that compiler since down the road, someone may want to use a different compiler (For instance, Clang instead of GCC, or the Intel compiler, etc)

Working on building Full.{so,dll,dynlib} is going to be the next step I think, with parts of the above list implemented as needed for that build.

[eugene2k]

I'll take a look, but I work lazily most of the time unless something gets me very excited, so don't expect much :)

[losinggeneration]

Fair enough. I just thought I'd make it clear that at least today I don't have a whole lot of spare time to work on it so people aren't expecting huge code drops throughout the day (since my day-job isn't terribly related.) I'm not entirely certain I'll have time tonight, but I think I will have time to at least get some more basics in there.

[DavidWyand-GG]

Pull Request #19 has been merged with the development branch, so that should get you started on some *nix compilation. For any other discussion, it would be great to go to the GarageGames' forums, such as Torque 3D Beginner or Torque 3D Professional. We would like to keep the GitHub issues section for actions that may be made on the repo.

Thanks!