glDoom Resurrected (yes 'that' glDoom) - updated April 11th 2022

[Gibbon]

Once upon a time, there was something called glDoom.  After being lost, then found, then patched and forgotten.. well, I just couldn't resist!

 

Especially since Bruce gave me the blessing to continue it, in its original name and carrying on from the last version (snippet below from the mail).  It definitely was nice talking to one of the old legends!  Especially since I was just 12 at the time.

Spoiler

Hi Adam,

Yes,  you certainly have my blessing. That project has lain in limbo for almost 25 years. That's the reason I uploaded that code when I found  it. When I lost it originally, it just took the wind out of me. When I found it on an old drive that I had given away, I was happy to find it. But I just didn't have the time to deal with it anymore. I'd love to see the name resurrected and it come to fruition. I think John Carmack might be interested in following what you do as well even though he's moved on from id Software to Oculus.

Also note that OpenGL has changed quite a bit since that code was written with the advent of shaders which will probably allow you to streamline the code quite a bit by offloading much of the effects programming to shaders. Unfortunately the changes I made after that code are lost (including the move away from fixed point to floating point).

 

So, the details.  What I have so far done:

• 64bit cleanups to allow it to build and run on 64bit systems (does not yet play)
• Cleanups for modern types (uintptr_t, intptr_t and MSVC specific functions like (underscore)access etc..)
• Addition of the score system code from WINDOOM (not yet in release builds)

 

What I will do (based on priority listings):

• Cleaning up and optimising the code to run properly on 64bit Windows
• Cleaning up the OpenGL code and moving some things to shaders
• Making glDoom multiplatform (Linux and macOS) - with an SDL window but still using OpenGL to draw and accelerate
• Allowing the user to select the resolution and fullscreen/window within glDoom's menu
• Increasing the vanilla limits and adding support for No Rest For The Living and SIGIL

 

Compilation:

Currently, glDoom compiles using Visual Studio 2022 using the latest C standard. The 32bit build works fine and while glDoom also now compiles and runs as a 64bit build, there is a problem with the zone memory management code where a pointer is clobbering the ZONE_ID and causing it to crash to desktop when starting a game or demo (the dreaded Z_Free error). I have not yet found out where it happens but I'm running it through debuggers constantly.

Run the Visual Studio project and build to your CPU architecture.

 

Builds:

https://github.com/atsb/glDoom/releases/tag/v0.96c

Edited April 11, 2022 by Gibbon : new release

[FEDEX]

That's great! I'll wait for the 64bit version. Following this one to give it a spin when it comes out :)

[DuckReconMajor]

This is an unexpected and wholesome surprise! I always get a chuckle out of the '5 Years of Doom' writeup on glDoom. I had no idea the author had found the code.

[Dusty_Rhodes]

A nice simple OpenGL, raised limits port sounds like fun. The Sigil and No Rest support is always appreciated as well.

[Dark Pulse]

 

[Nikku4211]

Do you plan to add the option to disable texture filtering?

 

Even if you prefer to have it on, I'm pretty sure most people who play Doom would turn it off if it was easy to do so.

[Gibbon]

4 hours ago, Nikku4211 said:

Do you plan to add the option to disable texture filtering?

 

Even if you prefer to have it on, I'm pretty sure most people who play Doom would turn it off if it was easy to do so.

The latest binary already hardcodes GL_NEAREST.  Meaning Vaseline mode is not enabled.

[Dusty_Rhodes]

6 hours ago, Gibbon said:

The latest binary already hardcodes GL_NEAREST.  Meaning Vaseline mode is not enabled.

Thank you. Vaseline mode is an accurate description. Besides, who would want Doom to look how Bobby Brown smells?

[jval]

Tested and worked fine in most cases, I had keyboard problems running it in my ASUS gaming laptop (keyboard is not responding at all, only with Alt+F4 I can close it), in other PCs it works OK. All systems are with Windows 10. Performance is good even with my potato N2808 laptop with build-in Intel GPU. 

 

Some ideas:

