Shadow Hog Posted July 20, 2020 Well, if I'm wrong, I'm wrong. What a bizarre setup, then. Yes, that should be defaulted to follow-mode on. 0 Share this post Link to post
wrkq Posted July 20, 2020 I'd bet you turned it on once years ago and it just remained in the config file ever since. :) It is a bizarre decision and possibly a totally accidental one (cph just zeroed the new "automapmode" variable because you typically zero everything for defaults, forgetting the default for follow was on). But that's how urban legends are born, I guess. :) 0 Share this post Link to post
Da Werecat Posted July 22, 2020 Is there any reliable way to enable square pixels? 0 Share this post Link to post
Recca Posted July 24, 2020 The latest git is crashing every time i kill an enemy with no item drops. Can anyone replicate this, or is it something on my end? 0 Share this post Link to post
Dimon12321 Posted July 24, 2020 (edited) How does -recordfromto in tandem with -skipsec actually work? From what I understand, it creates a new lmp file, fills it with a portion of old input and, in parallel, plays it back without rendering until it reaches the end, and then moves back to the point of -skipsec value. Because, after I quit the program, I see another lmp file which size is proportionate to how much time it had managed to skip. Is it the fastest safe method? I tested a heavy Boom WAD demo with the duration of 77 secs (-skipsec 77.0) and 2.5.1.4 fast-forwards it in 25 secs while 2.5.1.7 - in 42 secs. Apparently, some changes were made since then. What is the bottleneck of this process and is there a simple way to accelerate it? Edited July 25, 2020 by Dimon12321 0 Share this post Link to post
GoneAway Posted July 24, 2020 (edited) Hello @Ferk @fabian Demo playback is currently broken on the latest commit! Playback proceeds for around 10 seconds before seg faulting. I've gone back and tested past commits and the one that broke it is here: https://github.com/coelckers/prboom-plus/commit/b201a986345a091b11aae4029d2dfb5fd7574fa9 This has been confirmed on both windows and linux. Guessing it's related to this: https://github.com/coelckers/prboom-plus/commit/b201a986345a091b11aae4029d2dfb5fd7574fa9#r40873799 But that's just a guess. Edited July 24, 2020 by kraflab 3 Share this post Link to post
JadingTsunami Posted July 24, 2020 58 minutes ago, kraflab said: I've gone back and tested past commits and the one that broke it is here: https://github.com/coelckers/prboom-plus/commit/b201a986345a091b11aae4029d2dfb5fd7574fa9 Yes, nice work narrowing the issue. It looks like an uninitialized variable bug. The comment from @fabian that mentions a missing "else return;" is the issue and should fix the problem. 0 Share this post Link to post
seed Posted July 24, 2020 Heh, interesting to see what happened here. Issues like these are the main reason why I prefer waiting for a while before making a new release, to ensure major problems don't slip in by accident as much as possible. 0 Share this post Link to post
Altazimuth Posted July 25, 2020 Anybody want to glance over the updated PR+UM demo signature code? 1 Share this post Link to post
Dimon12321 Posted July 26, 2020 Looks like @Ferk fixed "dropped items" feature that somehow fixes demo launch time. Could someone, please, provide the latest compiled build, so I could test it? 0 Share this post Link to post
Dimon12321 Posted July 26, 2020 3 hours ago, Recca said: x64-Debug.zip Thank you, but it shows 0x000007b error when I launch it. 0 Share this post Link to post
Recca Posted July 26, 2020 2 minutes ago, Dimon12321 said: Thank you, but it shows 0x000007b error when I launch it. It could be that you're loading 32-bit DLLs on the 64-bit exe, or that you have a 32-bit CPU. Try using these DLLs (located in dependencies_x64/bin). Otherwise here's a 32-bit build: PrBoom+.zip 1 Share this post Link to post
Dimon12321 Posted July 26, 2020 (edited) 17 hours ago, Recca said: It could be that you're loading 32-bit DLLs on the 64-bit exe, or that you have a 32-bit CPU. Try using these DLLs (located in dependencies_x64/bin). Otherwise here's a 32-bit build: PrBoom+.zip Oh, now it works with 64-bit libraries. Thank you! BTW, what is the purpose of 64-bit version over 32-bit? I can't think of circumstances where PRB+ would require more than 3,28 GBs. On 7/24/2020 at 8:25 PM, kraflab said: Demo playback is currently broken on the latest commit! Playback proceeds for around 10 seconds before seg faulting. I've gone back and tested past commits and the one that broke it is here: https://github.com/coelckers/prboom-plus/commit/b201a986345a091b11aae4029d2dfb5fd7574fa9 Nice notice! Now, the demo loading time is fixed. Here are my results: PRB+ version || Time ========================== 2.5.1.4 || 1:04.45 2.5.1.7 || 1:23.56 2.5.1.7 commit 5dcb070 || 0:50.01 Edited July 27, 2020 by Dimon12321 0 Share this post Link to post
Recca Posted July 26, 2020 1 hour ago, Dimon12321 said: BTW, what is the purpose of 64-bit version over 32-bit? I can't think of circumstances where PRB+ would require more than 3,28 GBs. PrBoom+ is slightly faster in 64-bit: 32-bit: Spoiler DEMO1: sg28-1224.lmp: 64-bit: Spoiler DEMO1: sg28-1224.lmp: 4 Share this post Link to post
Never_Again Posted July 27, 2020 Less than 2% faster than 32-bit. Might as well be called statistical noise. 3 Share this post Link to post
fabian Posted July 27, 2020 On 7/25/2020 at 6:20 PM, Altazimuth said: Anybody want to glance over the updated PR+UM demo signature code? I don't get why you needed to develop an entirely new demo header format. Wouldn't a simple marker indicating that the demo has been recorded with UMAPINFO level progression suffice? 0 Share this post Link to post
JadingTsunami Posted July 27, 2020 3 hours ago, fabian said: I don't get why you needed to develop an entirely new demo header format. Wouldn't a simple marker indicating that the demo has been recorded with UMAPINFO level progression suffice? Hmm, isn't that basically what they did in the PR? Except making it extensible for future additions by specifying an expandable format. Or maybe I could ask it as, where did you have in mind to include the UMAPINFO marker within the existing demo structure? 0 Share this post Link to post
Dimon12321 Posted July 27, 2020 3 minutes ago, JadingTsunami said: Or maybe I could ask it as, where did you have in mind to include the UMAPINFO marker within the existing demo structure? Maybe I don't completely understand the topic, but here's an improvement of an existing demo structure. Looks like there are no free bits left for the UMAPINFO marker 0 Share this post Link to post
Altazimuth Posted July 27, 2020 7 hours ago, fabian said: I don't get why you needed to develop an entirely new demo header format. Wouldn't a simple marker indicating that the demo has been recorded with UMAPINFO level progression suffice? It's nothing crazy. It just adds a small extensible header that doesn't clash w/ EE, which is what happens right now. This reduces future headache if similar features are added that might want to be run in a lower-CL environment. 0 Share this post Link to post
Dimon12321 Posted July 27, 2020 (edited) So, if I record a demo in 2.5.1.4 and complete several maps until the moment where a secret exit would take me to a different map (described in MAPINFO file), will I be able save the progress in a new demo using -recordfromto command in 2.5.1.7? If so, will I be able to go back to 2.5.1.4 after I beat the secret map? For example, by using -warp command in 2.5.1.4? Will the demo sync? 0 Share this post Link to post
Spectre01 Posted July 28, 2020 Are -complevel -1 demos build-specific in 2.5.1.7? Like if I record one using the first build @seed posted, would it be watchable in subsequent ones or no? I assume not. 0 Share this post Link to post
P41R47 Posted July 29, 2020 (edited) On 7/22/2020 at 3:59 AM, Da Werecat said: Is there any reliable way to enable square pixels? You can open the .cfg and force the resolution to 320x240. You will get the square blocky visuals of the original executable :) Unfortunatelly, there is no low res option like in chocolate-doom, crispy, and Doom Retro (except that Doom Retro donwgrade 640x480 to 320x240, i think) to make it even more square for pixel lover. 0 Share this post Link to post
Da Werecat Posted July 29, 2020 I meant disabling the aspect ratio correction. It's for a potential TC. Working on squashed graphics is a bother, and it's annoying to have to uphold a quarter-century-old standard that was only relevant for a few years. I can sort of approximate it with setting a wrong aspect ratio, but it's far from perfect. 2 Share this post Link to post
NiGHTMARE Posted July 31, 2020 Would it be a lot of effort to add support for ZDoom's TEXTURES lump to this fork? I would love to see that become part of the unofficial "Boom Plus" standard :) I suspect the most work would involve support for rotating and scaling, if so perhaps those could just be ignored? 2 Share this post Link to post
ketmar Posted August 2, 2020 most work will be rewriting the whole texture manager and image loading code. ;-) 0 Share this post Link to post
Da Werecat Posted August 2, 2020 If not for rotating and scaling, then what's the point? 0 Share this post Link to post
Gez Posted August 2, 2020 The various patch recolor options and layering styles would be enough to make things very interesting IMO. 1 Share this post Link to post
Da Werecat Posted August 2, 2020 Sometimes I wish classic ports had scaling, TBH. One of the long-standing issues I've experienced involves faraway scenery like texture trees. Midget vegetation is a bit of a staple of Doom-derived games, but if you're ambitious you might wanna attempt a more realistic scale. This could be achieved in two ways. Both involve making gigantular textures (provided the source port of choice supports them), but in one case it's a properly detailed texture that looks good (if terribly flat) up close; the other means simply resizing an existing small texture. The former seems like one big advantage, until you consider that it takes effort to actually make it look good. You'd want to have them at a bunch of sizes too. Then again, while it involves a lot of wasted effort and space for all the detailing that will probably be removed quite far from the action, the latter is a perfectionist's nightmare: all the wasted space is still there, except now it's properly wasted on duplicated pixels or blurry craptaculance depending on the method of resizing. But at least it's quick. Then again, even with the former method that just seems like a luxurious waste of time, there may still be aesthetic issues. I remember someone saying that pixels should all be the same in a game where they're huge. This might be true in a level that is close in scale and detailing to something IWAD-like; I'm not so sure about expansive scenery, because then the contrast between the chunky foreground and the noisy background may be too jarring. Of course, using stock-like textures makes it all the worse, because then you can add a bunch of repeating patterns to the aforementioned background's issues, which would in turn necessitate a lot of complexity in the faraway structures. Which would then lead to even more noise. Engine-side scaling won't solve the problem of gigantular pixels if the player is allowed to approach the decoration, but this is a mapping issue. The efficiency of it would justify everything. Feels like slowly reinventing ZDoom though. 0 Share this post Link to post