Jump to content

Got bored, made a thing


bobsayshilol
 Share

Recommended Posts

Hi! Newbie here, but I got bored and made a thing:

eWSCOmc.jpg

I used to love this game as a kid, and recently I found the disk buried under a pile of, well, other disks. (I used to love RR and LI1+2 too, but not as much as this - I can't even remember if RR/LI1+2 had a theme, but I can hum LR's theme and the building room song without even thinking!) So now that I have more free time the idea popped into my head to reverse-engineer the game, because why not! Currently it can read the JAM file and create the main menu (well all apart from the man in the corner: just need to look at animations then once that's done it seems like a simple 3x3 matrix maps it into screen space) with sound playing (albeit in a very quiet and crackly way because I messed up the ADPCM converter and cba to redo it yet), but nothing is interactive yet. I wish I'd seen http://www.rockraidersunited.com/topic/6624-lego-racers-in-unity/ before I'd started working on this, but ah well.

 

Almost all of this is from reverse-engineering/guesses (no copy-pasta of libLR1 or anything else, except possibly the BMP format) and I prefer to work out and implement stuff myself rather than rely on other peoples implementations, so everything you can see I've written in C or C++ (it originally started in C as a JAM dumper but then expanded into a full C++ project with a single C file that doesn't want to change into C++ (Logging.c)). It relies on LEGO.JAM being in the same folder (although it also searches the parent folder as it makes the build folder setup easier) and the .tun files being in the same folder if you want audio. If it finds the folders "MENUDATA" and "GAMEDATA" next to it then it'll read from them and ignore the JAM file since that's what posts on here seem to suggest happens (note that I haven't been running the actual LR at all - only looking at the data and guessing what each bit does - and hence never needed to modify a file, but I guess having those folders would make that easier). Currently the only command line args from the original game it accepts are "-horzres" and "-vertres" (no support for "-fov" yet, although can't wait to add that!), and additional ones are "-runtests" that runs unit tests (currently all #if 0'd out in the code, except for the image dumping) and "-headless" which was used when I used to dev on my really really old machine (had lower specs than a raspberry pi) but should probably be removed now. It requires OpenGL 3.1 because that's the highest version my machine with an Intel GPU using the Mesa drivers can go, although it doesn't actually need that high a version and I should probably lower it, but chances are most machines nowadays can run it. Maybe if I lower it back down we can get LR running on a raspberry pi or phone... maybe one day.

 

Binaries are attached (debug and release in both Windows and Linux formats - the Linux one was built on Ubuntu 14.04 LTS, but the code requires no dependencies other than SDL2 (I think)) so have a go at running it if you feel like it, although all it does is draw what the picture shows. I think I have the 2001 re-release of the game, and from brief looks at libLR1's code when I got stuck reverse-engineering the file structures it doesn't seem to match my data exactly (unless libLR1 has never been tested against the 2001 data?). Also note that since most of this has been developed on Linux there might be subtle bugs in the Windows version - I gave it a test run and it all seems OK, and seeing as it doesn't do anything yet I don't see how it could go wrong :P

 

Anyway, thought you lot might want to know about this, and don't expect regular updates at all on this or even from me (I busy). Although if you want a statement of progression: on Friday morning it wasn't drawing anything, on Saturday morning it was drawing the images (so background and the logo in the top left), and last night I added the ability to print text on the screen, albeit in a bit of a hacky way (only 1 of the fonts works "OK" since they do something weird with glyph locations - just look at the location of the "Q" in "QUIT"). Oh and the reason the labels don't match what's in the game is I haven't found the mapping between what the internal names are (ie those shown atm) and where the translations are stored in the string files, but once I've found that out then it should be fine :D

contents.zip

Link to comment
Share on other sites

  • 1 month later...

Thought I'd update this since it's been a while since I posted. Been busy with work so not much progress has been made, however I can now view GDB models (with the occasional index going OOB for some reason, still need to work out why), SDB files look like skeletons, I've seen some basic ADB files in action/animated (test track's door :P), MDB's parse but I don't know how to translate their output into anything useful (although GARAGE.MDB definitely looks like screenshots of the build room), BVB is for bounding volumes and seems to have a BSP tree encoded in it, TMB parses but I can't remember what it does, and WDB files are strange but I've managed to get some info out of them. It's becoming harder to guess what these do only from inspection, so I might have to start reading through libLR1 and copying it or testing modified data on windows (2001 version ftw!).

