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

[Graf Zahl]

You still do not understand. ZDuke is not a ZDoom fork to play Duke Nukem, it's the original Duke Nukem source planted on top of the low level Windows system code in ZDoom - nothing more, nothing less. It has no Doom code and cannot play Doom content at all, and it's also nothing magical. It's just a barebones Duke Nukem port with no bells 'n whistles.
That's why nobody really cared when its source was lost. There's other projects out there which have taken the game a lot further.

[Redneckerz]

You still do not understand. ZDuke is not a ZDoom fork to play Duke Nukem, it's the original Duke Nukem source planted on top of the low level Windows system code in ZDoom - nothing more, nothing less

No, that's actually what i quite get, in fact . I never postulated the ability to play Duke, rather that it can load Build maps (As what Blzut says).

It has no Doom code and cannot play Doom content at all, and it's also nothing magical. It's just a barebones Duke Nukem port with no bells 'n whistles.

Understood. But previously this was considered lost (Well, the compiled build and source it is) and now there is this. So that's an win in my book, even though its only interesting for a select few (But i never argued otherwise obviously)

That's why nobody really cared when its source was lost. There's other projects out there which have taken the game a lot further.

Enjay seemed to care back in 2004: viewtopic.php?p=55681#p55681

I get what you are saying though. And i like to reiterate - I never expected anything to the point of playability considering a lot of ports have gone way further. I saw and see ZDuke as a little experiment with Build thinkings that got one or two compiled builds before this was abandoned and Randi would start incorporate Build code into ZDoom such as a loader and Polymost support (2.0.97).

I think all is researched enough now. Now what remains is if the Wiki entry should be edited to reflect this.

[Blzut3]

This is very interesting to read. So this is indeed the ZDuke port that got lost over time if i read you correctly.

Yes.

I understand its not a port that runs Duke content, but it can open its data files. That code has existed for a long time, but not as a seperate build which is what ZDuke is (If i read you correctly.)

No, that's actually what i quite get, in fact . I never postulated the ability to play Duke, rather that it can load Build maps (As what Blzut says).

Your use of pronouns (or rather switching between the two projects implicitly within the same paragraph) is what's confusing Graf and I here. I think you are understanding correctly (based on the end of the latter post), but to be clear at some point in the ZDoom 2.0.x series the ability to load build maps and art was added. This is independent from ZDuke, which absolutely can play Duke.

Regarding the bolded: Are you referring to the official source Randi released in 2009 and which was based on ZDoom 2.0.48 which indeed seems lost to time?

Correct.

So its some kind of hybrid thing. Is there any idea you may have why Fmod threw up the error that i posted? Considering it works on your XP machine, id love to load a build map and see what happens.

I would hesitate to call ZDuke a hybrid since doing so would be like saying every game that uses SDL is a hybrid of SDL and whatever game. Technically it's probably correct by the literal definition of the word, but it implies a lot more than "layer that fits between the OS and the game."

Based on the dates you gave for the files you tried I'm going to assume you didn't get fmod.dll from ZDoom 2.0.43?

So what should we do with this?

I've updated the wiki page to note that the 2.0.43 build exists and that "allegedly" the svn code drop was newer. I mean it's likely Randi did work on ZDuke a little longer, but I feel it's best to note that we have no poof.

Well, atleast one person (myself) got fooled by this, so perhaps this can be added?

One step ahead of you.

There is at least one other ZDoom release that seems to have existed (2.0.47q) but all that's left of it appears to be a diff from that version to 48. Randi was releasing quite rapidly at the time, probably because ZDoom wasn't in (public at least) version control at the time.

[Kinsie]

Yeah, GZDoom can load BUILD-engine assets just fine. Or it used to, at any rate. When I was converting BUILD map geometry for a Deathmatch Simulator map I used Zandronum 3.0 since it worked there and still had the "dumpmap" command to convert the geometry to Doom in Hexen format.

[Graf Zahl]

The Build map loader was removed because at some time it broke and there was little point fixing it as the map weren't playable.
What the engine can do is load Build texture sets and provide the ability to use them for mapping.

