ZDoom

Redneckerz wrote: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.)

You bought that in 2010? I'd say someone screwed you. It's the kind of hardware I purchased in 2004 (and then quickly upgraded myself), this is 3 or 4 generations behind what was current in 2010...

Graf Zahl wrote:

Redneckerz wrote: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.)

You bought that in 2010? I'd say someone screwed you. It's the kind of hardware I purchased in 2004 (and then quickly upgraded myself), this is 3 or 4 generations behind what was current in 2010...

Aye. It was a prebuilt budget PC. The GPU even back then was ass, but at the time i didn't need that, as i was mostly looking for an office PC that i also could do my study work on. Despite the cheap price, it had (for the time) rather a lot of RAM, 3 GB.

It basically was the really low price + the RAM that got me over for the purpose i needed it for,

I tend to go an unreasonably long time with hardware before upgrading (My previous PC before that was a P3 500 Mhz with Radeon 9200. Yes, i used that all the way up till 2008/2009, on occassion. I didn't had much need for anything else then). However with the PC purchase i also purchased a netbook.. and you guessed it, one of the worst available (Atom N280, 1 GB, GMA 950) which is now nearly inactive.

For gaming purposes on the cheap i rather use an Xbox 360 (Again, not something recent, haha) and a Thin Client that i am in the process of working over.

But for my next rig, ill definitely get something more modern. I could go for a Athlon 3000G but i figure Vega 3 isn't going to last a long time in terms of performance, so i am looking at a Ryzen 3 3200G, built in Vega 8 and 8-16 GB RAM. Atleast that's modern enough that i can run GZDoom with most bells and whistles. Not that ill purchase one soon, but perhaps next year.

The lesson I have learned from my last system is that going cheap will ultimately cost more in the end.
Back in 2012 when my previous system broke down I was unsure about what to buy, because CPUs are not particularly cheap. In the end I decided to spend a little bit more on the CPU but chose a more budget oriented graphics card because I knew perfectly well that I won't play modern games.

Turned out that this was the right thing - the system is still running well after 7.5 years and performance-wise holds its ground with a Core-i7-3770, 3.4 GHz.
The previous system which was a cheap prebuilt went kaboom after 5 years and the one before that was obsolete after 3 (simply too slow to do basic tasks and insufficient RAM.)

Graf Zahl wrote:The lesson I have learned from my last system is that going cheap will ultimately cost more in the end.

In terms of malfunctions? Well, i can't speak for everyone else, but at the very least the reason i end up using the hardware so long is partially because i hardly have issues with them. So i guess i am doing something right with them, haha.

In general, you are right though. Ultimately, the best system is a balanced one, but we all know that

Graf Zahl wrote: Back in 2012 when my previous system broke down I was unsure about what to buy, because CPUs are not particularly cheap. In the end I decided to spend a little bit more on the CPU but chose a more budget oriented graphics card because I knew perfectly well that I won't play modern games.
Turned out that this was the right thing - the system is still running well after 7.5 years and performance-wise holds its ground with a Core-i7-3770, 3.4 GHz.
The previous system which was a cheap prebuilt went kaboom after 5 years and the one before that was obsolete after 3 (simply too slow to do basic tasks and insufficient RAM.)

It also may have something to do with having a rather high and unrealistic tolerance towards what is slow - Though having worked with use cases of others that are more capable in hardware but far more slowly due to bloat - I dunno. It just isn't getting in my way yet.

The current rig is definitely reaching end of the line though because it is indeed more and more getting in the way of being usuable - Though i reckon with some proper clean up or turning to Linux its still a perfectly valid machine. My half-dead notebook, that somehow has turned into Slowlasses, will be perfect as a Linux machine, something ill plan on doing somewhere, sometime. Great re-usage of existing stuff instead of throwing it away, me thinks. The problem is time - I have way too many side interests and only a few i am actually good/capable at, such as writing content (As you can tell by now)

Ironically, even a last-gen AMD CPU part would be such a boost to performance (Let alone the GPU) that it would laugh at this machine with weeping tears. I know Biostar sells a really cheap motherboard with an AMD CPU (FX-8800p) and cooler onboard which is rather nifty, which would be very suitable, but i would be behind the grain once more. Quad core and 512 Radeon GCN cores of the pre-Vega generation is only going to push you so much, so for a next build, i am definitely looking into spending just a little bit more for a lot more gain.

Redneckerz wrote: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

Rachael uploaded ZDuke to https://zdoom.org/files/old/ so I've now updated the wiki to include a little more information. I opted not to include a bit about it being "rediscovered" since, no offense, but I don't think that fact adds anything to the article (put another way I don't see how the fact of when it was rediscovered furthers someone's understanding of the topic). You are right though that a link to this thread is warranted at least.

If you feel otherwise I'm not going to stop you from adding it yourself though.

It's too bad that this is non-functional on Windows 8. Same problem as ZDoom of the same vintage. The way it uses DirectDraw doesn't work on 8.1.

Graf Zahl wrote:It's too bad that this is non-functional on Windows 8. Same problem as ZDoom of the same vintage. The way it uses DirectDraw doesn't work on 8.1.

Does ZDoom also draw one frame and then crash? Since if I set it to XP compatibility mode in Windows 10 I do see the atomic logo before it crashes, so not sure if the crash is actually DirectDraw or if it's fmod. (Too lazy to reboot into Windows to find out.) In any case that's the same behavior as Windows 98SE so whatever the deal is ZDuke does seem to be pretty touchy about the OS it runs under, but not like I expected anything less given that it's not a polished release.

It should run with a DDraw emulator, if DXGL doesn't work dgVoodoo2 most likely will (the trojan is a false positive BTW).

Blzut3 wrote:

Graf Zahl wrote:It's too bad that this is non-functional on Windows 8. Same problem as ZDoom of the same vintage. The way it uses DirectDraw doesn't work on 8.1.

Does ZDoom also draw one frame and then crash? Since if I set it to XP compatibility mode in Windows 10 I do see the atomic logo before it crashes, so not sure if the crash is actually DirectDraw or if it's fmod. (Too lazy to reboot into Windows to find out.) In any case that's the same behavior as Windows 98SE so whatever the deal is ZDuke does seem to be pretty touchy about the OS it runs under, but not like I expected anything less given that it's not a polished release.

The problem I have is exclusive to Windows 8 and 8.1. 10 doesn't have it. That was confirmed when it first came up last year.

Here, I scraped this off of my hard drive. This should be everything, but the directory it was in is kind of a mess. It is probably the same version as was in the SVN, since I don't think I touched it after that. Don't expect it to compile as-is without some massaging. (But maybe it will work. I don't know; I didn't try.) 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.

Wow, nice! It's nice to see a piece of history preserved like this.

Judging from the dates in the archive it would seem the last time the project was touched was June 21, 2003? Would mean that the build that was posted all those years back probably is the one and only existing version.

Blzut3 wrote: Rachael uploaded ZDuke to https://zdoom.org/files/old/ so I've now updated the wiki to include a little more information. I opted not to include a bit about it being "rediscovered" since, no offense, but I don't think that fact adds anything to the article (put another way I don't see how the fact of when it was rediscovered furthers someone's understanding of the topic). You are right though that a link to this thread is warranted at least.

If you feel otherwise I'm not going to stop you from adding it yourself though.

Ill have to thank Rachael then for backing up that file way back in 2007 as it seems. So one could just link to that file instead of the older attachment post.
Regarding your new information additions: Its flawless, thank you for adding it all in and i understand your argument regarding the rediscovery part.

BTW, the October 11, 2003 date is when Randi uploaded that cab, but the build itself is from May 15, 2003. Not sure if that's useful to include, but there you go.

However, due to Randi's surprise post below, it seems yet another addition has to be made to include a reference and link to the ZDuke source that Randi uploaded today, as that's indeed new news.

Graf Zahl wrote:It's too bad that this is non-functional on Windows 8. Same problem as ZDoom of the same vintage. The way it uses DirectDraw doesn't work on 8.1.

I can test this stuff out on Windows 7 if that helps anything. If i remember correctly starting from Windows 8, DDraw was pushed by Microsoft to a legacy status. I have to check, but i recall that the code was either not enabled or supplied with Windows 8, which would mean one has to either download it or enable it for it to work again.

randi wrote:Here, I scraped this off of my hard drive. This should be everything, but the directory it was in is kind of a mess. It is probably the same version as was in the SVN, since I don't think I touched it after that. Don't expect it to compile as-is without some massaging. (But maybe it will work. I don't know; I didn't try.) 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.

... Well, whoa. There is only one emoji to describe this post:

Never would i have expected a post like this to materialize, let alone from the original author. This is a fantastic contribution in terms of historic preservation and a great enabler for others to look and learn from this little experiment.

When i set out this topic, all i expected initially was a little more details regarding the origins. By sheer coincidence, i came across your old October 2003, deceptively called Duke3d.cab. After it was confirmed by Blzut to be the real deal i figured that this was a perfect closure to the story. But now we also got the source.

I apologize for sounding a bit melodramatic in this, but this is way more than i bargained for or anticipated for in the first place. You have my most gratitious thanks for sharing this code and thereby completing the mystery of ZDuke (As much as it were one ) Absolutely amazing stuff.

Rachael wrote:Wow, nice! It's nice to see a piece of history preserved like this.

Indeed it is, and i want to thank you aswell for uploading the older cab way back in 2007. Perhaps it should be renamed Zduke3D.cab if possible, but to you, Graf and Blzut, thank you for this collective effort, one way or another. As little significance it may have to the general public, it holds great historic value for both ZDoom's and Build's history tree.

Blzut3 wrote:Judging from the dates in the archive it would seem the last time the project was touched was June 21, 2003? Would mean that the build that was posted all those years back probably is the one and only existing version.

That could be the SVN version that was uploaded in November 2009. The binary that was in the topic is from May 15, 2003. I have yet to check if Rachael's 2007 upload is the same date however, unless you have checked this already and the June 21 date is rather from the ZDuke source package (Which makes more sense now that i think about it).

Also, assuming you took a dive in the Source archive, where did you find that June 21 date? Looking through the archive i do find a rh-log.txt which is basically an internal notes log. Ill copy it below as is without formatting in case someone finds this useful to read without wanting to go through the process of extracting as that can be a bit cumbersome (Read below).

It is interesting to denote that Randi did work on it a bit further after the May 15, 2003 binary was posted on October 11, 2003. Perhaps the November 2009 SVN release included these additions from May 16, May 17 and May 20, 2003, but who knows.

Spoiler: rh-log.txt contents:

---

May 20, 2003
- Removed the used of the SP, SLT, SECT, etc macros because the debugger
doesn't understand them and will not automatically show the values of the
associated variables.

May 17, 2003
- Fixed the problem with multiplayer: My attempt to reformat getpackets() had
some braces in the wrong places, so the only player whose movements would
be received was player 0. However, it dies when SIMULATEERRORS is non-zero,
and I can't get the original Build packet code to work anymore. This
simulates a *very* bad network however, so I don't know how well I should
expect it to fare in a real network.
- Tried rewriting the code in mmulti.c to be a combination of the Doom and
Build connection systems. Actually playing a network game still doesn't work,
but the problems are the same as before, so I don't think mmulti.c is at
fault. The new code produces smaller packets, so unless I can't find the
problem elsewhere, I'm going to keep it in place.

May 16, 2003
- Ported the UDP driver from ZDoom. Since both Duke3D and Doom abstract the
network interface to an external program, this was relatively simple.
Unfortunately, networking doesn't really work yet. I can get as far entering
a level, and then it gets stuck.

May 14, 2003
- Added a real startup console viewer. Now I don't need to allocate a console
and hack the Visual C++ CRT to redirect stdio to it. This is even an
improvement over ZDoom's current workings, because if something goes wrong
and the game crashes, I can show the window so the user has a better idea
of where it happened.
- Removed the pause after the name of the current config file gets printed
during startup.
- Changed the CON compiler to use a binary search for identifying keywords.

May 12, 2003
- Changed playing sound tracking to use a linked list of the currently playing
sounds instead of storing this information with the sounds themselves.
- Reimplemented the RTS taunts for the new sound code.
- Added in-game resolution switching.

May 10, 2003
- Integrated the quote system with the console notify system.

May 9, 2003
- Added cvars for the shift, alt, and ctrl keys and the cond command so that
the function keys are fully bindable.

May 8, 2003
- Added EAX reverb support for hardware channels. On EAX3 cards, it uses the
sewer pipe preset as a base, and all other cards use the generic preset as a
base. Testing with my Audigy and nForce2, I think the sewer pipe sounds much
better on the Audigy than the nForce2, which is why I decided to do two
different types of reverb for EAX2 and EAX3 cards.
- Changed stopsound to be the same as stopenvsound so that you actually have
to specify which sprite's sound you want to stop. Now that you can have more
than one sprite emitting the sound at the time, this is needed. Removed
stopenvsound since it's now redundant.

May 7, 2003
- Changed some sounds that are effectively looping sounds (e.g. player jetpack
and just about anything played by a MUSICANDSFX sprite) so that they are
proper looping sounds even if the con doesn't define them as such.
- Simplified the FX_ layer so that it is now a very thin wrapper on top of
FMOD.
- Added the ASS "reverb" effect for software mixing.

May 6, 2003
- More 3D sound tweaking. Duke sounds have to travel a long distance before
they start being attenuated, and then they drop off to silence rapidly after
that--they're full volume for nearly half their audible range!

May 5, 2003
- Decided to not try to graft my ZDoom SFX code into Duke. The two games treat
sounds too differently. Instead, I have opted to take some of the backend
sound code that talks to FMOD directly and use it to fashion an ASS-like
layer for Duke to use. Now my only problem seems to be setting the min sound
distance and rolloff factors to best simulate Duke's sound.

May 3, 2003
- Got sounds working, after a fashion. Music is fine, but SFX still need work.

May 1, 2003
- Replaced as many spritetype::cstat, walltype::cstat, sectortype::floortype,
and sectortype::ceilingtype numeric constants I could find with symbolic
constants.

April 28, 2003
- Removed the sound reduction associated with 8250 UARTs.
- Added ONELEVELDEMO detection. Since I don't actually have this version, I
tested it by taking the shareware duke3d.grp and removing all the maps
past E1L1.

April 27, 2003
- Implemented console output, so now I can use it without typing blindly.

April 26, 2003
- Implemented more stuff: Key bindings, shareware (and presumably full version
1.3D) support, key input during dobonus, and console input. As the console is
currently invisible, I'm temporarily redirecting its output to stdout.

April 17, 2003
- Started moving the input code to use Doom's responder system. Duke handles
keyboard input quite differently from Doom. It uses an interrupt routine to
grab keyboard input as it happens and fill buffers. So to check if a key is
pressed or not, the game just looks at that key's entry in an array. The
keyboard interrupt routine also fills a queue for those times when the game
needs buffered keyboard input. There is no centralized event collection and
dispatch system. The simple keyboard handler I did on the 15th is no more,
but the menus and cheats work again.

April 16, 2003
- Fixed the various fade ins and outs so that they are actually visible.
- Ported my vlinetallasm4 routine back to the BUILD engine.
- Fixed BUILD engine bug: parascan() would draw one column past dax2.

April 15, 2003
- Added simple keyboard handler so I can start a game and enter cheats. Still no
controls.

April 14, 2003
- Fixed demo playback for v1.15 demos.

April 12, 2003
- First time I get the game to link and run, albeit there are no controls or sounds.

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.

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.

Redneckerz wrote: 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!