Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

PrBoom+ 2.6.66 (Jun 20, 2023)

Recommended Posts

Well, if I'm wrong, I'm wrong. What a bizarre setup, then. Yes, that should be defaulted to follow-mode on.

Share this post


Link to post

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. :)

Share this post


Link to post

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?

Share this post


Link to post

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 by Dimon12321

Share this post


Link to post

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 by kraflab

Share this post


Link to post

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.

Share this post


Link to post

Anybody want to glance over the updated PR+UM demo signature code?

Share this post


Link to post

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?

Share this post


Link to post
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

Share this post


Link to post
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 by Dimon12321

Share this post


Link to post
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:

32bit.png.9c5af9bb5ceb4c344318b80d751bde1e.png

 

sg28-1224.lmp:

32bit.png.104abfe1bcaecf80b7c326167a1c525b.png

 

64-bit:

Spoiler

DEMO1:

64bit.png.ff42485b5f6bf55f80320b6e02dc1241.png

 

sg28-1224.lmp:

64bit.png.658cd573336819994fe6855c0919810f.png

 

Share this post


Link to post
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?

Share this post


Link to post
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?

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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?

Share this post


Link to post

most work will be rewriting the whole texture manager and image loading code. ;-)

Share this post


Link to post

The various patch recolor options and layering styles would be enough to make things very interesting IMO.

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×