Irrlicht 1.1 errors on OS X - Fixes to get it to compile

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.
itistoday
Posts: 2
Joined: Thu Sep 28, 2006 4:12 am
Contact:

Irrlicht 1.1 errors on OS X - Fixes to get it to compile

Post by itistoday »

Hi all, I'm new to the forums and new to Irrlicht. I'm an OS X user and when I tried to compile Irrlicht 1.1 (that I downloaded from the main site) on OS X (10.4.7) I got a bunch of errors, so I set out to fix them. I fixed all of the errors that prevented compilation and so now it compiles and many of the demo programs work (more or less) although several do not.

I uploaded the source file directory with all the fixes and a text file documenting them all to my server here: http://www.kinostudios.com/OS_X_fixes_irrlicht1.1.zip

Here is a copy of that text file with the fixes:
error:
CImageLoaderPCX.cpp:66-75
XMin, XMax, YMin, etc not declared

solution:
prefix them with 'header.'

error:
CStaticMeshOBJ.cpp: No such file or directory

solution:
Got rid of old files in Xcode group "Engine", replaced with latest ones

error:
COpenGLSLMaterialRenderer.cpp:187,215:

invalid conversion from 'int*' to 'GLsizei*'

solution:
make explicit casts to GLsizei*

error:
COpenGLDriver.cpp:184
constructor poorly formed.

solution:
was missing the 'bool vsync' argument

error:
COpenGLDriver.cpp:542
pGlActiveTextureARB and pGlClientActiveTextureARB not declared in scope

solution:
replace with:
#ifndef MACOSX
if (!pGlActiveTextureARB || !pGlClientActiveTextureARB)
{
MultiTextureExtension = false;
os::Printer::log("Failed to load OpenGL's multitexture extension, proceeding without.", ELL_WARNING);
}
else
#endif
if (MaxTextureUnits < 2)
{
MultiTextureExtension = false;
os::Printer::log("Warning: OpenGL device only has one texture unit. Disabling multitexturing.", ELL_WARNING);
}

error:
COpenGLDriver.cpp:2567
no matching function call to 'irr::video::COpenGLDriver::COpenGLDriver(const irr::core::dimension2d<irr::s32>&, bool&, bool&, irr::CIrrDeviceMacOSX*&, irr::io::IFileSystem*&, bool&)'

solution:
vsync parameter missing; line 2567 change to:
device, io, vsync, antiAlias);
Misc problems:

Several of the demo programs refuse to launch, while others do. I had time to only look into one of them, but the problem could be the same for all of them.

SpecialFx crashes:

Code: Select all

Using renderer: OpenGL 1.3
ATI Radeon 9000 OpenGL Engine: ATI Technologies Inc.
OpenGL driver version is 1.2 or better.
Multittexturing active.
Loaded texture: #DefaultFont
Loaded mesh: ../../media/room.3ds
Loaded texture: ../../media/wall.jpg

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000010
main () at ../../../include/SColor.h:218
218                     inline void set(s32 a, s32 r, s32 g, s32 b) { color = (((a & 0xff)<<24) | ((r & 0xff)<<16) | ((g & 0xff)<<8) | (b & 0xff)); }
(gdb) bt
#0  main () at ../../../include/SColor.h:218
(gdb) quit

By commenting out line 86 in the main.cpp of SpecialFx I was able to get the program to run successfully. This is the line:

node->getMaterial(0).SpecularColor.set(0,0,0,0);

Perhaps someone could take a look into this and find out why this is happening? My guess is that it has something to do with the getMaterial() function, which, by the way, doesn't make any sense to me as to how it could possibly work in the first place:

Code: Select all

virtual video::SMaterial& getMaterial(s32 i)
{
	return *((video::SMaterial*)0);
}
What does that do? It seems to me like it tries to dereference a pointer to NULL...


Anyways, I hope that these fixes are useful, and if they haven't already been done in the SVN version then I'd be happy if they were incorporated into the Irrlicht 1.1 version on the main site.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Yes, 1.1 did not respect the OSX port - but this had been true for the previous releases, too. Usually the OSX port had been some weeks delayed, this time we asked the OSX people to use a stabilized SVN revision (I guess around 160 would be a good start). All problems mentioned are fixed in SVN for quite some time now.
I also encountered the specular color problem, maybe something's still wrong with BIG_ENDIAN code. However, the getMaterial usually works. You might have noticed the "virtual" in front of the method which tells C++ to use a refined version of the method depending on the type of the node.
jmiles
Posts: 19
Joined: Mon Oct 23, 2006 11:07 pm

Post by jmiles »

