Support OSX PPC, GameCube, Wii and WiiU as libretro core #1943
Conversation
396cef5 to
62f3ce3
Compare
| rotate &= 0b11; | ||
| flip &= 0b11; | ||
| rotate &= 3; | ||
| flip &= 3; |
There was a problem hiding this comment.
Why are changes like this necessary at all?
There was a problem hiding this comment.
OSX PPC default compiler is gcc 4.2 which doesn't support binary notation. Other than normal int a solution could be to have defines for BINARY_11 and similar
| bool b:1; | ||
| bool x:1; | ||
| bool y:1; | ||
| #if RETRO_IS_BIG_ENDIAN |
There was a problem hiding this comment.
Why is there so much of this, as long as all the code is on the same endianness, can't the compiler just sort this out itself? Is the problem use code inside the VMs or?
There was a problem hiding this comment.
Problems arise from 2 sources:
- Loading little-endian cartridge (few places)
- Union between bit-field and plain types like u*. E.g. you can write through gamepads.first.x and read through gamepads.data. Then the result will depend on endianness unless we do those changes
|
Added ngc/wii/wiiu as they are only a small patch on top of osx-ppc |
|
To be honest, I'm a little afraid of such changes, a lot of overhead for defining structures, isn't it? |
Unlike my previous attempt this minimizes the changes to actual code. Now solitaire.tic runs correctly. Only 2 fields were actually crossing byte boundary and needed byte-swap handling or field-splitting. Others were just a straight reorder of bitfields
Comment indicates that it's about SDL but this header is used outside of SDL as well. Instead put it in SDL-specific files
|
I'm also afraid of such huge patches for endianess. Are they no better solutions? |
Unfortunately no. There are only 2 solutions here:
First one results in a smaller patch. But I can do second as well. I don't care which approach |
Where are the existing unit tests? Unit tests usually would catch big-endian issues as long as they are executed in big-endian environment.
Not in progress. Pretty much finished. |
|
THan you for your help, pls add yourself to the credits list. |
|
@phcoder Several bugs have been reported that seem likely to have originated here... would you be willing to triage and work on fixes for them perhaps? If so I can do a quick sweep and drop a short list here. |
Unlike my previous attempt with big-endian this one minimizes code changes and instead fixes structs. Only chunk size and sound register needed special handling beyond structure change