ZDuke: The Lost Port (Aka an effort for preservation)

[Redneckerz]

Now that's a nice surprise.

What's really interesting here is that the menu code, despite the same brute force switch/case approach that can be witnessed everywhere in the Duke Nukem source, is rather straightforward and actually readable. Now I really have to wonder who turned that into the utter monstrosity that can be seen in recent EDuke versions and that had me stumped several times while wading through it. That code is on a level that far eclipses the "The menu code sucks" comment which ZDoom's old code once received.

In hindsight it makes sense, EDuke's menu code has little in common with the rest of the engine. The same is true with most other parts of the game I found most problematic - this code has none of that extreme clusterfuck-style coding, it's primitive and suboptimal for sure, but mostly readable, comparable with the Shadow Warrior menu code in terms of quality. Something must have gone extremely wrong with the follow-up development after the source release, and all evidence points to JFDuke being the one having messed things up.

Perhaps the Duke3D community can take a look at it or perhaps get some inspiration from it. Judging from the archive, it is released under GNU GPL, so perhaps it might be beneficial for eDuke32 and other ports to look at.

PS:
I just downloaded the source, but when unzipping it through WinRAR it throws up almost 200 errors and all files are 0 kilobyte. This has to be extracted with 7-Zip itself, as that gives the correct output.

Serves you right for using WinRAR!

First time WinRAR threw the towel in the corner, so who is actually to blame here? I am just going to write it off to an old version of the archiver being used that WinRAR does not seem to like. Fortunately a portable 7-Zip installation does the job.

[Graf Zahl]

Perhaps the Duke3D community can take a look at it or perhaps get some inspiration from it. Judging from the archive, it is released under GNU GPL, so perhaps it might be beneficial for eDuke32 and other ports to look at.

Doubtful. Remember - this is mostly the original state of the code. EDuke is so heavily dependent on the changes made by JFDuke it cannot go back to the roots - feature wise it wouldn't make any sense. The main problem is - JFDuke, while adding cool stuff, hasn't done the code quality any favor. And when you think about it, the transition from JFDuke to EDuke32 was 13 years ago - and in all that time nobody ever thought about refactoring the problem spots, the main addition was more and more scripting crutches that make the engine infinitely hard to handle these days.

[jdredalert]

I know it's probably too early for this since the source code has just resurfaced, but is it too much to dream with another take on ZDuke, development wise?

[Graf Zahl]

This code? No chance. It's simply too old. Remember: Despite the misgivings I have with the direction Build ports took, it has been 16 years in which development has not stood still.

The only thing of real interest is that this features a basic port of the sound system to FMod. EDuke and all its child ports still use a primitive homegrown 2D sound mixer, so for an eventual migration off that thing there may be some pointers in here how to do it. Beyond that - nah. It got no hardware renderer - not even Polymost, the renderer is still dependent on the assembly code, meaning it's deadlocked to 32 bit (The original Build code happily used integers to store pointers with reckless abandon - trying and fixing these would be a major chore all by itself) and possibly several other gotchas. It's an historical anecdote that has seen 6 weeks of work by Randi - the included log starts at April 12th and ends at May 20th, 2003.

[Blzut3]

Ill have to thank Rachael then for backing up that file way back in 2007 as it seems.

Don't read so much into file dates. It was just uploaded. I'm not sure what that 2007 date is, I would say "when these forums switched to phpBB 3.0" but I don't think we used beta versions of phpBB?

In general worth noting that Linux cares a lot less about preserving file dates than DOS/Windows, so unless a date seems right don't read into it.

Also, assuming you took a dive in the Source archive, where did you find that June 21 date?

Build engine asm file. There are a few other files dated in June.

First time WinRAR threw the towel in the corner, so who is actually to blame here? I am just going to write it off to an old version of the archiver being used that WinRAR does not seem to like. Fortunately a portable 7-Zip installation does the job.

Definitely WinRAR. Sorry, I've had too many people think it's acceptable to send me a rar file and made my life more difficult. When you have a public domain compression algorithm that achieves similar ratios (LZMA) I have no idea why people insist on using the proprietary one. (I'm going to assume Graf hates WinRAR for similar reasons but I can't speak for him.)

