Altazimuth

Good on you for this. For the record if there's any place to ask for support with formats, this is likely the place to do it. I'm under the impression that the long-term goal is proper tool support for the various formats (I would assume that means SLADE GUI support or some such?). As for now yeah, I think that when they're free GooberMan et al would likely be willing to help.

I've been poring over the ID24HACKED stuff (as I anticipate it'll be the biggest hurdle for EE) and had a few notes on the hashing formal spec. Misc section makes no mention of the "Monsters Infight" value. Is it simply not considered? I'm guessing this is the case. Various sections have stuff like "Thing index" as a field, is this the header, so "Thing %s"? Might benefit from being clearer that it's the block name. This might just be a byproduct of how I view the syntax of deh due to how EE's parsing code is formatted. "Code pointer" doesn't seem like it exists in EE. There's a "Pointer" block type, and states contain a "Codep Frame" at least. Be more explicit for subheadings of "Data processing orders" sections. "Sprites" could benefit from being instead "Sprites ([SPRITES])" or the like, and same for sounds, assuming that is intent. Otherwise, ports don't seem to use the "Sprite" block. Also what sort of feature set should be considered for ports that extended dehacked back in the day and still keep support? Eternity, for instance, added "Bits2" as a thingtype fields back in 1999 and still has that code kicking around.

No. It isn't something they did. The people responsible for ID24 are not the same people who are responsible for coming up with the uploader.

This is one of the existing DSDhacked wrinkles. Ports already had to know the deh version number and, based on that, resolve to a different hash key (if they used hashing already). This is not a new issue, nor is it an unsolved one. Eternity for instance specifies certain base indices from which DSDhacked definitions start. In short, no.

EE et al aren't standards. They never have been looked to that way. PR+ became an ad-hoc standard for a multitude of ports. dsda-doom continues from and displaces PR+. That means it implicitly has that same that responsibility that PR+ had. Pursuing, for instance, "standards" that only work in it and GZDoom and inherently cannot work in other ports jeopardises and displaces other projects, and willingly abdicates the responsibility that was held by PR+ for years.

I can corroborate this was the case for EE. No consideration for existing port-specific extensions seemed to have been made (unlike dehextra) which made support far more painful than it otherwise would have been. Anyway that's a very small portion of the text of that post, and relatively insubstantial compared to the rest, most of which is much more worthwhile in engaging with.

You're avoiding the heart of the matter. Can you truly claim to have the best intentions for the community given your actions since MBF21? As essel mentioned, there was the launch of DSDhacked prior to my intervention. There was also the assurances to me personally that ZDoom features would be gated behind a command line parameter to deter usage for anything but demos. There were also assurances that the ZDoom UDMF support would be just for demo compat, and not something mappers would target. While technically some amount of true, the spirit of this assurance was ignored by jumping to make a "dsda" namespace instead of aiming for a cross-port namespace. PRBoom+'s featureset ended up being the most common baseline for features for ports to support and, intentionally or no, you inherited that responsibility when you continued it in earnest with dsda-doom, so why ignore that responsibility with this? How can we trust that you yourself have the best intentions for the community at large, given these unilateral moves since MBF21's publishing that ignore the community far more than ID24 is?

The above quoted line from the draft standard is what I alluded in my earlier post: This wording was confusing to me, and so I asked about it during QuakeCon. I didn't make any statement that was too specific on that during my prior post in this thread as I didn't want to put words in mouths. Now that I've had time to actually ask if my memory was accurate I can actually speak about it with confidence. What is presently: should instead be worded more along the lines of: The purpose is to leave room for potential official projects like Legacy of Rust while ensuring that community standards and port extensions cannot be stomped over. I can explain more if desired, though may take a bit as I'm presently on a flight to LAX and will be on a flight to Sydney shortly after (and one to Wellington shortly after that) so apologies for that.

A tangent to current discussion (though still relevant to the thread), but I'll give my frank thoughts on ID24 as somebody who had eyes on the inside, and as a developer of a port who will want to be implementing this. This is solely me speaking as an individual. I'm gonna ramble a lot so I'm highlighting key thoughts in bold to make it easier to skim. I wasn't super involved with ID24 during the height of its development as I was occupied largely leading Dark Forces Remaster. My relationship to ID24 as it was in heavy development was largely me poking my head in, mopping more and more sweat off my brow as it became more and more involved, with maybe a smidge of chiming in here and there (I fully admit to my memory being inconsistent, and seemingly-arbitrary in what I do and don't retain). As things got to the later stages and things were more fleshed out I was able to ask more and things, with my viewpoint being solely as a representative of Team Eternity. Basically all my concerns with various features were explained away, and the same is true for any present wording I was concerned about. I'll fully admit it's a lot easier to deal with this stuff in causal conversation with only one or two other people than a busy thread, and my position on this matter is a privileged one. My stance at this stage is this: I have full confidence that those who worked and are working on this are developing it in good faith. It will be a long and hard road to supporting ID24 fully, but I know that everything in the standard has a sensible rationale behind it. It may take some time for support to get to a good place across ports—god knows I've got my work cut out for me—but I believe proper support for the standard will be a huge boon to mod developers, and I'm really excited to see what the community will be able to achieve with this.

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.

@xelax @Insaneprophet @Xyzzу Should be fixed in devbuilds whenever they next update? Hard call since portal rendering is extremely not my forte. There's still some issues with sprites in that area disappearing, but I think I know how to fix that (it requires doing proper line intersections of finite segments).

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.