T2D on Mac OS 10.6.8 [solved]
by Amjad Yahya · in Torque 2D Beginner · 07/11/2013 (2:34 am) · 30 replies
I want to see if anybody else is having the same issue I'm facing, and maybe with a little help we could figure out how to fix this:
Torque2D.app that comes with the binary version is not running on OS 10.6.8, here is a screen shot

Then I decided to compile using xcode 4.2, I get 20 errors and 20 warnings that are basically the same:

I appreciate any help to fix this issue.
Torque2D.app that comes with the binary version is not running on OS 10.6.8, here is a screen shot

Then I decided to compile using xcode 4.2, I get 20 errors and 20 warnings that are basically the same:

I appreciate any help to fix this issue.
About the author
#2
07/11/2013 (6:12 am)
This is the precompiled binary.
#3
07/14/2013 (4:04 am)
And I've tried the development branch too, same problem.
#4
1- changed the deployment target to 10.6:
this step resulted in the following error: clang: error: invalid deployment target for -stdlib=libc++ (requires Mac OS X 10.7 or later)
Command /Developer/usr/bin/clang failed with exit code 1
2- searched the web for a fix to the above error, found a recommendation to change the C++ standard library -in the project settings- from "lib++ (LLVM C++ standard library with c++'0x support)" to "libstdc++(GNU C++ standard library)", changed it and got the following error and warnings.
click here to see the errors
I'm stuck at this point and don't know what to do, "CTFontDrawGlyphs()" method is no where to be found, even in SDK OSX 10.6
I'm using Xcode 4.2
07/16/2013 (3:56 am)
The original "Torque2D.xcodeproj" project settings are set to work on OSX 10.7, so I did the following steps:1- changed the deployment target to 10.6:
this step resulted in the following error: clang: error: invalid deployment target for -stdlib=libc++ (requires Mac OS X 10.7 or later)
Command /Developer/usr/bin/clang failed with exit code 1
2- searched the web for a fix to the above error, found a recommendation to change the C++ standard library -in the project settings- from "lib++ (LLVM C++ standard library with c++'0x support)" to "libstdc++(GNU C++ standard library)", changed it and got the following error and warnings.
click here to see the errors
I'm stuck at this point and don't know what to do, "CTFontDrawGlyphs()" method is no where to be found, even in SDK OSX 10.6
I'm using Xcode 4.2
#5
replace the CTFontDrawGlyphs call with:
07/16/2013 (8:01 am)
I ran into this when porting the mac OSX layer to TGE for an old game. There are some functions that dont work on the older version of Mac OSX and need to be replaced with the older ways of doing it.replace the CTFontDrawGlyphs call with:
CGFontRef cgFont = CTFontCopyGraphicsFont(mFontRef, NULL);
CGContextSetFont(bitmapContext, cgFont);
CGContextSetFontSize(bitmapContext, CTFontGetSize(mFontRef));
CGContextShowGlyphsAtPositions(bitmapContext, &characterGlyph, &renderOrigin, 1);
CFRelease(cgFont);
#6
07/16/2013 (8:11 am)
Proper way to do it would be to ifdef the version and choose correct code path. If people are interested in a pull request for getting t2d working on 10.6 and Amjad wants to help me test (i dont have 10.6 anymore) I can do an official pull request.
#7
By all means, let me know when to download your repo and I will test it on my Mac and see what happens.
I will try the solution you've suggested and will let you know.
07/16/2013 (8:34 am)
@Tim: thanks for your offer to help sort this out, I will be more than glad to help testing T2D for 10.6, after all, not being able to run t2d -and ultimately the developed games- on 10.6 might get our games rejected by game portals who are targeting an audience with rather older hardware.By all means, let me know when to download your repo and I will test it on my Mac and see what happens.
I will try the solution you've suggested and will let you know.
#9
07/16/2013 (10:16 am)
No, t2d has a lot of warnings, I dont think you need to worry about that.
#10
07/16/2013 (10:23 am)
T2D on OS X has a lot of warnings? I thought we eliminated most, if not all of them.
#11
07/16/2013 (10:35 am)
You did. There are no warnings when building on OSX.
#12
07/16/2013 (11:55 am)
My bad, someone told me it did. I havent tried building it for 10.6 to see what warnings are.
#13
You are not getting any warnings probably because you are building on 10.7 which, I assume, was the developing platform for Torque 1.8 and T2D 2.0. But when I build on 10.6 I get 24 warnings (see the below image) some of which are really critical and needs to be addressed especially the warning that involves the toggleFullScreen which by the way freezes the engine when executing the sand box and hitting the "Full Screen" button.

Any help eliminating any warning would be appreciated.
07/17/2013 (2:05 am)
Quote:T2D on OS X has a lot of warnings? I thought we eliminated most, if not all of them.
Quote:You did. There are no warnings when building on OSX.
You are not getting any warnings probably because you are building on 10.7 which, I assume, was the developing platform for Torque 1.8 and T2D 2.0. But when I build on 10.6 I get 24 warnings (see the below image) some of which are really critical and needs to be addressed especially the warning that involves the toggleFullScreen which by the way freezes the engine when executing the sand box and hitting the "Full Screen" button.