• Support for DOOMWADDIR/DOOMWADPATH & Steam & GoG installed games.
• DPI awareness for Windows 8/10/11
• Wipe effect
• Remove color from spectres maybe?

 

 

 

[Ludi]

Wow! 

 

I always thought this port was lost to time, like a cave painting masked by thousands of years of dirt and erosion.

 

It's so cool to see this be resurrected. Mad props to Gibbon for this!

[HavoX]

Cool.

 

I wonder what kind of magic Gibbon will put out of his hat next...

[xX_Lol6_Xx]

1 hour ago, jval said:

Tested and worked fine in most cases, I had keyboard problems running it in my ASUS gaming laptop (keyboard is not responding at all, only with Alt+F4 I can close it)

Neither on my HP laptop, the only buttons that actually respond are Pause (Which brings up the menu but then I can't do anything) and Alt+F4.

 

These are my specs if they help on anything ;-)

 

 

[Gibbon]

38 minutes ago, Lol 6 said:

Neither on my HP laptop, the only buttons that actually respond are Pause (Which brings up the menu but then I can't do anything) and Alt+F4.

 

These are my specs if they help on anything ;-)

 

 

Yeah unfortunately glDoom is using ancient directinput code for this.  I’ll be moving the keycodes and input to SDL2.

 

It works on my ibm keyboard because it’s old :)

 

2 hours ago, HavoX said:

Cool.

 

I wonder what kind of magic Gibbon will put out of his hat next...

 

Well I have done a DOS port of Tekwar to tasm assembler..  my hat is very deep lol

[Redneckerz]

1 hour ago, Gibbon said:

Yeah unfortunately glDoom is using ancient directinput code for this.  I’ll be moving the keycodes and input to SDL2.

 

It works on my ibm keyboard because it’s old :)

 

 

Well I have done a DOS port of Tekwar to tasm assembler..  my hat is very deep lol

Is that Tekwar assembly port for no reasons at all somewhere? :)

[Gibbon]

33 minutes ago, Redneckerz said:

Is that Tekwar assembly port for no reasons at all somewhere? :)

My GitHub :P

[Nikku4211]

13 hours ago, Gibbon said:

The latest binary already hardcodes GL_NEAREST.  Meaning Vaseline mode is not enabled.

Thanks.

[Redneckerz]

4 hours ago, Gibbon said:

My GitHub :P

Cheater, you only just made it lol

[Gibbon]

So, a bit quiet, but was hard at work.

1. Ported the codebase to 64bit (it could probably run on Windows ARM too but I don't have one to compile and test on)
2. Fixed a bug where TNT and PLUTONIA wads were crashing on load
3. Added some fixes and cleanups to z_zone, w_wad and p_setup.c files
4. Added the -showscore and -keepscore functionality from WinDoom
5. Raised vanilla limits 

Windows 32/64bit builds:

https://github.com/atsb/glDoom/releases/tag/v0.96b

 

The legacy DirectInput is still there, so it may be janky on fancy gaming keyboards and such.  I've tested it on a modern Lenovo standard keyboard and my trusty German Cherry keyboard, works fine.

 

Edit:

For anyone who wants a 'show me'.  The below was recorded on the new 64bit build with the score functionality on.

Spoiler

 

 

Edited March 25, 2022 by Gibbon

[YeOldeFellerNoob]

Jesus Christ ANOTHER Source Port? You must REALLY love source ports. Either that or you are just bored.

[Gibbon]

1 hour ago, YeOldeFellerNoob said:

Jesus Christ ANOTHER Source Port? You must REALLY love source ports. Either that or you are just bored.

I enjoy keeping old software alive.  Compared to a lot of my other non-doom stuff it isn’t even that old :P

 

But hey, it wasn’t mine, I’m keeping it warm for Bruce.

[marver0PS]

I can't launch the port, it complains that ucrtbased.dll and VCRUNTIME140D.dll is missing.

[rzh]

24 minutes ago, marver0PS said:

it complains

Ah jeeze dude, you're missing those .dll files, how am I supposed to start without them?

[Gibbon]

Fixed that yesterday.  Sorry I should have said so :)

 

