Game Development Community

T3D -- OpenGL support? MAX OS X? Linux ??

by Jeff Yaskus · in Torque 3D Professional · 08/13/2012 (2:09 pm) · 44 replies

So, has there been any change in porting T3D fully to Max / Linux ?

Last posts I could find, mention openGL porting and Mac OS X drivers as the road block.

But I haven't seen any updates since 2009 ... and recently became involved in a project whose intended target is schools --- which all use MAC OS.

And when searching the GG forums, came across a recent post
www.garagegames.com/community/forums/viewthread/129581

where Richard states the following ... which piqued my curiosity;
When we get back up and running on Mac OS X it should get us an OpenGL renderer that might be easier to port back to Linux than trying to wade through the DirectX to OpenGL path, but there's no word on when that'll happen.

Is it a strictly OS X issue? namely, crappy drivers were mentioned as previous cause of delays.
Or is it an OpenGL issue? If so, what exactly ?

Was the code partially ported, then stopped when roadblocks encountered??

And if openGL is resolved, will it also allow it to then run on Linux builds as well?

If Advanced Lighting is an issue ... can't we work on a build that just uses basic lighting??

... I'm not asking for someone to do all this, just want to know the current state of things.


TGE compiles and works under Linux / Mac OS X / Windows OSes, right? (I had the license)

Maybe I should consider that as a possible solution if T3D is still years from a working *nix port.

Besides, T3D just looks so much better!
#21
08/28/2012 (11:47 pm)
hmm ... just as I suspected ... love the sound of "steamed pengiuns";
blogs.valvesoftware.com/linux/steamd-penguins/
#22
08/29/2012 (1:23 pm)
@Jeff,
There are guides to get hardware that is "compatible" with OSX. Search around for getting PC hardware that OSX will run on without changing the kernel. There are also resources for changing the OSX kernel and you can search for that.
#23
08/29/2012 (4:18 pm)
@Jeff: OS X runs best on Apple hardware ("best" meaning "you won't tear your hair out while installing"), and the virtualisation tools intentionally don't directly support OS X guests on anything but OS X hosts. Apple requested it, probably. You can get disk images which work, but then you're a dirty poser ;)

If you want to build your own system to try OS X on rather than buying a Mac, you'll need as many Intel components as you can and a lot of reading about supported GPUs.
#24
08/29/2012 (4:24 pm)
Keep in mind that running OS X on non-Apple hardware does violate Apple's EULA, so you don't want to do any dev work on a machine like that.
#25
08/29/2012 (6:31 pm)
It'll also break randomly. Apple have historically not used any form of serial for their OS installations, but lately they supposedly report the computer serial number during installation. If it's not a Mac they could decide to deny any or all services at some point. There have been reports of the MAS picking up the Lion installation of a new computer so that logging in to the store with an Apple ID registers it as a legitimate purchase on that account, so they're certainly doing things to keep track of what people have bought. They haven't done anything serious beyond that, like banning computer serials from the store/updates (OS updates come through the Mac App Store too now). Yet :)
#26
08/29/2012 (7:18 pm)
@Scott,
Keep in mind that Apple also lost the jailbreak lawsuit. If this is ever challenged in court then it may go to the same fate. It is not the same, but it is a similar issue. Rather than alienate a legitimate customer it is in their best interest to not ever pursue this. This is not the same as someone stealing the OS. Companies can put anything in the EULA it does not mean it will hold up in court.

You are right in that to certify it works on Apple hardware and software it should be tested on Apple hardware and software. That is what beta testers are for...
#27
08/29/2012 (7:39 pm)
Sorry, I didn't mean to suggest anything that would violate EULAs!

That must be why they only distribute the OS through their App Store ... I'd gladly register with Apple and purchase a license for the OS.

IMHO that's what helped make MS Windows so prevalent ... all the cheap cloned PCs available, drive costs down.

Although, in retrospect it sure made drivers a pain in the butt -- and resulted in tons of bloat to the OS.
#28
08/29/2012 (7:48 pm)
Microsoft were also not in the hardware market at that time.
#29
09/06/2012 (11:17 am)
Update on Mac test build ... can confirm it will require version 10.7 or higher ... as testing it on a Mac Laptop with 10.6.8, the program won't launch saying it requires 10.7

