I’ve re-activated my Twitter account, so from here on, I will be making announcements and updates regarding to my projects. So feel free to follow if you want to keep up with all the stuff that I’ve been working on!
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.
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.
– 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
– Support for zipped (ie. pk3) and directory WADs
– Controller support (with N64 Controller)
– Support for replacing sounds
– Scripting language integration (AngelScript)
– 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: firstname.lastname@example.org. Keep in mind that I live in Norway, so I might be asleep when you try to talk to me.
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
* 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:
* Doom Builder 64
Plan for the future:
* Full controller support
* Support for multiple image and audio formats
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!
Yeah I know, more unrelated news, but figured I mention this anyways since it runs on the same engine that powered PowerslaveEX. Its kinda funny how much this has evolved since the first time I announced it….
Guess there’s no need to be quiet about this anymore. But anyways, Powerslave EX has been in development for a month now and I’ve decided to create a new blog dedicated for this project. You can find it here: https://powerslaveex.wordpress.com/
There’s no deadline or any date that I intend on finishing this other than “it’ll be done when its done”.
Tools used to generate lightmaps (DLight) is officially released as well as custom configs needed for GZDoom Builder are available. Documentation can be found here: http://steamcommunity.com/app/317040/discussions/0/627456486499559686/
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:
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!
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:
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:
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.
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!