[Gibby]

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...

[lowlevelsoul]

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.

[MangoFusion]

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.

[Hutch]

https://github.com/JeffProgrammer/Torque3D/tree/macosx

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

Contributers:
- @

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

Requirements:
- 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.

[Azaezel]

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 ... ightP.glsl into a non-compiling state did report errors.

--Recieving warning spam of the form:

Code: Select all

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.


[Hutch]

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.

[Azaezel]

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/blo ... ing.cs#L79 is getting read right, but https://github.com/Azaezel/Torque3D/blo ... iz.cs#L162 is not, while
killing off all but a red-return for https://github.com/GarageGames/Torque3D ... ightP.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/Torqu ... 639da79c83 (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/Torqu ... l.cpp#L516

https://github.com/JeffProgrammer/Torqu ... p.cpp#L576

https://github.com/GarageGames/Torque3D ... h.cpp#L246 (shouldn't effect terrain though)

https://github.com/GarageGames/Torque3D ... ce.cpp#L35 VS https://github.com/GarageGames/Torque3D ... pp#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.

[Azaezel]

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.)

[Hutch]

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...

[Timmy]

Impressive az & hutch, nice work