Jump to content

Mac-Heads, Unite!


Recommended Posts

Greets all:

Given the renewed interest in an OSX port of T3D and of T3D in general, I've decided to make an OSX how-to my priority. To that end, I'm taking Luis' suggestion and would like to form an ad hoc team to help get it done and tested. I myself an not a real coder, per se, but have considerable experience with Torque on Macs. I've had it working in OSX up to version 3.62 and am updating one of my Macs to compile 3.7 with the intention of writing a wiki.

If you are a mac user with experience with xCode, we need your help. If you own a mac and would be willing to help test/troubleshoot, we need your help as well.

If interested, contact me here...

Link to comment
Share on other sites

I'm willing to help. I'm not sure how much time I can give right now as I have other commitments but once those are out of the way; I'm willing to devote some time to the Mac build.

A little bit about me; I've worked as a programmer in the games industry for the last 16+ years on a variety of platforms. I've worked on platform base code, rendering, physics, animation, collision detection, content tool-chains and a whole load of other bits and bobs. Currently, I'm employed by one of the big three console manufacturers as part of their development support team.

Right now, my main issue is that I've been contracted to write a book which I'm trying to finish. Once that's out of the way, I can spare the time.

Link to comment
Share on other sites

Having worked on the Frozen Cortex Mac port, I'd say it shouldn't be too hard with stock T3D. The platform code needs updating to strip out the last of the carbon code however.

From a maintenance standpoint it might be worth making the mac code use the SDL2 linux code for 99% of the core platform stuff and then add on the menu bar and popup menu stuff as platform-specific extras. Given the current state of each OSX release deprecating crucial APIS, I am personally moving towards such a solution for future games.

Link to comment
Share on other sites

  • 5 months later...


Started about a week ago. Here's what we got done, and what we *need* done.


- @Azaezel

- Glenn S.

- @JeffR

HW tested on so far:

- Macbook Pro Late 2013 15inch

- Intel Core i7 2.00ghz (4 physical, 8 logical)

- 8GB DDR3 1600mhz RAM

- Intel Iris Pro 1536MB

- 256GB SSD


- An Intel Mac (if you are using PPC still....why are you on a gamedev forum)

- OSX 10.9+ (OpenGL 3.3 stuff is being used at the moment)

- Xcode using LLVM/Clang compile as 32bit (relying on carbon)

What works:

- Basic lighting pretty much works, haven't found any issues yet

- Gui renders and works

- General fixes for the apple platform

- OpenGL fixes to the mac platform is getting to be pretty solid

- most PostFX

- Impostors render correctly

- Reflections work fine

- Advanced lighting mostly works, see below for what needs fixed

- CMake build system

- OpenAL sound system

What needs done:

- Carbon needs to be gutted out of there for 64bit.

- Advanced lighting - spotlights [and probably point lights] need fixed

- There's some stupid crash when calling .dump() on an object

There are a bunch of shader warnings, but I believe that is the OSX driver because we manually bind attributes of input and output in shaders that are not used in every shader for consistency.

In regards to OpenGL, there seems to be some corruption that is happening within the circularvolatilebuffer system, where occasionally a vbo handle seems to be invalid.

Edited by Hutch
Link to comment
Share on other sites

To elaborate on the testing done as of tonight, some additional notes, which may or may not all be related:

Outpost on hutch's machine:

Reflection, particles, precipitation, scattersky, cloudlayer, and the tree imposters for the forest - proper coloration

All visualizers save for the new one running through vectorLightP.glsl to display PSSM_DEBUG_RENDER information render properly. (so normal, depth et-al are getting packed right)

Prior testing via empty terrain:

any translucent, or emissive/glowing object, multiple layer materials, scrolling et-al all operate properly.

Material preview window render offset. (Possibly flipped vertically?)

--Nontranslucent objects render black, though thier profiles appear to be correct.

--No smearing from the buffer not being cleared properly.

-- No shader compilation errors or warnings. Forcing https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/shaders/common/lighting/advanced/gl/vectorLightP.glsl into a non-compiling state did report errors.

--Recieving warning spam of the form:

Program shadergen:/f1d4dbcc_V.glsl / shadergen:/f1d4dbcc_P.glsl: WARNING: Could not find vertex shader attribute 'vTexCoord4' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord9' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord2' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord7' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vBinormal' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord5' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord8' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord1' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord3' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord6' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vColor' to match BindAttributeLocation request.
WARNING: Could not find fragment shader output 'OUT_col3' to match FragDataBinding request.
WARNING: Could not find fragment shader output 'OUT_col1' to match FragDataBinding request.
WARNING: Could not find fragment shader output 'OUT_col2' to match FragDataBinding request.

Link to comment
Share on other sites

so. Status update for the week:

short version: no visible resolution, though we found a few interesting bits.

Long version with many links for folks to poke along:

We threw deferred at it, since among other things, that had additional visualizers and namedrendertarget references. results:

http://imgur.com/a/gsDYG - windows/linux

http://imgur.com/hJJ6w2z + http://imgur.com/a/hBOP8 Hutch's Mac.

from that we can tell that https://github.com/Azaezel/Torque3D/blob/mac_deferred/Templates/Full/game/core/scripts/client/lighting/advanced/deferredShading.cs#L79 is getting read right, but https://github.com/Azaezel/Torque3D/blob/mac_deferred/Templates/Full/game/core/scripts/client/lighting/advanced/lightViz.cs#L162 is not, while