[Redneckerz]

Blzut, may i thank you once more in advance for testing and confirming these things aswell as clarifying aswell as putting up an edit in the Wiki entry? I do hope this did not take too much of your precious time.

Now, on to the post. I hope being very lengthy on this post is not an issue considering the nature of this topic: Stuff like this is often in the details and i rather provide a lengthy, but correct response than a short, but erroneous reply.

Yes.

Great stuff. Then the target goal of this topic (Preservation and confirmation that it is ZDuke) has been achieved. Thank you in particular for aiding in this

Your use of pronouns (or rather switching between the two projects implicitly within the same paragraph) is what's confusing Graf and I here. I think you are understanding correctly (based on the end of the latter post), but to be clear at some point in the ZDoom 2.0.x series the ability to load build maps and art was added. This is independent from ZDuke, which absolutely can play Duke.

Yes, i apologize for the confusion in my part. This is occurring because reading back posts by randi in the past make things rather complicated. To name one example: There is one post that implicate another port/version but then based on ZDoom itself but nothing is clarified on what this means. I like to think Randi mean't to refer to the builds that would add Build loading support (which was earlier than anything of this) or Polymost support (So 2.0.95/97) so if i am mixing things together or say one thing but i mean the other, this is likely the culprit.

Again, apologies to both you and Graf for unintentionally confuse the both of you, and to myself for confusing myself aswell in the process.

So to summarize:

• - The ZDuke version discussed here in this topic: A now confirmed ''new'' (In brackets, as i am trying to say its merely rediscovered) version of ZDuke, uploaded by Randi in 2003, based off of 2.0.43. Besides the fact that few people care about this and never bothered with it, this release was also distinguished by the fact that it was labeled duke3d.cab, and was not explictly mentioned by Randi in the post as ZDuke, so when the ZDuke wiki entry was made, it can therefore be assumed that this particular thread never was checked because there was very little to indicate it was ZDuke in the first place. I just happened to stumble upon this during research in a lucky case of coincidence. This is a Duke 3D sourceport that cannot run Doom whatsoever, and just uses ZDoom start up code among other things. It is supposed to play Duke Nukem 3D only and thus by doing so distinguishes it from the later, 2004/2005 experiments to extend the already existing Build map loader with display/Polymost code.
  - The ZDuke SVN 2009 version: This is the one considered lost, uploaded by Randi in 2009 and based off of 2.0.48. This is a Duke 3D sourceport that cannot run Doom whatsoever, and just uses ZDoom start up code among other things. It is supposed to play Duke Nukem 3D only and thus by doing so distinguishes it from the later, 2004/2005 experiments to extend the already existing Build map loader with display/Polymost code.
  - ZDoom 2.0 beta 13: The build where Randi added a Build map loader. I believe part of the confusion stems from the fact that this is from August 2002, over a year before ZDuke even became a thing. So it would not have been odd to assume ZDuke was basically a ZDoom compile but with only this loader working. Like i said, convoluted stuff.
  - ZDoom 2.0.95/97: Randi's December 2004 to February 2005 experiments to add Build map loading support and Polymost code to the ZDoom codebase. This remained available in code till 2014 when it was removed. This is not a Duke 3D sourceport, but rather a Doom engine with code to load up and display Build maps in wireframe or solid color modes.

I think this should correct my prior confusion i believe. Please feel free to correct me otherwise.

