Gibby Posted April 1, 2015 Share Posted April 1, 2015 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... Quote Link to comment Share on other sites More sharing options...
lowlevelsoul Posted April 2, 2015 Share Posted April 2, 2015 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. Quote Link to comment Share on other sites More sharing options...
MangoFusion Posted April 6, 2015 Share Posted April 6, 2015 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. Quote Link to comment Share on other sites More sharing options...
JeffH Posted October 1, 2015 Share Posted October 1, 2015 (edited) https://github.com/JeffProgrammer/Torque3D/tree/macosxStarted about a week ago. Here's what we got done, and what we *need* done.Contributers:- @Azaezel- Glenn S.- @JeffRHW 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 SSDRequirements:- 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 systemWhat 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 objectThere 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 October 13, 2015 by Hutch Quote Link to comment Share on other sites More sharing options...
Azaezel Posted October 1, 2015 Share Posted October 1, 2015 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 colorationAll 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. Quote Link to comment Share on other sites More sharing options...
JeffH Posted October 3, 2015 Share Posted October 3, 2015 quick update:The prepass stage in advanced lighting is good. lightinfo is where we're failing at. Will be doing more debugging soon. Gettin' narrower and narrower to hopefully once and forall fix advanced lighting on mac. Quote Link to comment Share on other sites More sharing options...
Azaezel Posted October 10, 2015 Share Posted October 10, 2015 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/linuxhttp://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/JeffProgrammer/Torque3D/blob/macosx/Engine/source/gui/3d/guiTSControl.cpp#L516https://github.com/JeffProgrammer/Torque3D/blob/macosx/Engine/source/app/mainLoop.cpp#L576https://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. Quote Link to comment Share on other sites More sharing options...
Azaezel Posted October 10, 2015 Share Posted October 10, 2015 edited the above. had the wrong link for hutch's specular/lightcolor/specularmap test (the first two reference lightinfo, the third, the upcomming tertiary rendertarget, matinfo. apologies for the confusion.) Quote Link to comment Share on other sites More sharing options...
JeffH Posted October 13, 2015 Share Posted October 13, 2015 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. :)http://imgur.com/Bxlfg4r^^bbcode isn't working...so just providing link... Quote Link to comment Share on other sites More sharing options...
Timmy Posted October 13, 2015 Share Posted October 13, 2015 Impressive az & hutch, nice work :mrgreen: Quote Link to comment Share on other sites More sharing options...
Azaezel Posted October 13, 2015 Share Posted October 13, 2015 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.) Quote Link to comment Share on other sites More sharing options...
Azaezel Posted October 15, 2015 Share Posted October 15, 2015 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/blob/development/Templates/Full/game/core/scripts/client/lighting/advanced/shaders.cs#L46-L52 so the focus-point will likely be around https://github.com/GarageGames/Torque3D/blob/2044b2691e1a29fa65d1bdd163f0d834995433ce/Engine/source/gfx/gl/gfxGLStateBlock.cpp#L142-L149 or so. Quote Link to comment Share on other sites More sharing options...
MangoFusion Posted October 27, 2015 Share Posted October 27, 2015 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). Quote Link to comment Share on other sites More sharing options...
elfprince13 Posted January 8, 2016 Share Posted January 8, 2016 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. Quote Link to comment Share on other sites More sharing options...
chriscalef Posted January 9, 2016 Share Posted January 9, 2016 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? Quote Link to comment Share on other sites More sharing options...
JeffR Posted January 11, 2016 Share Posted January 11, 2016 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.@elfprince13Yeah, 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? Quote Link to comment Share on other sites More sharing options...
elfprince13 Posted January 11, 2016 Share Posted January 11, 2016 Sure. Here's the PR - https://github.com/JeffProgrammer/Torque3D/pull/4And here's my fork, which also has some of the newer patches from the official repo: https://github.com/elfprince13/Torque3DIt builds and "runs", but doesn't seem to be quite working correctly graphically. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.