OpenDeadlock / Decoding Project Blog: Recent posts

An encoder for HDX/HDD file pairs has been released under decoding project.
[EnHDX] should be able to encode every type of HDX/HDD pair, however, decoding and reencoding one of the files came up slightly different and I cannot identify if it was my fault or that there was something with the original file.
Still there is no reported problem until now.

An extractor for HDX/HDD file pairs has been released under decoding project.
[DeHDX] is a tool that is able to extract every known HDX/HDD file pair, which are widely used within DL2.

The [CAM Tools] also include a CAM Encoder. This tool can be used to create [CAM File]s. This way you can replace files used by DL2.

A CAM file extractor is now available (see [CAM Tools]).

It is currently capable of extracting any single format ([CAM File]), widely used in DL2.

I didn't intend to spend too long on auxiliary tools but I hope this is worth it.
The Sprite Tool has been updated and the basic version of the String Tool is available.

The idea of the String tool is not to tag everything, it was planned to evolve to a string management tool for the OpenDeadlock. It would also become a tool for translators.

More news!

Now we have standings for the top collaborators for the sprite tagging and categories.
Do not forget to check it over there.
Standings

As promised, the sprite decoder now interfaces with ImageMagick (Magick++) to read more palette formats and write more image formats.

Please be advised that using images as palette may cause precision loss, but this should not cause problems if you use tool to rematch the colors if needed (GIMP with imported palette and then Palette Tool match).

Do not use lossy formats if you intend to edit sprites!... read more

Good news for you.

The long awaited sprite decoder is now available.
It took a while because I had to structure the code better and detach the dumps from it. In my previous (closed-source) versions, I had the Okteta write a .C file of the dump into an array and everything was fixed from compile time.

Still... be advised that this code contains several legacies from the closed-source version, such as the typedef to replace the template definition (which was useful when I was unsure about the spriteinfo format) mixed CSTD and C++STD libraries. The code is procedural and uses returns to check the success instead of defining exception types. It should work fine anyway with good (overall) performance.... read more

The Decoding/Encoding tools repository now has the source code of two verified open source tools used to decode and encode sprites.

These two are not limited to deadlock, they can be used in any palette indexed file that is stored in raw binary data.

PaletteTool is an exception because it was not written in C++. Since it is a standalone tool, it will not cause any problem, on the contrary.

PaletteTool is also simple, but it has already been proven a powerful and useful tool. It is an image viewer, palette converter and palette matcher, all in one. It can be used to convert palettes dumped from memory into actual image files and vice-versa using arbitrary byte orders.
It can also be used to match a file to a palette. The output may be another image file or a binary file, which can be loaded into a sprite file.... read more

Yesterday Ubergeneral Grunt allowed me to take a look into the data fork/section of the original Deadlock for MacOS.

I was interested about it to make sure of the structures and variables lengths.

I didn't expect that the MacOS version data would be RLE encoded, but it didn't cause many problems, it was clear when the encoding replaced the zeros by a 01 byte and their count set by the lower half of the following byte.... read more

Please help us tag the sprites!

We have an application for tagging, naming and describing the sprites.

Ask me for an account and you should be able to help at no time.
See http://opendeadlock.sourceforge.net/spritetag.php

I admit I was uneasy at first, waiting for someone else to work on it but I was surprised no one else was working on it.

Following instructions from the original developers, I tried creating my own solution but with low success because I didn't have exact offset of the first image I had decoded.

After teaming up with RenanSPH, who knows much more about disassembling than I do, he found the instructions that copy the data and pass to the GDI to be paint on screen. ... read more

We have created a wiki specially for decoding the original data,
It explains memory data structures, known constant pointers and file format structures.

Do not forget to enjoy the sauce: https://sourceforge.net/p/opendeadlock/decode-wiki/.

Hello everybody!

This is the Decoding Project Blog.

We will be posting news about how the Deadlock series decoding project started and how it advances.

If you are interested, consider reading related information at http://forum.galliusiv.com/.