Altazimuth

A relatively small release. This fixes some nasty bugs, introduces renderer resolution that can be independent of the window resolution, and that's about the last of the big interesting changes that end-users will notice. The rest of the changes can be found in the readme. Readme file Official Windows builds: x64, x86, x86 for CPUs without SSE2 Official macOS build Source Code: .zip, .tar.gz Documentation is available on the wiki (some new features are still in the process are being documented) Example WADs:  SOON™ Update: I botched initial release. If you downloaded either of the x86 Windows builds please make sure to re-download these files.

I made it seemingly work on Eternity. Get devbuilds at http://devbuilds.drdteam.org/eternity/ Congrats on the release! I guess yell at me if it's secretly broken in EE, but it seemed OK.

UPDATE: It's live! Get any devbuild from May or later to use it! https://devbuilds.drdteam.org/eternity/ Well hi there. I just got done putting the final touches on my multithreaded renderer branch to make it actually usable! While I'd love to just sit on these changes forever and keep my mental state and blood pressure in check, I need people to actually test that I haven't introduced any extreme weirdness or crashes by making all these changes. To that end, it's time for a public beta! You may find the files at the bottom of the post, and the source is on the multithreaded-renderer-fixes branch if you wish to compile it yourself. In the meantime a brief explanation of the new settings and how to mess with them. r_numcontexts: Video Options > Page 2 > Renderer Threads. This does what it says on the tin. The higher the number, the more render contexts there are. This number ranges from 1 to however many threads your CPU supports. The optimal number of threads will vary based on your CPU and how complex the scene you're rendering is. Do not assume that the highest number is the best. Note that this number is technically off by one if you're talking about threads. It spawns one fewer than the number of contexts, because one context is actually run on the main thread. Separately implemented from this, if you only have one render thread then the whole system acts as it used to. Everything is executed on the main thread. r_sprprojstyle: Video Options > Page 2 > Sprite Projection Style. This has three settings, Default, Fast, and Thorough. Default means Fast for 1 thread, or Thorough for more than 1 thread. Fast is the classic Doom sprite projection style—if a subsector isn't visible in a given render context then it won't be renderered. This may cause sprites to have a cut-off appearance between the boundaries of render context windows. As the setting implies though, it is a fair bit faster than the Thorough setting. Thorough will (generally) eliminate the issues seen in Fast. It works by not just considering sprites that have their centre in the sector being renderered, but anything whose hitbox (yes, it's based on hitbox radius instead of sprite size) is within the rendered sector. Previously-drawn sprites that frame are then cached to avoid redrawing. Though this can cause a reduction in performance in more heavy scenes compared to Fast, in your average vanilla WAD you're not likely to notice much of a difference. It's not in the menus, but if you want to compare FPS between settings you will want to set `d_drawfps` to `on`. If you have any scenes where the rendering glitches out where it didn't previously then the ideal thing to provide would be your resolution, number of contexts, any savegames that have the exact frame where the glitch is happening, and the WADs you're running it with. Crashes are much the same as above, though obviously you can't provide a save; the crash report application will give you further instruction on how best to report crashes. BUILDS: 2023-05-01: Windows (x64) 2023-04-30: Windows (x64) 2023-04-29: macOS (x64), macOS (Apple Silicon) 2023-04-28: Windows (x64) NOTE: There's no load balancing yet because I'm so tired, dude, just so tired. I just wanna show this off now that it seems mostly done. I was worried this was gonna take another year or so of off-and-on work but nope, it's working just fine seemingly. You can thank GooberMan for this existing at all. Without Rum & Raisin doom I wouldn't ever have managed this.

Had I_Error issues in multithreaded builds. I have fixed this, and it'll be working fully starting from the next devbuild. In other news this somehow eluded me till now. Great mapset. Thoroughly enjoyed.

Oh god I'm reproducing it. I'll look into it. EDIT: Fixed

Yeah. Try turning that off. I think it might cause issues of some unknown variety.

What does your final page of video options look like?

Thanks! Props to ceski, Edward850, and InsanityBringer for helping point me in the right direction to help alleviate stress on threads. In other news the devbuilds are working again, so please get builds from there if you want. https://devbuilds.drdteam.org/eternity/

I've been trying to sort this out. Recent libpng updates have caused devbuilds to not work. I tried to fix it but failed to do so prior to the scheduled time last night. Hopefully it'll be sorted by next time. In the meantime have a manual build from me. Eternity_Master_2606a1.7z

It's live! The new DRDTeam build (about 19 hours from now) will have this officially in. Yes, I lied, I couldn't wait. Earlier today I made an important change that means that it scales far better with number of threads, both performance (faster) and CPU usage (lower). A sensible maximum at this stage is the number of physical cores your processor has. I did see some gains past that point on my 7950x but not that huge. I haven't tested this on a processor with E and P-cores and frankly I'm scared of what'll happen if I do.

@ceski Found an issue with r_sprprojstyle which I have since fixed. I'm not going to upload a new build since I plan on merging into master tomorrow.

I gave a stab at an incredibly simplistic attempt but couldn't quite figure out how to resolve rendering issues easily enough to bother. It seemed like some sort of persistent data was causing sprites to not render in the zones between the render context where the load balancing was happening. I'll probably pester GooberMan when he's freer.

I've decided I'm pretty happy with how things are, even without load balancing. I plan on merging this into master in 1.5 days, unless anybody has any major reports.

Edward850 got a Steam Deck and his crap experience using it to play Eternity prompted me to drastically improve the out-of-the box controller experience for that. You could try a devbuild if you want, though there's still stuff that needs improving (certain numeric fields only take input via kb). Either way it's much better than it used to be.

Yeah honestly for the guy who ironed out all these multithreading kinks I really don't know what I'm doing to a large degree. Initial set-up was based on Rum & Raisin code and then the vast majority of it was coming up with novel solutions to issues reported to me by ThreadSanitizer. It should be beared in mind there's no thread joining here, just setting an atomic bool to true and releasing of a semaphore (at which point the threads will spin). The whole communication between the threads happens on the render end here, and on the main thread's end here.

Just the start/end of threaded rendering. I might be using terminology incorrectly here, to be fair. Any synchronising within the render threads should be at a minimum. All texture caching and such were moved outside rendering. Allocations are all for thread-local heaps, last I checked. There is a mutex for the global zone heap, but basically nothing uses it from within the render threads.

Not sure how I'd figure out how to do this. Would require some wide-scale rewrites and even with that done I'm not sure I'd be confident in any sort of heuristics I could use to figure out what the best thread count it. I think NUTS is largely slow due to just how many monsters are thinking, rather than being rendered. It's definitely a combo but IIRC the thinking takes up way more time, meaning that faster rendering isn't gonna help toooo much.

Glad to hear of the perf improvement! Sadly as long as the synchronisation time increase per thread is so large it'll end up outweighing the gradually-decreasing gains from increasing the number of render threads. If there's any way that people think I might be able to improve this then I'd owe you a debt of gratitude if you informed me of it. In other news I uploaded another build, though this only really folds in fixes from master. Most of the rendering changes were to tidy things up and make more things const.

Thanks for all the kind words. I've uploaded a new build that fixes a crash if you changed the number of contexts after a swirling flat had been rendered (it'd crash as soon as another swirling flat was drawn).

