GoneAway Posted November 11, 2020 (edited) Hello everyone :^) Introducing the dsda-doom source port, which is a fork of prboom+um. The focus is on tooling that is important for our automation work on the archive, quality-of-life improvements for demo recording, and fun additions to the demo playback experience. The project is over here: https://github.com/kraflab/dsda-doom You can report bugs at the Github link above, or on the Discord: here Edited August 19, 2022 by Maribo 124 Share this post Link to post
Spectre01 Posted November 11, 2020 Cool, but I'm noticing significantly lower FPS in Software mode compared to the latest compilation in the 2.5.1.7 thread. In fact, it's basically halved across the board for me, using Sunlust map28 as an example. GL performance is also lower, but not as significant. I am getting around 90FPS in that same spot compared to around 120FPS in the 2.5.1.7 version I've been using. Could be just me though. 0 Share this post Link to post
Altazimuth Posted November 11, 2020 Holy crap. I heard some talk about automating detection of if pacifist was violated pretty recently. Great job on getting this out so soon after. I look forward to seeing how this develops moving forward. Given the limbo the 'Extensible demo format + "PR+UM" signature' pull is in on the main repo you're forked off of I may directly make another pull request for this project, though not quite yet. 1 Share this post Link to post
sponge Posted November 11, 2020 I'm happy to hear about tracking the pacifist rules automatically! I had brought something similar up when the new rules were being talked about, and while I don't really have much of an opinion either way, I think that being able to build it into the game itself can only help the community that wants to keep the category alive. 1 Share this post Link to post
GooberMan Posted November 11, 2020 I started programming a "suicide if pacifist" feature in to Rum and Raisin. And also Tyson functionality. My approach is more player-focused than demo-authentication though, so :+1:. 7 Share this post Link to post
dew Posted November 11, 2020 15 minutes ago, sponge said: I had brought something similar up when the new rules were being talked about, and while I don't really have much of an opinion either way, I think that being able to build it into the game itself can only help the community that wants to keep the category alive. Your point definitely stuck with me and I did use it as an argument for the simplest, most internally coherent and verifiable ruleset possible. Glad to see it actually translated into a practical implementation, this is huge for speedrunning staying relevant and future-proof. Big props to kraflab & the team. 0 Share this post Link to post
The Green Herring Posted November 11, 2020 Awesome work in rebranding PrB+ into a speedrunning port and adding features for that very purpose. However, I tried out that compiled binary for a bit and I get a signal 11 (segmentation violation) the instant I take any damage from nukage. I wonder if there's something amiss in the floor-damage code... 3 Share this post Link to post
GoneAway Posted November 11, 2020 8 minutes ago, The Green Herring said: Awesome work in rebranding PrB+ into a speedrunning port and adding features for that very purpose. However, I tried out that compiled binary for a bit and I get a signal 11 (segmentation violation) the instant I take any damage from nukage. I wonder if there's something amiss in the floor-damage code... Alright, probably something I didn't account for, I'll fix it :^) 2 Share this post Link to post
GoneAway Posted November 12, 2020 Should be fixed now (updated zip) - didn't realize the "inflictor" object could be NULL. 0 Share this post Link to post
Xlelight Posted November 12, 2020 Sounds kinda cool! i'm looking forward to this, as Prboom was my favorite ports of all time outside of GZDoom, keep up the hardwork on this! have a great day. 0 Share this post Link to post
GoneAway Posted November 12, 2020 1 hour ago, Spectre01 said: Cool, but I'm noticing significantly lower FPS in Software mode compared to the latest compilation in the 2.5.1.7 thread. In fact, it's basically halved across the board for me, using Sunlust map28 as an example. GL performance is also lower, but not as significant. I am getting around 90FPS in that same spot compared to around 120FPS in the 2.5.1.7 version I've been using. Could be just me though. Probably something with how I'm building it. Does this work better? dsda-doom-v0.1.1.zip 1 Share this post Link to post
Spectre01 Posted November 12, 2020 32 minutes ago, kraflab said: Probably something with how I'm building it. Does this work better? dsda-doom-v0.1.1.zip Yep! Now I'm getting more frames than the build I was using. Great stuff. 2 Share this post Link to post
Arbys550 Posted November 12, 2020 This might be a dumb question, but could this be used in the future to ensure runs are non-TAS? 0 Share this post Link to post
Shepardus Posted November 12, 2020 (edited) Will the PrBoom+ at coelckers/prboom-plus still see development, and if so will this fork merge in commits to that repo? Or is this effectively a replacement? 2 Share this post Link to post
GoneAway Posted November 12, 2020 7 minutes ago, Arbys550 said: This might be a dumb question, but could this be used in the future to ensure runs are non-TAS? A port by itself can't really provide a guarantee like that, and we wouldn't want a situation where people are pressured to use a specific port to be trusted. 2 Share this post Link to post
GoneAway Posted November 12, 2020 3 minutes ago, Shepardus said: Will the PrBoom+ at coelckers/prboom-plus still see development, and if so will this fork merge in commits to that repo? Or is this effectively a replacement? As long as prboom+ is still updated, we will merge the commits there into dsda-doom. But not in the other direction. Similar to how crispy is an extra set of features on top of the chocolate base. Of course, anything important can still be brought to prboom+ :^) 0 Share this post Link to post
GarrettChan Posted November 12, 2020 It's definitely nice to have additional things for the port, especially the Pacifist rule tracking. I'm wondering, is there possible to have: 1. In-game reset like Crispy Doom? 2. Proper ammo display for advanced HUD? 0 Share this post Link to post
Gez Posted November 12, 2020 (edited) 9 hours ago, Arbys550 said: This might be a dumb question, but could this be used in the future to ensure runs are non-TAS? Not really because ensuring there's no tool assistance is an extremely fuzzy thing. You could have some sort of filter that detects if movements are unnatural (e.g. inputs that change more quickly than humanly possible for fingers to command); but a TAS demo does not necessarily use unnatural movement input. Some ways of cheating may be non-detectable automatically. 2 Share this post Link to post
GoneAway Posted November 12, 2020 9 hours ago, GarrettChan said: It's definitely nice to have additional things for the port, especially the Pacifist rule tracking. I'm wondering, is there possible to have: 1. In-game reset like Crispy Doom? 2. Proper ammo display for advanced HUD? I think both of those things would be welcomed in prboom+ directly (I think someone has a pr / issue / branch working on in-game reset there already). The state of prboom+ is not really clear to me right now though - on the one hand Fabian (and others) are taking care of lots of things like bug fixing and general improvements, but anyone with the authority to make an official release seems to be absent or otherwise uninterested. 1 Share this post Link to post
GarrettChan Posted November 12, 2020 42 minutes ago, kraflab said: I think both of those things would be welcomed in prboom+ directly (I think someone has a pr / issue / branch working on in-game reset there already). The state of prboom+ is not really clear to me right now though - on the one hand Fabian (and others) are taking care of lots of things like bug fixing and general improvements, but anyone with the authority to make an official release seems to be absent or otherwise uninterested. Spoiler I don't know whether I should say this, but as you mentioned, I guess it's fine? I'm currently using Ribbik's branch for 2.5.1.5 and probably that's the one you were talking about. It's working fine, but I personally support random seeding instead of fixed seeding even though this is 99% of the time has no impact... The HUD thing is a major annoyance in PrBoom+ for sure because you have no way to tell your exact ammo and plan around it... so I think many would like to see it implemented. I did look at the code and it seems I can understand those part, but writing a new method to do it is out of my range as I haven't written any code for such a long time. Just like you said, it's kind of an awkward situation because different groups of people may focus on different features or stuff. Sometimes asking somebody to do a thing that they don't really care seems quite strange to me. Anyway, thanks a lot for the effort for this and all other general stuff. Cheers. 0 Share this post Link to post
Grain of Salt Posted November 12, 2020 20 hours ago, Shepardus said: Will the PrBoom+ at coelckers/prboom-plus still see development, and if so will this fork merge in commits to that repo? Or is this effectively a replacement? Shepardus!!!!!! On 11/11/2020 at 9:38 PM, kraflab said: Hello kraflab here is my list of dream features for a doom port. You are welcome Saves are unique to each wad (or even unique to maps maybe) Save to keyboard keys, a la mame Switch palettes with a key, without exiting (if you want to A/B compare palettes you currently have to take a screenshot in each and flip back and forth in an image viewer) Single keypress exit Extremely customisable stbar -- like prb for a start, but bars that don't suck, more customisability and the ability to put it on a bar rather than hud Stbar tells you when you have ssg, chainsaw, berserk, blue/green armor and maybe backpack A lump that dictates the complevel so I don't have to manually change 2 to 9 and back again every day A better implementation of gamma correction which could adjust the screen to display dark areas more legibly without doing weird things to hue etc 320x200 scaled up with no filter. I want to see pixels!! Select solonet from the menu like it's a difficulty (maybe also -fast and -respawn and pistol starts and stuff like that) Play sp with multiplayer tagged items but not solonet's multiplayer behavior. Play starting from player 2 (or 3 or 4) start. Play maps past 32 without needing warp or nomusic Button that warps you to a random map Ability to bind more than one key to an action (I currently have to rebind a few keys if I switch keyboards) Replace doom 2 maps with blanks if you've just loaded one pwad with maps in. An autoload folder. Wads you put in it autoload. There must be a better way of playing demos that were recorded with -nomusic (and similar weird cases) than having to use the command line Just automatically record to a timestamped demo whenever a level is played (except loaded games, cheats used, etc) Table for each wad (shown during interpic??) that tells you which maps in a wad you've beaten, on what skill, and whether you used saves, what your time was... etc automap tells you skill settings and command line settings 4 Share this post Link to post
BigBoy91 Posted November 12, 2020 Brilliant! The only fork of PrBoom+ that loads in full screen with zero lag. I'm used to having to run in windowed mode. I'm gonna have to fork out some cash and get a better PC though. SDL2 does not agree with my potato laptop. 0 Share this post Link to post
Dimon12321 Posted November 13, 2020 (edited) On 11/11/2020 at 11:38 PM, kraflab said: Fix boom rng seed (previously this was hardware dependent and not random) I haven't seen any Boom demos that would get out of sync. You mean, when a demo is created, an RNG seed is picked by the hardware and not by random? I don't think it's an issue then. 0 Share this post Link to post
GoneAway Posted November 13, 2020 It's not a syncing issue. The boom seed is supposed to be random - each time you run a map you get different rng. Unfortunately prboom+ would use the startup time as the seed. This meant that different players got different seeds, and usually only a few possible values. For why this is particularly bad, there were certain short runs where some players could get faster times than others. Not because of skill but because of how prboom+ chose seeds. 1 Share this post Link to post
Ks4 Posted November 13, 2020 Please add modifiable typematic delay like cndoom, that could help to run better 0 Share this post Link to post
Redneckerz Posted November 13, 2020 (edited) On 11/11/2020 at 10:38 PM, kraflab said: Hello everyone :^) We on the dsda team have started working on a "dsda-doom" source port, which is a fork of prboom+ 2.5.1.7. The focus is on tooling that is important for our automation work on the archive. dsda-doom-v0.1.1.zip BRUH i just find out about this. Epic stuff. A Speedrun specific source port that can do demo's, analysis, and has brilliant compatibility - And done by a dedicated team that knows everything on Speedrunning. Yet another one of those ''Why was this not invented yet'' ideas. Brilliant. 2 Share this post Link to post
GoneAway Posted November 13, 2020 4 hours ago, kokrean said: Please add modifiable typematic delay like cndoom, that could help to run better I'm not sure exactly what you mean. What did cndoom do? 0 Share this post Link to post
GoneAway Posted November 13, 2020 Updated to v0.2.0 (download updated). New stuff: - reality and almost_reality have been added to the analysis file (almost reality means you only took nukage damage). - added some basic specs that play a bunch of demos and confirm that everything syncs, which should improve reliability. 4 Share this post Link to post
GarrettChan Posted November 14, 2020 (edited) 1 hour ago, kraflab said: New stuff: - reality and almost_reality have been added to the analysis file (almost reality means you only took nukage damage). Oh, wow, didn't expect this because I always think this is a meme category although I ran so much of this. Also, I thought nobody cares about almost_reality, but well, it's not the case. Just in case got missed, so I tagged you again, sorry for the bother @kraflab - It seems now glboom-plus.exe also reads prboom-plus.cfg instead of glboom-plus.cfg. At least I put my config file to overwrite only glboom-plus.cfg, it doesn't work. - It seems reality and almost_reality are mutual right now, which doesn't make sense in a logical sense as almost_reality is a strict subset of reality. I guess for actual reality, both "reality" and "almost_reality" should be 1? Edited November 14, 2020 by GarrettChan 2 Share this post Link to post
Eric Claus Posted November 14, 2020 Hey liking what I am seeing here! PrBoom with chocolate doom sourced mouse control? Speed run specific settings? I don't know if you intend to add something akin to -tyson so it has a notification of that kind of rule break as lame a feature as that may sound since we have one for pacifist and the like, but understandable if not a priority. I think this is great and might move me back to PrBoom+ as a daily driver if I like the feel! 0 Share this post Link to post