Right now the project is decompiled to the point where it is feasible to
try porting it to another platform. It doesn't work 100% correctly, but
it's nearing this state.
To port it to Linux I mmapped the openrct2.exe into expected places,
disabled two offending calls (RCT2_CALLPROC_EBPSAFE(0x0040701D) and
RCT2_CALLPROC_X(0x006E7FF3…)), replaced memory management routines
with generic ones and removed all the function-pointer calls.
A basic, non-exhaustive check is included to verify that memory is
loaded correctly in place.
That last bit is probably the most intrusive one, but had to be done, as
the calling convention on Linux differs from the one on Windows. It
could possibly be emulated (just like RCT2_CALLFUNC_X) until dependency
on exe is dropped.
It is possible to completely remove calls out to original code by
commenting out contents of RCT2_CALLFUNC_X, right now this will yield
working UI, but no rendering of peeps, rides or rest of world. This can
be used as a benchmark or test platform for correctness of
implementation. The data sections will still be required for now.
Assets are expected to be in specific places, so to launch it, following
needs to satisified:
* $build/data/ has to have contents of $RCT2/Data/
* $build/data/ (same as above) has to have contents of $repo/data/
* $build/ObjData/ has to have contents of $RCT2/ObjData/
* $build/../openrct2.exe has to be $repo/openrct2.exe (as of 976ea0d)
Keep in mind you can symlink stuff and that filesystems are case
sensitive!
You can copy more of required data to possibly improve your experience.
Pretty much all of this commit will possibly have to be reverted by the
time OpenRCT2 gains independence.
Remember to build with -DDISABLE_NETWORK=ON -DDISABLE_HTTP_TWITCH=ON
`platform_enumerate_files_begin` (and it directory counterpart) can
return `-1`, make sure we handle that value properly when passed on
to `platform_enumerate_files_next` and `platform_enumerate_files_end`
As it turns out, you have to declare your link directories before you
use them in cmake, otherwise your executables/binaries will have no
knowledge of them.
This should fix travis builds for mingw.
Add bulk of the platform file for linux, change the compilation target
from shared library to executable for linux, provide necessary changes
to make it compile & load the stub of a process.
Make sure functions are marked as stubs where needed, and implementation
is expected.
Step 1 on road towards Linux.
Remove windows-specific code, stub it out where needed and make sure we
can still compile it the way it is.
Take care of Travis' build matrix to include new build configuration.
Install new packages.
Ted John