Why exactly can't it work with Mac OS?
-
Guest
Can I get a copy?
I was wondering if I could get a copy as I have some interest on it being ported to OS X 10.3.5
That last one was my post
I forgot to log on, but could I get a working copy of the OS X port?
--Jon
--Jon
--
[END TRANSMISSION]
[END TRANSMISSION]
-
Guest
if you want alpha mac code...
OK, due to some demand, I will distribute my alpha mac native irrlicht code. If you don't care about the release notes, just skip to the downloads at the end (and ignore the warnings about bad bugs that are in the release notes - remember - ALPHA code here)
Release notes
It is based off irrlichtnx .7.1 and currently depends on SDL (the native driver needs to be rewritten due to a design flaw and I figured people would rather have something than my slow port
As of 10/22/2004 known bugs:
mouse problem the 2D demo block that is supposed to follow the cursor is inverted. This is because SDL apparently reverses the mouse on mac (bug?) so I hacked in an inversion function so the mouse actually moves in the right direction - then found it's inverted in other places (like the Quake map demo), so I need to reanalyze this. It's low priority.
The shaders code (example 11) might be bugged (I fixed the linux code, and it may require a similar typecast). I plan to test this on one of the (few) G5s at work when no managers are around, but that hasn't happened yet. They frown on running foreign software, but I don't care
Quake maps are sorta broken. My analysis so far: it looks like the OctTree (the loader ignores the BSP info) is flipped, as all objects are in the correct order, but stuff that is far away and should be hidden is visible. This is top priority. I haven't tested it with any other type of map, so it may be a general problem.
Loaded models have black seams (only some types maybe?). I'm not sure what is causing this, but it could very well be a missed endian swap somewhere, or maybe a loop I didn't parse far enough. This is medium priority.
Sydney disappears after 1 frame on the HelloWorld demo. This is also a problem in Linux and has been for some time, so it is a low priority bug for me (if you use an animator, she'll draw fine - see the movement example).
Quake maps load dark - I believe this is just a matter of adding the SDL gamma correction, but it could be a flaw in the light map loader (doubt it - I've gone over that code line-by-line in a debugger trying to find what I now think is an oct-tree problem). This is low priority (because I know at the very least it is correctable by boosting gamma)
While this is not a bug, if you are looking at my code, you should at least be aware of it - I put a little hack in the bitmap loader to identify whether the bitmap was built in or loaded. This is because the built in font is an array of s32 (signed ints) but actually is a bunch of data of varying sizes. That means I basically hand unpack it by knowing the BM structure. The loader will probably die a horrible death if the font is switched to true color, as I never finished the 16/32 bit loader portiion of the code because it isnt' needed.
Another non-bug is you need to use
int main(int argc, char* argv[])
this is an SDL requirement, not mine. I've changed all the samples to reflect this.
I've also commented fps in a couple of places because it used a string lib OS X.2 didn't have, so consider that your warning.
Loading files is currently done the UNIX way - you need to know the path to the data files. I haven't added in finder foo yet for getting the files, but it's on my list of things to do. If you know your mac coding well enough, you can work around it anyway (by using mac stuff to pass it the correct path in the first place).
Also from a dev perspective, the SDL files are in an SDL directory in the source - copy them up a level if you want to keep the Irrlicht-normal all files in one place structure.
Some loaders haven't been tested well - like Milkshape (MS3D) - though I had a tiny Max Payne outline thing running around, so I think it might work. .X should work (it's a text file) and .3ds works (but has the line artifacts mentioned earlier).
My files were compiled with MacOS X 10.2 using a Project Builder Project. That means I didn't have wchar, nor did I have some of the string functions used in the examples, so I commented these out of the examples and partially implemented wchar in code. I believe this should auto-detect MacOS X.3 when you compile, so if you've got it, you should just compile it and it should use the correct setting. All of the missing functions are in X.3, so feel free to remove the comments. It'd also be nice to have a 10.3 (or even Tiger/10.4) library release, but I currently don't have the means to create it.
If you decide to recompile using XCode, set compiler options to-D SDL -DBIG_ENDIAN
You may also need -no-cpp-precomp, as I was having problems building without it and put it in, though I think I resolved the problems (just never took that out).
In your linker settings, add -seg1addr badf000 (some Irrlicht engine humor there - there's a line of code that uses 0xbadf00d, but since I need a multiple of 1000 it ended up badf000, which I find funnier anyway
If you just want the development embedded Framework, download it http://66.93.17.228/Irrlicht/IrrlichtSDL.framework.tgz (tar xvfz to decompress if not using stuffit expander) and place it in ~/Library/Frameworks (this is my unnamed home static IP, but I don't have a bandwidth limit and it's 1500/768, so shouldn't take too long on high speed lines). You will also need http://www.libsdl.org - the SDL developer framework (1.2.7 currently) which should automatically place the file in your ~/Library/Frameworks folder. When you build your project, add a copy files phase and copy both of these frameworks (also include them in your build). If both I and you did everything correctly, you should be able to build an Irrlicht program with it.
The source tarball is http://66.93.17.228/Irrlicht/irrlichtnx-devel.tgz. The code identifies current mac OS by compiler version (10.2 uses gcc 3.1, while 10.3 uses 3.3 by default), so if you're compiling stuff using 3.1 on X.3 you may need to do some code hacking (personally, I feel this will be rare, so I'm not too worried).
I've also included the shader demo - http://66.93.17.228/Irrlicht/ShadersSDL.tgz on the off chance someone with a very new machine wants to try it (I may add code to use OpenGL EXTs as a fallback for some older cards, but not a top priority, either).
If you tinker with my project (fixing all the links to my user since I was too lazy to set them up generically this time) you should be able to build all the examples.
oh, and yes, I am Clewin on IRC (named after a long dead RPG character I was fond of who was a bit crazy).
Release notes
It is based off irrlichtnx .7.1 and currently depends on SDL (the native driver needs to be rewritten due to a design flaw and I figured people would rather have something than my slow port
As of 10/22/2004 known bugs:
mouse problem the 2D demo block that is supposed to follow the cursor is inverted. This is because SDL apparently reverses the mouse on mac (bug?) so I hacked in an inversion function so the mouse actually moves in the right direction - then found it's inverted in other places (like the Quake map demo), so I need to reanalyze this. It's low priority.
The shaders code (example 11) might be bugged (I fixed the linux code, and it may require a similar typecast). I plan to test this on one of the (few) G5s at work when no managers are around, but that hasn't happened yet. They frown on running foreign software, but I don't care
Quake maps are sorta broken. My analysis so far: it looks like the OctTree (the loader ignores the BSP info) is flipped, as all objects are in the correct order, but stuff that is far away and should be hidden is visible. This is top priority. I haven't tested it with any other type of map, so it may be a general problem.
Loaded models have black seams (only some types maybe?). I'm not sure what is causing this, but it could very well be a missed endian swap somewhere, or maybe a loop I didn't parse far enough. This is medium priority.
Sydney disappears after 1 frame on the HelloWorld demo. This is also a problem in Linux and has been for some time, so it is a low priority bug for me (if you use an animator, she'll draw fine - see the movement example).
Quake maps load dark - I believe this is just a matter of adding the SDL gamma correction, but it could be a flaw in the light map loader (doubt it - I've gone over that code line-by-line in a debugger trying to find what I now think is an oct-tree problem). This is low priority (because I know at the very least it is correctable by boosting gamma)
While this is not a bug, if you are looking at my code, you should at least be aware of it - I put a little hack in the bitmap loader to identify whether the bitmap was built in or loaded. This is because the built in font is an array of s32 (signed ints) but actually is a bunch of data of varying sizes. That means I basically hand unpack it by knowing the BM structure. The loader will probably die a horrible death if the font is switched to true color, as I never finished the 16/32 bit loader portiion of the code because it isnt' needed.
Another non-bug is you need to use
int main(int argc, char* argv[])
this is an SDL requirement, not mine. I've changed all the samples to reflect this.
I've also commented fps in a couple of places because it used a string lib OS X.2 didn't have, so consider that your warning.
Loading files is currently done the UNIX way - you need to know the path to the data files. I haven't added in finder foo yet for getting the files, but it's on my list of things to do. If you know your mac coding well enough, you can work around it anyway (by using mac stuff to pass it the correct path in the first place).
Also from a dev perspective, the SDL files are in an SDL directory in the source - copy them up a level if you want to keep the Irrlicht-normal all files in one place structure.
Some loaders haven't been tested well - like Milkshape (MS3D) - though I had a tiny Max Payne outline thing running around, so I think it might work. .X should work (it's a text file) and .3ds works (but has the line artifacts mentioned earlier).
My files were compiled with MacOS X 10.2 using a Project Builder Project. That means I didn't have wchar, nor did I have some of the string functions used in the examples, so I commented these out of the examples and partially implemented wchar in code. I believe this should auto-detect MacOS X.3 when you compile, so if you've got it, you should just compile it and it should use the correct setting. All of the missing functions are in X.3, so feel free to remove the comments. It'd also be nice to have a 10.3 (or even Tiger/10.4) library release, but I currently don't have the means to create it.
If you decide to recompile using XCode, set compiler options to-D SDL -DBIG_ENDIAN
You may also need -no-cpp-precomp, as I was having problems building without it and put it in, though I think I resolved the problems (just never took that out).
In your linker settings, add -seg1addr badf000 (some Irrlicht engine humor there - there's a line of code that uses 0xbadf00d, but since I need a multiple of 1000 it ended up badf000, which I find funnier anyway
If you just want the development embedded Framework, download it http://66.93.17.228/Irrlicht/IrrlichtSDL.framework.tgz (tar xvfz to decompress if not using stuffit expander) and place it in ~/Library/Frameworks (this is my unnamed home static IP, but I don't have a bandwidth limit and it's 1500/768, so shouldn't take too long on high speed lines). You will also need http://www.libsdl.org - the SDL developer framework (1.2.7 currently) which should automatically place the file in your ~/Library/Frameworks folder. When you build your project, add a copy files phase and copy both of these frameworks (also include them in your build). If both I and you did everything correctly, you should be able to build an Irrlicht program with it.
The source tarball is http://66.93.17.228/Irrlicht/irrlichtnx-devel.tgz. The code identifies current mac OS by compiler version (10.2 uses gcc 3.1, while 10.3 uses 3.3 by default), so if you're compiling stuff using 3.1 on X.3 you may need to do some code hacking (personally, I feel this will be rare, so I'm not too worried).
I've also included the shader demo - http://66.93.17.228/Irrlicht/ShadersSDL.tgz on the off chance someone with a very new machine wants to try it (I may add code to use OpenGL EXTs as a fallback for some older cards, but not a top priority, either).
If you tinker with my project (fixing all the links to my user since I was too lazy to set them up generically this time) you should be able to build all the examples.
oh, and yes, I am Clewin on IRC (named after a long dead RPG character I was fond of who was a bit crazy).
-
Clewin
special effects also broken
I forgot on my list of known problems several things. Special Effects has lots of problems. The floating wisps are not getting blended with the background (multitexture issue?) and the fire is blue blobs, not red and not semi-transparent.
The dwarf model in the interface demo appears to be sorted backwards, too... maybe this is the problem with all models on mac.
The interface browser allows you to open a file, but you can't move out of the current directory. This flaw may also exist on Linux and is a fairly low priority.
I can't switch the antialiasing in the UI. This should be an easy thing to debug (finding the exact line where the problem occurs is very easy - I just need to determine why it's not working).
see the html files in http://66.93.17.228/Irrlicht for screenshots of some of the problems.
The dwarf model in the interface demo appears to be sorted backwards, too... maybe this is the problem with all models on mac.
The interface browser allows you to open a file, but you can't move out of the current directory. This flaw may also exist on Linux and is a fairly low priority.
I can't switch the antialiasing in the UI. This should be an easy thing to debug (finding the exact line where the problem occurs is very easy - I just need to determine why it's not working).
see the html files in http://66.93.17.228/Irrlicht for screenshots of some of the problems.
-
SwiftCoder
- Posts: 32
- Joined: Thu Jan 15, 2004 7:33 pm
- Location: Carribean
Been away for a long time, working on my own engine.
Just a few pointers for the mac port (since I am primarilly a mac coder):
Don't bother with a completely mac port, just work all the bugs out of the SDL port, and fix all the endian issues.
Then there are a few lower priorities, like supporting copy-paste in text-boxes.
I had a completed port, all graphics working, etc... But then niko released 2 more versions, and I haven't had time to merge the changes.
Just a thought, but I have a feeling shader support may be a little more work than the rest, OGRE seems to have terrible trouble.
Hope to be in contact more regularly,
SwiftCoder
Just a few pointers for the mac port (since I am primarilly a mac coder):
Don't bother with a completely mac port, just work all the bugs out of the SDL port, and fix all the endian issues.
Then there are a few lower priorities, like supporting copy-paste in text-boxes.
I had a completed port, all graphics working, etc... But then niko released 2 more versions, and I haven't had time to merge the changes.
Just a thought, but I have a feeling shader support may be a little more work than the rest, OGRE seems to have terrible trouble.
Hope to be in contact more regularly,
SwiftCoder
most of the bugs were resolved, but now a bit behind core
I had it all running with 7.1 with all bugs fixed. SDL version worked 100%, mac native version had some fullscreen bugs to work out, but nothing serious (for a while it even worked). I had planned to rewrite the mac driver at some point to fix some bad coding on my part, but have been involved with nx++ (irrlichtnx fork). Once I rewrite the fullscreen driver for that port (I'm moving everything to AGL because of request for clean context switches), I may revisit my irrlicht driver (in bad need of a rewrite of a couple of sections).
I switched from SDL to writing a native driver for one reason - SDL was giving me a hit of about 4-8fps and that's on a machine that maybe gets 24fps at best (though that should be improving soon).
all the endian issue fixes are in irrlichtnx cvs: http://irrlichtnx.mmdevel.de, including some for other drivers.
I can see why OGRE is having problems with Shader support - Apple seems to be waiting for Tiger to support shading languages, if they ever will (they do support vertex and pixel shaders, just not high level shading languages like GLSL). The reason they may never support them is that with OpenGL 2.0 compliant cards, the shading language is entirely in the card, so you just need the function pointer. There may be workarounds using Core Image if GLSL isn't in Tiger, but since I'm not an ADC preferred member, I get to wait for the release to find out.
I switched from SDL to writing a native driver for one reason - SDL was giving me a hit of about 4-8fps and that's on a machine that maybe gets 24fps at best (though that should be improving soon).
all the endian issue fixes are in irrlichtnx cvs: http://irrlichtnx.mmdevel.de, including some for other drivers.
I can see why OGRE is having problems with Shader support - Apple seems to be waiting for Tiger to support shading languages, if they ever will (they do support vertex and pixel shaders, just not high level shading languages like GLSL). The reason they may never support them is that with OpenGL 2.0 compliant cards, the shading language is entirely in the card, so you just need the function pointer. There may be workarounds using Core Image if GLSL isn't in Tiger, but since I'm not an ADC preferred member, I get to wait for the release to find out.