Mac game porting problems

[kenmo]

Yesterday I installed PureBasic 5.0 B4 and Xcode 3.1.4 onto a Mac I had access to. I ran some of the examples, and they mostly worked fine.

Today I officially started "porting" my game from Windows to Mac, and I ran into.... many problems. I solved a few right away, but the rest are listed below. Any insight or tips would be helpful. I've never owned a Mac, and I have almost zero PB-for-Mac experience except a small program I wrote at school 2 years ago.

Disclaimer: This Mac still has OSX 10.5. I know it's years old. I fear (or hope?) that upgrading the OS and Xcode will fix some of these.



1. The default subsystem is Cocoa, and "carbon" is the alternative, right? I ask because my game (60 FPS on Windows XP) gets about 30 FPS on the default Mac subsystem and 45-60 on "carbon". (I don't know why there is so much difference - the game is just a bare Screen with mostly 2DDrawing and some rare Sprite commands. I played with SmartSync, SetFrameRate, and Delay but saw no good changes.) Carbon runs better for me, currently, but I should probably target Cocoa for the biggest Mac audience, yes?

2. The game will freeze (spinning rainbow cursor) at seemingly random times. I have to kill it with the debugger. Neither the debugger nor the Purifier indicate anything is wrong. I have not found a consistent cause yet.

3. My game runs in both windowed and fullscreen modes. In both cases, I call CloseScreen() when I'm done. But on the Mac, if I call CloseScreen() while in a WindowedScreen, the whole display does a black fade effect (as if closing a FullScreen) then I get an IMA crash.

4. Also, when I open in WindowedScreen, the keyboard works fine. When I switch from WindowedScreen to FullScreen within the game, it works fine. But if I initially open in FullScreen, the key states seem messed up... for example my game thinks Escape is being pressed when it is not... I will try to write up some example code.

5. One of the old Mac bugs that played mono sounds at double-speed seems to be fixed. But I ran into another sound error: at least one of the Ogg Vorbis music files I streamed was at HALF-speed... not sure why, will investigate more.

6. Finally, perhaps the most concerning to me... player deaths "randomly" occur while standing on moving platforms (cause = illegal collisions) which never happens in the Windows version. This is strange, because my collision and physics are all custom written, using just PB math commands, so I would expect them to run identically (they are on similar Intel processors, not sure if that matters). This worries me that there might be some fundamental difference in the way floating points are being calculated or something...

Other observations:

7. The help file says #PB_Window_MinimizeGadget automatically adds #PB_Window_SystemMenu, but this wasn't true for me. I only had the yellow minimize button, I had to manually add SystemMenu to get the red close button.

8. The keyboard constants seem to differ between Cocoa and Carbon compiles... is this normal?

9. Does the Mac IDE not highlight matching braces? If not, why?



I know this is a big list, and without code snippets, it's hard to help. But it's only Day 1, I will report any solutions I find as I go. A friend with OSX Mountain Lion has offered to install PB and test Cocoa/Carbon versions for me... I will see if that helps at all.

[J. Baker]

Yeah, I would target Cocoa.

1.) Use a timer for execution, such as ElapsedMilliseconds(). SetFrameRate() causes a stutter issue and Delay() is no good for timing.

2.) ?

3.) I find that making a game 720p and using the stretch feature for a WindowScreen() is best. Also wilbert has imported the EnableFullScreenButton command for OSX 10.7 and 10.8 which works great with the stretch feature. http://www.purebasic.fr/english/viewtop ... 19&t=50688

4.) ?

5.) Again, wilberts sound library for Core Audio Files (*.caf) uses half the resources on Mac then Ogg. Same link as above.

6.) ?

7.) ?

8.) Stick with Cocoa.

9.) Not sure what you're describing here?

Without code, I had to put the "?". Maybe some of the above will help.

[wilbert]

Cocoa is probably slower because the message sending system it uses is slower compared to the more simple carbon calls.
But more and more of the Carbon API gets deprecated so it still is better to use Cocoa. If things are not fast enough, you might consider using more of the Sprite commands. Sprites use Open GL (hardware accelerated) while the 2DDrawing commands don't (as far as I understand).