I don't even know what people find so great about the WinRAR file manager either (compared to all the other tools available anyway).

[Graf Zahl]

Definitely WinRAR. Sorry, I've had too many people think it's acceptable to send me a rar file and made my life more difficult. When you have a public domain compression algorithm that achieves similar ratios (LZMA) I have no idea why people insist on using the proprietary one. (I'm going to assume Graf hates WinRAR for similar reasons but I can't speak for him.)

I don't even know what people find so great about the WinRAR file manager either (compared to all the other tools available anyway).

I don't like WinRAR because that company still feels entitled to charge money for a compression algorithm. My second gripe is that this is essentially the format most warez come in. No, definitely not my format of choice. 7zip is by far the best unarchiver out there and the only one I've been using for more than 10 years now. Why pay for something that has better free alternatives?
Very much the same applies to other commercial archiving tools.

[Rachael]

I think the WinRAR versus 7-zip debacle can be equated to say, Cinema 4D versus Blender.

Most of the time it comes down to comfort of use - even though 7-zip and Blender are clearly superior to their respective counterparts in this comparison, the proprietary tools might have either an easier interface to use, or at least one that its users are more comfortable with.

Even still though - 7-zip is just an archiver - nothing more. There's nothing intimidating about its user interface and I was up and running with it and figured the thing out within minutes. I'm sure less tech-savvy folks can figure the darned thing out within a day or two, at most.

[jdredalert]

This code? No chance. It's simply too old. Remember: Despite the misgivings I have with the direction Build ports took, it has been 16 years in which development has not stood still.

The only thing of real interest is that this features a basic port of the sound system to FMod. EDuke and all its child ports still use a primitive homegrown 2D sound mixer, so for an eventual migration off that thing there may be some pointers in here how to do it. Beyond that - nah. It got no hardware renderer - not even Polymost, the renderer is still dependent on the assembly code, meaning it's deadlocked to 32 bit (The original Build code happily used integers to store pointers with reckless abandon - trying and fixing these would be a major chore all by itself) and possibly several other gotchas. It's an historical anecdote that has seen 6 weeks of work by Randi - the included log starts at April 12th and ends at May 20th, 2003.

Well, shame. But i was expecting that, specially after that thread about a GZDoom-like engine for Build and the George.txt file that describes how much of a pain was to work with Silverman's code. Now this is just out of curiosity, but let's say someone starts to work on the ZDuke code, how doable would be adding Duke-oriented Decorate lump to it? I think the greatest strength of the ZDoom family is how easy it is to make mods for it. In a hypothetical scenario were someone decides to make ZDuke into something more than just a piece of history, would that be even possible?

[Rachael]

It is possible, yes. How much work it actually is remains to be seen, though. I've personally worked with Ken Silverman's code, myself, and the reputation it gets is well earned. Say what you will about the Doom source code - but from what I can see Carmack went out of his way to make it readable and easy to understand. Despite the spaghetti-ness of it (which makes it really messy to add features to, especially in the renderer worst of all), it is still a lot easier to work with than Ken's. I actually used Carmack's code to help me learn C.

And let the results speak for itself: Hundreds upon hundreds of people have worked with both Carmack and Silverman's code. Look where we are with Doom ports versus Build ports. When that many people have played with the code and done the things they have to it - ultimately we have GZDoom, Eternity, EDGE, and Vavoom from Carmack's code, and we have EDuke32, BloodGDX, and a few others with Build engine code. Comparatively, all the Doom engines I listed I think are more advanced than any of the Build engines I have ever seen, with EDuke32 seeming to show the most promise. In my opinion, that speaks volumes about how readable Ken's code is.

I'm not going to join the hate brigade and say Ken Silverman is a bad coder. He very obviously isn't. It's just that his methods did not mesh well with the idea of collaboration, and I honestly doubt even he could work with that code today, unless he's been playing with it himself very frequently in the past 2 decades.

[Graf Zahl]

but let's say someone starts to work on the ZDuke code, how doable would be adding Duke-oriented Decorate lump to it? I think the greatest strength of the ZDoom family is how easy it is to make mods for it. In a hypothetical scenario were someone decides to make ZDuke into something more than just a piece of history, would that be even possible?