EDIT: Version history details that Polymost code got removed at version 2.8.0 in 2016, (https://zdoom.org/wiki/ZDoom_version_history#2.8.0) but the Wiki entry details it was removed in 2014: https://zdoom.org/wiki/Polymost. I assume it was disabled in 2014 but removed in 2016? Basically a phrasing issue at best perhaps, or some release note confusion in the worst part?

Correct.

Then we can reasonably assume that it (This build) is similar in featureset, perhaps slightly buggier as compared to the SVN build. Since that got lost, we can't detail what the improvements between the two may have been without asking Randi directly. Unless a code scholar is interested in wanting to know the differences between the two, i'd consider that another layer of detail that seems unneeded at this point in time considering the effort that is needed for it (bothering/asking Randi about this).

Based on the dates you gave for the files you tried I'm going to assume you didn't get fmod.dll from ZDoom 2.0.43?

That is correct. I was not yet aware of 2.0.43 downloads until you mentioned it yesterday (Thank you for this). Before i wrote this response, i nabbed the download and used the Fmod.dll from there.

Results:
I got a loader screen but also a Very Serious Error, from ZDoom However, starting the exe again then correctly generated a Game.CON file and it opened. However nothing appeared further and i got the same situation as Enjay had way back in 2003: In the bottom of the screen, in 640x480: viewtopic.php?p=8109#p8109.

Unfortunately, none of the keyboard options that were given in that topic work, from both layouts as mentioned there. Nor does Biff's solution of going full screen fix the issue. The only thing i did get is that pressing either of the buttons 6 times gives you a message that you have been playing the One Level Exclusive Demo of Duke Nukem 3D, before closing.

I have Duke 3D Atomic on CD so i could test that out further, but as is i am stuck. I wager this has something to do with the fact that i run Windows 7 on 64 bit, not Windows XP as per your test build. I assume that Enjay and others back in 2003 ran XP aswell and thus could get something working. Since you ran this on XP, you got further then what i have. Ill tinker with this some more, if you are interested in further results i will PM you these instead since i think that's beyond the scope of what this topic tries to set out. At the very least, it ''works'' and that's enough for this topic. Randi mentioned you would have to write an ini script to set any settings yourself, so perhaps ill have to look into that first.

I've updated the wiki page to note that the 2.0.43 build exists and that "allegedly" the svn code drop was newer. I mean it's likely Randi did work on ZDuke a little longer, but I feel it's best to note that we have no poof.

Thank you a bunch for this To that effect, may i suggest the following suggestions?

• - Reword the wiki text: But it also resulted in a ZDoom-based Duke Nukem 3D source port, entitled ZDuke. ZDuke had one release, based on ZDoom 2.0.43, and was afterwards more or less abandoned. to include that it got ''Rediscovered'' in 2019, or one can include that in the sentence after the November 2009 part.
  - A link to this preservation thread.
  - Mention that the ZDuke binary needs the fmod.dll from ZDoom 2.0.43, as others may or may not work, perhaps with a link to that .cab file since it isn't present in the version history page on Wiki itself.
  - Some more clarification on what this does and how it differentiates from the aforementioned ZDoom builds in the list above. This bit is a bit too superfluous i reckon.

I totally would do add this info myself right now (I have yet to make an account) to not strain you any further with what essentially is a preservation nugget that 99.99% of users do not care about (and for good reasons obviously), but from a historical perspective, this stuff is mighty interesting, and thats only the 3rd time i have said that here.

Yeah, GZDoom can load BUILD-engine assets just fine. Or it used to, at any rate. When I was converting BUILD map geometry for a Deathmatch Simulator map I used Zandronum 3.0 since it worked there and still had the "dumpmap" command to convert the geometry to Doom in Hexen format.

In Zandronum, all of that loader code (and possibly Polymost addition) is still existing considering its based on an old ZDoom build. One of the folks at Duke4 made this mention to me yesterday. (Rather silly that i didn't connect the dots here at first.) I reckon that, considering that according to https://zdoom.org/wiki/Source_port Zandronum is based on the 2.5 branch (And with either 2.7.1/2.80 being the last version with the Polymost/Loader code intact) you would still be able to load up Build maps. I am not sure if the Dumpmap command got removed prior to 2.7.1 or 2.5.x, however.

The Build map loader was removed because at some time it broke and there was little point fixing it as the map weren't playable.
What the engine can do is load Build texture sets and provide the ability to use them for mapping.

Is that still a current option in the latest ZDoom builds? Because judging by history, all Polymost/loader code got removed.

[Phredreeke]

I think what Graf means is the engine can load tiles from Build ART files

[Graf Zahl]

Precisely. If you load any sort of resource file containing a Build style palette plus a set of Build ART files it will set them properly up as textures, e.g. you could just load Duke3d.grp as-is and use its textures. Of course they won't have the most meaningful names, because BTILxxxx is really all that can be done without further info.

[Blzut3]

- The ZDuke SVN 2009 version: This is the one considered lost, uploaded by Randi in 2009 and based off of 2.0.48. This is a Duke 3D sourceport that cannot run Doom whatsoever, and just uses ZDoom start up code among other things. It is supposed to play Duke Nukem 3D only and thus by doing so distinguishes it from the later, 2004/2005 experiments to extend the already existing Build map loader with display/Polymost code.

If you read the old news posts here you'll see what appear to be indications that Randi planned ZDoom 2.0 to be a whole new custom engine. This seems to have included using rendering techniques from build. I don't know what happened to these plans since I wasn't involved with ZDoom when this was a thing, but it's likely for the better that ZDoom remained the Doom engine. (This was also the time when ZScript, then DoomScript, was announced.)

I can only speculate as to why the build map loader was originally added, but I'd guess it was to provide test data while trying to add build's features to the Doom engine.

April 17, 2002
- Added a loader for BUILD maps. It's not very useful since the Doom engine is
so much more limited than BUILD, but it's fun to be able to load them anyway.

- ZDoom 2.0.95/97: Randi's December 2004 to February 2005 experiments to add Build map loading support and Polymost code to the ZDoom codebase. This remained available in code till 2014 when it was removed. This is not a Duke 3D sourceport, but rather a Doom engine with code to load up and display Build maps in wireframe or solid color modes.

While you can load a build map and display them like that using polymost, I should note that ZDoom doesn't have any sort of "build mode" or anything like that so it would translate build maps to the internal doom structures. You can turn polymost on with any map and you don't have to use polymost with build maps. The plan, to the best of my knowledge, was to use polymost to form polygons and Randi was going to write a software texture mapper over it (unlike say eduke32 which uses it for OpenGL). Someone that has been here longer than me can correct me on that, but I do know Randi pointed out that polymost doesn't have to be used with hardware rendering.

EDIT: Version history details that Polymost code got removed at version 2.8.0 in 2016, (https://zdoom.org/wiki/ZDoom_version_history#2.8.0) but the Wiki entry details it was removed in 2014: https://zdoom.org/wiki/Polymost. I assume it was disabled in 2014 but removed in 2016? Basically a phrasing issue at best perhaps, or some release note confusion in the worst part?

This is consistent. One is when 2.8.0 was released, the other is when the feature was removed. 2.8.0 started development in 2013.

I got a loader screen but also a Very Serious Error, from ZDoom However, starting the exe again then correctly generated a Game.CON file and it opened. However nothing appeared further and i got the same situation as Enjay had way back in 2003: In the bottom of the screen, in 640x480: viewtopic.php?p=8109#p8109.

Yeah it starts in a fixed location but on 1920x1080 I could just move the window after opening the menu.

Unfortunately, none of the keyboard options that were given in that topic work, from both layouts as mentioned there. Nor does Biff's solution of going full screen fix the issue. The only thing i did get is that pressing either of the buttons 6 times gives you a message that you have been playing the One Level Exclusive Demo of Duke Nukem 3D, before closing.

I used the Duke Nukem Atomic Edition grp.

I wager this has something to do with the fact that i run Windows 7 on 64 bit, not Windows XP as per your test build. I assume that Enjay and others back in 2003 ran XP aswell and thus could get something working. Since you ran this on XP, you got further then what i have.

On Windows 10 and Windows 98SE ZDuke just crashes immediately, so it sounds like you're getting as far as I do with Windows 7. Right now I don't have any Vista or 7 machines so can't confirm. But yes, ZDuke was developed on XP so that'd be the OS to run it on. (Off topic note: ZDoom was always developed on NT. It's hilarious reading some of the old posts where people claim that ZDoom "doesn't like NT" and Randi is just like "that's strange since it's developed on NT4.")

Randi mentioned you would have to write an ini script to set any settings yourself, so perhaps ill have to look into that first.

Well if you want to persist any settings you'd need to do that. You can just input stuff in the console.

[Redneckerz]

I think what Graf means is the engine can load tiles from Build ART files

Precisely. If you load any sort of resource file containing a Build style palette plus a set of Build ART files it will set them properly up as textures, e.g. you could just load Duke3d.grp as-is and use its textures. Of course they won't have the most meaningful names, because BTILxxxx is really all that can be done without further info.

Understood. Interesting that this tidbit has remained, but i can see its usefulness for modders alike Thank you both.

If you read the old news posts here you'll see what appear to be indications that Randi planned ZDoom 2.0 to be a whole new custom engine. This seems to have included using rendering techniques from build. I don't know what happened to these plans since I wasn't involved with ZDoom when this was a thing, but it's likely for the better that ZDoom remained the Doom engine. (This was also the time when ZScript, then DoomScript, was announced.)

I can only speculate as to why the build map loader was originally added, but I'd guess it was to provide test data while trying to add build's features to the Doom engine.

If we take the history as a whole, it seems that Randi has dabbled with Build on multiple occassions: Namely for ZDoom 2.0, when a Build loader was added, When ZDuke was made, and the December 2004-February 2005 additions. So roughly 3-4 moments where Randi dabbled with Build stuff in some way, shape or form. DoomScript, unrelated to the Build ideas but in the same timeframe, was likely (at the time) also one of these more ambititious ideas that were thought about.

Eventually, DoomScript became Z-Script, so despite the long walk up to it, that idea got fulfilled, even tho Randi didn't complete it.
As for the Duke/Build stuff, well, it remained a bunch of written idea's that saw some output (Loader first, ZDuke later, and ending with Polymost) and it has seen some actual usefulness too (And it still remains present in Zandronum).

I agree that for all intents and purposes, it was indeed better that ZDoom remained the Doom engine in the end, but it did deliver some useful tools in the process

While you can load a build map and display them like that using polymost, I should note that ZDoom doesn't have any sort of "build mode" or anything like that so it would translate build maps to the internal doom structures. You can turn polymost on with any map and you don't have to use polymost with build maps. The plan, to the best of my knowledge, was to use polymost to form polygons and Randi was going to write a software texture mapper over it (unlike say eduke32 which uses it for OpenGL). Someone that has been here longer than me can correct me on that, but I do know Randi pointed out that polymost doesn't have to be used with hardware rendering.

That much i knew (That Polymost was not exclusive to HW acceleration only) and im also aware what the Polymost code tried to do and what its purposes once were (If fully implemented, Doom would gain true 3D perspective and rendering support without Y-shearing). That was however not the case here.

Speculative, considering Build now has had a successor in Build 2, one could pretty much do all the experiments Randi did from 2002-2005 regarding Build all over again and see what's useful. That said, given how Build 2 seems to be rather different in a many ways compared to Build 1, its obviously not worth the effort, along with Silverman code being brilliant in all its hacked up nature imo. Or perhaps one could look at the lesser known engines Silverman worked on, like Polytex or Cubes5. But that's why its speculation, ofcourse.

This is consistent. One is when 2.8.0 was released, the other is when the feature was removed. 2.8.0 started development in 2013.

Both versions announce the removal of Polymost code, which is why i made a mention. I am sure only one is correct, but perhaps i am still not seeing it correctly?

Yeah it starts in a fixed location but on 1920x1080 I could just move the window after opening the menu.
I used the Duke Nukem Atomic Edition grp.

Combined these two quotes for better readability and shortening of the response.
I can go full screen to my rather low res monitor (1280x1024) but that's about it. I didn't yet use anything but the built in one level demo, so i will give this a shot in the future using the Atomic Edition GRP.

On Windows 10 and Windows 98SE ZDuke just crashes immediately, so it sounds like you're getting as far as I do with Windows 7. Right now I don't have any Vista or 7 machines so can't confirm. But yes, ZDuke was developed on XP so that'd be the OS to run it on. (Off topic note: ZDoom was always developed on NT. It's hilarious reading some of the old posts where people claim that ZDoom "doesn't like NT" and Randi is just like "that's strange since it's developed on NT4.")
Well if you want to persist any settings you'd need to do that. You can just input stuff in the console.

Again combined these two quotes.
Well consider it from my end then that ZDuke out of the box, so with the 2.0.43 Fmod.dll and just operating with what is in the Zduke exe, it throws a general error first, then creates a Game.CON, then it gets the aforementioned behavior. I do have an XP virtual machine laying around somewhere still, but it would be a bit too tedious to set that up just to test that out.

Regarding input: I understand you need to create an ini to hold any settings, my issue at the moment is that i can't even bring up/pull down the console in the first place. Neither of the solutions Enjay gave in his old topic with different keys and layouts has had any effect.

Lastly:
Regarding the Wiki suggestions: I hope these were okay with you or that you didn't take it the wrong way considering you didn't make a mention of it. If nothing else, ill edit it in myself if it takes up too much of your time, but considering you updated the entry for it, out of courtesy id like to know what you think of them in the first place

[Gez]

If we take the history as a whole, it seems that Randi has dabbled with Build on multiple occasions: Namely for ZDoom 2.0, when a Build loader was added, When ZDuke was made, and the December 2004-February 2005 additions. So roughly 3-4 moments where Randi dabbled with Build stuff in some way, shape or form. DoomScript, unrelated to the Build ideas but in the same timeframe, was likely (at the time) also one of these more ambitious ideas that were thought about.

There's more bits and bobs out there. Like the support added to the Bloodbath announcer (Blood deathmatch). ZDoom can load Blood's RFF files, too. IIRC, the parameters for ambient sound things were also based on the functionalities of their equivalent in Blood. Randi was very interested in Blood, more than in Duke 3D, and had started reverse-engineering and decompiling it -- all that work was, however, lost in a hrd drive crash.

Little trivia: the ZDoom secret message "A secret is revealed!" comes from Blood.

[Graf Zahl]

Randi was very interested in Blood, more than in Duke 3D, and had started reverse-engineering and decompiling it

Understandable, considering the code quality issues of Duke 3D...

-- all that work was, however, lost in a hard drive crash.

Which only reinforces the notion of frequent backups. But those were different times, all this happened long before the ZDoom SVN repo in 2006.

[Dynamo]

What the engine can do is load Build texture sets and provide the ability to use them for mapping.

Assuming this is still possible in the current versions, how would one go about loading .art files and getting them recognized as valid graphics? I have no need for this for my maps, obviously, but it still would be interesting to know.

[Graf Zahl]

You need to put all ART files of a set plus the palette into the same directory of an archive. Then you can access the textures by the path to the data plus the name BTILxxxx where xxxx is the tile number. This is an officially supported engine feature.

[Redneckerz]

There's more bits and bobs out there. Like the support added to the Bloodbath announcer (Blood deathmatch). ZDoom can load Blood's RFF files, too. IIRC, the parameters for ambient sound things were also based on the functionalities of their equivalent in Blood. Randi was very interested in Blood, more than in Duke 3D, and had started reverse-engineering and decompiling it -- all that work was, however, lost in a hrd drive crash.

Little trivia: the ZDoom secret message "A secret is revealed!" comes from Blood.

It would be rather hilarious if a ZBlood compiled exe existed somewhere, but this seems to be even more obscure than ZDuke. Still, thank you for sharing these bits and pieces, that's some interesting trivia

I always thought the secret message was also present in regular Doom, but i have no recollection of that (I played that like 20 years or so ago). Stuck to ZDoom ever since, and that is going to be LZDoom now considering my graphics hardware is old enough to not be GZdDoom compatible despite being a 2010 PC by nature.

(Its garbage, honestly. My mobile phone has more modern GPU support than this thing (Mali T720 MP2 versus Geforce 6150 SE IGP), so i am well aware what i can and cannot run.)