Why exactly can't it work with Mac OS?

brcolow · Post by **brcolow** » Wed Jun 09, 2004 1:50 am

Hey,

I am sure almost every programmer here is concerened about having there applications/games available on as many operating systems as possible. Why is it that Irrlicht can't be compatible with Mac OS 9/X. Is it a .DLL issue? Include files? What is it?

I am interested in mabye working with some people in making it available on Mac OS 9/X, to increase interpolarity!

Thanks for any information you can provide!
-Brcolow

Robomaniac · Post by **Robomaniac** » Wed Jun 09, 2004 2:20 am

IIRC, Mac uses Big Endian, which causes conflicts (Irrlicht is Little Endian). But i don't know. Other than that, its just a matter of adding the mac framework code. Theres nothing really holding you back from adding it if you sort out the Endian thing, but it'll pretty much involve rewriting a lotof the engine.

brcolow · Post by **brcolow** » Wed Jun 09, 2004 2:26 am

Alright, thanks for your reply. I will do a google search on Big Endian and see exactly what it is, then get back to you on my decision to mabye start a porting project.

brcolow · Post by **brcolow** » Wed Jun 09, 2004 2:38 am

Alright, after just a little bit of reading I sort of understand:

Big Endian: A data architecture that stores the most significant value in a sequence is stored first.

Little Endian is obviously the opposite.

Now, how exactly does this affect C++ coding? Is it when Niko writes ANY string or ANY interger, it has to be defined differently? That would mean that any Macintosh C++ programmer has to write strings and intergers differently? I doubt that is the case. Or, is it when Niko (if he does this I am not sure) directly defines something in a hexidecimal manner? Could someone point out some specific lines of code anywhere in the Irrlicht engine that are SPECFICALLY Little Endian so I can see why?

Thanks!

brcolow · Post by **brcolow** » Wed Jun 09, 2004 5:26 am

Just taking a stab at it here...

Is something like this little endian?

ITexture.h - Line 31

Code: Select all


	ETCF_ALWAYS_16_BIT = 0x00000001,

It probably isn't, but it looks like a data sequence.[/code]

sami · Post by **sami** » Wed Jun 09, 2004 9:22 am

I think little and big endian comes into consideration when you load stuff into the app like textures and meshes.

so what you first have to look at are the image and texture loaders.
then maybe some color bitorders might also differ.

I think there was some time ago someone who programmed an SDL video driver, you might also have a look there

brcolow · Post by **brcolow** » Wed Jun 09, 2004 5:50 pm

Alright, I will take a look at the image loaders and texture loaders, can you tell me what file name(s) those are? I saw the SDL video driver, but I am looking to port the engine, not just use another device.

brcolow · Post by **brcolow** » Wed Jun 09, 2004 6:48 pm

I found:

CImageLoaderBmp.cpp
CImageLoaderJpg.cpp
CImageLoaderPcx.cpp
CImageLoaderPsd.cpp
CImageLoaderTga.cpp

Those are obviously the image loaders for different image types (bmp, jpg etc.). I looked at a few but I still don't see exactly why those are Little Endian specific. Any help?

Robomaniac · Post by **Robomaniac** » Thu Jun 10, 2004 1:06 am

Look on gamedev. There was recently an article about converting big endian to little endian and vice versa. Just take a look, i'm sure that there's something there about why its different.

brcolow · Post by **brcolow** » Thu Jun 10, 2004 2:42 am

Alrighty, I found this article:

http://www.gamedev.net/reference/articl ... le2091.asp

I will read it and try to study some more about how to port Irrlicht!

brcolow · Post by **brcolow** » Thu Jun 10, 2004 3:29 am

CImageLoaderBmp.cpp - Lines 50 to 56

Code: Select all

//! returns true if the file maybe is able to be loaded by this class
bool CImageLoaderBmp::isALoadableFileFormat(irr::io::IReadFile* file)
{
	u16 headerID;
	file->read(&headerID, sizeof(u16));
	return headerID == 0x4d42;
}

On line 55 you see:

Code: Select all

	return headerID == 0x4d42;

That number, 0x4d42 is a hexadecimal number. In decimal form, that is 19778. So it returns 19778 as the headerID. The point is, is that, hexadecimal may be Little Endian specific. If that is so, can I simply replace that with:

Code: Select all

	return headerID == 19778;

To ensure portability to Mac? Thanks!

brcolow · Post by **brcolow** » Thu Jun 10, 2004 4:58 pm

Website: www.flashstand.com/mac_irrlicht

Also, I still need feedback on last post!

brcolow · Post by **brcolow** » Fri Jun 11, 2004 8:18 am

Bump...no one is interested in a Mac port....?_?

fretnoize · Post by **fretnoize** » Fri Jun 11, 2004 9:40 am

not that I claim to know this, far from it, but from hacking my ultima 3 characters back in the day I had to deal with this. Ok so if the PC is little endian, it is storing the most significant byte last. So for example if i wanted to represent the decimal number 2500 in hexidecimal (09C4) on the PC, the number would read C409 rather than 09C4, because the MOST significant byte, meaning the larger part of the value, is stored last.

that being said I have not done much stuff at all with hexidecimal yet in C/C++ so I don't know how much it applies to coding. And to add to that, I have never programmed for the macintosh so thats about the extent that I can help you.

It seems like it would probably be a lot of work to make this run on a mac, I think it might be a good idea to start with porting something smaller, so you become aware of issues that arise when porting to a different platform, and then maybe apply that knowledge to a larger project, such as this.

good luck with what ever you do, wish I could have been more help

warui · Post by **warui** » Fri Jun 11, 2004 1:04 pm

fretnoize wrote:the MOST significant byte, meaning the larger part of the value

Wrong, the most significant byte is just the left most byte. It could be filled with zeros and it's still MSB

@brcolow:
Youcan read more about byte ordering here:
http://developer.apple.com/documentatio ... ering.html