T3D 1.1 Final Mac OSX 10.6.7
by Tod · in Torque 3D Professional · 06/02/2011 (5:02 pm) · 19 replies
Just installed T3D Final on my macbookpro. I proceeded to load up the demos. Both Deathball Desert and Mars demos fail on startup. The Blank Room and Burg run fine. Last few lines in Console.log are
Program shadergen:/3a2f33d23d88e820_V.glsl / shadergen:/3a2f33d23d88e820_P.glsl: WARNING: vertex shader writes varying 'screenspacePos' which is not active.
Warning: shape art/shapes/buggy/Buggy.DAE collision detail 1 (Collision-1) bounds exceed that of shape.
Program shadergen:/5a0843ed59463d17_V.glsl / shadergen:/5a0843ed59463d17_P.glsl: WARNING: vertex shader writes varying 'screenspacePos' which is not active.
Warning: shape art/shapes/Cheetah/Cheetah_Body.dae collision detail 1 (Collision-1) bounds exceed that of shape.
Mapping string: MissionStartPhase2 to index: 9
*** Phase 2: Download Ghost Objects
<end of file>
Snip from the crash report:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 ...agegames.FPS Example Bundle 0x12e6fb61 GenOp::print(Stream&) + 25
1 ...agegames.FPS Example Bundle 0x12e6fb6d GenOp::print(Stream&) + 37
2 ...agegames.FPS Example Bundle 0x12e6cc1f MultiLine::print(Stream&) + 37
3 ...agegames.FPS Example Bundle 0x12e6e6f5 ShaderGen::_printPixShader(Stream&) + 141
4 ...agegames.FPS Example Bundle 0x12e6ebeb ShaderGen::generateShader(MaterialFeatureData const&, char*, char*, float*, GFXVertexFormat const*, char const*, Vector<GFXShaderMacro>&) + 1089
Model: MacBookPro6,1, BootROM MBP61.0057.B0C, 2 processors, Intel Core i7, 2.66 GHz, 4 GB, SMC 1.57f17
Graphics: NVIDIA GeForce GT 330M, NVIDIA GeForce GT 330M, PCIe, 512 MB
Graphics: Intel HD Graphics, Intel HD Graphics, Built-In, 288 MB
Program shadergen:/3a2f33d23d88e820_V.glsl / shadergen:/3a2f33d23d88e820_P.glsl: WARNING: vertex shader writes varying 'screenspacePos' which is not active.
Warning: shape art/shapes/buggy/Buggy.DAE collision detail 1 (Collision-1) bounds exceed that of shape.
Program shadergen:/5a0843ed59463d17_V.glsl / shadergen:/5a0843ed59463d17_P.glsl: WARNING: vertex shader writes varying 'screenspacePos' which is not active.
Warning: shape art/shapes/Cheetah/Cheetah_Body.dae collision detail 1 (Collision-1) bounds exceed that of shape.
Mapping string: MissionStartPhase2 to index: 9
*** Phase 2: Download Ghost Objects
<end of file>
Snip from the crash report:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 ...agegames.FPS Example Bundle 0x12e6fb61 GenOp::print(Stream&) + 25
1 ...agegames.FPS Example Bundle 0x12e6fb6d GenOp::print(Stream&) + 37
2 ...agegames.FPS Example Bundle 0x12e6cc1f MultiLine::print(Stream&) + 37
3 ...agegames.FPS Example Bundle 0x12e6e6f5 ShaderGen::_printPixShader(Stream&) + 141
4 ...agegames.FPS Example Bundle 0x12e6ebeb ShaderGen::generateShader(MaterialFeatureData const&, char*, char*, float*, GFXVertexFormat const*, char const*, Vector<GFXShaderMacro>&) + 1089
Model: MacBookPro6,1, BootROM MBP61.0057.B0C, 2 processors, Intel Core i7, 2.66 GHz, 4 GB, SMC 1.57f17
Graphics: NVIDIA GeForce GT 330M, NVIDIA GeForce GT 330M, PCIe, 512 MB
Graphics: Intel HD Graphics, Intel HD Graphics, Built-In, 288 MB
#2
Might be a good idea to pull it from the downloads then? No use frustrating other Mac users if the product is known to not function properly?
06/03/2011 (8:38 am)
Thanks Michael,Might be a good idea to pull it from the downloads then? No use frustrating other Mac users if the product is known to not function properly?
#3
We may re-upload it with the Preview naming for it so that there's less confusion.
06/03/2011 (9:24 am)
We wanted to give Mac users something so that they could at least see what the current state of the engine was for Mac as they haven't gotten anything in a very long time. Since the engine does at least compiles and run (any level that uses imposters will crash still) we felt it was ok to release that much with full Mac support coming later.We may re-upload it with the Preview naming for it so that there's less confusion.
#4
Thanks!
06/03/2011 (11:02 am)
I'm glad you guys uploaded it...I would like to poke at it some myself since I am primarily on a Mac these days (iPhone development for my day job).Thanks!
#5
Obviously graphics related - is there a known "this stuff needs fixing" list for WHAT though?
I'd love to help get this working in a better shape, as similar to Matt most of my dev time is on a Mac (and rebooting into Windows in order to work on a hobby project almost ensures that hobby doesn't get done)
06/03/2011 (4:59 pm)
Is there any place where we can see a list of known issues on the Mac?Obviously graphics related - is there a known "this stuff needs fixing" list for WHAT though?
I'd love to help get this working in a better shape, as similar to Matt most of my dev time is on a Mac (and rebooting into Windows in order to work on a hobby project almost ensures that hobby doesn't get done)
#6
1) Make all of the demos run (without crashing) in Basic Lighting and look basically correct
2) Update to using the newer version of PhysX which has a Mac version
3) Finish implementing Advanced Lighting on the Mac (with some work arounds and probably lower quality shadows)
The first one is just someone with good Torque knowledge and a reasonable grasp of GLSL and OpenGL on the Mac plowing away for a couple of weeks.
The second one isn't too bad but might be best to wait for the PC version to update to the latest PhysX so that they do most of the work.
The third is a pretty big undertaking and will require expert knowledge in OpenGL on the Mac as well in deferred rendering and shadowing techniques and in Torque 3D. Not something to undertake lightly.
06/03/2011 (6:03 pm)
There are 3 major things that need fixing:1) Make all of the demos run (without crashing) in Basic Lighting and look basically correct
2) Update to using the newer version of PhysX which has a Mac version
3) Finish implementing Advanced Lighting on the Mac (with some work arounds and probably lower quality shadows)
The first one is just someone with good Torque knowledge and a reasonable grasp of GLSL and OpenGL on the Mac plowing away for a couple of weeks.
The second one isn't too bad but might be best to wait for the PC version to update to the latest PhysX so that they do most of the work.
The third is a pretty big undertaking and will require expert knowledge in OpenGL on the Mac as well in deferred rendering and shadowing techniques and in Torque 3D. Not something to undertake lightly.
#7
4) The web publishing doesn't work on anything newer than OS X 10.5 (and the min spec for Torque 3D is OS X 10.6.6 because of graphics drivers bugs). Unfortunately, I don't think this is fixable without completely rewriting the web publishing for the Mac.
06/03/2011 (6:15 pm)
Whoops! Forgot a big one:4) The web publishing doesn't work on anything newer than OS X 10.5 (and the min spec for Torque 3D is OS X 10.6.6 because of graphics drivers bugs). Unfortunately, I don't think this is fixable without completely rewriting the web publishing for the Mac.
#8
06/03/2011 (7:20 pm)
Any chance you might revive the old policy of giving owners access to your Subversion (or whatever you're using now) repository? I can't make any promises - I have a full-time job and game programming is just a when-I-get-time gig - but if I do find & fix any bugs I'd be happy to send in the diffs. Even read-only access to the repository would help with that.
#9
06/03/2011 (7:42 pm)
GarageGame's current Subversion host makes it fairly expensive to add new users (they also get access to the other project management and wiki features of the package they are using) so I don't expect them to open it up any time soon (unless you are under contract with them). Not even the Associates have Subversion access anymore.
#10
06/03/2011 (7:47 pm)
Ah well. I figured it was a long shot anyway - worth asking about though. :-) 
#11
06/04/2011 (5:42 am)
Can't even run the current 1.1 download at all, it simply quits/crashes before anything shows up. Been like that since always, I've been running the Windows version in Parallels and putting up with some graphical glitches. Perhaps I'm missing something obvious.
#12
I fired up the windows version and gasped. First thing I thought is, "Wow, this is slick!" I do a lot of my art work on my Mac, so I was pretty excited to load that up. I admit I was a bit discouraged when the demo's crashed right away. Matt's list is pretty accurate. I would put emphasis on #1 and #3.
Without ending on a low note, I have to say, damn nice job on the windows version though. I am extremely happy with what I have seen :-)
06/04/2011 (7:17 am)
I certainly understand the motivation to release it. The OSX folks haven't had any new toys to play with in a while. Maybe just remove the demos that don't work from the install. I fired up the windows version and gasped. First thing I thought is, "Wow, this is slick!" I do a lot of my art work on my Mac, so I was pretty excited to load that up. I admit I was a bit discouraged when the demo's crashed right away. Matt's list is pretty accurate. I would put emphasis on #1 and #3.
Without ending on a low note, I have to say, damn nice job on the windows version though. I am extremely happy with what I have seen :-)
#13
I also wouldn't mind seeing some of the other systems cleaned up to use Cocoa instead of deprecated Carbon code. Keyboard input comes to mind.
06/06/2011 (8:03 pm)
The fine folks over at Wolfire Games seem to have the ins and outs of advanced GLSL programming for Mac (and everything else) down pat. They have their hands pretty full making Overgrowth, but I suspect they could point you in the direction of some other developers with similar tastes and talents. If GarageGames is actively pursuing Mac-based graphics programmers, that may be a lead worth following up.I also wouldn't mind seeing some of the other systems cleaned up to use Cocoa instead of deprecated Carbon code. Keyboard input comes to mind.
#14
06/07/2011 (12:09 am)
Quote:I also wouldn't mind seeing some of the other systems cleaned up to use Cocoa instead of deprecated Carbon code++ to that. I want to head down that path for iTorque 2D as well.
#15
[edit]
From the XCode documentation:
[edit 2]
The TextInputSources functions are still Carbon, but are evidently "modern Carbon" and relied on by both Carbon and Cocoa.
06/07/2011 (12:29 pm)
It seems like this might be an appropriate library for fixing the keyboard layout code, but I'm not convinced that Text Input libraries are really what we want for a gaming application? Does anyone else have knowledge about this? developer.apple.com/library/mac/#documentation/TextFonts/Reference/TextInputSour...[edit]
From the XCode documentation:
Quote:API deprecation
Except for KBGetLayoutType, all of the functions in Keyboards.h are deprecated in Leopard and unavailable in the 64-bit API. The preferred alternatives are the functions in TextInputSources.h.
Notable Bug Fixes
KLGetCurrentKeyboardLayout previously returned the Script Manager's notion of current key layout - that is, the keyboard layout with numeric ID corresponding to GetScriptVariable( GetScriptManagerVariable(smKeyScript), smScriptKeys ). This had several problems: it would not return a Unicode-only layout if it was the current layout; it would not always return the current key layout in use if the calling application was not in focus; and it would not reflect the effect of key layout overrides, e.g. from calling TISSetInputMethodKeyboardLayoutOverride. Now KLGetCurrentKeyboardLayout returns the key layout that corresponds to the result of TISCopyCurrentKeyboardLayoutInputSource, which addresses these problems.
KLSetCurrentKeyboardLayout now also sets the keyboard layout override for input methods (effectively calling TISSetInputMethodKeyboardLayoutOverride).
KLGetKeyboardLayoutProperty now returns resNotFound if the requested property is kKLKCHRData but the value is NULL. This is a much more common scenario now that KCHR data is not available for many Apple-supplied keyboard layouts (for which the preferred format is uchr).
[edit 2]
The TextInputSources functions are still Carbon, but are evidently "modern Carbon" and relied on by both Carbon and Cocoa.
#16
Done with macCarbInput.cpp. Fixed both the deprecated keyboard layout and copy-paste code.
06/07/2011 (1:52 pm)
www.garagegames.com/community/resources/view/21059Done with macCarbInput.cpp. Fixed both the deprecated keyboard layout and copy-paste code.
#17
I've gone through the standard steps of copying the missing icon and info.plist file, and generating the projects, but I get a ton of errors regarding "OSAtomicCompareAndSwap64"
Any ideas?
---edit:
I diff'd the 1.1 project file and 1.0.1 and noticed differences in the architecture and SDK. Changing both those and I can build again.
06/07/2011 (11:17 pm)
Has anyone been able to build this?I've gone through the standard steps of copying the missing icon and info.plist file, and generating the projects, but I get a ton of errors regarding "OSAtomicCompareAndSwap64"
Any ideas?
---edit:
I diff'd the 1.1 project file and 1.0.1 and noticed differences in the architecture and SDK. Changing both those and I can build again.
#18
Thanks
07/28/2011 (1:26 pm)
Hello Bryan, can you share Xcode and SDK version you are using to build with success?Thanks
#19
09/27/2011 (12:26 am)
I think you cannot 
Employee Michael Perry
ZombieShortbus