search

XProger / OpenLara

Classic Tomb Raider open-source engine
http://xproger.info/projects/OpenLara/
BSD 2-Clause "Simplified" License
4.71k stars 364 forks source link

Big Endian support ? #397

Open BeWorld2018 opened 2 years ago

BeWorld2018 commented 2 years ago

Hi, i port some program to MorphOS but platform is BE, opengl 1.2 and no shaders (seem ok for 2 last point)... I try to compile OpenLara but seem not bigendian compatible.

Have you plan to fix it ? plaform concern : XBox360, PS3, Wii and AmigaOS compatible

Thanks you

XProger commented 2 years ago

Yep, it's in plan for the new version of engine ("fixed" folder), it's already compatible with BE due 3DO support, but the code isn't complete and it uses pre-converted levels format.

Kroc commented 2 years ago

Mac PPC folks will also be thankful!

XProger commented 2 years ago

@Kroc yep, I've iBook G4 for this reason 8)

BeWorld2018 commented 2 years ago

Ok, Thank you for your answer.

jnmartin84 commented 2 years ago

I had to do some work in this area to get OpenLara running on the Nintendo 64. It isn't quite in shape for a pull request but for reference the changes can be found in my OL fork under the nintendo64 branch: https://github.com/jnmartin84/OpenLara/tree/nintendo64

Of paticular interest is src/format.h, grep for stream_read16 / stream_read32 to see most of the changes. https://github.com/jnmartin84/OpenLara/blob/f9dffc2493a83795e90a80a5c4a0557bef91062f/src/format.h#L3195

Also look for any bitfields and associated unions in the struct definitions in that file, they needed to be modified.

XProger commented 2 years ago

@jnmartin84 hi, Stream class already has readBE16 and readBE32 According roadmap (#353) the main branch code is deprecated and will be archived after "fixed" branch will be completed. Of course you can continue working on your fork, but the code isn't suitable for old platforms such as N64.

jnmartin84 commented 2 years ago

Sure, understood.

My original intent was to introduce a compile-time check/define for endianness and eventually work through all of the uses of read_/read_LE/read_BE and make them behave appropriately regardless of host platform vs data platform endianness.

I never finished working that through, but I was able to identify all of the code with little-endian assumptions on a big-endian platform (particularly the code that read structures from disk in a single read rather than reading individual fields and byte/word swapping as necessary). I can finish working that through so there is better platform independence in the data file loaders, if that is of interest to you/you haven't already done that work for the future.

Whenever your "fixed" branch is mature I can move things over to that.

This was a personal/free time challenge, the deprecated main/floating-point version works better than expected given how the code is written.