Announcing Nightly Builds!

Since I’ve been very busy with other ‘EX’ projects (3 to be exact) , dotfloat has been kind enough to continue maintaining Doom64EX. So without further adieu, here’s an update from dotfloat:

 

We’re happy to announce automatic nightly builds for Windows. This marks a major milestone for the continuation of the project.

But first, I’ll introduce myself; I’m dotfloat. I’ve been working on and off (mostly off to be fair) on Doom64EX in silence for the past few years. I became interested in programming because of Doom and I hope to make Doom64EX a strong engine.

Download the latest in-development version here

Note that since this is an in-development build meant for beta testing; stuff will break. If you’re not willing to lose your saves, please use version 2.5 instead.

The current long-term goals for the engine is to be a faithful recreation of the original Nintendo 64 game, while also being highly moddable. The minimum requirements will hopefully stay the same. If you can’t run the nightly builds, but can run 2.5, please report it as a bug.

iskcnmu

What’s new:
– Better Linux support (even though you have to compile it from scratch…)
– New Image loading system with support for Doom Picture format
– SDL2 support
– Various bug fixes and improvements

What’s next:
– Support for zipped (ie. pk3) and directory WADs
– Controller support (with N64 Controller)
– Support for replacing sounds
– Scripting language integration (AngelScript)

Other Notes:
– Multiplayer has been re-enabled, but it’s very buggy and unusable at this moment.
– OS X builds are a bit tricky because I don’t have an Apple machine. I’m trying to find one though!
– Animated textures don’t work correctly if you use an older WAD. You’ll have to regenerate it with the command “doom64ex.exe -wadgen “. However, this is only a graphics bug, and won’t affect gameplay.

Big thanks to GuntherDW, ProfessorKaos64, volumetricsteve, alexey-lysiuk, DieMatratze, aFoxNamedMorris, gogtytsufvhgekwzyuow (what a name) and others for having the patience to compile Doom64EX and report bugs.

If you wish to help out by submitting bugs or feature requests, you can do so on Github. I will also be checking the forums periodically, so you can report there as well.

You can also contact me on IRC at #doom64ex on irc.oftc.net, twitter as @dotfloat, email: dotfloat@gmail.com. Keep in mind that I live in Norway, so I might be asleep when you try to talk to me.

Doom64EX Status

For those who are unaware, I have been swamped with other projects (one of them being Turok2 EX) and has left me with little to no time to update Doom64EX. However since the most recent release, I have gotten help from a few contributors. For the time being, dotfloat, MP2E and Quasar will be assisting me in maintaining Doom64EX.

The following is a list of goals that dotfloat hopes to accomplish:

GitHub repo: https://github.com/svkaiser/Doom64EX

New Stuff:
* SDL2 support
* Wadgen integration
* Various bugfixes
* 64-bit support on Windows and Linux

What needs to be done before a full release can be considered:
* New UI for Wadgen
* Fix save/load-related crashes

What won’t be considered for the next release:
* Multiplayer
* Doom Builder 64

Plan for the future:
* Full controller support
* Support for multiple image and audio formats
* Scripting

While nothing is set in stone yet, since I have the tenancy to drop off the face of the earth, I do have plans on migrating the Kex3 codebase with Doom64EX as I start wrapping up other things. This will introduce a ton of new features and improvements (hopefully) from my other projects. Anyways, thanks for keeping interest in this project wish the guys the best of luck!

Sprite Clipping in Strife: Veteran Edition Explained

The intention of this post is to document and share some information on how some of the features in the renderer works for Strife: Veteran Edition. I am hoping that this may be useful for source port authors and programming hobbyists alike.

One of the most common issues seen in OpenGL source ports is that when rendering sprites, they intend to get ‘clipped’ by the surrounding floor/ceiling geometry because of the depth buffer. Since there’s no such thing as a depth buffer in the software renderer, sprites could be drawn on top of anything.

A typical solution would to simply nudge the sprite a few units above the ground. Since most sprites in Doom pokes only a few minor pixels below the ground, which wouldn’t be a problem to adjust them. Strife on the other hand, suffers this problem the most as most of the sprites are clipped halfway through, which looks really ugly and undesirable and nudging them wouldn’t be a good solution.

Below is a example:

Software
STRIFE02

OpenGL (Hardware)
STRIFE00

My approach is to leverage frame buffer objects (FBOs). Before rendering the walls and floors, I bind the FBO and render all sprites from a single scene into a texture, which is then blended on top of the final scene, allowing them to be drawn on top of the floor. This however exposed another problem: they are now being drawn on top of everything, including walls!

Whoops
STRIFE03

So I had to come up with another way to fix this. I needed to find a way to properly clip the sprites by the walls but still let them draw on top of the floors and ceilings. I decided to take advantage of the depth buffer to accomplish this. So during BSP traversal, I store a list of visible linedefs (not segs) into a draw list. This also includes linedefs facing away from the player’s view. Culling is not accounted for during this step.

Before rendering walls and flats, I bind the FBO and disable color masking and culling and then I render the draw list containing the linedefs (I call this draw list ‘occlusion’ lines). This draws them ONLY into the depth buffer, after which color masking and culling are re-enabled and then sprites can be drawn afterwards. But there’s another problem, since masked/translucent walls are drawn last, the sprites in the FBO are now drawing on top of them. To fix this, I had to also draw the masked/translucent walls after rendering the sprites in the FBO. While this fixed it, it introduced some rendering glitches when viewing masked walls behind translucent geometry. Simply re-drawing the masked walls (after rendering the scene as normal but before blending the FBO) fixes this.

The process in rendering the occlusion lines is like this: when rendering a one-sided occlusion line, the top and bottom z-axis of the vertices (that makes up the geometry to render the wall) is extended into infinity, making sure that we fill the depth information on the screen. For upper/lower sidedefs, the upper z-axis is extended for upper sidedefs while the lower z-axis is extended for lower sidedefs.

However, this introduced yet another problem which, compared to software mode, still doesn’t look right:

Doh
STRIFE04

So to fix that, we just simply not draw them if the player’s view z axis is higher/above the geometry used to create that occlusion line. Allowing us to finally mimic the way sprites are drawn in software mode:

View Z Axis above the lower sidedef geometry. Occluder is ignored
STRIFE10

View Z Axis below the lower sidedef geometry. Occluder is drawn to the depth buffer
STRIFE11

This technique is also used for skies as well. Linedefs that’s connected to skies are added to a draw list and are drawn into the depth buffer, with the top portion of the geometry extended into infinity.

Before
STRIFE21

After
STRIFE20

That just about covers it. This isn’t the BEST way to do it and it results in A LOT of overdraw but this seems to be the best approach that doesn’t involve shaders or any advanced OpenGL feature. If there’s anything else that you guys might like to have documented or explained, then let me know!