Irrlicht Engine

I like the methods like readInt in COgreMeshFileLoader.cpp

We should extend the file readers with such methods, so that endian conversion is done automatically: readIntLE for reading data that is known to be little endian, etc.

Ah, I think you're right.

Network Byte Order is actually Big Endian. Thus, these methods won't swap bytes on a big endian machine.

How about we use POSIX htonl, htons, ntohl, ntohs?

These will be optimized for the platform they're on, I imagine. We can just use our own #defines to change the API.

Perhaps we should take care of endian issues in the reading and writing functions; we can pass flags to the file readers specifying ...

Currently, Irrlicht makes liberal use of OSReadSwapInt32 , and its ilk, for BIG_ENDIAN fixes. However, these are a Mac OS X thing, and the functionality is somewhat incomplete, as there is no way to deal with floats and doubles (in fact, a recent addition to Irrlicht uses OSReadSwapFloat32 , which ...

The OpenGL backend is being cleaned up as we speak. DirectX 9 will be cleaned up as well.

This may seem simple to say, but make sure you optimize your binary with the proper compiler flags. This can tremendously improve performance; at least it did for me.

JPEG, BMP, PNG, and TGA seem more than enough at this point, and they all work now (with the patches listed in my last comment).

The PCX and PSD code is currently very old and incomplete and it certainly doesn't handle endianness.

Does anybody actually use these? Can we just drop them?

I think I've got the image loading problems pretty much narrowed down:
1) jpegs and pngs should already work, because they are loaded with jpeglib and libpng.
2) BMP and TGA have been fixed ; BMP now supports 16-bit files too.
3) PCX is incomplete
4) PSD isn't confirmed as yet

I will first get ...

Well, I imagine SVN tries to maintain the encoding as it is submitted.

The files I have dealt with are CRLF. I figure SVN stores the files as normalized LF, but has flags to convert them to their original forms, which in my case has been CRLF.

Sometimes my editor gives me troubles; even though I ...

Unfortunately, auto-props only apply to newly introduced files; it doesn't apply on checkout or to existing files.

I call it standard and nonstandard for the sake of discussion; I'm defining those two terms. In particular, the OpenGL specification uses packed pixel formats instead of nonstandard; these were added later, and they are probably around, because of Windows and Endian issues.

OpenGL has two ways to deal with texture data:
1) standard :
OpenGL deals with bytes. That is, GL_RGB and GL_UNSIGNED_BYTE specify that
unsigned char* data;
data[0] = R;
data[1] = G;
data[2] = B;

On all machines, byte locations are the same, but bit locations are not.

2) nonstandard ...

Unfortunately, there is no way to set default properties.

Consequently, I'll just have to deal with each file individually.

I'd prefer to have each platform use its own line ending and let subversion do the conversion.

Sounds great. I didn't realize SVN did that though, because it certainly doesn't for me.

Do I need to tell SVN to do so?
Edit: Ah yes, it's a property that can be set. Thank you!

Does anybody object to making the default line ending for source code the unix line ending, \n?

Please voice your support as well.