Mac Build Comments

You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.
Post Reply
Pallas
Posts: 3
Joined: Mon Apr 12, 2004 2:14 am

Mac Build Comments

Post by Pallas »

It's cool that this is available now, but there are a couple things which could use a bit of revision:

Overall:
  • The Xcode project builds a static library called 'libMacOSX.a'. That's sort of silly, because it means programs will need to use the linker flag "-lMacOSX". A much more friendly way to do it would be to build a Framework, but barring that, it should build "libIrrlicht.a" so there's no confusion about the purpose of the file.
  • It's probably bad to have a nib file that needs to get distributed with the library. This will just cause confusion to non-Mac users that want to quickly build a Mac version. Distributing in the Resources directory of a framework would be OK, but it would be better not to require a nib at all.
  • Speaking of menus, the "Mac menu" doesn't reflect the Irrlicht menu, when one exists. Obviously this is fine in full-screen mode. But in windowed mode, this is weird. Using the Mac menu instead of the Irrlicht menu could cause compatibility problems, but it would be nice if the Mac Menu duplicated the Irrlicht menu.
  • There doesn't seem to be any way to intercept Cmd-Q in Irrlicht. Lots of programs will probably want to prevent people from accidentally quitting in the middle of something.
The XCode project:
  • The project file seems to have only the source files referenced, and none of the headers. That makes it very hard to make any changes in XCode.
CIrrDeviceMacOSX.mm:
  • 'static bool firstLaunch' would be better as a static class variable of CIrrDeviceMacOSX, wouldn't it? *
  • When compiling, I got a lot of warnings about `void*' being an invalid receiver. These should probably be of type `id' instead. *
  • I also got a warning about the isQuit selector *
  • When I tried running the demo, it had "Direct3D 9.0c" selected by default. It crashed, because obviously I don't have Direct3D. From what I see in CIrrDeviceMacOSX::createDriver(), it should fall through to the default case. But it doesn't look like it's doing what it claims; shouldn't VideoDriver be assigned a new driver? *
  • Also, if Direct3D isn't supported, why should it be on the list in the first place? It would be good to have an overloadable method of CIrrDeviceStub to return a vector of supported video::E_DRIVER_TYPE's (though it would of course be up to the developer to use such a value intelligently).
The notes marked with asterisks required simple, local fixes, so I went ahead and did them myself. Patched version of the files are available at CIrrMacOSXDevice.mm, CIrrDeviceMacOSX.h, and AppDelegate.h.
Post Reply