More info on the project? #1
Comments
|
I am decompiling the game disassembly manually using IDA. The variable / method names are my own judgement at what the code is doing and also based on the OpenTTD 0.1 source code which is similar. The Roller Coaster Tycoon Techinical Information Depot has also been a useful resource. The source compiles to a DLL. I patched the original game so that its entry point simply calls my DLL entry point instead. Code in the DLL then runs but is able to read/write to the original game's RAM and call methods. This means that the game can be gradually decompiled while still being playable. New features can also be implemented before the whole game has been decompiled. The source code can only be compiled in Visual Studio due to the inline assembly used and also because RCT2 was compiled with an older version of Visual Studio. This will be the case until the whole game has been decompiled and running on SDL2 calls. Then it will be truly cross platform. I will write up a manual on how to compile the game soon and how the new code is still able to call the original non-decompiled code. To be able to help decompile the game, x86 assembly knowledge and reverse engineering experience is necessary. Currently the game runs and renders in an SDL2 window which can be resized freely. The sound is still using DirectSound and the input is in the process of being decompiled. Many window functions have been decompiled now. Decompiling the code for all the windows in the game will be straight forward. Rendering of the viewports and game logic updating will be more complicated. |
|
Awesome! Wish I could help in some way; I've got limited experience with x86 to be honest (one compilers class). Is there a way to estimate your progress on decompiling? Also I tried the link on Tycoon Technical Depot but it's 404ing, http://www.gamespy.com/rctuk/tid/ |
|
I have currently named / identified the function of ~25% of the procedures in rct2.exe. I have maybe decompiled around ~15%. Try this backup: |
|
I've created a copy of the pages from the Technical Depot which relate to technical information, which you can access here. (slightly off topic, but the "Ride Structure" part of the sv4structs page may be helpful in finding the meaning of some of the unknown variables in ride.h) Still though, excellent work so far with this project! |
|
Thanks for copying the pages, that is very useful. The ride structure has changed slightly from RCT1 to RCT2, so each variable must be confirmed before assuming its the same. I am not sure how much it has changed or whether a lot of the variables have just been offset slightly. Its hard to tell at this stage. |
|
I've written a Go library to read ride formats into a Go struct. I've also Kevin Burke | Twilio On Thu, Apr 17, 2014 at 3:55 PM, UnknownShadow200
|
|
Which version of IDA are you using? |
|
IDA 5.0 freeware |
|
I don't have time to work on your project unfortunately :( But I can decompile the whole thing with IDA 6.5 and hex-rays decompiler and provide C files. Would that help you? |
|
I don't think the automatic decompiler would work very well due to the game being written in assembly and therefore not following typical compiler conventions. Thanks for the offer though. |
|
Good point! Good luck with your project! |
|
@IntelOrca |
|
@UnknownShadow200 Keep them separate. Make a new page, probably with a new name, with all of the new findings. If the code is well-commented, separate documentation may not even be all that necessary. |
|
@UnknownShadow200 that's fine |
Fixed the buffer overflow. Increased the number of pixels again
Could you provide more information on how this was done? Perhaps you wrote a script or you have designed a patch file. I'd be interested in knowing how to reproduce those changes on the original rtc2.exe |
|
I used CFF Explorer to modify openrct2.exe so that it imported openrct2.dll and the exported new main function. I then used IDA to find the address of the WinMain function in openrct2.exe and a hex editor to overwrite the instructions at that address to stack the WinMain parameters and call the exported function using the virtual address provided by CFF explorer for the new main function in the DLL. |
|
I followed your instructions, using Ollydbg instead of IDA and I was able to export WinMain into a dll and then call it afterward (with the help of adresses.h). |
Refactor sub_6A9DE1. Now uses known structures.
ghost
mentioned this issue
While looking at #7176 (comment) I got a crash with stacktrace: #0 0x7f9e81fa2e30 in object_entry_get_entry(int, unsigned long) ../src/openrct2/object/ObjectList.cpp:181 #1 0x7f9e81fa24ae in get_loaded_object_entry(unsigned long) ../src/openrct2/object/ObjectList.cpp:142 #2 0x7f9e8215d64f in S6Exporter::Export() ../src/openrct2/rct2/S6Exporter.cpp:169 #3 0x7f9e8216de71 in scenario_save(char const*, int) ../src/openrct2/rct2/S6Exporter.cpp:757 #4 0x7f9e81c932b0 in game_autosave() ../src/openrct2/Game.cpp:1590 #5 0x7f9e828625b6 in scenario_autosave_check() ../src/openrct2/scenario/Scenario.cpp:297 #6 0x7f9e81c8a958 in game_update() ../src/openrct2/Game.cpp:439 #7 0x7f9e81c6731f in OpenRCT2::Context::Update() (/home/janisozaur/workspace/OpenRCT2/build/libopenrct2.so+0x10f331f) #8 0x7f9e81c6674c in OpenRCT2::Context::RunVariableFrame() (/home/janisozaur/workspace/OpenRCT2/build/libopenrct2.so+0x10f274c) #9 0x7f9e81c6402d in OpenRCT2::Context::RunFrame() (/home/janisozaur/workspace/OpenRCT2/build/libopenrct2.so+0x10f002d) #10 0x7f9e81c638f4 in OpenRCT2::Context::RunGameLoop() (/home/janisozaur/workspace/OpenRCT2/build/libopenrct2.so+0x10ef8f4) #11 0x7f9e81c627bf in OpenRCT2::Context::Launch() (/home/janisozaur/workspace/OpenRCT2/build/libopenrct2.so+0x10ee7bf) #12 0x7f9e81c5b08a in OpenRCT2::Context::RunOpenRCT2(int, char const**) ../src/openrct2/Context.cpp:170 #13 0x56323695b95e in main ../src/openrct2-ui/Ui.cpp:60 Sadly I cannot reproduce it anymore
This commit ignores keypresses when the mod key is held.
The reasoning is that an odd interaction happens between SDL applications and
tiling window managers. Tiling window managers like Xmonad and i3 usually use
the mod ("windows") key and a number to change workspaces. When changing
workspaces, however, the WMs still send the number key through instead of
"eating" it. It's not clear why, exactly, but it seems universal.
Mod+1 -> Goes to workspace OpenRCT2#1
Mod+2 -> Goes to workspace OpenRCT2#2
...
Mod+9 -> Goes to workspace OpenRCT2#9
Most applications don't even see the number key being sent, so if you move to
workspace 1, Firefox won't type "1" into the browser bar, Vim won't type "1"
into your file, etc. But SDL applications, for whatever reason, DO see this
keydown. Of course, they'll handle it like a regular key press. So if you move
to workspace 1, which contains OpenRCT, it inadvertently toggles x-ray mode.
I first found this bug in another SDL game, The Powder Toy. After some
discussion with the devs, they fixed it like this, by ignoring keydown events
when the mod key is pressed, since the mod key is reserved for the window
manager anyway. It works well and should be in the next release.
The-Powder-Toy/The-Powder-Toy@c761938...93b920a
I did the same thing here.
This commit ignores keypresses when the mod key is held.
The reasoning is that an odd interaction happens between SDL applications and
tiling window managers. Tiling window managers like Xmonad and i3 usually use
the mod ("windows") key and a number to change workspaces. When changing
workspaces, however, the WMs still send the number key through instead of
"eating" it. It's not clear why, exactly, but it seems universal.
Mod+1 -> Goes to workspace OpenRCT2#1
Mod+2 -> Goes to workspace OpenRCT2#2
...
Mod+9 -> Goes to workspace OpenRCT2#9
Most applications don't even see the number key being sent, so if you move to
workspace 1, Firefox won't type "1" into the browser bar, Vim won't type "1"
into your file, etc. But SDL applications, for whatever reason, DO see this
keydown. Of course, they'll handle it like a regular key press. So if you move
to workspace 1, which contains OpenRCT, it inadvertently toggles x-ray mode.
I first found this bug in another SDL game, The Powder Toy. After some
discussion with the devs, they fixed it like this, by ignoring keydown events
when the mod key is pressed, since the mod key is reserved for the window
manager anyway. It works well and should be in the next release.
The-Powder-Toy/The-Powder-Toy@c761938...93b920a
I did the same thing here.
This commit ignores keypresses when the mod key is held.
The reasoning is that an odd interaction happens between SDL applications and
tiling window managers. Tiling window managers like Xmonad and i3 usually use
the mod ("windows") key and a number to change workspaces. When changing
workspaces, however, the WMs still send the number key through instead of
"eating" it. It's not clear why, exactly, but it seems universal.
Mod+1 -> Goes to workspace OpenRCT2#1
Mod+2 -> Goes to workspace OpenRCT2#2
...
Mod+9 -> Goes to workspace OpenRCT2#9
Most applications don't even see the number key being sent, so if you move to
workspace 1, Firefox won't type "1" into the browser bar, Vim won't type "1"
into your file, etc. But SDL applications, for whatever reason, DO see this
keydown. Of course, they'll handle it like a regular key press. So if you move
to workspace 1, which contains OpenRCT, it inadvertently toggles x-ray mode.
I first found this bug in another SDL game, The Powder Toy. After some
discussion with the devs, they fixed it like this, by ignoring keydown events
when the mod key is pressed, since the mod key is reserved for the window
manager anyway. It works well and should be in the next release.
The-Powder-Toy/The-Powder-Toy@c761938...93b920a
I did the same thing here.
Ignores keypresses when the mod key is held.
The reasoning is that an odd interaction happens between SDL applications and
tiling window managers. Tiling window managers like Xmonad and i3 usually use
the mod ("windows") key and a number to change workspaces. When changing
workspaces, however, the WMs still send the number key through instead of
"eating" it. It's not clear why, exactly, but it seems universal.
Mod+1 -> Goes to workspace #1
Mod+2 -> Goes to workspace #2
...
Mod+9 -> Goes to workspace #9
Most applications don't even see the number key being sent, so if you move to
workspace 1, Firefox won't type "1" into the browser bar, Vim won't type "1"
into your file, etc. But SDL applications, for whatever reason, DO see this
keydown. Of course, they'll handle it like a regular key press. So if you move
to workspace 1, which contains OpenRCT, it inadvertently toggles x-ray mode.
I first found this bug in another SDL game, The Powder Toy. After some
discussion with the devs, they fixed it like this, by ignoring keydown events
when the mod key is pressed, since the mod key is reserved for the window
manager anyway. It works well and should be in the next release.
The-Powder-Toy/The-Powder-Toy@c761938...93b920a
I did the same thing here.
Where did you get the files from? Are you generating the variable/method names or are they coming from the source code?
How would I build this myself? What platforms are supported?
The text was updated successfully, but these errors were encountered: