So I finally found where they where hiding those codes...
#21
whops, updated my post while you were posting... bottom line: those files are borked. Wink
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#22
I don't think they're borked. Isn't the "Rollcage.IDX" file supposed to be the 'directory' for the IMG data file? (that's what the wiki said anyway)

Besides that ... the very last file can be ripped as raw audio data and plays all the game's sound effects.


I guess we'll just have to wait for Spont to be able to make sense of any useful data I found out of this, but I have a feeling they can be made useful. If I already knew how to open BTP files for example (what I believe the textures are saved as) then I might be able to figure this out a bit better.

That tool I used probably isn't perfect, anyway... but I'm sure I just didn't produce 40 megabytes of garbage. :l
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#23
Yes the idx file contains all info about where the files start and stop, but the program you used missread it (and you got a bunch of files consisting of the <end of file1>+<the beginning of file2>, etc...). It's not garbage, but it's just the img file (incorrectly) split into smaller files. Anyway Spont has extracted the files correctly (when I get the time, I'll try out that python script and check the outputted files).
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#24
I see O_o

I wonder if it's got something to do with that patch I installed that fixed the bump mapping? It kinda figures I should have tried it on a 'clean' install ... my bad.

x.x
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#25
I doubt it's anything you did, probably just someone writing some code without properly testing it. Wink
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#26
Thanks for uploading that rar - they do seem to be borked, but it would have been nice to save some time.

First up - the algorithm on xentax doesn't translate directly into code. It's definitely a breakthrough, but it's also vague on a few crucial details. The |ControlBits|Data|ControlBits|Data| organisation looks correct - and it explains the broken-up text we were puzzling over before. I've highlighted the 32bit Control sections below:

00000000 47 54 32 30 21 15 03 00 03 00 00 00 00 00 00 00 |GT20!...........|
00000010 e0 02 00 00 0d 0a 2f 2f 2d f8 ff 2d cc 20 50 4f |......//-..-. PO|
00000020 53 53 49 42 4c 45 20 4f 50 54 49 4f 4e 20 46 49 |SSIBLE OPTION FI|
00000030 45 4c 5c 00 08 41 44 53 88 fd 34 fe 53 54 52 49 |EL\..ADS..4.STRI|
00000040 4e 47 28 59 45 53 29 f3 5b fd 09 45 f2 40 26 20 |NG(YES).[..E.@& |
00000050 25 4c 49 53 48 f6 f2 3a 20 59 65 73 7e 7e f3 5d |%LISH..: Yes~~.]|
00000060 fc 47 45 30 23 66 62 52 4d 41 4e 36 ff 4a 61 3f |.GE0#fbRMAN6.Ja?|


I've been working with this file, since it looks to contain plain-text - note the 0d 0a (Line Feed and Carriage Return) followed by the "//" - which could very well indicate a comment line - "Possible option fields" fits well with that speculation.

The first set of control bits look like this: 0000000000000000000001011100000

Which (reading from right to left) means the first five bytes are uncompressed (the carriage return/line feed and "//-"), then there is a pattern repeat (the ones indicate compression) before starting a long section of uncompressed text "Possible option fiel".

Then you have the next control bits: 01000001000010000000000001011100

Which tell the decompressor to pick up the "ds", before repeating another previous pattern... then there's a long section of zeros which corresponds to the "STRINGS(YES)" section, etc.

So it's relatively simple once you know the secret. It's just taking longer than it should since I've been pretty much stuck in bed the last few days with the flu and I'm making lots of dumb mistakes. But this is a fun distraction from my malady, and I expect it should be done soon.


Also - I don't expect to find file-names - these are usually stripped away by the compiler, since they're only useful for debugging. It's possible there's a list of 290 file-names tucked away in one of the executables, but I don't expect to find them. That said - once we have the files decompressed, and are able to load and view them, naming them shouldn't be that hard.
Reply
#27
Code:
$ ./IMGHack
in:72564 out:202017
..//------------------------------------------------..-- POSSIBLE
OPTION FIELDS..//-----------------------------------------------
-......STRING(YES)..[...ENGLISH..E[..: Yes~~..[]..]GERMAN..E[..:
Ja~~..[]..]ITALIAN..E[..: S.~~..[]..]SPANISH..E[..: S.~~..[]..]FR
ENCH..E[..: Oui~~..[]..]....STRING(NO)..[...ENGLISH..E[..: No~~..
[]..]GERMAN..E[..: Nein~~..[]..]ITALIAN..E[..: No~~..[]..]SPANISH
..E[..: No~~..[]..]FRENCH..E[..: Non~~..[]..]....STRING(ON)..[...
ENGLISH..E[..: On~~..[]..]GERMAN..E[..: An~~..[]..]ITALIAN..E[..:
Attivato~~..[]..]SPANISH..E[..: Actitodo~~..[]..]FRENCH..E[..: A
ctoo.~~..[]..]....STRING(OFF)..[...ENGLISH..E[..: Off~~..[]..]GER
MAN..E[..: Aus~~..[]..]ITALIAN..E[..: Disattivato~~..[]..]SPANISH
Reply
#28
Fun O_o

I still reckon my fiddling was borked due to me probably using a ROLLCAGE.IMG file that was modified beyond what that program was expecting to read.

can't remember if the bumpmap fix hack modified the .IMG file or not.
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#29
I couldn't find the right plugins for that software, so I wasn't able to test it.
Reply
#30
well once I got the program to actually load ... I just tried to open the ROLLCAGE.IMG file and it produced what I showed and uploaded.

I dunno why it's not working for you although I did have a lot of trouble just getting it to work. compatibility issues and all that nonsense.


Funny thing is that for me all that "GT20" stuff ends up at the end of files but you guys all have it at the start. So ... either the program's just trash or it's read it wrong due to modifications.
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#31
My decompressor still isn't perfect. But getting some recognisable stuff out.

   

   
Reply
#32
Holy crap, isn't that the hidden dev loading screen?

o_o whoa.

Also we should totally use that polygonal font in RCX. =D
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#33
So here (attached) is my crappy little program for extracting the files. I made it all one file, to make it easier to share.

To compile (written in linux, should work in cygwin):

Code:
$ g++ IMGHack.cpp -o IMGHack

Then run it in the "disk1/Rollcage/IDXData" directory. It'll automatically pick up the IMG and IDX files, and extract the contents. If it works, it'll look something like this:

Code:
$  ./IMGHack
Writing: 000 Compressed:7785 Unpacked:27020 Additional data:3
Writing: 001 Compressed:7655 Unpacked:27032 Additional data:3
Writing: 002 Compressed:7983 Unpacked:27344 Additional data:3
Writing: 003 Compressed:7837 Unpacked:24876 Additional data:4
...

I haven't had time to poke around much.


Attached Files
.cpp   IMGHack.cpp (Size: 6.66 KB / Downloads: 239)
Reply
#34
Holy shit, bitmap images!

O_O

Unfortunately for me a few of them seem to be busted (i.e. distorted halfway through) but quite a few others ... including a loading screen I just found - load absolutely fine.

wow.


edit

actually, most of the bitmaps I've found so far are pretty messed up. Some just show a few lines of offset as they go down. Others are completely garbled and others have wrong colour palettes. I suspect this may be my ROLLCAGE.IMG and of course it could be due to me running this in Windows (it did work O_o) so if you get any further on the files then say so.

All the files at the end (bar the last one) seem to all be textures. Not sure what the smaller files are but most of the 300KB files are loading screens.

I'm going through them thus far.
Bump.

The file labelled at 079 intrigues me ... it's a texture, but for what I can't figure out. It's a bit messed up like the other files for me. I'm not sure if it's for a car or for a world object.


edit

Take a look at files 060 through to 079. I do believe that these are the car skins, but for me they're all "bluescale" Is it the same for you?
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#35
My 079 looks like this:
   

I hadn't noticed any messed up data... are you running it on linux or windows? Do you have the number of a garbled image so I can compare?


The BTP files are next.. they seem to contain multiple images, and the header contains simple offsets (which are named in plaintext later in the file).. so it shouldn't be too long until we can look at those, too. Here's what I have so far:

00000000 42 54 50 20 00 00 00 00 c0 02 00 02 9d 0b 00 00 |BTP ............|
00000010 61 01 00 00 50 00 00 00 00 00 00 00 50 55 14 00 |a...P.......PU..|
00000020 00 00 00 00 90 17 00 00 a0 40 14 00 00 00 00 00 |.........@......|
00000030 00 00 07 06 20 00 12 00 3c 57 14 00 cc 58 14 00 |.... ...<W...X..|
00000040 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 |................|


Key:
COBJECTS
CLOUD DATA
TPAGE DATA
PALETTE

Extracting the models is going to be interesting ;-)
Reply
#36
Okay, so my ROLLCAGE.IMG file (or the IDX file) is messed up.

[Image: 24echus.png]


No biggie, that obviously means that the program didn't particularly read my files wrong. My files are wrong ... probably messed up from the bump-mapping patch.


The BTP files are probably the collections of specific textures used in each individual track ... that's my guess, anyway. The really big files are the only ones I can't load in any programs so I'm guessing they are all the models and track textures.

I don't particularly understand why the car body textures are all grayscale; I assumed that they all had individual skins for each colour but it seems that the colours are post-appled somewhere. A similar thing is used in Blur. Interesting.
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#37
My first guess would be to blame my program - but, if there are any errors in decompression then it should just abort. Have you tried more than one image viewer? Can you upload the original 079 file?
Reply
#38
That's why I suggested that my files are probably busted.

Anyways, I'll just upload everything your program ripped, so you can compare the differences.

However, I doubt it's a bug in the program but an issue with my files.

Oh, and I can't .7z or .tgz them because winRAR doesn't let me. :l
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#39
Thanks for that. Wow - everything is different! I have an idea for a fix, but I'll have to call it a night for now.
Reply
#40
Please give this new version a try. I fixed a bug where I wasn't closing files properly - might trip up cygwin more than linux? Also, I still don't really know what the "additional data" field is, and what it means - I changed the handling because it looks like some of the files might have been missing a few bytes at the end. Again, I don't see how it'd be directly related to your problem -- but without looking at your IDX/IMG files, I can't say where the problem lies.


Attached Files
.cpp   IMGHack.cpp (Size: 6.93 KB / Downloads: 147)
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)