killing off all but a red-return for https://github.com/GarageGames/Torque3D/blob/development/Templates/Empty/game/shaders/common/lighting/advanced/gl/vectorLightP.glsl returned a red-tint light for win/linux and remained black for mac, which pretty much re-confirms that it is in fact a lightinfo buffer, and lighinfo alone I/O flaw.

We did find two additional points of strange behavior directly linked to the GFX subsystem, https://github.com/GarageGames/Torque3D/pull/1428 and https://github.com/JeffProgrammer/Torque3D/commit/c04125f4e6bda47b95fa7e516cce26639da79c83 (the latter was spitting out insanely high divisors into the shaders/proceedural/autogenconditioners.h file rather than the expected 65535.0)

Additional points that caused raised eyebrows:



https://github.com/GarageGames/Torque3D/blob/b1d2ba8412bf2dc5688ae563dea416bc9407f4fd/Engine/source/ts/tsMesh.cpp#L246 (shouldn't effect terrain though)

https://github.com/GarageGames/Torque3D/blob/c152ae86f3f09b3c1d736954b352723d274582f1/Engine/source/gfx/gl/gfxGLAppleFence.cpp#L35 VS https://github.com/GarageGames/Torque3D/blob/c152ae86f3f09b3c1d736954b352723d274582f1/Engine/source/gfx/gfxFence.cpp#L42-L68 (several potential things missing there, like stateblock, event delegate, and RTT)

We also threw out the lions share of gglHasExtension as having causality by stripping those off the win machine to see if that could cause replication. It didn't.

Sadly, the partridge in a pear tree did not magically show up at the last second of the week to edify us on what else we could be overlooking, so if anyone with additional insight would like to weigh in, it would be greatly appreciated.

Link to comment
Share on other sites

So, folks,

az and i found out that state blocks were messing up advanced lighting. That is now fixed. spotlights need fixed but we know its more stateblocks that are needed to be checked. I added in the openal fixes from Tim-MGT that he sent me probably over a year ago, so now we have advanced lighting and sound working! It's progress people!

Oh, and you do not need the 10.7 SDK anymore to compile. Just make sure that you compile as 32bit because we still rely on carbon. Please note that 64-bit is planned so that we do not have to rely on old frameworks anymore. :)


^^bbcode isn't working...so just providing link...

Link to comment
Share on other sites

To be a bit clearer there, we've isolated it down to a non-default setting https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/core/scripts/client/lighting/advanced/shaders.cs#L27-L52 being misinterpreted. still need to track it a bit more for a proper fix. Also need to hunt down terrain detail blending going a bit pearshaped looks like. (which may very well be stateblock based as well, for that matter.)

Link to comment
Share on other sites

Link to comment
Share on other sites

  • 2 weeks later...

If you want to get rid of those shader attribute warnings you need to link the shader twice: once to get the used attributes, and once again to link the USED attributes. i.e....


  // Link it!
  glLinkProgram( mProgram );

  GLint linkStatus;
  glGetProgramiv( mProgram, GL_LINK_STATUS, &linkStatus );

  GLint activeAttribs  = 0;
  glGetProgramiv(mProgram, GL_ACTIVE_ATTRIBUTES, &activeAttribs );

  GLint maxLength;
  glGetProgramiv(mProgram, GL_ACTIVE_ATTRIBUTE_MAX_LENGTH, &maxLength);

  FrameTemp<GLchar> tempData(maxLength+1);
  *tempData.address() = '\0';

  for (U32 i=0; i<activeAttribs; i++)
     GLint size;
     GLenum type;

     glGetActiveAttrib(mProgram, i, maxLength + 1, NULL, &size, &type, tempData.address());

     StringTableEntry argName = StringTable->insert(tempData.address());

#define CHECK_AARG(pos, name) static StringTableEntry attr_##name = StringTable->insert(#name); if (argName == attr_##name) { glBindAttribLocation(mProgram, pos, attr_##name); continue; }

     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_Position,    vPosition);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_Normal,      vNormal);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_Color,       vColor);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_Tangent,     vTangent);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_TangentW,    vTangentW);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_BlendIndex,  vBlendIndex);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_BlendWeight, vBlendWeight);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_Binormal,    vBinormal);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_TexCoord0,   vTexCoord0);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_TexCoord1,   vTexCoord1);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_TexCoord2,   vTexCoord2);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_TexCoord3,   vTexCoord3);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_TexCoord4,   vTexCoord4);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_TexCoord5,   vTexCoord5);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_TexCoord6,   vTexCoord6);
     CHECK_AARG(GFXGLDevice::GL_VertexAttrib_TexCoord7,   vTexCoord7);

  // Link it!
  glLinkProgram( mProgram );

  glGetProgramiv( mProgram, GL_LINK_STATUS, &linkStatus );


(either that or you need to know the attributes beforehand which would require parsing the shader yourself).

Link to comment
Share on other sites

  • 2 months later...

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


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.

Link to comment
Share on other sites

The graphics layer would need an OpenGLES or Metal implementation in order to do the renderstuffs, but the SDL implementation SHOULD pave the way from a platform layer side of things.


Yeah, SDL should be defaulting to on if you utilize cmake. Also, just for simplicity's sake, could you toss a link to the PR you did in here?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...