Blast_Brothers Posted December 5, 2021 I understand this is a niche request, but would it be reasonable to support OPL3 emulation somewhere down the road? I'm considering developing a GENMIDI replacement that uses the OPL3-exclusive waveforms and it'd be nice to have a Boom-compatible port which supports that. 0 Share this post Link to post
HackNeyed Posted December 5, 2021 3 hours ago, Blast_Brothers said: ... support OPL3 emulation ... nice to have a Boom-compatible port which supports that. I hope I'm not stepping on any toes but Woof! seems to have OPL3 emulation. No OPL2 it seems. At least e1m1 is in stereo in Woof like when Chocolate-Doom is set to OPL3. Unlike the mono sound when set to OPL2 in Chocolate/PrBoom-Plus and descendants. 1 Share this post Link to post
Blast_Brothers Posted December 5, 2021 5 hours ago, HackNeyed said: I hope I'm not stepping on any toes but Woof! seems to have OPL3 emulation. No OPL2 it seems. At least e1m1 is in stereo in Woof like when Chocolate-Doom is set to OPL3. Unlike the mono sound when set to OPL2 in Chocolate/PrBoom-Plus and descendants. Indeed it does! I didn't know that. I suppose that reduces the immediate need for FDWL to support OPL3 from my perspective, but I figured it was worth asking since it became my port of choice recently. 0 Share this post Link to post
Charlie Love Posted December 5, 2021 19 hours ago, Blast_Brothers said: I understand this is a niche request, but would it be reasonable to support OPL3 emulation somewhere down the road? I'm considering developing a GENMIDI replacement that uses the OPL3-exclusive waveforms and it'd be nice to have a Boom-compatible port which supports that. I don't have any immediate plans on upgrading to OPL3, unfortunately. I'm not against it, but it's more likely it would get implemented upstream via prboom+ or dsda-doom first. 1 Share this post Link to post
xX_Lol6_Xx Posted April 5, 2022 Damn, second time I bump a thread Anyways, I wanted to check how are things going with this port, and ask if we'll get another release? 0 Share this post Link to post
Gibbon Posted April 5, 2022 12 hours ago, Lol 6 said: Damn, second time I bump a thread Anyways, I wanted to check how are things going with this port, and ask if we'll get another release? I did a pull request 9 days ago and nothing yet. The repo hasn’t been touched in 6 months. 1 Share this post Link to post
xX_Lol6_Xx Posted April 5, 2022 3 hours ago, Gibbon said: I did a pull request 9 days ago and nothing yet. The repo hasn’t been touched in 6 months. It's a shame, I really was enjoying this port. 2 Share this post Link to post
LadyMistDragon Posted April 9, 2022 On 4/5/2022 at 10:30 AM, Gibbon said: I did a pull request 9 days ago and nothing yet. The repo hasn’t been touched in 6 months. Well that's annoying. Although I did get the impression the Chaz essentially made it as a more user-friendly DSDA Doom and doesn't necessarily prioritize the continued development of it. 0 Share this post Link to post
Charlie Love Posted April 10, 2022 (edited) Sorry I haven't been very active here of late. Working on getting those changes merged. I need to fix my Github notifications as they haven't been getting to me lately. I'm currently trying to decide where to take the port going forward. I was planning on doing something a bit more special with it, but I've just been swamped with other things lately. The port started as a way for me to implement features that I felt were likely out of scope for the DSDA Doom project. Due to DSDA adding many of these features in via their own methods, it kind of started to get a bit more complex when it came to deciding what to merge and what to rewrite which is why DSDA updates weren't brought in at the very least. The goal of this fork has never been to constantly have new features, but more to tweak or adjust things for my particular needs and wants. I unfortunately ended up a little too satisfied with where things ended up and stalled for a bit. :) I do plan on coming back and making things more active when life gets a bit less hectic. I really want to bring in game play modes and modifiers as a new feature in the future as well as tidy up the UI to make things more batteries included and in-game menu driven. 7 Share this post Link to post
Fluuschoen Posted October 26, 2022 (edited) Sorry for bumping this thread, if it was unwarranted, a moderator will chew my ear off, but I have two questions, hopefully not too stupid, and I didn't find answers here (or maybe I'm just bind, my bad if that's the case). So 1) Can I record complevel 2, 3, 4, 9 and 11 demos without possible desync (submitting to Doom Speed Demo Archive)? I suspect I can, but I'd like to hear a definite truth on this, if possible. 2) Did you do something with the software renderer (improving the frame interpolation calculation or something)? My gripe with Pr+/DSDA (and even Woof!, which is weird) has always been the bit (well, not a bit in old Pr+) input laggy software renderer, so I had to use OpenGL/Shaders for the best responsivity. However, your fork feels awesome, Crispy-like in software mode! Anyhow, really cool little tweaks you implemented here, bro, some of them I truly appreciate. Edited October 26, 2022 by Fluuschoen 0 Share this post Link to post
Shepardus Posted October 26, 2022 10 minutes ago, Fluuschoen said: 1) Can I record complevel 2, 3, 4, 9 and 11 demos without possible desync (submitting to Doom Speed Demo Archive)? I suspect I can, but I'd like to hear a definite truth on this, if possible. I haven't looked at this fork's implementation of the viewbob/weapon sway toggles, but if you leave those enabled I don't think there's any reason for demos to desync. 12 minutes ago, Fluuschoen said: 2) Did you do something with the software renderer (improving the frame interpolation calculation significantly or something)? My gripe with Pr+/DSDA (and even Woof!, which is weird) has always been the bit (well, not a bit in old Pr+) input laggy software renderer, so I had to use OpenGL/Shaders for the best responsivity. However, your fork feels awesome, Crispy-like in software mode! It's the same as in dsda-doom aside from defaulting to a 500fps framerate cap and some stuff that disables vsync under certain conditions (if you had it enabled in the first place) such as when playing in a window. 1 Share this post Link to post
Fluuschoen Posted October 26, 2022 (edited) 8 hours ago, Shepardus said: I haven't looked at this fork's implementation of the viewbob/weapon sway toggles, but if you leave those enabled I don't think there's any reason for demos to desync. I wouldn't want to turn them off like in Quakes. The dynamic feeling of the movement that comes from the bobbing/swaying is one of the main reasons I play Doom (almost exclusively). I figure you checked DSDA, and it doesn't desync if you turn these off, but in case of FDWL, you have the option to do just that for demo playback. Could this be relevant to the question at hand? Sorry, I'm anything, but a programmer; 25 years ago I could draw basic shapes with QBASIC, and that's the end of it. 8 hours ago, Shepardus said: It's the same as in dsda-doom aside from defaulting to a 500fps framerate cap and some stuff that disables vsync under certain conditions (if you had it enabled in the first place) such as when playing in a window. No, I always deactivate every kind of sync (and playing in full screen). Weird, because I don't think it's placebo though. Tried the 500 fps cap with DSDA after playing with FDWL, but the latter still felt a bit better. Can you remove this cap btw? 0 Share this post Link to post
Shepardus Posted October 26, 2022 9 minutes ago, Fluuschoen said: I figure you checked DSDA, and it doesn't desync if you turn these off, but in case of FDWL, you have the option to do just that for demo playback. Could this be relevant to the question at hand? Sorry, I'm anything, but a programmer; 25 years ago I could draw basic shapes with QBASIC, and that's the end of it. Removing weapon bobbing can cause desyncs if not done right because the position of the weapon ever so slightly affects how long it takes to switch weapons. dsda-doom avoids the issue by separating the rendering of the weapon from its "actual" position so it always behaves like the weapon is bobbing whether the player sees it that way or not. I haven't checked whether FDWL does the same. 14 minutes ago, Fluuschoen said: No, I always deactivate every kind of sync (and playing in full screen). Weird, because I don't think it's placebo though. Tried the 500 fps cap with DSDA after playing with FDWL, but the latter still felt a bit better. Can you remove this cap btw? Pretty sure the 500fps cap is just a default and you can adjust or remove it via the config/menus. 0 Share this post Link to post
Fluuschoen Posted October 26, 2022 1 minute ago, Shepardus said: Removing weapon bobbing can cause desyncs if not done right because the position of the weapon ever so slightly affects how long it takes to switch weapons. dsda-doom avoids the issue by separating the rendering of the weapon from its "actual" position so it always behaves like the weapon is bobbing whether the player sees it that way or not. I haven't checked whether FDWL does the same. Hmmm...I should test this. I have to load up a complevel demo with turned off bobbing/swaying, and if it doesn't play properly, then it desyncs. Is this correct? 1 minute ago, Shepardus said: Pretty sure the 500fps cap is just a default and you can adjust or remove it via the config/menus. Well, you can't set it from the menu, but I haven't checked the cfg yet. 0 Share this post Link to post
Shepardus Posted October 26, 2022 (edited) 1 hour ago, Fluuschoen said: Hmmm...I should test this. I have to load up a complevel demo with turned off bobbing/swaying, and if it doesn't play properly, then it desyncs. Is this correct? It's not guaranteed to desync, since for what I described to make a difference you have to fire immediately upon drawing a weapon. disregard that, there must be other ways it affects demo sync too, since NightTerror's D2All UV Max of Doom II desyncs almost immediately if weapon sway is disabled (I just tested). 1 hour ago, Fluuschoen said: Well, you can't set it from the menu, but I haven't checked the cfg yet. Should be "Framerate Limit" in the menu (under video settings, first page of general settings) and dsda_maxframes in the config. Doesn't look like you can set it higher than 500 or lower than 35, though, so I guess uncapped isn't possible (in dsda-doom a limit of 0 would indicate uncapped). Edited October 26, 2022 by Shepardus 0 Share this post Link to post
Fluuschoen Posted October 26, 2022 (edited) 9 hours ago, Shepardus said: It's not guaranteed to desync, since for what I described to make a difference you have to fire immediately upon drawing a weapon. disregard that, there must be other ways it affects demo sync too, since NightTerror's D2All UV Max of Doom II desyncs almost immediately if weapon sway is disabled (I just tested). Hmmm...I should look for some definite information about this, because it wouldn't be too nice if I did a cool run, and couldn't submit it. Maybe on Discord, or I don't know. Google is not really helping this time. 9 hours ago, Shepardus said: Should be "Framerate Limit" in the menu (under video settings, first page of general settings) and dsda_maxframes in the config. Doesn't look like you can set it higher than 500 or lower than 35, though, so I guess uncapped isn't possible (in dsda-doom a limit of 0 would indicate uncapped). I find my way around these things, as one of my hobbies was to write/modify (so experiment with) cfgs for Quake 3/Quake Live; in the last couple of years, I could start from a blank text document, and write a complete, organized config file by heart. Thanks though, it really looks like it's fixed, just at the time of the last post, I haven't looked into it yet on a deeper level, because I figured it could be simpler to just ask here from someone who's more initiated in the nuances of this source port. 0 Share this post Link to post
Shepardus Posted October 26, 2022 1 hour ago, Fluuschoen said: Hmmm...I should look for some definite information about this, because it wouldn't be too nice if I did a cool run, and couldn't submit it. Maybe on Discord, or I don't know. Google is not really helping this time. Demos desync when you use FDWL's weapon sway option (as in, disable weapon sway), it doesn't get more definite than that. But you said earlier that you wouldn't turn it off anyway so that shouldn't be a concern to you. 1 Share this post Link to post
Fluuschoen Posted October 27, 2022 (edited) 1 hour ago, Shepardus said: Demos desync when you use FDWL's weapon sway option (as in, disable weapon sway), it doesn't get more definite than that. But you said earlier that you wouldn't turn it off anyway so that shouldn't be a concern to you. Ah, yes, somehow I missed it (I mean the connection of that sentence with FDWL), even though I take pride in reading stuff properly lmao... Thanks again. 0 Share this post Link to post
Charlie Love Posted October 27, 2022 (edited) My personal preference to cope with my motion sickness is weapon sway on, view bob off. I didn't touch weapon sway code at all, so I wouldn't be surprised if disabling it desynced demos, but through my testing view bob shouldn't. I never liked how weapon sway goes away when view bob gets disabled in many games so I made sure that was decoupled from the game logic, essentially calculating those values and then lying to the renderer so the players camera doesn't go up or down. The reason the game feels so smooth is that I default the engine to run at higher framerates and turn off vsync for certain software configurations when using smart vsync, which on every machine I tested don't end up with screen tearing. You can likely do the same for dsda if you use similar settings. I don't outright state this anywhere, but I consider FDWL to be a software first port as I'm not too keen on how hardware mode looks, although it is certainly a necessity for more complex maps. 0 Share this post Link to post
Fluuschoen Posted October 27, 2022 (edited) 1 hour ago, Charlie Love said: The reason the game feels so smooth is that I default the engine to run at higher framerates and turn off vsync for certain software configurations when using smart vsync, which on every machine I tested don't end up with screen tearing. You can likely do the same for dsda if you use similar settings. I never use any kind of sync (140 Hz @ 35 fps, but rather 144 Hz @ avg. 900-1000 fps in software | avg. 2000+ fps in OpenGL), never had any issue with screen tearing whatsoever, camera turning is buttery smooth. I wasn't talking about PoV movement smoothness, just about a bit less input lag (meaning slightly more responsive mouse control) in software renderer compared to DSDA. Tried 500 fps cap with DSDA, but tbh, the more fps the less input lag, no matter the refresh rate, so this shouldn't be the cause, and FDWL still felt a little bit better in software mode @ all sync off. A small difference was that it was fixated 500 with DSDA, but FDWL's limit was more like 498-499, and couldn't get to rock solid 500. Edited October 27, 2022 by Fluuschoen 0 Share this post Link to post