Mac-Heads, Unite!

  • 1
  • 2
17 posts Page 2 of 2
Azaezel
Posts: 385
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Tue Oct 13, 2015 8:45 am
To be a bit clearer there, we've isolated it down to a non-default setting https://github.com/GarageGames/Torque3D ... 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.)
Azaezel
Posts: 385
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Thu Oct 15, 2015 3:03 am
Threw a different hardware spec at it from one of the mac users in my own crew, and she played up until we killed off https://github.com/GarageGames/Torque3D ... cs#L46-L52 so the focus-point will likely be around https://github.com/GarageGames/Torque3D ... #L142-L149 or so.
MangoFusion
Posts: 50
Joined: Wed Feb 04, 2015 12:00 am
by MangoFusion » Tue Oct 27, 2015 3:12 pm
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....


Code: Select all


   // 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).
elfprince13
Posts: 24
Joined: Mon Mar 09, 2015 3:41 am
 
by elfprince13 » Fri Jan 08, 2016 9:44 pm
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.
chriscalef
Posts: 339
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Sat Jan 09, 2016 11:06 pm
This is probably a very stupid question, but does this work put us any closer to getting T3D working on iOS? Or is that just an entirely different beast and not even on the table?
JeffR
Steering Committee
Steering Committee
Posts: 763
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Jan 11, 2016 5:36 am
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.

@
User avatar
elfprince13

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?
elfprince13
Posts: 24
Joined: Mon Mar 09, 2015 3:41 am
 
by elfprince13 » Mon Jan 11, 2016 5:30 pm
Sure. Here's the PR - https://github.com/JeffProgrammer/Torque3D/pull/4

And here's my fork, which also has some of the newer patches from the official repo: https://github.com/elfprince13/Torque3D
It builds and "runs", but doesn't seem to be quite working correctly graphically.
  • 1
  • 2
17 posts Page 2 of 2

Who is online

Users browsing this forum: Bing [Bot] and 1 guest