Aside from the fact that I'd recommend anyone to try to work on a Duke Nukem port take at least RedNukem as a base rather than this, Duke Nukem's actor system is a nut I haven't cracked yet. All related code is endless switch/case blocks with no decent structure of code ownership. I'm afraid but I think that the best that could probably be done is CON v2 with a better syntax. It cannot be refactored due to the shitty scripting language coming with it that needs to be kept working.

[Redneckerz]

Doubtful. Remember - this is mostly the original state of the code. EDuke is so heavily dependent on the changes made by JFDuke it cannot go back to the roots - feature wise it wouldn't make any sense. The main problem is - JFDuke, while adding cool stuff, hasn't done the code quality any favor. And when you think about it, the transition from JFDuke to EDuke32 was 13 years ago - and in all that time nobody ever thought about refactoring the problem spots, the main addition was more and more scripting crutches that make the engine infinitely hard to handle these days.

I was thinking along the lines of the start up code and the menu system - Though, admittely, stuff like that would also exist in ZDoom itself already.

I know it's probably too early for this since the source code has just resurfaced, but is it too much to dream with another take on ZDuke, development wise?

I can't see that happening honestly.There is way too much exit points inbetween the Doom core and the Build core for it to handle, let alone that both pieces of code are designed around a vastly different design philosophy. In Build's case that would be convoluted given who made it. Its amazing that it works considering, but in terms of third party friendlyness, everyone, including Duke members, would have to agree that the Doom engine has a better position here.

Note that i am not talking about modding, but rather reading the code and applying improvements on it.

What could be interesting but which isn't present in ZDuke is fulfilling a full grown Polymost implementation so ZDoom gains true 3D rendering support. But likewise, history gives a good reason why that never came to full fruition.

This code? No chance. It's simply too old. Remember: Despite the misgivings I have with the direction Build ports took, it has been 16 years in which development has not stood still.

The only thing of real interest is that this features a basic port of the sound system to FMod. EDuke and all its child ports still use a primitive homegrown 2D sound mixer, so for an eventual migration off that thing there may be some pointers in here how to do it. Beyond that - nah.

Indeed. At best, it provides a glimpse of what one could use - Even using code out of the source you would definitely need to spice it up modern standards. Nevertheless, it remains an interesting piece of code for various reasons and most importantly, the option now exists to examine, learn or experiment with it.

Which is more than anyone ever could ask for in the first place, its a novelty port in the ZDoom/Build history tree after all.

Don't read so much into file dates. It was just uploaded. I'm not sure what that 2007 date is, I would say "when these forums switched to phpBB 3.0" but I don't think we used beta versions of phpBB?
Build engine asm file. There are a few other files dated in June.

Noted, it was just a passing mention, nothing more.
Regarding the second bit: Interesting, i just went off by the logs initially. I guess it saw some look ups then, but obviously, nothing significant.

Definitely WinRAR. Sorry, I've had too many people think it's acceptable to send me a rar file and made my life more difficult. When you have a public domain compression algorithm that achieves similar ratios (LZMA) I have no idea why people insist on using the proprietary one. (I'm going to assume Graf hates WinRAR for similar reasons but I can't speak for him.)

I don't even know what people find so great about the WinRAR file manager either (compared to all the other tools available anyway).

Can't provide you a proper answer there. I am just a user of the program, not someone that works with compression methods and all. And for that job, it is sufficient (Else why would you sell it in the first place). Developers, such as yourself and Graf will have a different perspective of it, i am just saying, here i am the consumer's POV.

Well, shame. But i was expecting that, specially after that thread about a GZDoom-like engine for Build and the George.txt file that describes how much of a pain was to work with Silverman's code. Now this is just out of curiosity,but let's say someone starts to work on the ZDuke code, how doable would be adding Duke-oriented Decorate lump to it? I think the greatest strength of the ZDoom family is how easy it is to make mods for it. In a hypothetical scenario were someone decides to make ZDuke into something more than just a piece of history, would that be even possible?

The question should rather be why you would use such old code for that. I would rather backport whatever is useful to either a Duke based source port, or grab a more recent zDoom build and work from there.

