Dynamo's One-Stop Resources Shop(NEW!Realms of the Haunting)

[HMNuke93]

If you're not practical with coding your own tools the easiest way is saving the palette with .pal extension, import it in slade then right click->Palette->Tweak, then set Luminosity to 200% twice.
Anyway I checked the beginning with 8x8 tile size like you suggested, but all I see is http://imgur.com/yKjr2YS
Some tiles in the middle vaguely make some sense, but size definitely isn't 8x8

My mistake, i meant the image format is 8 bits x pixels..... i'll try the method you suggested. The file i attached is an example (with an edited palette) of what i was able to rip with tiledggd. The panel width is 256, the height changes in all LIF files. Generally in the beginning of the file you find some textures,then sprites,and toward the end of the file you find fonts and system graphics.

[Yagotzirck]

Alright, I'll search the widthxheight values of a few sample textures/sprites to see if I can find the archive's file allocation table, so that I can automate the extraction process. Thanks

[HMNuke93]

Glad to help , and by the way, your method worked!

[Ozymandias81]

Glad to help , and by the way, your method worked!

OHSHITOHSHIT IT'S HAPPENING...

[HMNuke93]

Glad to help , and by the way, your method worked!

OHSHITOHSHIT IT'S HAPPENING...

You bet

---

Sei italiano?

[Ozymandias81]

@HMNuke93
When the set will be completed, I think you'll need to work on it in order to give more bright colors... Maybe compare them to the available resource on ZDForums from LR.

---

Debbrutto cumpà! Evitamose de farlo notà troppo!

[ect0s]

I have a near complete rip of killingtime for the PC.

If your trying to do it on your own, understand 90% of the sprites are compressed and in a special format. I wrote a bunch of pythonscripts to extract, decompress, slice and convert them. TiledGGG will not work for most of the files.

I have about 90% of things, theres a few frames of some animated sprites that throw errors. I also have to rework my script for the menu extraction and sounds extraction.

If tinyupload is allowed, heres a current copy of my dump folder (minus sounds and some menus):

Mind you: Some of the files are not in 100% ready shape due to an offset error I'm correcting and an issue with processing alpha, most things should be 'usable'.

EDIT: New(er) Dump, No Menus, Sounds or First Person Weapons. Missing 6 animation frames.
http://s000.tinyupload.com/index.php?fi ... 3297255060

I'll likely have a proper full dump in a few days/weeks.

[Dynamo]

Hey, thanks very much for this definitely looking forward for the final build of it, feel free to post it here if you happen to get it

---

e non preoccupatevi che ho altro in serbo per tutti

[ect0s]

I have one correction to make to a calculation to fix most of the offset issues.

Beyond that, PIL (Python Image Library) doesn't like converting the alpha without flipping pixels insides sprites. Would they be usable without alpha built in? Someone would have to do it by hand.

The Menus just need a new dump done now that things have been updated, while I'm at it I'll redo the POV of the weapons since they are essentially the same format.

The Sounds are unsorted, and theres about 200 of them I have to play then rename to something appropriate.

[Dynamo]

Well for transparency I imagine it could be easy to make or find a tool to do it automatically, I had one that did it for the Prime Target and Damage Incorporated rips: that is, as long as the background color isn't being used elsewhere in the sprite. Something like cyan or bright purple helps in that regard, but usually white works as well

[ect0s]

The 'alpha' color in game is set to black in the pallet.

Black is also used in the sprites, for instance the wasp/hunter in the dump I linked have obvious issues with this.

Technically, I think the black used inside of the sprites is sopposed to be a different pallet color number, but because both it and the alpha map to the same color PIL treats them the same when converting alpha. Its the same black value

I can easily force them to dump as another image type, or as a raw image, or I can change the alpha color to something else (another color triplet) in the pallet. Changing the color didn't work.

I also have the map data, its in a doomlike format, but I haven't looked into converting them into a wad - Lots of things would be broken even if I did.

[Dynamo]

yeah, conversion seems to be out of the question, but nonetheless documenting it in some format may always prove to be useful - I've done that for cybermage for example in the (remote) possibility anybody wants to mess with the levels of that game, they have something to start with.