Any help eliminating any warning would be appreciated.
#14
07/17/2013 (5:33 am)
I did have to make some changes that involved removing toggleFullScreen call but I cannot remember if they were all related to 10.6 or to this TGE game. Anyway here is my replacement function for setWindowSize which i assume is where you are getting the toggleFullScreen warning. You are welcome to try them.- (void)setWindowSize:(int)width height:(int)height
{
// Store the width and height in the state
_windowSize.x = width;
_windowSize.y = height;
// Get the window's current frame
NSRect frame = NSMakeRect([_window frame].origin.x, [_window frame].origin.y, width, height);
// Get the starting position of the bar height
F32 barOffset = frame.size.height;
// If we are not going to full screen mode, get a new frame offset that accounts
// for the title bar height
if (!_fullscreen)
{
frame = [NSWindow frameRectForContentRect:frame styleMask:NSTitledWindowMask];
// Set the new window frame
[_window setFrame:frame display:YES];
// Get the new position of the title bar
barOffset -= frame.size.height;
// Update the frame of the torqueView to match the window
frame = NSMakeRect([_window frame].origin.x, [_window frame].origin.y, width, height);
NSRect viewFrame = NSMakeRect(0, 0, frame.size.width, frame.size.height);
[_torqueView setFrame:viewFrame];
[_torqueView updateContext];
}
else
{
NSRect mainDisplayRect = [[NSScreen mainScreen] frame];
// Update the frame of the torqueView to match the window
NSRect viewFrame = NSMakeRect(0, 0, mainDisplayRect.size.width, mainDisplayRect.size.height);
[_torqueView setFrame:viewFrame];
[_torqueView updateContext];
// Otherwise, just go straight full screen
[_torqueView enterFullScreenMode:[NSScreen mainScreen] withOptions:nil];
}
}
#15
07/17/2013 (5:34 am)
I think the rest of those warnings should be harmless, but I am not 100% positive.
#16
It partially worked, it switches to full screen with no problems, but when switching back to windowed mode it just gives me a white screen.
I thought, maybe this line of code is not supposed to be there, so I omitted it:
now I don't have a white screen but still it wont switch back to windowed mode and just displays the menu bar, strange, isn't it?
07/17/2013 (9:26 am)
Thanks Tim.It partially worked, it switches to full screen with no problems, but when switching back to windowed mode it just gives me a white screen.
I thought, maybe this line of code is not supposed to be there, so I omitted it:
[_torqueView enterFullScreenMode:[NSScreen mainScreen] withOptions:nil];
now I don't have a white screen but still it wont switch back to windowed mode and just displays the menu bar, strange, isn't it?
#17
btw, that call keeps it from showing the menu bar since it causes it to enter true fullscreen.
07/17/2013 (12:22 pm)
I had the same issue with TGE. Its been long enough I cant remember the fix, its most likely in another file. If i come across it Ill let you know.btw, that call keeps it from showing the menu bar since it causes it to enter true fullscreen.
#18
07/18/2013 (1:55 am)
Well, here is what I have discovered so far: I have been testing full screen toggle on the sandbox all along, it uses the toggleFullScreen() to switch between full screen and windowed modes rather than setScreenMode(), toggleFullScreen() for some reason is not working properly on OSX 10.6, using setScreenMode() instead should do the trick.bool Video::toggleFullScreen()
{
if ( smCurrentDevice )
{
smCritical = true;
bool result = smCurrentDevice->toggleFullScreen();
smCritical = false;
return( result );
}
return( false );
}
#19
The OSX version lacks this centering routine for some reason and applying the above code won't work either because it's a WINDOWS API code.
I even took a look at the old TGB 1.7.5 to see how this was handled but it turned out that it uses a very different approach with macCarbOGLVideo.cc.
Any thoughts?
07/18/2013 (3:02 am)
Another problem arose (Mac only): when switching from full screen mode to windowed mode the window position is not in the center of the desktop, it is positioned at the left down corner of the screen, that is not the case on "Windows OS" which handles this situation using the below code to center the window (from winOGLVideo.cc)// Center the window on the desktop:
U32 xPos = 0, yPos = 0;
if(adjWidth < (U32)winState.desktopClientWidth)
xPos = ( winState.desktopClientWidth - adjWidth ) / 2;
if(adjHeight < (U32)winState.desktopClientHeight)
yPos = ( winState.desktopClientHeight - adjHeight ) / 2;
test = SetWindowPos( winState.appWindow, 0, xPos, yPos, adjWidth, adjHeight, SWP_NOZORDER );
if ( !test )
{
dSprintf( errorMessage, 255, "OpenGLDevice::setScreenMode\nSetWindowPos failed trying to move the window to (%d,%d) and size it to %dx%d.", xPos, yPos, newRes.w, newRes.h );
AssertFatal( false, errorMessage );
return false;
}
AnimateWindow( winState.appWindow, 90, AW_BLEND );The OSX version lacks this centering routine for some reason and applying the above code won't work either because it's a WINDOWS API code.
I even took a look at the old TGB 1.7.5 to see how this was handled but it turned out that it uses a very different approach with macCarbOGLVideo.cc.
Any thoughts?
#20
07/18/2013 (5:32 am)
The reason it does that is because its spawning the window at position 0 0 and Mac OSX uses opengl so 0 0 is bottom corner. You just need to set the window position to center of screen based on that. You should be able to find the window position in the code that goes back to window mode.
Employee Michael Perry
ZombieShortbus