I've run into a theoretical snag with my rotation support. I assume that bitmaps store data in big-endian order when I rotate the bitmaps. This is true for OS 1-4, and is true for my NX, but there could be some units, perhaps now and perhaps in the future, that will store bits in little-endian order in V3 bitmaps created by BmpCreateTypeV3().
I have a few options: 1. Do nothing and wait to see if anybody complains about rotation producing scrambled text/images on an OS 5+ machine. This is not a dangerous option, because given how the rotation works, scrambled text/images in rotated mode is the only bad thing that would happen. It wouldn't crash or anything like that. (Note, too, that if anybody reported a problem, I could cobble together a solution on a moment's notice but at the cost of higher memory consumption. This would involve using 8- or 16-bit bitmaps instead of 1-bit for text rotation.) 2. There is a field in the V3 bitmap structure which stores the bit format, and includes endianness info. I could check that in my rotation routine. The downside is that one isn't supposed to look in internal fields of structures produced by the OS, since they can change between versions. 3. The most compatible option is to write my own BmpCreateTypeV3() function that produces bitmaps set to big-endian order. This could be done, as long as one didn't feed into it any bitmaps created by the OS (since then one would have to access internal fields of structures produced by the OS). This the most work of all the solutions, but is the most forward-compatible. I am inclined to stick to #1 for now. Alex _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
