Use of DCC decoder in DGEngine

Hi there,

First of all, this is a really nice project.

I'm the author of DGEngine (https://github.com/dgengin/DGEngine). I used your DCC decoder (not yet committed) and would like to add it to DGEngine. I also merged some other classes that were used and removed others I had an alternative to in DGEngine. Your code would be in a cpp/h file.

I would like to know if it's OK to do so and if I can keep using the ZLib license, since your project uses GPL which is incompatible.

Regards,
DGEngine author

[Lectem]

Hi, thanks for asking !
I would be genuinely be interested to know if you considered using WorldStone as a library ?
I'm asking this to know what made you choose integrating it by modifying it and not linking it as a library.
I would very much like to know if there are some design decisions I took (or didn't take) that made you take this choice.

• Is WorldStone too hard to integrate ? (API not easy, too restrictive ?)
• Is it too big ?
• Is it pulling too many dependencies ?

If this is a problem, I could try and change this, as I would like to make it easier for people to link against the decoders. (Seeing that I don't have that much free time, WorldStone become more of a place where I write file formats informations than an engine)

I wouldn't mind changing it to be LGPL in that case.
Another reason I'm asking is that this way it might also make it easier for you to update in the future if I make some fixes or update some fields.

Note that I stay open for discussion about re-licensing, but I'm first and foremost interested in answers to the above questions.

[Lectem]

Oh and I'm also a bit curious as to why you want to be able to read .dcc files for a Diablo1 engine :)

DGEngine started as a Diablo 1 game engine, but the goal is to have it generic enough to run other games (similar to Diablo, but not to run them 100% like they run from retail) and use other game's assets, given the appropriate game files.

If you browse the code, you can see it can curently load assets from Diablo (CEL/CL2) and Flare (PNG images). In fact, it currently renders Flare's maps (which are a bit different than Diablo's) as in the latest version of Flare, including parallax layers (to simulate rain, snow, fog, etc). It can also load and render players using flare's images.

Loading DC6/DCC game assets is the logical next step. The reason being that people could mix and match game assets from Diablo 1 and 2. DC6 and DCC files are basically image archives, like CEL/CL2 files. I did those in DGEngine abstracted away inside an ImageContainer interface (which has been slightly modified to spit out offsets for DC6/DCC) and that's why I made a stripped down version from Worldstone.

There's a playground project in the repo that shows Diablo and Flare game assets being mixed together here: https://github.com/dgengin/DGEngine/tree/master/gamefilesdex
It's simply Diablo, but the map is done differently (smaller, in the corner) and you can load flare maps and diablo maps in the same game.

Here's what I currently have from Diablo 2:

Most Diablo and Diablo 2 projects I saw try to recreate the engine in a way that doesn't modify the original game's assets (ex: loading strings from TBL files instead of using something else). This makes it harder to progress since you end up wasting too much time recreating the original engine. DGEngine does it so that you only really need the images/palettes/sounds from the games. Everything else is JSON files. CEL/DCC/PNG are just images and/or image packs. If I want to write a string in DGEngine, I need a font, which uses a texture. The texture can come from any image format (CEL/PCX/DC6). The code that draws the font is the same one used for Diablo/Flare/Diablo 2 and the text that's diaplayed is a JSON property in a "text" element.

Adding DC6/DCC to DGEngine allows me to load all of Diablo 2's game assets, except for tiles/maps and leverage what I already wrote for Diablo/Flare (fonts, players, levels, spells, items, menus, scrolling texts, etc).

I'm using these from your project:

ImageView
SimpleImageProvider
AABB
BitStreamView

I use PhysFSStream instead of your stream class and I modified the above to remove what I didn't need. I wanted to write it so that I didn't have to decode the whole direction to get a frame, but I don't think I can do it for DCC files because of how they work - I did so for DC6.

I've isolated these classes (and merged them) into a singe file (the cpp file). This is what I have right now in the header file:

#pragma once

#include <cstdint>
#include "ImageContainer.h"
#include <string_view>
#include <vector>

class DCCImageContainer : public ImageContainer
{
private:
	std::vector<uint8_t> fileData;
	uint32_t numberOfFrames{ 0 };
	uint32_t directions{ 0 };
	uint32_t framesPerDir{ 0 };

	/** Offset of each direction header in the file, follows the @ref Header.
	 * Actually holds directions+1 values, the last one being the size of the file
	 * It lets us compute the size of a direction by substracting the next offset by the current
	 * one.
	 */
	std::vector<uint32_t> directionsOffsets;
	std::vector<uint32_t> framePointers;

public:
	DCCImageContainer(const std::string_view fileName);

	virtual sf::Image2 get(size_t index,
		const PaletteArray* palette, sf::Vector2f& offset) const;

	virtual size_t size() const noexcept { return numberOfFrames; }
};

you can see the structs to decode the file aren't in the header now.

I used Worldstone's implementation because I found it to be the easiest to integrate into DGEngine, similar to how I used savagesteel's CEL/CL2 decoding algorithm (which I also found easy enough to integrate): https://github.com/savagesteel/d1-graphics-tool

Linking it as a library would be too much. for instance, you did a great job with D2's Palettes, but I'll do it differently for DGEngine. I'll load a png image with all the adjusted palletes and use an index to select the right one, so I wouldn't be using what you did to decode palettes.

The license doesn't really bother me, but I'm using snippets (like the algorithm to calculate the fon't letter spacing - not really used since I'm loading the letter spaces from bin files for both D1 and D2) from a few other projects and some aren't compatible with GPL.

[Lectem]

Sorry for the delay,
I asked a bit around, and the only way to maintain my code under (L)GPL while authorizing you to use it would be either for your to use it as a library, or me to provide an explicit authorization just for your repository.
That would mean nobody can fork it, or that I must allow forks wich mean basically allow any copy of my code through your codebase.

So it looks like to me the easiest would be:

• Use it as a library (it only requires me to put it under LGPL, and you to mention it + make a shared library out of the .cpp)
• Use another DCC decoder such as Paul Siramy's http://paul.siramy.free.fr/_divers3/MergeDCCv2_sources.zip

How about if I dual license DGEngine and use a CMake define to determine whether or not to use DCC decoding. If it's set, then DGEngine is licensed as GPL with DCC support. If not, then it's licensed as zlib without DCC support.

Hi Lectem,

I'm almost ready for the next release. I've modified my CMake to only include the decoders if a flag is set and am planning to change the license as I described above.

If you have any objections with that, let me know. I can always change things afterwards.

Regards,
DGEngine author

[Lectem]

Sorry, I've been quite busy lately and forgot to answer.
I'm ok with the flag option, it seems like a decent option to me ! (and used by other software such as ffmpeg?).