Going to upgrade this laptop and see where the testing goes...
#30
09/06/2012 (11:38 am)
Probably due to Mac OS 10.7 is the first version to support OpenGL 3.2 and that's the minimum recommended OpenGL specification to develop for these days. Sure, you could just support OpenGL 2.1, but then you have conflicts between it and OpenGL ES 2.0 of which more developers are more familiar with these days, programming wise anyway.
#31
09/06/2012 (5:53 pm)
The program actually saying you require 10.7 is because you probably used a 10.7 SDK, which defaults to that minimum deployment version. You can set it lower if you want to, but Snow Leopard is at OpenGL version pathetic.useless, so no point. Lion doesn't even support it fully, but it's not too much different. Read the official docs for pointers.
#32
09/24/2012 (11:09 pm)
The MIT version runs on Wine 1.4/Ubuntu, hence we might only need an exporter.
Is there a Mac version or the last Linux version that I could look at?
Thanks for links etc.
#33
09/25/2012 (10:58 am)
michael@ not yet, but eventually the MIT version will be updated to include Linux and Mac OS X (10.7+) support.

There is a beta version of a mac port for v1.2 but its not released to general public and still used the older t3d license.

And the CE project is also merging the mac port changes into its base, but again that is not yet open to all ...
#34
09/25/2012 (6:19 pm)
Been trying to get compile the different versions on Mac OS X (10.8) and seem to repeatedly run into the same error... my hunch is its a result of using the latest apple compiler, which interprets syntax ... as it compiles in windows w/ the same errors.

It stops on different locations each time I try to compile in Xcode with the stock compiler (LLC 4.1)

and spits out this error ...
"Cast from pointer to smaller type loses information"

Here is an example from opcode / OPC_SweepAndPrune.cpp
if (element) element = (SAP_Element*)(udword(element) + delta);

or

opcode / OPC_OptimizedTree.cpp

"Cast from pointer to smaller type 'udword(aka 'unsigned int') loses information"

linear[box_id].mNegData = (udword)&linear[NegId];

So its clearly an issue with how pointers are handled ... just got me at the moment.

Reminds me of issues on windows related to using GCC vs MS compilers ?!

Any ideas ??
#35
09/25/2012 (6:21 pm)
Are you sure you're compiling in 32-bit mode? That library is a known problem for 64-bit porting.
#36
09/25/2012 (6:23 pm)
hmm... its set to use "Standard (32/64-bit)" for Architecture

and Base SDK "Latest OS X (10.8)"
#37
09/25/2012 (6:26 pm)
Ronny@ I think that helped, changing it to "32 bit Intel" gets past those errors ... thanks!

will push on with merging and testing :)
#38
09/25/2012 (7:21 pm)
Yes, debug mode will compile in the native mode. Archive builds (release) would still fail if you left it at universal.
#39
10/24/2012 (4:27 pm)
Made some progress ... verified the apple port would compile and run with Basic Lighting on OS X 10.8

Then merged the code changes from it, into the T3D MIT release ... now working on tweaking it to compile and link properly.

Once it compiles and runs, will work on uploading the changes back to T3D MIT on GitHub ... so the community can assist with resolving the errors with Advanced Lighting.
#40
10/25/2012 (3:19 pm)
Trying to resolve an error caused by the _DELCARE_ENUM macro ... It keeps triggering an error:

found in engineTypeInfo.h
_DECLARE_ENUM( EngineTypeKind );
"Explicit specialization has extraneous, inconsisten storage class 'extern' "

The macros are :
#define _DECLARE_ENUM( type )
  _DECLARE_TYPE( type )
  template <>
  struct _EngineTypeTraits< type > : public _EngineEnumTypeTraits, type > {};

#define _DECLARE_TYPE( type )
   template<> extern const EngineTypeInfo* TYPE< type >();
   template<> struct _SCOPE< type > {
      EngineExportScope& operator()() const {
        return *reinterpret_cast< EngineExportScope* >
          const_cast< EngineTypeInfo* > ( ( TYPE< type >() ) )
        );
      }
   };