I just dl'd the 1.1 from main page (rather than the svn revisions i've been trying to get working) as well as your fix file and the system is now building, albeit with 177 warnings but it is a better starting point that i had previously, thank you :)
ssexton
Posts: 54
Joined: Wed Oct 25, 2006 7:46 am
Location: South Florida
Contact:

Post by ssexton »

So I'm new to Irrlicht as of yesterday, and I've learned lesson #1 which is: check the forums if you have problems! Ok, so when I say it like that it makes me sound really dumb...

For anyone else trying to build Mac version from the 1.1 download... don't. With the latest svn (272), it runs _great_ although there are a few minor issues before it will compile (missing files, a #if 0 here and there). And it has some very nice features that aren't in the 1.1.

I just wish I'd seen this thread BEFORE I spent all night working with it. Oh well. I can really appreciate the changes now. To whoever spent the time sorting out the endian issues... THANK YOU! I was having my doubts about using this library with the previous code (esp. after debugging SColor.toOpenGLColor) and it looks much cleaner now.

btw, the Mac demo code still needs the #if MACOSX in the CMenu class (from 1.0), so that it starts up the engine with the OGL renderer instead of the software renderer. Otherwise all you get is a blank window.
jmiles
Posts: 19
Joined: Mon Oct 23, 2006 11:07 pm

Post by jmiles »

Would you be willing to share the changes that needed to be made to get revision 272 building correctly? I've been unable to correctly build this revision.

thanks
ssexton
Posts: 54
Joined: Wed Oct 25, 2006 7:46 am
Location: South Florida
Contact:

Post by ssexton »

I can try. Patch file posted to http://www.hurricanegames.com/irr272.patch.zip . Note this gets it to compile, but it isn't a proper fix. I just removed the offending bits with #if 0 and added some missing files. Even with this, you may get collision detection bugs in the demo. I did, I got stuck on the floor a lot. But I have no idea if that was due to platform (OS X) or hardware (dual processor), I don't have a dual x86 to test with.

PS. Sorry I didn't reply sooner, I've been busy playing with my new toy. :)
jmiles
Posts: 19
Joined: Mon Oct 23, 2006 11:07 pm

Post by jmiles »

Excellent :D Thank you.

Looking forward to trying this out this afternoon and seeing what happens. Take a look at what you have done and compare to what I did to get 276 to build and see what I can learn from your work. Thanks :)
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Indeed the 'if 0' etc. are wrong and should be GL_EXT_framebuffer_object instead. Moreover, the capability check should go into check function of the drivers, with a new capability enum symbol. I'll see what I can do with my Solaris system.
bitplane
Admin
Posts: 3204
Joined: Mon Mar 28, 2005 3:45 am
Location: England
Contact:

Post by bitplane »

oops sorry, i merged mandrav's patch without reading it through properly.. will be more vigilant in future :oops:
Submit bugs/patches to the tracker!
Need help right now? Visit the chat room
jmiles
Posts: 19
Joined: Mon Oct 23, 2006 11:07 pm

Post by jmiles »

Thank you for the advice, Hybrid, I was having a similar problem, though I was reling on #ifndef MACOSX which allowed things to compile but textures were not being loading in samples.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

I've fixed in yesterday evening, at least it compiles under Solaris again. I'm not 100% sure if I disabled something for the usual systems, though. Maybe someone has a test case for FBOs set up and can test the latest SVN code with it. I've also updated the glext.h to OpenGL 2.1 such that no manually added OpenGL defines are needed anymore.
jmiles
Posts: 19
Joined: Mon Oct 23, 2006 11:07 pm

Post by jmiles »

Thanks, Hybrid, I'll grab a copy of that today and see what happens. If it all goes well I'll provide a copy of my XCode project file
jmiles
Posts: 19
Joined: Mon Oct 23, 2006 11:07 pm

Post by jmiles »

I received the following error in regards to line 54 in COpenGLTexture.cpp:

/COpenGLTexture.cpp:54: error: 'GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT' was not declared in this scope

so I must need some #ifdef right before this but not real sure what, I would be tempted to just fall back to my
#ifndef MACOSX
just to get past that line, but I'm sure that is a lousy solution.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

But when using Irrlicht on OSX it chooses the non-extension-pointer version for OpenGL. Thus, glext.h is not included. So your OpenGL version seems to define the GL_EXT_framebuffer_object and thus should support these symbols!
jmiles
Posts: 19
Joined: Mon Oct 23, 2006 11:07 pm

Post by jmiles »

So, basically, it should work just fine, but doesn't...well.... :?
Post Reply