@rzh @marver0PS just redid load and it’ll be fine.

 

I always forget to do a release build and always end up using the debug build (which requires those dlls) as I use that for development.

[rzh]

4 minutes ago, Gibbon said:

Fixed that yesterday.  Sorry I should have said so :)

 

@rzh @marver0PS just redid load and it’ll be fine.

 

I always forget to do a release build and always end up using the debug build (which requires those dlls) as I use that for development.

No worries, I was just joking around.

I did have the same issue though, so glad to hear it was fixed.

[Mr.Rocket]

Pretty nice @Gibbon! I was actually able to compile and run this on the slightly bloated VS2019.

Can we have an alt+enter windowed mode switch and a way to turn the midi down via game menu?

Though, I see it's set to do nothing atm. ;)

 

Thanks.

[Gibbon]

glDoom 0.96C is here!

Changes:

• VSync (via glext)
• Fixing the wall wiggle bug
• HOM fixes (From Pooch/MBF)
• Using linear for close and nearest for far (GL_NEAREST, GL_LINEAR) for the rendering of distances))
• Little optimisation for larger maps (in automap display for large maps)
• Increasing the demo and maxdemo limit

 

Controls are not yet updated, so those who had issues will still have them.  Probably the most visible change is the use of glext.dll for the vsync (I hate screen tearing).  This is hardcoded for now.  Once I add more glext extensions I'll make them switchable in the config.

[Dusty_Rhodes]

VSync and HOM fixes are very nice indeed. Thanks for the update Gibbon. I wonder why GL rendered ports had HOMs on vanilla wads? The text file for Redux.wad by Bad Bob mentions it having HOM problems in hardware ports but not in the DOS executable. Even more interesting, Redux.zip includes a file that supposedly fixes it. It wasn't a .dll, it was something I didn't recognize . . . . I'll probably take a look in a minute. 

[Gibbon]

It was not like the traditional software version where it would either flicker or go bananas and draw the previous contents everywhere.  It was quite weird actually, it just displayed the previous content, but without the effect being very noticeable.

 

One thing that doesn't happen is slime trails, the GL renderer in this one totally obliterated that part of the code in order to draw the textures onto polygons.

[Dreemurr Deceevurr]

I keep receiving this error about MIDI devices.

 

 

Most of the time I can't click okay since the cursor is hidden and it brings me to whatever's behind it. On the rare times I can it runs without music, but then I get it again whenever I load a level. I have to use the task manager to close the program, and I have to reset my resolution from 640 x 480 every time since it won't change back. I use OmniMIDI and setting the MIDI mapper back to Microsoft GS Synth does nothing to help.

 

Edit: Setting nosound to 1 in the ini does fix this at the cost of well, no sound. But now I've run into another problem: the game will not recognize my inputs and I have to ALT+F4, meaning I still have to fix my res in the control panel.

Edited April 11, 2022 by Giant Jumbo Jellyfish

[Gibbon]

7 hours ago, Giant Jumbo Jellyfish said:

I keep receiving this error about MIDI devices.

 

 

Most of the time I can't click okay since the cursor is hidden and it brings me to whatever's behind it. On the rare times I can it runs without music, but then I get it again whenever I load a level. I have to use the task manager to close the program, and I have to reset my resolution from 640 x 480 every time since it won't change back. I use OmniMIDI and setting the MIDI mapper back to Microsoft GS Synth does nothing to help.

 

Edit: Setting nosound to 1 in the ini does fix this at the cost of well, no sound. But now I've run into another problem: the game will not recognize my inputs and I have to ALT+F4, meaning I still have to fix my res in the control panel.

 

What’s your system (and keyboard and audio adapter?)

glDoom currently uses antiquated Windows APIs for sound and input.  I never understand how some systems will work and others won’t.  On my Lenovo and HP Prodesk they both run it fine.  Also on 3 of my keyboards.

 

But I will now be upgrading these to modern Windows APIs and usages so I’d say just wait until then.