There's now macOS builds (both x64 and ARM) courtesy of printz. There's no major differences between them and the builds I made yesterday. The only fix present is for the off-by-one that skillsaw pointed out, and that's extremely minor.

Thanks for the report, fixed. Good to know it's running far better in Heartland. That was one of my targets, and some scenes really tested the performance. I won't generate a new build for solely this change just to keep things simpler in the case that there are crash reports to deal with soon. I'm half-tempted to make the contexts a number entry field to reduce the window recreation spam, but then there's no exact way to know the max thread count, and also number entry fields don't work if you're going controller-only which is something I've been trying to improve the experience for recently.

Try a devbuild, please. You can find at https://devbuilds.drdteam.org/eternity/

The list is old as balls. It's just from before a lot of the monitor resolutions we have today even existed. It should be updated at some stage, really. Doomy__Doom is correct though, and you can input custom resolutions and such to your heart's content.

I added support for compressed nodes to EE today. Tomorrow's devbuilds (see link in pantheon's above comment) will manage MAP08 just fine.

This thread is intended to be a round-table between maintainers of ports with UMAPINFO support. The ports I know of behaviour of are dsda-doom, Eternity Engine, GZDoom, Odamex, and Woof!. Knee-Deep in KDiZD in particular demonstrates an edge-case in episode-handling behaviour (Eternity it requires modification to do so) that the spec does not explicitly define the intended behaviour of. It only defines a single episode, and different ports handle this differently. There are two approaches that different ports take. GZDoom and dsda-doom show no episode select, but will respect the episode start, so will launch the single episode on the appropriate map. Eternity, Woof!, and Odamex all pop up an episode select with only an individual episode. The core thing I want to do here is try and maybe get a Rev 2.2 which either clarifies this behaviour, or if we can't come to an agreement at least explicitly states the behaviour is implementation-defined. I'm tagging a list of people who I know work on ports with UMAPINFO support. Apologies if I forgot to tag you, though others here with better knowledge than me please feel free to tag others. I want discussion of this to be as inclusive among the people actually having to develop support for this as possible: @fabian, @AlexMax, @Graf Zahl, @rfomin, @printz, @jval. My personal opinion: I honestly don't mind if it becomes officially implementation-defined. My guess as to the most "sensible" answer is that dsda-doom (via PR+UM) and GZ have the reference implementations, so their behaviour should be considered the correct one and codified as such. By the same token though, I really don't think it's so overwhelmingly important that ports should have to conform to this very specific behaviour. So what do others think? Should it remain implementation-defined, or should there be a default and if so what should that default be?