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

PrBoom+ 2.6.66 (Jun 20, 2023)

Recommended Posts

Sorry if this is easily found information, but is MBF21 implemented in the UMAPINFO fork yet? I can't find mention of it on the Github page.

Share this post


Link to post
Quote

 The spec is fully implemented in dsda-doom, with work well on the way in woof (probably pr+ after that).

 

Share this post


Link to post

2.6um is the latest stable build. However, you can also find continuous integration builds in the GitHub Actions tab. For Windows, download vs_win32 or vs_x64 from one of the workflow runs, and pair that with the dependencies here (within the zip, look within x86 or x64 depending on which build you downloaded, and extract the dlls within /bin to the same folder as the build).

Share this post


Link to post
7 hours ago, zx64 said:

Dwars has made a nice video guide on getting started:

 

 

Actually how I got to know UMPAINFO, pretty cool stuff. Have been messing around in the port and it's great fun.

 

Just outta curiosity: why does the game looks sorta blurred out when running 640x400 in OpenGL compared to 32-bit? Don't really have this issue with OpenGL in GZDoom - looks like something to do with scaling but I'm not entirely sure. (Huge PrBoom+ newbie btw, so there might be something obvious I'm missing here)

Share this post


Link to post

If you're using the software renderer, it draws at your chosen resolution and then scales it up to fit your display's resolution, without changing the display's resolution, but if you use OpenGL, it actually changes your display's resolution to that size. How this is scaled depends on factors outside the game (OS? GPU? monitor? I'm not sure...), but generally ends up blurry.

Share this post


Link to post

It may be a stupid question, and probably it has already been answered, but, what can the UMAPINFO lumps do, and, is there any tutorial of how to use it? 

Share this post


Link to post
1 hour ago, Lol 6 said:

It may be a stupid question, and probably it has already been answered, but, what can the UMAPINFO lumps do, and, is there any tutorial of how to use it? 

Here's the documentation

Share this post


Link to post
14 hours ago, Shepardus said:

If you're using the software renderer, it draws at your chosen resolution and then scales it up to fit your display's resolution, without changing the display's resolution, but if you use OpenGL, it actually changes your display's resolution to that size. How this is scaled depends on factors outside the game (OS? GPU? monitor? I'm not sure...), but generally ends up blurry.

 

Oh that makes sense, thanks. Linear scaling is definitely the culprit in GZDoom - having it off makes the image look nice and crispy in 640x400. Still looking for a similar effect in PrBoom.

Share this post


Link to post
20 minutes ago, Mike Stu said:

Oh that makes sense, thanks. Linear scaling is definitely the culprit in GZDoom - having it off makes the image look nice and crispy in 640x400. Still looking for a similar effect in PrBoom.

 

Under Options > General you can find many display scaling settings. You might try playing around to find settings that suit your preferences.

Share this post


Link to post
20 hours ago, Lol 6 said:

It may be a stupid question, and probably it has already been answered, but, what can the UMAPINFO lumps do, and, is there any tutorial of how to use it? 

Define an episode selection screen, define secret exits from anywhere to anywhere, and define what A_BossAction affects in a level when relevant monsters die, for a start.

Share this post


Link to post
20 hours ago, Lol 6 said:

It may be a stupid question, and probably it has already been answered, but, what can the UMAPINFO lumps do, and, is there any tutorial of how to use it? 

UMAPINFO can make you add levels, change level order, "remove" levels, place secret levels anywhere, and like @Shadow Hog demonstrated, "define what A_BossAction affects in a level when relevant monsters die, for a start.".

Share this post


Link to post

I'm currently having a mouse input stuttering issue, I'm running a dev build and using the latest windows dependencies. Hope someone has a solution.

 

Edit:

I solved this by switching to the x32 and with x86 Windows dependencies.

Edited by Firebert : Solution found

Share this post


Link to post
7 hours ago, Firebert said:

I'm currently having a mouse input stuttering issue, I'm running a dev build and using the latest windows dependencies. Hope someone has a solution.

 

Edit:

I solved this by switching to the x32 and with x86 Windows dependencies.

 

I think you may have solved this dude's issue

Share this post


Link to post
On 6/15/2021 at 3:17 PM, Firebert said:

I solved this by switching to the x32 and with x86 Windows dependencies.

Just started playing again today, and the stuttering is back, very strange.

 

Edit:

Just switched back to x64 and its gone. What's going on here?

Edit again:

Just tried x32 and its gone there too, I'm starting to doubt it has to do with which version you're using.

Edited by Firebert

Share this post


Link to post
3 hours ago, Firebert said:

Just started playing again today, and the stuttering is back, very strange.

 

Edit:

Just switched back to x64 and its gone. What's going on here?

Edit again:

Just tried x32 and its gone there too, I'm starting to doubt it has to do with which version you're using.

 

You might try narrowing the causes at your system level at this point.

 

E.g.:

  • Are you using a laptop? Does it matter whether it's plugged in? 
  • Have you tried setting Windows to Performance mode? Does it make a difference?
  • Are you using a Bluetooth mouse? If so, try a wired mouse and see if it improves.

 

Share this post


Link to post
On 6/16/2021 at 5:15 PM, JadingTsunami said:

Are you using a laptop? Does it matter whether it's plugged in? 

I'm using a desktop

 

On 6/16/2021 at 5:15 PM, JadingTsunami said:

Have you tried setting Windows to Performance mode? Does it make a difference?

No difference

 

On 6/16/2021 at 5:15 PM, JadingTsunami said:

Are you using a Bluetooth mouse? If so, try a wired mouse and see if it improves. 

I'm using a wired mouse.

 

For the record, I can run GZDoom and it's mouse input is perfect.

 

Edit:

Not sure if it's significant but running PrBoom+ by dragging doom2.wad over the executable has the mouse input work fine.

Edited by Firebert

Share this post


Link to post
On 6/16/2021 at 9:03 PM, Firebert said:

Not sure if it's significant but running PrBoom+ by dragging doom2.wad over the executable has the mouse input work fine.

 

I've also noticed this. ZDL doesn't seem to like UMPAINFO for whatever reason. PrLauncher works just fine.

 

Edit: Just to clarify, I'm unable to replicate this behavior in ZDL consistently, so it may not have anything to do with it afterall... Regardless, it does not seem to ever happen when simply dragging and dropping wads in the executable.

Edited by Mike Stu

Share this post


Link to post

while playing on linux i had a very weird crash

 

i was playing doom 2 with complevel 2 trying to beat the game without dying and i was doing really well i was already at map 15 when the crash happened i got no error message but on the terminal i got this:

 

P_GetNodesVersion: using normal BSP nodes
G_DoSaveGame: [5] MAP15 (DOOM2.WAD), Skill 4, Level Time 00:00:00, Total Time 01:13:27
W_CacheLumpNum: High lock on DSSWTCHN (127)
W_CacheLumpNum: High lock on DSPISTOL (4223)
W_CacheLumpNum: High lock on DSPISTOL (4239)
W_CacheLumpNum: High lock on DSPISTOL (4255)
W_CacheLumpNum: High lock on DSPISTOL (4271)
W_CacheLumpNum: High lock on DSPISTOL (4287)
W_CacheLumpNum: High lock on DSPISTOL (4303)
W_CacheLumpNum: High lock on DSPISTOL (4319)
W_CacheLumpNum: High lock on DSPISTOL (4335)
W_CacheLumpNum: High lock on DSPISTOL (4351)
W_CacheLumpNum: High lock on DSPISTOL (4367)
W_CacheLumpNum: High lock on DSPISTOL (4383)
W_CacheLumpNum: High lock on DSITEMUP (847)
W_CacheLumpNum: High lock on DSDSHTGN (687)
W_CacheLumpNum: High lock on DSDBOPN (687)
W_CacheLumpNum: High lock on DSPLPAIN (191)
W_CacheLumpNum: High lock on DSDBLOAD (687)
W_CacheLumpNum: High lock on DSDBCLS (687)
SetRatio: width/height parameters 1366x768
SetRatio: storage aspect ratio 683:384
SetRatio: assuming square pixels
SetRatio: display aspect ratio 683:384
SetRatio: gl_ratio 2,134376
SetRatio: multiplier 512/683
W_CacheLumpNum: High lock on DSWPNUP (335)
SetRatio: width/height parameters 1366x768
SetRatio: storage aspect ratio 683:384
SetRatio: assuming square pixels
SetRatio: display aspect ratio 683:384
SetRatio: gl_ratio 2,134376
SetRatio: multiplier 512/683
I_SignalHandler: Exiting on signal: Segmentation fault
I_ShutdownMusic: removed /tmp/prboom-plus-music-N3mzbG
I_ShutdownSound: 
 

thats all the log i had since i started the map thankfully i saved in case something like that happened

 

i guess it has something to do with resolution but thats really weird i was using the 8 bit renderer btw i dunno if any of this information will be helpfull but well here it is

Share this post


Link to post
11 hours ago, omalefico32x said:

i guess it has something to do with resolution but thats really weird i was using the 8 bit renderer btw i dunno if any of this information will be helpfull but well here it is

 

Unfortunately, the terminal output doesn't say anything specific about the crash, but I doubt that it has to do with your screen resolution (which isn't that uncommon). Is this crash reproducible in any way?

Share this post


Link to post

I'm having a completely separate crash for a completely different reason. I've recently compiled a recent commit of PrBoom-Plus on my x86_64 Windows machine, and after it tries to access my MIDI device it crashes. I know it involves portmidi, as when support for compiling with it is disabled I don't get the crash. 

Something worth noting is that I normally have Coolsoft's Midi Mapper installed. I uninstalled it thinking the problem might be related, but it doesn't appear to be the case. 

prboom-plus debug.zip

Share this post


Link to post

This didn't seem appropriate for the github, so making a post here. Seems like long automap names and message strings get cut off (presumably due to rendering internally at 320x200, but it can also happen with custom fonts). Examples from BTSX E1:

 

Spoiler

 

doom00.png.5decc792f287815350a6e154976f4d7c.png

 

doom01.png.d6c22438a3693fd7d9dcf0df46e29f23.png


 

 

Could the text(s) perhaps wrap below?

Share this post


Link to post
On 6/16/2021 at 5:03 PM, Firebert said:

I'm using a desktop

 

No difference

 

I'm using a wired mouse.

 

For the record, I can run GZDoom and it's mouse input is perfect.

 

Edit:

Not sure if it's significant but running PrBoom+ by dragging doom2.wad over the executable has the mouse input work fine.

 

I think I may have been having the same issue where moving the mouse around produced an effect that sort of looks like frames skipping but wasn't reflected in the FPS counter. This may not be the sole cause, but I found that I can reliably reproduce it by using Japanese IME as my keyboard input in Windows. As soon as I switch to use US English input, there's no choppiness.

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
×