If the game freezes, you might consider running the OS X Activity Monitor.
That way you can see the cpu load and memory usage of your application.

As for the lib Joe is referring to, I described the same functionality (enabling the full screen button and using cocoa sound objects) also in this thread
http://www.purebasic.fr/english/viewtop ... 19&t=50795

[Fred]

ScreenOutput() (if you are using it) is very slow on OS X and Linux and should be avoided. For the other specific problem, don't hesitate to post a bug report with a small snippet showing the issue.

[J. Baker]

I didn't even think about 2DDrawing. That's not good in OpenGL for Mac or Windows. DirectX seems to handle it fine but all 2DDrawing's should be made sprites. Also, a good thing to know is that OpenGL on Mac doesn't go any higher then 60fps in OSX 10.7 and 10.8. Not sure about 10.6 or earlier. Didn't use to be anyway. So you can get away with timers currently on Mac. But you never know, that could change. See Example...

Code: Select all

InitSprite()

OpenWindow(0, 0, 0,1280, 720, "Mac 60 FPS", #PB_Window_SystemMenu | #PB_Window_ScreenCentered | #PB_Window_MinimizeGadget)
OpenWindowedScreen(WindowID(0), 0, 0, 1280, 720, 0, 0, 1)

  CreateSprite(1, 128, 128)
   StartDrawing(SpriteOutput(1))
    DrawingMode(#PB_2DDrawing_Default)
     Box(0, 0, 128, 128, RGB(0, 0, 220))
   StopDrawing()
   
   X = 0
   StartTime = ElapsedMilliseconds()
   
Repeat
 
  Event = WindowEvent()
 
  FlipBuffers()
  ClearScreen(RGB(235, 235, 235))
 
  ElapsedTime = ElapsedMilliseconds() - StartTime
 
  If ElapsedTime >= 1000
     StartTime = ElapsedMilliseconds()
     Debug X
  EndIf
  
  X + 1
  
  If X >= 1280
     X = 0 -128
  EndIf
 
  DisplaySprite(1, X, 360 - 64)
 
Until Event = #PB_Event_CloseWindow

[wilbert]

@Joe, my iMac display doesn't support higher rates.

The display refresh rate reports 59.936 Hz, the actual rate a display link callback is called is a little bit lower but I don't know if that is really true or to blame to an inaccuracy of ElapsedMilliseconds().
Are there any Macs that have displays with higher refresh rates ? Otherwise a higher framerate doesn't make any sense.

Code: Select all

Structure CVSMPTETime
  subframes.w
  subframeDivisor.w
  counter.l
  type.l
  flags.l
  hours.w
  minutes.w
  seconds.w
  frames.w
EndStructure

Structure CVTimeStamp
  version.l
  videoTimeScale.l
  videoTime.q
  hostTime.q
  rateScalar.d
  videoRefreshPeriod.q
  smpteTime.CVSMPTETime
  flags.q
  reserved.q
EndStructure

ImportC "/System/Library/Frameworks/QuartzCore.framework/QuartzCore"
  CGMainDisplayID()
  CVDisplayLinkCreateWithCGDisplay(displayID, *displayLinkOut)
  CVDisplayLinkSetOutputCallback(displayLink, callback, *userInfo)
  CVDisplayLinkStart(displayLink)
  CVDisplayLinkStop(displayLink)
EndImport

Global DisplayLink, Counter, TimerStart

ProcedureC MyDisplayLinkCallback(displayLink, *inNow.CVTimeStamp, *inOutputTime.CVTimeStamp, flagsIn.q, *flagsOut.Quad, *displayLinkContext)
  Counter + 1
  CallRate.d = 1000 * Counter / (ElapsedMilliseconds() - TimerStart)
  RefreshRate.d = *inNow\videoTimeScale / *inNow\videoRefreshPeriod
  SetGadgetText(0, StrF(CallRate, 2) + "   " + StrF(RefreshRate, 3) + "FPS")
EndProcedure

If OpenWindow(0, 0, 0, 150, 40, "Timing", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  StringGadget(0, 10, 10, 130, 20, "")
  
  If CVDisplayLinkCreateWithCGDisplay(CGMainDisplayID(), @DisplayLink) = 0
    CVDisplayLinkSetOutputCallback(DisplayLink, @MyDisplayLinkCallback(), #Null)
    TimerStart = ElapsedMilliseconds()
    Counter = 0
    CVDisplayLinkStart(DisplayLink)
  EndIf
  
  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf

[J. Baker]

@wilbert
Yeah, my Mac doesn't either since OSX 10.7. Before that (on OSX 10.6) I had to create a timer or SetFrameRate(60) else the speed of something moving from point a to point b was crazy fast.

No, I believe all Mac monitors are 60hz. Nice code by the way.

[kenmo]

Thanks for the feedback and helpful links.

That's unfortunate that the 2DDrawing library is slow on most platforms... (I already decided I would go all-Sprites for future games)... since this game is 99% filled boxes and filled circles, is it feasible to replace Box and Circle with direct sprite replacements?

Pseudo PB code:

Code: Select all

Procedure SpriteBox(x, y, w, h, color)
  TransformSprite(GenericBox, 0, 0, w, h)
  RecolorSprite(GenericBox, color)
  DisplaySprite(GenericBox, x, y)
EndProcedure

I can't pre-generate sprites for every object in the game because they all fade and change colors in realtime... that's why they're drawn manually.

Some of those other issues (like using CloseScreen() while Windowed) I will demonstrate with code snippets tonight or tomorrow.

[kenmo]

Alternatively, would direct screen access be a better/faster than the 2DDrawing commands? It wouldn't be hard to write a filled box/circle procedure.

Also.. is DrawingBuffer() constant while a screen is open? Or can it change its return value at later times?

[wilbert]

Have you considered using a CanvasGadget instead of a WindowedScreen ?

[kenmo]

I have not considered the CanvasGadget because I was under the impression it is not suited for fast-paced games (I even recommended AGAINST the CanvasGadget in another thread)... although I use it extensively in the game's editor and I like it very much.

Also it would be messy to handle fullscreen and windowed drawing/input so drastically different.

I think my friend is going to loan me his newer Mac Wednesday, so expect a 9-point update later this week

[wilbert]

I mentioned the canvas gadget because Fred mentioned ScreenOutput() being slow.
The speed for drawing to a canvas is comparable to the speed of drawing to an image (as far as I can tell).
Drawing a box to a canvas is pretty fast if you use the default drawing mode, if you are using #PB_2DDrawing_AlphaBlend drawing becomes much slower.
But if you have a lot of rectangles to draw, you probably need something hardware accelerated like OpenGL.

[kenmo]

OK, I borrowed my friend's newer faster Mac with OSX 10.7 and I tried a few things. Here are updates using the same numbers I originally posted.

1. On OSX 10.7, my 2DDrawing game now gets 60 FPS. This is a relief, but I will still look into faster ways to draw everything.

2. The random freezing doesn't seem to happen on this Mac... I will keep investigating.

3. CloseScreen problem: http://www.purebasic.fr/english/viewtop ... 24&t=51673

4. FullScreen keyboard issues: still investigating, maybe I can reproduce it in a small snippet.

5. OGG audio issues: still investigating, might have been because I was streaming from a USB drive.

6. Random collision/physics problems: still happens with newer OSX/Xcode Not sure why yet, it's all floating point math...

7. PB_Window_MinimizeGadget problem: http://www.purebasic.fr/english/viewtop ... 24&t=51674

8. Keyboard constants: http://www.purebasic.fr/english/viewtop ... 24&t=51676

9. Neither of the Macs I tried seem to be highlighting matching/mismatched parentheses in the IDE, even though it is enabled in the preferences. Parentheses just show up plain black. Matched/mismatched keywords are underlined correctly.

10. New questions about the main Mac menu: http://www.purebasic.fr/english/viewtop ... 19&t=51677

Thanks for dealing with a Mac amateur like me

[Fred]

I just fixed the matching brace highlight on OS X.

[kenmo]

Thanks Fred, I see you are already fixing my bug reports. That's one of the best things about PureBasic!

I just posted one more, http://www.purebasic.fr/english/viewtop ... 24&t=51679

Something about ScreenOutput() seems to leak a big amount of memory, and I think this might fix problem #2 and #5.