Something like what you are suggesting would/could be in the same realm as Randi's Polymost integration - Experimental, for sure, and perhaps someone may find a use out of it, but ultimately, it would be a case of ''How much additional work will this non related to DOOM code cost me?''.

Ultimately, i would rather wager, perhaps Team Build should first look at other things from ZDoom to implement in their own code - Be as it may, ZDoom's code is rather universally better to read than the spaghetti code of Build, though ofcourse veterans may have implemented their own features to it.

Even me as a non-programmer (But with knowledge of how things work) can read ZDoom code better than Build code, and that's not even without the commentary that's added in. If Dr.Smallbrains can read it, then i am fairly certain any Build dev can.

EDIT: Catch-22: Basically Rachael is saying the same thing as i do, to the point of calling it ''spaghetti''
To add to that: Nowhere will i say Ken is a shitty programmer - Far from it. Nor will i say anything bad on his release policies as he includes sources for everything. And i do think it would be interesting to look at code from his other engines (Polytex, Kenvex, Cubes5 and Voxlap) but, assuming Build 2 is equally spaghetti (As noted by Graf), i would expect similar there.

Silverman was and is a brilliant coder, but as the George.txt mentions, Silverman has little affinity with system design and coherency.

[Graf Zahl]

I'm not going to join the hate brigade and say Ken Silverman is a bad coder. He very obviously isn't. It's just that his methods did not mesh well with the idea of collaboration, and I honestly doubt even he could work with that code today, unless he's been playing with it himself very frequently in the past 2 decades.

The main issue with Ken Silverman's code is one typical 90's programmer's fallacy, i.e. it was the machine that mattered not the programmer or the game developers having to work with his code. Back then I have written similar code, mostly by necessity, though. With Silverman I have the feeling that this matched his way of approaching problems which makes the result so much worse.
He also did the second thing popular back then - working on a static set of global variables that were used to pass state around through the code.

Back then it was probably necessary and here it's the follow-up programmers I mostly blame for not refactoring this stuff out. Yes, it'd be a lot of hard work but shouldn't be dismissed for faster turnaround times. In the long run it will always backfire.

[Graf Zahl]

What could be interesting but which isn't present in ZDuke is fulfilling a full grown Polymost implementation so ZDoom gains true 3D rendering support. But likewise, history gives a good reason why that never came to full fruition.

Forget Polymost. Its throughput is 1/10th of what GZDoom's hardware renderer manages, and that still doesn't render a single pixel. dpJudas's software rasterizer for GZDoom's hardware renderer is far more promising because it doesn't depend on such inefficient setup code. Poly most is as much a relic of its time as the ZDuke source. It performs the entire polygon clipping and projection in software and only sends the fully processed polygon to the hardware instead of actually using the hardware to do this stuff. Back in 2004 this made things faster, but today it's heavy baggage dragging the engine down.

[Redneckerz]

What could be interesting but which isn't present in ZDuke is fulfilling a full grown Polymost implementation so ZDoom gains true 3D rendering support. But likewise, history gives a good reason why that never came to full fruition.

Forget Polymost. Its throughput is 1/10th of what GZDoom's hardware renderer manages, and that still doesn't render a single pixel. dpJudas's software rasterizer for GZDoom's hardware renderer is far more promising because it doesn't depend on such inefficient setup code. Poly most is as much a relic of its time as the ZDuke source. It performs the entire polygon clipping and projection in software and only sends the fully processed polygon to the hardware instead of actually using the hardware to do this stuff. Back in 2004 this made things faster, but today it's heavy baggage dragging the engine down.

I forgot about dpjudas's work on this that would indeed be a better replacement (And more feature-rich, too).

Thanks for the reminder Graf.

[drfrag]

I am rather sad that it now spits out an error that DirectDraw returned no display modes, so it doesn't get very far during the startup process.

Thanks for sharing, it's always nice to have a piece of history recovered. I succesfully managed to run ancient ZDoom versions on win 8.1 using DXGL.
Edit: for me it extracts fine with winrar. 7Zip has a better algorithm but Winrar's UI is better, you can't even add files to an archive from the UI.