dsda-dev

Maybe end of the month or in June.

The lump is based on the common and accepted standards, as seen by both source ports and authors, which work for most wads. There are rare, nonstandard use cases not covered by this lump. One example is having multiple complevels used in one wad in different maps. Another is numerical complevels targeting specific engine behavior that doesn't represent a cross-port standard. It might be more worthwhile to understand what kind of behavior you are trying to get and codify it in more compatibility behavior flags for the next iteration of mbf21+. There's a thread where such things can be gathered over in the editing forum.

Ya, I'll put it on the todo list. It didn't go unnoticed, it's just an old bug inherited from prboom+ so not a new issue for discussion. I think there is a thread about it somewhere here or maybe it's back in the pr+ port thread, not sure. I don't remember the specific details to be honest.

This is not an announcement of a new standard. MBF21 has been out for quite some time now and seen wide adoption, including half of the top 12 cacowards from 2023. While it was a big step forward from MBF, the standard was not meant to be the end, but rather to evolve over time alongside the community, and various developers and creators have discovered both strengths and weaknesses in the few years since its inception. This thread is a place to gather those ideas and critiques of the format that can be used to fuel potential future iterations. If you've run into blockers in your projects, or headaches working with the standard, or if you've got cool ideas that would enable new stuff, please share your thoughts below. It would also be helpful to know what works particularly well that should be preserved going forward. I (and Xaser if willing 😉) will collect and organize everything together if something formal takes shape in the coming year :^)

High res is very expensive in software mode. You'll get similar performance to woof if you lower the resolution to what it uses. Hardware rendering is relatively accurate and it can do a variety of "tricks" that software mode has, but there are still some gaps and some errors (for instance, corpses clip into the floor in opengl). The long term goal is to have complete parity between the modes, but for now it's a tradeoff.

Yes, this is also affecting some other wads. I'll be looking into it. Thanks for the report and the video.

Gregor: hit me up on discord if you are around there and I can see if I can make a build that works for you

Updated to v0.27.5 (same link in first post) DSDAHUD lumps are "merged" now so only redefined huds are changed Fixed umapinfo bunny scroller crash Fixed volume issue on song restart in OPL (rfomin) Getting this one out since the umapinfo crash affects a few projects.

Can you make a minimal wad demonstrating the problem?

The default is already "if intended by the author". This setting is an override if you want to allow it all the time. I can update the text. Boom sprite stuff can be changed in the config file or via the in game console. I'll be giving the whole menu system a look for 0.28.

Updated to v0.27.4 (same link in first post) Added background fps limit menu option Added option to hide stat totals until they are reached Added option to hide stat labels (unectomy) Added missing quitmsg dehacked keys (t-117) Changed invalid sndinfo definition to a warning Fixed some note skipping in opl (rfomin) Fixed textured automap showing in strict mode Fixed mapinfo Passover melee range height check Fixed undefined buffer issue with screenshots and viddump Fixed an overflow causing distant sprites (~8k map units) to not be rendered Fixed fullscreen cwilv replacement render position on entering screens

There have been a few cases where the parser doesn't work with all the different syntax in some SNDINFO lumps. I'll have this fixed for the next patch. Thanks for the report. I've kept posting here because it's the historical home and speedrunners are the group that need to know about new releases, but you're right that it probably doesn't make sense anymore.

I've looked into this some more. It's due to how actors spawn in the vanilla engine (you see the same effect if you spawn an enemy close to a wall for instance). The "floor" isn't updated until the actor moves / crosses lines, so it uses the sector floor and ignores the 3d midtex. I would need to add an algorithm that searches for the true floor / ceiling heights when spawning, and this won't just affect 3d midtex but normal geometry as well. I won't make that kind of big change in a smaller patch, so I'll put this on the topic list for 0.28 and it can be considered a limitation of the current implementation.

Yes, eventually. It's not a case of just copying Woof's code unfortunately.

This one is fixed for the next patch fyi