Due to now widespread adoption of DSDA-Doom, starting from February 1st, 2025, the DSDA will being a new policy of enforcing accepted source ports and versions in order to get everyone on a level playing field. The TL;DR is, in order for your vanilla/limit-removing/Boom/MBF/MBF21 demos to be eligible for DSDA submission, you will need to use one of the following ports or a more recent version:
- DSDA-Doom v0.28.2.
- Woof v14.5.0.
- Crispy-Doom/Crispy-Heretic/Crispy-Hexen 7.0.0.
- Vanilla Doom/Doom 2/Final Doom exes will continue to be accepted.
This means that, if you are not upgraded to at least those versions of the above ports by that date, or you are still using PrBoom+ or earlier, your demos will not be accepted. Likewise, no alternative forks of PrBoom+, DSDA-Doom, Woof, etc. will be accepted to DSDA. For any of the above options that support strict mode, that option must be turned on for the demo to be accepted. Especially if you are on a much older version of DSDA-Doom or not on it yet at all, you are encouraged to make this switch as early as possible to ensure that you can iron out any issues you may have with the port switch and adjust to any differences.
As part of this change, the source port list on the DSDA websitehas been updated to host the above source ports.
Below FAQ will hopefully clarify any details of this change:
Why is this change needed?
Essentially, the goal is to have everyone on a level playing field. Up to the point of DSDA-Doom, PrBoom+ did not make significant distinctions in the menus between which settings are acceptable for recording and which ones aren't. Since DSDA-Doom, these standards have been iterated on and solidified through discussion and the creation of the strict mode setting which provides an easy way for any runner to know for sure that every quality-of-life improvement they are using is allowed per DSDA rules. In the interests of fair competition, I believe it is now a good time for everyone to make the switch to a unified recording environment.
What about other ports (e.g., GZDoom, etc.)?
Demos for source ports with WADs explicitly requiring them such as ZDoom, GZDoom, Zandronum, ZDaemon, Eternity Engine, Doomsday, etc., will still be accepted as usual. No standards will be enforced for which version of those ports must be used for any particular WAD, although you are encouraged to reach out to the community if you want to confirm what version to use for a particular WAD, as these source ports have changed significantly over their history, so the latest version may not be correct (or may not even work) with a particular WAD.
Demos with those ports for WADs that do not require them (i.e., vanilla/limit-removing/Boom/MBF/MBF21 demos) may be submitted, but they will be marked incompatible. That said, while such demos are accepted, it is highly encouraged to use the enforced ports above for such demos unless you really want to demonstrate something unusual that is only possible in more advanced compatibilities, as incompatible demos are both additional work for uploading and will not count for records.
Other oddball exceptions will be listed here as they come up:
- CNDoom D1ALL demos will be accepted, but as a side note, they will likely be all marked incompatible as well in favor of DSDA-Doom's -chain_episodes mode.
What will happen to existing demos?
All existing demos recorded using older versions of other source ports will be kept, and no changes will be made to them.
Is there a guide to moving to the newer ports?
If you are on a relatively recent version of DSDA-Doom, I believe it should be safe to just override everything in the directory with the newer versions of the executable and other files. I'm not sure if this affects DSDA-Doom, but for upgrading Woof, you may need to delete all of the dll files in the directory, as newer versions of Woof combined all of those into one file. In general, this may be the safest approach (i.e., before overriding all the files, delete the dll files in the current version of the directory).
For moving from PrBoom+ to DSDA-Doom (especially if you are still on v2.5.1.4 of PrBoom+), you will need to adjust your sensitivity. I do not recall the details, but I believe you will need to set DSDA-Doom's sensitivity to roughly 1.8x (according to @GarrettChan) PrBoom+'s sensitivity to have a close enough match, but it will not be an exact match, especially in the case of moving off v2.5.1.4 due to the underlying SDL library upgrade. If someone in this thread remembers this more exactly, I will update this with more details.That said, DSDA-Doom and Woof provide two different options for mouse code, and both are very robust and work well for the majority of the active community, so this change is scarier than it sounds in my experience. You might even find your skills improved once adjusting. :)
What about demos posted before the switch that are not on DSDA for some reason (e.g., WAD not on idgames, etc.)?
Any demo that was verifiably uploaded prior to the deadline is eligible for DSDA submission for historical reasons. That means that, as long as you post your demo before February 1st, 2025, your demo will be safe, assuming it is valid and syncs whenever the WAD in question is eligible for DSDA.
Are TAS demos affected by this change?
There will be no change to TAS demo guidelines or eligibility.
What about Chocolate Doom?
While Chocolate Doom is not really a port I'm concerned with, it has almost no usage at all for speedruns, so there's no real reason to allow it. As it has no footers, demos recorded in Chocolate Doom are a bit more maintenance effort for DSDA, so that's one more reason to not allow it.
After this change, can I continue updating to newer versions of the port?
Yes, unless there's a specific announcement to avoid a version due to some major bug, you're always free to use newer versions of the port and update at your convenience.
Will there be further updates mandated to the port?
Over time, it is possible, but these are not necessarily expected to be consistent or regular. Primarily, there are most likely to be further requirements if major changes happen to compatibility or strict mode, otherwise, it's probably not going to be too regular.
Why is only the final version allowed for DSDA-Doom/Woof/etc.?
Mainly, this is because if we are going to mandate a version, it might as well be the latest. The latest version is the most up-to-date and bug-free, and it's fairer for everyone to migrate at once IMO. At this point v0.28.2 is considered stable, and Kraflab has confirmed it is best that everyone move to it instead of any older version.
Can I still post any demos using non-allowed ports to the Doom Speed Demos subforum?
Yes, this ruling has no effect on the rules of this subforum; any demos, whether they are accepted on DSDA or not are welcome to be posted here going forward.
I'm in the middle of a demo pack. Can I continue working on it and post it with mixed ports after the deadline?
Generally speaking, you are encouraged to post all demos not using the latest ports now. However, I will accept the odd demo pack of this type after the deadline for some time to account for this case, provided this rule is not abused (i.e., don't start thirty demo packs now just to work around the deadline).
Will there be a grace period for demo submissions with old versions of the port?
Yes, in cases where someone was not aware of the enforcement, for about a month after enforcement, I might still upload demos for earlier versions.
One important note in case this isn't clear: this is NOT an invitation to suddenly downgrade the version of your source port to take advantage of something you otherwise wouldn't have access to. At this point, while you are free to use your current version of the port until the deadline, any demos recorded with a downgraded version of your port will not be accepted.
Edited by 4shockblast: Updating title
