I will gladly accept your repackaged version of FreeDOOM and add it to
the FDNPKG repository (as well as any other packages that might be
contributed by willing volunteers) :)
About packaging - I still have to think about modifying the packaging
style for FreeDOS packages, to make it possible to use customizeable
paths for installing packages, but anyway - when it will change,
repackaging stuff to fit into the 'new packages' format should be easy.
About cheating with 7z - I personally think it's better to stick with
the default zip archive. If a user installs the FreeDoom packages, it's
probably because he wants to play right away. Also, Doing a 'package
into the package' would make it impossible for FDNPKG to uninstall the
game properly later (because it would try to remove a possibly
non-existing-anymore 7z file, while in the meantime there appeared other
files from the extracted archive).
On 10/14/2012 11:02 PM, Rugxulo wrote:
> On Sun, Oct 14, 2012 at 6:26 AM, Mateusz Viste <mate...@viste-family.net>
>>> I saw this, but I can already tell some of it needs updating, e.g.
>> I'm not a big expert on Doom, and available ports or forks today.. I
>> think that I simply took the FD 1.0 package on this one. :)
> I'm far from a Doom expert, nor that heavy a gamer, just average (and
> only barely these days). But I'm willing to (re)package newer FreeDoom
> + Eternity for you, presumably later this week.
> Boom was the (eventually GPL'd) DOS "bugfixes and no limits"
> improvement of Doom from way back in 1999 or such. It used Allegro 3.0
> and old GCC tools (and hence needs some heavy tweaks for modern
> versions, which I never bothered trying to understand).
> FreeDoom (now at 0.8-beta1, as of May 2012) is a BSD-licensed set of
> levels for the Doom (actually Boom-compatible) engines. Their download
> page lists two engines as supporting DOS: Boom and Eternity.
> Unfortunately, Eternity hasn't supported DOS since like 2004 or such,
> and the new rendering engine / backend is DOS incompatible, so
> basically it won't support DOS "unless some backports it". And Boom,
> of course, is old and abandoned since over ten years ago. (EDIT: I
> don't think Vavoom [slow, abandoned] nor ZDoom are preferable here
> either, for various reasons that I can't remember.)
> I think Boom was forked several times. I can't remember exactly, but
> it's something like SMMU then Eternity succeeded it. Can't remember
> how much (if any) others borrowed code. CDoom is fairly minimal and
> small (and only 320x200 VGA, i.e. only one I found that runs under XP)
> but uses a different music library (MUSLIB or some such).
> All of these (ironically enough) use DJGPP and Allegro for the DOS
> ports. I don't know of any supporting OpenWatcom. And no DOS-based
> Doom engine is still maintained, sadly, at least none that I know of.
> Even Allegro has dropped DOS support in latest 5.x versions, esp. due
> to no developers being interested and the switch to CMake (which we
> don't have ported anyways). Most of these ports use "old" Allegro 3.x,
> either 3.0 or 3.1, which is back when it was DOS-only (I think). I
> can't remember, but I think 3.1 by default supported vbeaf.drv and
> patches.dat (unlike 3.0 proper which only supported the latter by
> default). Not really a huge issue except for certain old machines,
> where it might run a little better.
> Like I said, I have (for fun) occasionally rebuilt some of these
> engines, but even Eternity was hard to find and lacked a proper DOS
> makefile. Even then, when recompiling, it sometimes had some rare
> audio bugs. And Legacy isn't Boom compatible enough as that one (old?)
> level didn't work properly (switch didn't raise the bridge, so it was
> unplayable at that point without cheating).
> Anyways, FreeDoom has had a lot of updates over the years, especially
> since 2006, and they've removed some copyrighted files that had
> conflicting license or dubious origin, so updating would be especially
> nice for purists. However, it's fairly large. Would it be better to
> offer the equivalent of the (smaller) "shareware" .WAD in downloads in
> lieu of larger "full" .WAD version? Or should we cheat and just 7-Zip
> / .7z it and put *that* inside the main .ZIP? ;-)
> P.S. Mateusz, are you aware of the DJGPP package manager Pakke
> (formerly Zippo)? I've never tried that, but apparently it tried to
> support a similar thing (though the maintainer, Richard Dawe, gave up
> on DJGPP many moons ago and I'm not aware of anyone actively using
> Pakke for updating).
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> Freedos-user mailing list
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
Freedos-user mailing list