MacOS X and latest SVN

SukkoPera · Post by **SukkoPera** » Tue Oct 30, 2007 9:48 am

Hi,
I just tried Irrlicht for a project we are developing at the company I work in. We need a cross-platform 3D engine, and Irrlicht seems to fit the job pretty well. The only problem is that we need to compile our application on MacOS X as well, so I set out to get Irrlight compiled with Xcode.

Thanks to the several hints on the forum (in particular thanks to this post), getting 1.3 to compile and work has been actually quite easy. Although, I encountered the issue mentioned by syndicatedragon in this thread, namely some missing textures in Quake3Map under certain angulations, and the white characters in Collision (see screenshots in the mentioned thread, the situation is exactly the same).

Hence, I tried to get the latest SVN version and to compile it. Here is a list of the fixes I had to make:

Remove all the missing (red) files from the project.
Add all of the missing files (the not-greyed out ones when you do Files -> Add existing) to the project.
Comment out, through the use of #if 0... #endif, as described here, part of the pnggccrd.c file (which has to be added to the project, by the way).
Add #define GL_EXT_texture_env_combine 1 at the very beginning of COpenGLDriver.cpp, before any #include's. This is probably a workaround and should be placed somewhere else. Anyway this was my first time hacking OpenGL stuff, so I just solved it this way.
Change in include/ICursorControl.h:
virtual bool isVisible() const = 0;
to
virtual bool isVisible() = 0;
Again, this should probably be solved somewhere else, but I had no idea where.
Change in include/IrrlichtDevice.h:
virtual bool isWindowActive() const = 0;
to
virtual bool isWindowActive() = 0;
Finally, to get the Demo to compile, I had to remove #define USE_IRRKLANG. This isn't necessary if you only want to build the lib, anyway I think this should be disabled by default, as not all Irrlicht users also use Irrklang. Please note that the Demo will not work anyway, and it will crash with a "Bus error".
Also note that the examples will not work launched from Finder, but need to be launched from a terminal from the bin/MacOSX directory.

That's all for now, I hope this helps any MacOS X users out there. I would like the above mentioned bugs to be fixed, but I guess there are other priorities and, unfortunately, I don't know any graphics-related stuff, so I cannot help. Anyway we'll try to make our project work with the current versions, as it won't require any complex graphics.

Thanks for the work you all have put into Irrlicht so far

.

rogerborg · Post by **rogerborg** » Tue Oct 30, 2007 11:54 am

That's super. Can I suggest that you create and upload a Subversion patch to the tracker (see my .sig), as (as far as I know) none of the devs with SVN access have a Mac, so it'll be far easier for them if you can submit complete patches.

SukkoPera · Post by **SukkoPera** » Tue Oct 30, 2007 1:50 pm

It would be easy to provide a patch, but my fixes are mostly workarounds, so I don't want them to go mainstream. I chose to publish them here so that one of the developers can commit proper fixes. I guess it would take about 5 minutes

.

I came to this solution also because some changes (i.e.: the removal of those const's) would probably break other engines. It should just be a matter of updating the MacOS X engine reflecting the changes in the interface, but unfortunately I don't know how to do that

.

ssexton · Post by **ssexton** » Tue Oct 30, 2007 10:07 pm

Hey Sukko,

Just wanted to let you (and e1 else) know that after seeing your post yesterday, I decided to have a go at getting the 1.4 beta code going on MacOSX. I didn't try the latest SVN (I wasn't that brave!) but I do have it compiling now and at least the Demo.app runs (and runs by double-clicking in the Finder, as it did in previous versions). I've never been so happy to see Sydney and that goofy Faerie, let me tell ya!

I'll work on packaging up the changes and posting them (as changed files, I think... I don't feel like answering a slew of "what do I do with this .patch file" emails...) in a few minutes. Unlike previous releases, I went back to pristine sources for 1.4, so I have an updated .xcodeproj to share this time. I can't promise I'll maintain this for very long, but you're welcome to it while it lasts.

Also, this is only tested on PPC. I don't have an x86 Mac to test with, but the build does create a Universal.

ssexton · Post by **ssexton** » Tue Oct 30, 2007 10:46 pm

Here's the link:

http://hurricanegames.s3.amazonaws.com/ ... 1-mac.sitx

The archive contains a skeleton directory layout (overlay) of just the changed & new files, including a precompiled libIrrlicht.a and Demo.app.

I took a second look at your list, and I did essentially the same set of fixes, with a few changes.

