[Project] Zero's Resources - NEW!: Quarantine 2 & More!

[Zero X. Diamond]

I could attempt to strip out the data with a hex editor; the tool shows you exactly where the start of what you're looking at currently is at. However, without any clear ability to see where one file ends and another begins... it could get messy. I'll give this method a shot, but I won't make any guarantees.

EDIT: Predictably, this endeavor ended in failure. Regular graphics editors fail to recognize the extracted hex data as an image.

[Gez]

At any rate, my search for some sort of easy to use RLE decompressor has come up completely blank. I haven't even found a difficult to use one. I haven't found one at all! Anyone have any ideas of how to approach this?

Well, if you like programming, you can use the RLE code that is present in ZDoom (and/or SLADE3) to handle IMGZ files and some of the font formats.

[Caligari87]

EDIT: Predictably, this endeavor ended in failure. Regular graphics editors fail to recognize the extracted hex data as an image.

Maybe try manually inspecting the hex code, compare it to the RLE/Bitmap standards, and see if you missed any header/footer bits? Maybe your image viewer is only showing the image data range itself.

[InsanityBringer]

The problem is that the RLE bitmap format is pretty much undefined. RLE's just a type of compression, the actual implemention can vary to the best of my knowledge.

[Caligari87]

Ah, shows how much I know.

[Zero X. Diamond]

At any rate, my search for some sort of easy to use RLE decompressor has come up completely blank. I haven't even found a difficult to use one. I haven't found one at all! Anyone have any ideas of how to approach this?

Well, if you like programming, you can use the RLE code that is present in ZDoom (and/or SLADE3) to handle IMGZ files and some of the font formats.

Ah, but there's the rub! I don't like programming. DECORATE and QBASIC are about it for my skillset, and pretty sure that neither of those are going to solve my problem.

EDIT: Interesting! For some reason SLADE3 refuses to show the actual existing palette for me (it shows up as a mess of gray colors even in a Doom wad) but it appeared to show a single frame from one of the weapons. Downloading the latest beta to see if that fixes my palette issues to confirm; if so, the code from SLADE3 might be just what the doctor ordered!

[NeuralStunner]

Slade 3 always defaults to a gray palette if no PlayPal is present in the file. If you know what the palette's like, make an .act of it and put it in a \Palettes subdirectory of Slade's directory.

[Zero X. Diamond]

Yeah, after I updated I changed the lump from PALETTE to PLAYPAL and it worked. At any rate, here's what SLADE3 displayed the single (almost) working weapon frame as:

necrodome_weapon_almostcorrect.png

EDIT: And actually, the single frame here appears to be the gun you get when your vehicle is destroyed, which would mean that it's also inexplicably rotated 90 degrees counterclockwise. Not that that's actually out of the norm considering I've seen plenty of games where graphics data is stored as such, but usually in an editor like this it's rotated to be properly displayed or whatever. Curiouser and curiouser...

[Gez]

Slade 3 always defaults to a gray palette if no PlayPal is present in the file.

More precisely:

You've got a palette chooser and a base archive chooser.

The default value for the base archive chooser is "none". You've got to set them up yourself. Then it remembers them and you can switch them around. Very nifty.

The default value for the palette chooser is "default/global".

This means that if the current archive has a PLAYPAL, it uses it. If not, it uses the PLAYPAL from the base archive. If the base archive has no PLAYPAL either, or there is no base archive at all, it uses a grayscale palette.

You can override that by choosing any of the built-in palettes offered by the palette chooser. There's a nice variety of choice and you can add more.

Oh and by the way: there's a little tool you can use to convert palettes from 6-bit format to 8-bit format, since SLADE3 uses 8-bit palettes to display images. So if you find the game's palette but the colors are wrong, try selecting the palette's lump, opening the console, and typing the command "palconv". It'll turn it into an 8-bit palette and you can extract it, put it in the Palettes directory, and restart SLADE3.

[Gez]

EDIT: And actually, the single frame here appears to be the gun you get when your vehicle is destroyed, which would mean that it's also inexplicably rotated 90 degrees counterclockwise. Not that that's actually out of the norm considering I've seen plenty of games where graphics data is stored as such, but usually in an editor like this it's rotated to be properly displayed or whatever. Curiouser and curiouser...

SLADE3 does not specifically support Necrodome. It's just a bit of a coincidence that it works here. This means that the format used is very close to the Dom gfx format; but apparently it's a row-major format (Doom is column-major). Making a new format loader that knows that they're rows and not columns may solve the glitches that partially damage the image.

What's the format of these POD archives, I wonder. If they can be opened, they are extremely similar to one of the known formats, but the directory has garbage for the entry names, so it's not entirely compatible.

[Zero X. Diamond]

I'm guessing it was never really figured out since XWE has the same limited compatibility with the exception of it showing less stuff than SLADE3 appears to.

EDIT: If you want a better picture, from what I can tell this is how stuff is laid out in there:

Palette data is the very first thing to be listed in the files, followed by lightmaps and what have you. Then you have some menu graphics (the title screen, various doodads for the menus, the fire effect that burns up the screen when a new game is started) followed by the HUD and the various animated control stuff upon it (clutch, joysticks, etc.). Almost immediately after that is some sort of green bodied digital timer, which is followed by the weapons data that appears to be RLE compressed. After that come the textures (which appear to be incredibly small at 32x32), followed by sprites for both static objects and monsters. After that comes textures for the 3D models that make up vehicles and whatnot, and assumably after or within that data come the 3D models in some unknown format. After that I believe come the sounds. Finally, there appear to be a number of icons that look like they were probably used for placement of objects in a map editor and then the game's sky graphics.

I can try and get some estimates on the hex addresses for everything, but most of it wouldn't be 100% accurate.

[Snarboo]

Is it possible that Necrodome's file structure is close to Cyclones and Shadowcaster? They are all Raven games, so there might be overlap.

[Zero X. Diamond]

I don't see why that couldn't be the case, especially since it shares some resources with Cyclones (the rat, the bulging with muscles barbarian guy and the red robot dude).

[Gez]

Yeah, but the garbage names show that they've changed the directory structure at least. If I had the files I could probably find out the differences and extend proper support.

[Snarboo]

As far as I know, the demo's data format is identical, save having fewer entries. Here's a link:
Necrodome Demo