[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Freenukum game data

Am 07.11.22 um 10:37 schrieb Simon McVittie:

On Mon, 07 Nov 2022 at 08:43:25 +0100, Wolfgang Silbermayr wrote:

It also extracts all files in lowercase, haven't looked at what GDP does.
Currently, FreeNukum can only load these, although I intend to change that


[...]


Teaching your engine to be able to load files case-insensitively would
be nicer for people who have copied the data directory from a Windows
installation without using a special tool, though.
That would be my preferred way, as it imposes less requirements on the input files, thus being more robust. 


You pointing me to GDP got me thinking that I might want to find a different
solution for this, always just having the extracted original data on disk,
and not requiring it to be converted to the well-known formats already.


[...]


It's fine to have converted versions on-disk *alongside* the originals
as an optimization, or for the benefit of an engine that doesn't know
how to load the originals - if necessary, g-d-p can run imperative code
to convert or edit them, on a "write-only" basis.
game_data_packager/games/lgeneral.py is an example of this.
That's an interesting feature, but I would only want to use it in case there are performance or memory problems that would require such a measure. The original data is very small (~1M for each original episode, graphics are not compressed). I'd rather teach the engine to load both the original as well as "modern" (as in current well-known formats) data. 


I'm currently in the process of migrating FreeNukum to the Bevy engine. The
fact that files of different types have the same suffix (.dn1, .dn2 or .dn3,
but the same for graphics, sound and level data), caused some issues there,
as Bevy can only register one asset loader per suffix


g-d-p can rename files if necessary, and can look for source files under
more than one name, although the syntax for that is relatively verbose
so you wouldn't want to use it for more than a few files.
As mentioned above, I'd rather make the loading more robust instead of imposing requirements on the data, especially because that doesn't scale well over multiple distros and operating systems, just as you mention below. 


Again, if you can teach your engine to be able to load the original files
without modification, that would make it easier for people who have copied
a Windows installation without using a special tool.


My long-term vision is to have free assets for FreeNukum as well, so that
the game can be played without requiring any proprietary data.


That game wouldn't be Duke Nukem, it would be a different game that
happens to have Duke-Nukem-like gameplay and share an engine - similar
to the relationship between Quake III Arena and OpenArena. The way we
generally represent that is to have a free engine (packaged directly in
main or contrib), a package representing the free game that depends on the
engine (packaged directly in main or non-free depending on licensing),
and a parallel g-d-p-generated package representing the original game
that also depends on the engine (non-redistributable), so that you can
install either or both of the two games.
To be fair, FreeNukum isn't Duke Nukem 1, and never has been, it has always been a different piece of software that is able to load the original files. The idea is to just have different asset loading functionality, all the rest (game mechanics etc) would be run by the same code.
I'd love to have FreeNukum packaged for Debian some day, but it's not ready yet. Having transitioned to Bevy, and being able to play the original game data start to end is imho the bare minimum for that, and right now the final enemy doesn't even appear in the game yet, so no possibility to finish. :-)
Reply to: