As you guessed the glx stuff isn't needed.

Or they're not doing byte-swapping, and therefore not recognizing their own format on big-endian machines...

Quote:Originally posted by Feanor
The other thing I cannot be sure I will not have to deal with is endianness issues, since this software is targeted at x86 directly. If it uses only library calls to work with resource data, probably I won't have a problem.

Funny how I expected this, but when I encountered it, I totally forgot about it. Can I blame it on being up at 2a.m.?

I opened testing.srt and sure enough, the version number is "0c 00 00 00", which is twelve in a reverse byte order 32-bit integer. I'll have a look at making a test and byte swapping code. I can probably steal something from some old code I have, in fact.

SDL has a bunch of macros/routines for byte-swapping stuff. Probably easiest to use them since you've already got SDL

Quote:Originally posted by OneSadCookie
SDL has a bunch of macros/routines for byte-swapping stuff. Probably easiest to use them since you've already got SDL

Thanks for suggestion. It is now necessary to figure out how many places in the code access the .srt file. There is evidence that file access is not fully localized.

Is this going to be a proper port or just a hack to get something going. The answer to this question will impact on how much care I take in getting it to work.

For now just a hack. I cannot afford to take the time to maintain the code. I was just assessing the difficulty.