Oh and I got it compiling and linking on my Pi (takes 3 and a half minutes to build natively), but because it's currently running headless I don't have a way to see if it draws :( I'll probably plug it into a screen when I go home for xmas and report back with screenshots.

  • Like 3
Link to comment
Share on other sites

Heh (sorry for the crappy quality, and yes that's running without X started).

No video of the skeletons or maps since that used GL's immediate mode as a hack to show it on Linux, although thinking about it I think the rpi actually supports immediate mode... maybe another day since it's back to being a server for the moment.

Link to comment
Share on other sites

I remenber your popular roblox places, glad you are moving on to bigger and better things.

I've never played roblox before so I think you might be confusing me with someone else :P

Link to comment
Share on other sites

supercoolguy32

I remenber your popular roblox places, glad you are moving on to bigger and better things.

I've never played roblox before so I think you might be confusing me with someone else :P

oh, ok.

Link to comment
Share on other sites

On 12/24/2015 at 5:13 AM, Firedude34 said:

How did you run LL on Mac? Isn't LL for Windows only?!

He is on Linux from the looks of it. Also it is possible to run LR on Mac. That's what I run it on. Put the disc into the computer. Download Crossover. Run disc with Crossover. Done.

Link to comment
Share on other sites

bobsayshilol
On 12/24/2015 at 10:13 AM, Firedude34 said:

How did you run LL on Mac? Isn't LL for Windows only?!

 

On 12/26/2015 at 7:12 PM, LegoRacersFanForever said:

He is on Linux from the looks of it. Also it is possible to run LR on Mac. That's what I run it on. Put the disc into the computer. Download Crossover. Run disc with Crossover. Done.

^ This. Until this holiday I'd only been working on this by reading through the data with xxd on Linux (can't use WINE for reasons). But over the holiday I made a simple script that rebundles the JAM file and I've been playing with the files. I even put up some christmas decorations:

6daU7Zj.png

 

I've also noticed that reading back through my posts makes me look like a bit of a <insert curse word here> since I'm not using any of the tools or info you lot have discovered and just heading off on my own, but that's only because I enjoy a challenge and not because I'm a <insert curse word here>.

 

I don't see any sort of wiki so I'll just dump some info I've found out that may or may not be new to anyone (note that all of these are for the 2001 re-release data since I don't own any other version, although I guess I could look at the demo's data at some point):

  • The executable opens the String Resource File (purely a guess at the acronym) "/MENUDATA/MENUNAME.SRF" and preloads the files inside. The first few are all Menu Interface Binary (MIB) files (which is what I was concerned with for the menu stuff). It then loads the *second* MIB in the list (splash) which then tells it to cd into the "LEGAL" directory and load up the Cutscene Data Binary file "SPLASH1.CDB". This then says to load the empty World Data Binary file "EMITTER.WDB" and the effects. I can't remember how but the CEB (Cutscene Effect Binary?) also gets loaded and that loads the Image Data Binary. The image that is going to be displayed must be 640x480 and RLE compressed, although I did find a way to turn it upside down which suggests that we can also change the compression it looks for (it's part of the bitmap header to have the upside-down flip thing, so I'd guess there are more too. To anyone that wants to try it out swap the 0x29 for a 0x28 inside the IDB file).
  • Then the main menu loads. It should be noted that swapping the "splash" and "mainmenu" strings in the list (or swapping their data) causes the game to hang. I expect it expects a "cutscene" MIB in the second string, and similarly an "interactable" MIB in the third. I don't know what the first index wants (says "testmenu", might be another file type, don't know). If a file wasn't able to be preloaded from the list in the SRF then it will carry on as if nothing happened, but it won't be there for MIB's that need it: ie if you remove "GARAGE.MIB" from the data folder it'll still show the main menu but the button will be missing to go to "BUILD".
  • The XXB files seem to be more stateful than I had previously assumed - I found a file ending in the byte sequence "0x14 0x04 0x00 0x06" to close 4 0x05's rather than the expected (or at least what I expected to see) "0x06 0x06 0x06 0x06". Obviously the first sequence expands to the second, but this implies a lot more state is kept than a simple pass through and interpreting bytes as they come along. It should be noted that swapping the first sequence for the second didn't break anything. The same is also true of any dynamic structs (0x16), ie rather than doing "0x16 0x17 0x03 0x03 0x03 0x03" then later using "0x17 <float> <float> <float>" you can instead skip the 0x17 registration and do "0x03 <float> 0x03 <float> 0x03 <float>". This also explains the huge mess at the top of the Animation Data Binary's (ADB's). For now I just have a ton of hacks lying around, but I'll probably need to fix that.

I can't think of any other points I've found, but if I do I'll update this post.

  • Like 1
Link to comment
Share on other sites

Huge, big thumbs up! :) Its fun to see how many ppl are working on something based off LR. Seriously if we throw together all I found here we almost have a complete remake :D

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.