jmortiger
jmortiger
It's little endian. There's no rush; I'm working on a diagnostic thing anyways, might help.
I've made a [branch](https://github.com/jmortiger/FITD/tree/debug-investigation) whose only changes are the addition of numerous print statements showing the memory values being returned from the PAK files. Running this on Windows as a...
That's the thing; it *doesn't* go down those path, but when I modified it to go down those paths, *then* it worked.
I have the correct values of what should be being read from the working Windows build now, so I'll compare it to the garbage data the Linux build is reading;...
> The issue here is more likely that compiled defines are messed up on linux and go down the old path that was intended for powerPC mac, and that was...
Honestly, I'd say it'd be wise to have tests that automate retrieving pak data, interpreting sample data, etc. and comparing their output w/ known correct outputs; not sure how much...
A further complication: on Windows, `long int`'s are (seemingly) *always* 32 bits; they're [64 bits w/ GCC & Clang](https://www.linuxquestions.org/questions/programming-9/c-preprocessor-define-for-32-vs-64-bit-long-int-4175658579/#post6021525). Adding this ```c++ void detectGame(void) { #ifdef FITD_DEBUGGER printf("...BTW, here's the...
Nevermind! It turns out that ~while my speakers indicate the whole reading garbage data thing might still a problem~ the incorrect sizing of types is the big problem. It's compiling...
I don't want to lose my progress on my Linux fix, so I'm just gonna push to this branch; I'll reopen this with a backed-up version of the current state...
I've restored the prior state of the repo. To keep the changes isolated, this does not contain any bug fixes; that is confined to #13. If that is pulled first,...