[HMNuke93]

I have a near complete rip of killingtime for the PC.

If your trying to do it on your own, understand 90% of the sprites are compressed and in a special format. I wrote a bunch of pythonscripts to extract, decompress, slice and convert them. TiledGGG will not work for most of the files.

I have about 90% of things, theres a few frames of some animated sprites that throw errors. I also have to rework my script for the menu extraction and sounds extraction.

If tinyupload is allowed, heres a current copy of my dump folder (minus sounds and some menus):

Mind you: Some of the files are not in 100% ready shape due to an offset error I'm correcting and an issue with processing alpha, most things should be 'usable'.

EDIT: New(er) Dump, No Menus, Sounds or First Person Weapons. Missing 6 animation frames.
http://s000.tinyupload.com/index.php?fi ... 3297255060

I'll likely have a proper full dump in a few days/weeks.

you're my hero

[Yagotzirck]

The 'alpha' color in game is set to black in the pallet.
Technically, I think the black used inside of the sprites is sopposed to be a different pallet color number, but because both it and the alpha map to the same color PIL treats them the same when converting alpha. Its the same black value

Can you describe the original picture format and how you're decompressing it? I think the transparency should be treated during the decompression process, kinda like in doom where there isn't a transparent palette color, but instead the transparent pixels are simply skipped by defining each column's beginnings: http://doomwiki.org/wiki/Picture_format

I'd suggest to scan each image for an unused palette index(since it's unlikely that a sprite/picture will use all of the 256 colors) and using that as a transparent color, that's what I did when I ripped Target and it worked quite well

[ect0s]

http://s000.tinyupload.com/index.php?fi ... 5880186095

Looks similar to the doom format.

Above is a raw sprite of a key. The keys are not compressed in the original archive (Killingtime.rez). Many of the object sprites and all of the enemy sprites are compressed, and are also group together into one file with an additional header.

Format:

Code: Select all

04 00 00 00 18 00 31 00 0C 00 31 00

04 00 00 00 - Marker as single frame sprite.

18 00, 31 00 - Width, Height, little endian.

0C 00, 31 00 - Draw Offset for center of sprite in game.

Begin Line Descriptor Pointer Table:

Code: Select all

38 00 3D 00 
4A 00 57 00 64 00 71 00 7A 00 83 00 8C 00 95 00 
9E 00 A7 00 AC 00 B1 00 B6 00 BB 00 C0 00 C5 00 
CA 00 CF 00 D4 00 D9 00 DE 00 E3 00

All pointers are two bytes, little endian, they're origin is relative to the 4th byte in the file (add 4 to each pointer). The Number of pointers is equal to sprite width. If a pointer is 00 00, the scanline is empty and has no descriptors

Descriptors:

Descriptors are 4 bytes long, there can ever several for each scanline. Between Scanlines there is a flag byte (FF, 255). You can find the length of a set if descriptors by subtracting the current pointer from the next pointer and subtracting 1. This will fail on the final scanline, but is required because in at least 6 cases a descriptor starts with FF, these are the 6 frames currently not in the dump. You append the offset to the beginning of the pixel array (First Descriptor Pointer) to make the math workout.

Scanlines are actually equal to height, requiring a rotation and flip after the entire pixel array is built.

Example for scanline one of linked sprite:

Code: Select all

07 04 E8 00 FF

07 - Padding (alpha)

04 - Number of Pixels in line

E800 - Pointer to Pixels to get from file start+4

FF - End of Scanline (fill the rest of line with padding).

Next Line.

Code: Select all

05 0C EC 00 27 04 F8 00 2D 04 FC 00 FF

05 - Pad

0C - Run of Pixels to read

EC 00 - Offset to read from.

27 - Pad - However, Subtract current line length to get value of pad bytes to fill.

04 - Run of Pixels

F8 00 - Offset to read from.

...

FF

Next line, And so on.

Pallets are stored seperately, there is no color table in each sprite, just raw values that map to the pallet.

I suppose your right in that I could make the pad bytes another color, I would just have to add an array for already found colors and choose something not included.