Attached is some reversed source for a path parser. It can only handle R1Path, path 1.
It will call the decoder with given arguments for the first few screens. It still needs the following:
-A unit test for current input/output
-Refactor the code to be human readable/figure out wtf is going on (use unit testing to check nothing was borked)
-Figure out how the format is working properly, I Think there might be another function that sets up the placement objects maybe.. who knows..
There are 3 hard coded values, two offsets in the file and the path items which is 0xC. Hence this wont work for any other path since these values change. It should be possible for someone else to at least screw with the first few screens after spending a lot of time looking at this
Edit: btw slight issue with the code, swap the arguments of main() around, also figuring out collision detection reading from the path still needs figuring out too
Sample output from the loading screen to the first screen of the game
Loading to S1
aIndex: 0 aIteration: 1 Arg3: 1 Arg4: ffffffff
OPCODE: load_unknown_1
OPCODE: load_null
OPCODE: load_null_1
OPCODE: load_font_q
OPCODE: load_slig_bans2
OPCODE: load_unknown
OPCODE: load_glow_bans
OPCODE: load_glow_bans
OPCODE: load_glow_bans
OPCODE: load_glow_bans
OPCODE: load_glow_bans
OPCODE: load_hoist_rocks
OPCODE: load_null_35
EXIT LOOP!
aIndex: 0 aIteration: 2 Arg3: 1 Arg4: ffffffff
OPCODE: load_hoist_rocks
OPCODE: load_null_1
OPCODE: load_font_q
OPCODE: load_slig
OPCODE: load_slig_bans2_proxy
OPCODE: load_unknown_4
OPCODE: load_glow_bans
OPCODE: load_null_35
OPCODE: load_info_point
EXIT LOOP!
aIndex: 1 aIteration: 1 Arg3: 1 Arg4: ffffffff
OPCODE: load_null_1
OPCODE: load_hoist_rocks
OPCODE: load_hoist_rocks
OPCODE: load_switch_bans
OPCODE: load_hoist_rocks
OPCODE: load_unknown_bans_1
OPCODE: load_mud
OPCODE: load_unknown_bans_1
OPCODE: load_hoist_rocks
OPCODE: load_unknown_8
OPCODE: load_switch_bans
OPCODE: load_null_35
OPCODE: load_meat_saw
OPCODE: load_meat_saw
OPCODE: load_meat_saw
OPCODE: load_unknown_11
OPCODE: load_unknown_4
OPCODE: load_glow_bans
OPCODE: load_mud
EXIT LOOP!
aIndex: 0 aIteration: 1 Arg3: 1 Arg4: ffffffff
OPCODE: load_unknown_1
OPCODE: load_null
OPCODE: load_null_1
OPCODE: load_font_q
OPCODE: load_slig_bans2
OPCODE: load_unknown
OPCODE: load_glow_bans
OPCODE: load_glow_bans
OPCODE: load_glow_bans
OPCODE: load_glow_bans
OPCODE: load_glow_bans
OPCODE: load_hoist_rocks
OPCODE: load_null_35
EXIT LOOP!
After the first exit loop that is everything for the first screen, it appears to also load items for each screen around it, e.g:
ParsePath( &data[0], 0, 1, 1, -1 );
ParsePath( &data[0], 0, 2, 1, -1 );
ParsePath( &data[0], 1, 1, 1, -1 );
ParsePath( &data[0], 0, 1, 1, -1 );
Paying attention to only arg1 and 2 we can see that screen 0,1 is loaded which is the very first screen. Then 0,2 which is the screen DOWN or under the first. Then 1,1 which is the screen to the right... and then the first screen again for some reason..
However screen 2 to 3 makes much more sense:
std::cout << "\nS1 to S2\n";
ParsePath( &data[0], 0, 3, 1, -1 );
ParsePath( &data[0], 0, 2, 1, -1 );
screen 0,3 - the 3rd screen is loaded, and screen 0,2 the 2nd screen is loaded. Thus is always loading one extra screen. And the NEXT screen seems to be done first.