KHkhedoros1·Oct 15, 2017
> I think this comes down to a particular design decision of the GBA homebrew SDK (https://github.com/devkitPro/libgba) to not be ABI-compatible with the official SDK.
I think it comes down to the fact of SDK libraries being statically, and inextricably, linked into the ROM.
> [about DF2:JK] I would say that this is open-source, yes.
I'd say it isn't. First, the license is just as closed as the rest of the code. Second, it's not "the game" unless there's an engine to pair the data+code elements with. And since there's no open engine to go with the closed-but-readable code, I wouldn't use the words "open source" with any part of it.
> So this is at least open-source code now, no?
If an open engine is available, then the combination of the open game logic and open game engine would be open. Otherwise you could say "An Open engine for X" or.
Read the rest
..well, a nicely-packaged way to describe open game assets on a closed engine would be called "a mod for X" or a "total conversion", I suppose.
> But does that make the .wad file itself less open as a product?
The .wad itself could be open, but it's not "a game". It's a set of game assets. Pair it with an engine, and it's a game. Pair it with a different engine, and the same assets might be a significantly different game. The whole wad+engine game couldn't be open until at least late 1997 when the Doom source was released.
> But with C#, you don't expect that; you just expect to receive the binary containing the individual business logic, and then use the runtime library you have available (Microsoft's on Windows; Mono everywhere else) to run it.
Right. C#, Java, etc are expected to have an external, completely separate runtime as a dependency. When there isn't an open runtime available, it's the situation that used to be called something like "the Java trap".