dsda-dev

dsda-doom's minimum requirement is opengl 2

It's not a bug, but it probably makes sense to use the default instead if it's in the demo reel.

dsda-doom has beta support for udmf as of 0.26, which will leave beta in 0.27. Depending on what features you're using, your current project may even be adaptable (if you're interested in that). See here: https://github.com/kraflab/dsda-doom/blob/master/docs/udmf.md

Update to this post from a long time ago: DSDA-Doom v1.0 Formats [x] doom-in-hexen (0.22-0.25) [x] mapinfo (0.27) [x] udmf (0.26) Demos [x] more powerful tas building (0.27) [ ] rewind support for hexen (0.28) [ ] ability to record nearly everything (0.29) Graphics [x] software-style opengl (0.26) [ ] picture-in-picture (coop, fixed angle cameras, movie making) (1.0) [ ] new menu system (0.28) Miscellaneous [ ] dynamic music replacement (0.28)

Oh, in dsda-doom you can supply deh files with -file as well. Maybe you were using that syntax in woof and that's the issue.

As far as I'm aware it does not do that.

That code isn't reachable unless you're debugging and isn't present at all in any released version of dsda-doom. Please don't post portions of code you don't understand and make claims about features you don't know anything about. That will only confuse the people that are looking for help.

As already mentioned, it feels like a lot of the proposed features are already covered by or could be added to the existing mbf21 + dehextra format. Keep in mind though that not every port adopted those changes, and further few would adopt these, so you won't be able to have something that is as cross-compatible as dehacked. Every generation of changes leaves some ports behind, and a complete format change will leave more than a simple extension. The thing with decorate is that not all features can be injected into a port in isolation. Let's say I do define 32 weapons. How does the user access them? Should there be 32 weapon hotkeys? What does the hud look like? There are usability problems that can be addressed in the advanced ports because they can also customize the interface significantly. Now a point about the general approach. If you come in with a solution already planned out, it adds a lot of baggage to the conversation and there are many assumptions that are more difficult to pull apart and address. Creating new standards is way more a matter of lobbying and communication than it is about technical details or how it might look in crispy doom. When I started thinking about mbf21, the first thing I did was open a thread asking creators (not software developers!) about what their immediate headaches were. What kind of problems do they face regularly that prevent them from achieving their goals? Focusing on the problem itself and refining it in a wider discussion will make sure there is a basic alignment already among the people involved before even thinking about a solution. If / when we start thinking about the next mbf2x, I will begin by asking creators where they are running into walls and can't quite do what they want to. I know a few have started to write down different actions that are missing for instance that would open up a lot of flexibility. I'm not sure it's the right time to have that conversation though - there is something I will call "standard fatigue" or that there needs to be a cooldown between standard changes where we can recalibrate and see exactly how things are. By that I mean mbf21 is getting a lot more attention right now, but I wouldn't say it's "fully explored", which means a conversation about its limitations might also be premature. There is also just the hard reality that bugs come up over time that need to be addressed and we want a stable baseline before stacking new things on top. In terms of dsda-doom specifically, I'll say I don't have much interest in implementing a comprehensive new standard like this right now. There are plenty of existing stable standards that still need to be supported, and I would rather focus on them.

You can disable bobbing completely while in strict mode. It's for people that feel sick with the doom bobbing on.

The .x patches are usually bug fixes, so it's a good idea to update. Copying a config file works in most cases, especially between versions in the same .x (so 0.26.1 to 0.26.2 should be fine, you can just copy the file).

The armor is colored by type rather than by threshold.

I'd like to mention @fabian for his stewardship of prboom+ now that it is complete. In addition to his personal flagship ports that have been widely used for years he has at times taken over this role of maintainer for ports that otherwise would not see active development and ensured they receive the ongoing polish and stability improvements needed to keep them alive. That impact can be felt throughout the growing ecosystem of very-vanilla ports we see today, where something old continues to feel new.

Put a 1 for the flags you want to turn on. I.e., "weapon_text 220 42 bottom_right 1" I may update how this works, but for now these fields are just values instead of text keys.

Yes, anything is possible eventually, but probably not any time soon :^)

Updated to v0.26.2 - Fixed overflow in texture scaling (bkoropoff) (this caused the Eviternity issue) Download here.

This is a limitation of opengl. As far as the fullscreen question you're correct, the exclusive fullscreen toggle only affects the software renderer. I'm not sure what would cause the resolution issue you mention though.

Updated to v0.26.1 - Fixed secret messages carrying over between levels - Fixed locked door color in udmf - Fixed blood color leaking into raised sprites - Fixed ansi endoom crash - Fixed textured automap not working if map started with textured mode off Known issues: - Small-font hud elements configured for the automap are misaligned when using the fullscreen hud - Opengl issue with floor above ceiling when ceiling isn't a sky Let me know if anything else comes up! Download here.

Open the console and enter "game.describe". It won't stay up permanently but you can check with that if you need to. I will probably add a hud component in the future.

Small update: had the wrong key for the sky on map 1 in gzdoom. Fixed version attached above.

I want the visual experience of players to be consistent, and consistent with the original style. This isn't a port for fancy graphic features and those old light modes were inherited features that are opposed to that goal. By the way, since you're a speedrunner, it's very likely that the indexed mode would have been forced in strict mode anyway, even if the old light modes were still there. There are some pretty significant differences in visibility. The only reason it wasn't already is because there were still some big bugs in 0.25. Having less variance in renderer options also reduces the surface area for bugs, of which there are currently still many in opengl, and makes it easier to address them and test fixes. Sometimes breaking things down and simplifying is the best path towards the long term goal. It may frustrate you in the short term but I'm thinking about the distance future and there are a lot of things I still want to do.

Name the file DSDATC.lmp and put it into the autoload and it should get picked up.

https://www.doomworld.com/forum/post/2650773

Can you post the wad and save file?

https://github.com/kraflab/dsda-doom/blob/master/docs/text_color.md You'll want to set the map_title value (it's not required to also set all the others).

As boris mentioned in his comment, this is the namespace version.