About Mac
most stuff working on mac port
Clewin (that's my IRC handle) and elskizo are working on it. I've ported all of the drivers and they seem to work using SDL for GUI management. I'm now working on a native mac driver, which is semi-functional but riddled with bugs, mainly because my mac native coding is rusty. I think elskizo has even submitted all of our SDL code to nx++ (an irrlicht offshoot). My code is based on irrlichtnx 7.1, which is basically 7.1 with bug fixes and some useful patches... like adding in linux (and mac) shader extensions.
I'm shooting for ~Christmas 2004 for getting the native mac driver working, but that depends on both work and home responsibilities not chewing up too much of my time.
I'm shooting for ~Christmas 2004 for getting the native mac driver working, but that depends on both work and home responsibilities not chewing up too much of my time.
Re: most stuff working on mac port
Hey... Nice job.schnarr wrote:Clewin (that's my IRC handle) and elskizo are working on it. I've ported all of the drivers and they seem to work using SDL for GUI management. I'm now working on a native mac driver, which is semi-functional but riddled with bugs, mainly because my mac native coding is rusty.
I would have like to know how to make that kind of work...
I'll be very thanksfull if you tell me when you've done it.
And if you can give me some advices about how to manage your kind of stuffin'...
C u...
Where is my minde...?
download latest archived mac source
if you want, you can grab my latest source and binary draft and take a look:
http://66.93.17.228/Irrlicht/irrlichtnx ... 02.tar.bz2 (note: it's huge, as it includes lots of built stuff).
Source only is here: http://66.93.17.228/Irrlicht/source-20050102.tar.bz2
you can also try just grabbing the latest build of irrlichtnx, as I believe that has all the mac files now, with the exception of the ugly kludges for X.2 and my with some extra test drivers.
older archives
http://66.93.17.228/Irrlicht/irrlicht-m ... 04.tar.bz2
http://66.93.17.228/Irrlicht/irrlichtnx ... 05.tar.bz2
to create your own embeddable framework (you can also build it as .dylib or .a or even a regular framework, if you want), create a new XCode project and add all the files in the irrlicht/source directory except these:
from the jpeg directory, cjpeg.c, ckconfig.c, djpeg.c, rdjpeg.c wrjpgcom.c
I usually ignore the zlib directory's files and just include the system libz.1.1.3.dylib in external Frameworks and Libraries. You will also need (/System/Library/) Carbon.framework (or Cocoa.framework), OpenGL.framework, and if using SDL, SDL.framework
from the main release, remove CIrrDeviceWin32.cpp and .h and CIrrDeviceLinux.cpp and .h. The mostly functional SDL driver requires you to add CIrrDeviceSDL.cpp and the SDL embedded framework (Simple DirectMedia Layer) to your project. Since the default is mac native, set the SDL compiler flag (go to GCC Compiler settings for the target and choose -D SDL ). If building a native driver, you don't need this, but the native driver is incomplete 'cause some stuff strangely doesn't work, even though it should (by comparing code to the linux and Windows drivers). Anyhow, to create an embeddable framework, choose Installation settings, then Path, and change it to @executable_path/../Frameworks
Next,
Finally, make sure the headers (include files) are copied into the framework (you really need a subset of them, but we'll deal with that when an official release is made)
oh, and before I forget, I'm using the linker setting -seg1addr 0x2badf000 - the selected segment is an in-joke, but it practically will speed up your runtime, so is worth adding.
Build it. when finished, copy the framework to ~/Library/Frameworks (your home directory's Frameworks directory).
Now you should be able to create a project using the SDL stationary and get all the required SDL files, or create a new application if not using the SDL files. Don't forget to add the Irrlicht.framework you created in ~/Library/Frameworks to your project.
http://66.93.17.228/Irrlicht/irrlichtnx ... 02.tar.bz2 (note: it's huge, as it includes lots of built stuff).
Source only is here: http://66.93.17.228/Irrlicht/source-20050102.tar.bz2
you can also try just grabbing the latest build of irrlichtnx, as I believe that has all the mac files now, with the exception of the ugly kludges for X.2 and my with some extra test drivers.
older archives
http://66.93.17.228/Irrlicht/irrlicht-m ... 04.tar.bz2
http://66.93.17.228/Irrlicht/irrlichtnx ... 05.tar.bz2
to create your own embeddable framework (you can also build it as .dylib or .a or even a regular framework, if you want), create a new XCode project and add all the files in the irrlicht/source directory except these:
from the jpeg directory, cjpeg.c, ckconfig.c, djpeg.c, rdjpeg.c wrjpgcom.c
I usually ignore the zlib directory's files and just include the system libz.1.1.3.dylib in external Frameworks and Libraries. You will also need (/System/Library/) Carbon.framework (or Cocoa.framework), OpenGL.framework, and if using SDL, SDL.framework
from the main release, remove CIrrDeviceWin32.cpp and .h and CIrrDeviceLinux.cpp and .h. The mostly functional SDL driver requires you to add CIrrDeviceSDL.cpp and the SDL embedded framework (Simple DirectMedia Layer) to your project. Since the default is mac native, set the SDL compiler flag (go to GCC Compiler settings for the target and choose -D SDL ). If building a native driver, you don't need this, but the native driver is incomplete 'cause some stuff strangely doesn't work, even though it should (by comparing code to the linux and Windows drivers). Anyhow, to create an embeddable framework, choose Installation settings, then Path, and change it to @executable_path/../Frameworks
Next,
Finally, make sure the headers (include files) are copied into the framework (you really need a subset of them, but we'll deal with that when an official release is made)
oh, and before I forget, I'm using the linker setting -seg1addr 0x2badf000 - the selected segment is an in-joke, but it practically will speed up your runtime, so is worth adding.
Build it. when finished, copy the framework to ~/Library/Frameworks (your home directory's Frameworks directory).
Now you should be able to create a project using the SDL stationary and get all the required SDL files, or create a new application if not using the SDL files. Don't forget to add the Irrlicht.framework you created in ~/Library/Frameworks to your project.
closer, but still having issues
I have a few older (large) screenshots of special effects showing shadows:
http://66.93.17.228/Irrlicht/special1.png
http://66.93.17.228/Irrlicht/special2.png
keep in mind the framerates are low because
a) I'm in window mode, which is composited on mac taking several cycles
b) my graphics card is an old Rage 128 - it doesn't even support OpenGL 1.2
c) My mac is an upgraded B&W G3 (600MHz G4 in it now). Not exactly a performance monster.
d) I'm running OS X.2 still. I'm upgrading to Tiger as soon as it's available, but upgrading to Panther at this point seems silly (since Tiger is ~ 3 months away).
OS X.2 compatibility will be abandoned with the release of Tiger - there are too many issues to keep it backwards compatible that far back, the primary one being irrlicht moving more and more towards wide character support, which is very bad in Jaguar and MUCH improved in Panther and later. I had to create several files just to use that OS, and that doesn't include the swprintf stuff that's starting to appear in the examples.
progress info:
the mac native (non-SDL) driver now works except for some mouse issues. I need to tear out the current mouse handling and rewrite it because it's too slow, and most of this was caused by shoddy Apple documentation for Core Graphics. Essentially, the main problem was that CGPoint is a float, and sometimes is in screen percentage (.5,.5 for middle of screen) and sometimes in pixel points from upper left corner (why you'd use a float for that is beyond me...). Making a call to a function that uses CGPoint requires the second type, however, and I have values stored as the first. Needless to say, I'm doing a lot of converting and it has a performance cost and I need to eliminate this. I now have a MUCH better understanding of the mouse, so should be able to write better code the second time around. Ultimately, I'd like to rework all the drivers to support multiple displays and rendering contexts by reworking SMapper (the thing that keeps track of windows). I'll try to release something before I do that, though
btw, the reason for the month-later-than-anticipated delay was because fullscreen support was much harder than I initially thought. I started working with the AGL API, but after discovering it was unsupported, moved to the supported CGL API. This transition proved painful as it meant separating my fullscreen and windowed code (since CGL doesn't support windowed mode, I had to leave all that AGL) and writing new event loops specifically for the fullscreen code. I did find some bugs in my window code that I would've never caught, however, so in some ways it was worth it.
http://66.93.17.228/Irrlicht/special1.png
http://66.93.17.228/Irrlicht/special2.png
keep in mind the framerates are low because
a) I'm in window mode, which is composited on mac taking several cycles
b) my graphics card is an old Rage 128 - it doesn't even support OpenGL 1.2
c) My mac is an upgraded B&W G3 (600MHz G4 in it now). Not exactly a performance monster.
d) I'm running OS X.2 still. I'm upgrading to Tiger as soon as it's available, but upgrading to Panther at this point seems silly (since Tiger is ~ 3 months away).
OS X.2 compatibility will be abandoned with the release of Tiger - there are too many issues to keep it backwards compatible that far back, the primary one being irrlicht moving more and more towards wide character support, which is very bad in Jaguar and MUCH improved in Panther and later. I had to create several files just to use that OS, and that doesn't include the swprintf stuff that's starting to appear in the examples.
progress info:
the mac native (non-SDL) driver now works except for some mouse issues. I need to tear out the current mouse handling and rewrite it because it's too slow, and most of this was caused by shoddy Apple documentation for Core Graphics. Essentially, the main problem was that CGPoint is a float, and sometimes is in screen percentage (.5,.5 for middle of screen) and sometimes in pixel points from upper left corner (why you'd use a float for that is beyond me...). Making a call to a function that uses CGPoint requires the second type, however, and I have values stored as the first. Needless to say, I'm doing a lot of converting and it has a performance cost and I need to eliminate this. I now have a MUCH better understanding of the mouse, so should be able to write better code the second time around. Ultimately, I'd like to rework all the drivers to support multiple displays and rendering contexts by reworking SMapper (the thing that keeps track of windows). I'll try to release something before I do that, though
btw, the reason for the month-later-than-anticipated delay was because fullscreen support was much harder than I initially thought. I started working with the AGL API, but after discovering it was unsupported, moved to the supported CGL API. This transition proved painful as it meant separating my fullscreen and windowed code (since CGL doesn't support windowed mode, I had to leave all that AGL) and writing new event loops specifically for the fullscreen code. I did find some bugs in my window code that I would've never caught, however, so in some ways it was worth it.
Hem...Anonymous wrote:I thought it would take more time...
Graet!
I'm downloading and I'll try it out.
Your post about the way to create our own embeddable framework is almost blur for me. I haven't anderstande everything.
Good job schnarr. Really.
I'm that "guest". Forgot my password . As I'm Ikka . I use to forget things... once it will be my brain or some like that...
Beg you all pardon.
Where is my minde...?
Hello,
I was interrested in this code for Mac to try it out.
But only a "Not Found" page is dispayed.
Is Schnarr working for Apple now?
No... seriously, none of all these links about this subject works.
If someone has been able to download the sources and test; is it about modifying the code of the SDK or the code of some plugs?
Thanks.
I was interrested in this code for Mac to try it out.
But only a "Not Found" page is dispayed.
Is Schnarr working for Apple now?
No... seriously, none of all these links about this subject works.
If someone has been able to download the sources and test; is it about modifying the code of the SDK or the code of some plugs?
Thanks.