update xcode project to remove missing files (red) and add new ones
fix the pnggccrd.c as I posted previously
rather than #define GL_EXT_texture_env_combine (which is probably a valid fix) I followed these instructions and added a #define for all the _EXT to the _ARB equivalent. This one needs to be sorted out by the Irrlicht devs. There are multiple ways to fix it, and I don't pretend to understand how GL headers are being setup in Irrlicht, but hopefully the info in the provided link is enough to explain what the issue is.
for the pure virtuals in ICursorControl.h and IrrlichtDevice.h: rather than remove the const on the base class, I added it to the MacOSX class. Your way would have messed up the Linux and Win32 ports. This *might* also be what is causing your Bus Error.
#undef irrKlang from Demo, because I didn't want to download it and possibly fix it
in the demo's main menu, add an #ifdef for MACOSX to use OPENGL as the default renderer not Burning's.
The demo works fine double-clicked from Finder. No Bus error. Besides the previous #ifdef (which gives you a grey window if you don't do it) you also have to be sure to select the OpenGL renderer from the menu.
I didn't try the examples, so no idea if they are compiled as app bundles or if they were just left as command-line tools.

And again, this is with PPC.

SukkoPera · Post by **SukkoPera** » Wed Oct 31, 2007 9:56 am

Thanks a lot for your work, I'm glad we're helping each other

.

I've tried your archive: Demo.app starts when double-clicked from Finder, but then the app visualization is mostly garbage and when I click on "Start demo", the screen goes light blue for a bit, then it goes back to Finder saying that the application has closed unexpectedly.

I will try your #ifdef MACOSX trick in my SVN compile and will let you know what happens. Oh, by the way, my Mac is x86!

EDIT: I fixed che const's by adding them to the MacOS device (couldn't imagine it was this easy! I didn't know this C++-specific syntax) and added the #ifdef in the demo, although the demo still crashes for me. Anyway I will submit a diff to the tracker. Thanks for your help.

EDIT2: Patch submitted: http://sourceforge.net/tracker/index.ph ... tid=540678

ssexton · Post by **ssexton** » Wed Oct 31, 2007 2:46 pm

SukkoPera wrote:I've tried your archive: Demo.app starts when double-clicked from Finder, but then the app visualization is mostly garbage and when I click on "Start demo", the screen goes light blue for a bit, then it goes back to Finder saying that the application has closed unexpectedly.

The archive is intended for Demo.app to be copied into your existing Irrlicht directory.

If you *didn't* do that (instead tried to run it where it was from the archive), I strongly suspect that the problem is that Demo.app tries to locate some external resources relative to its path (resources that won't be found unless you put it in the Irrlicht directory) and that is what causes the garbage visuals and crash.

If you *did* do that, it could be something with the x86. I have no way of testing that. It could be there is an endian bug in the code - for example, somewhere an #ifdef MAC that should be #ifdef BIG_ENDIAN.

EDIT: I fixed che const's by adding them to the MacOS device (couldn't imagine it was this easy! I didn't know this C++-specific syntax)

.

In C++, the "const" qualifier is part of the method signature. That's why the compiler complained: because the non-const method in the subclass doesn't override the =0 (pure virtual) method in the base class, like you think it would. If you get bored, do a search on "const correct C++" to get some idea of why you'd want to put a const on your method in the first place.

SukkoPera · Post by **SukkoPera** » Wed Oct 31, 2007 3:13 pm

Erm, actually I'd forgotten to put your files in my Irrlicht directory, but doing so actually makes things worse, as the Demo won't even start but instead give an unexpected error right adter double clicking on it

.

I'll try to look into the code, but I guess I won't find much

.

Thanks for the explanation about const, I've just learnt something new

.

hybrid · Post by **hybrid** » Fri Nov 02, 2007 12:32 am

Ok, the consts are added. I could not really understand what the link suggested (does testing for EXT_texture_env_combine help or does Macs need all _EXT replaced by _ARB?). BTW: What happens without the define? I hope that Niko will fix the XCode project etc.

ssexton · Post by **ssexton** » Mon Nov 05, 2007 10:33 pm

hybrid wrote:Ok, the consts are added. I could not really understand what the link suggested (does testing for EXT_texture_env_combine help or does Macs need all _EXT replaced by _ARB?). BTW: What happens without the define? I hope that Niko will fix the XCode project etc.

Mac doesn't define any _EXT constants. They all come up as undefined symbols. Mac does define the equivalent _ARB constants.

I 'fixed' this by doing #define xxx_EXT xxx_ARB for all the _EXT constants that were used in (I forget the filename). I don't know if this is a good fix or if it is better to pull in the local glext.h (or whatever) header.

andyvn22 · Post by **andyvn22** » Tue Nov 20, 2007 2:30 am

Thanks so much! I've been trying to compile irrlicht with XCode for over a year now; this topic FINALLY got it to compile with no errors!

I still can't get any of the apps to compile (I keep getting undefined symbols errors), but I feel like I'm getting closer to being able to do something. When I first tried to compile the demo apps, I got a message suggesting I run ranlib, so I did; now I just get undefined symbols with all the demo apps. Anybody know what I need to do?

hybrid · Post by **hybrid** » Tue Nov 20, 2007 6:59 am

Maybe you have to add some more cpp files to your project?