PrBoom-Plus, ver. 2.5.1.4

Unfortunately, that didn't help - I'd already tried saving with different nodebuilders, and rebuilding the nodes in doombuilder made no difference. To be clear: there's a giant wall which appears to jiggle up and down as you ascend stairs opposite it, and a HOM elsewhere; these cover large sections of the level, hence 'massive rendering errors'. GLBoom is better but it still has the problems with thing collision and monster line of sight. I'm more worried about those to be honest - it's game breaking.

 

Anyway here's the wad: https://www.dropbox.com/s/b09ynmf9qwgshet/technogoatexorcismUNFINISHED.wad?dl=0

1 person likes this

Share this post


Link to post
12 minutes ago, Krull said:

Wow that's some map☺. Afraid to say it seems to display fine for me in latest pr+ svn, both in software and GL. That said, I've an idea of what the problem might be — an integer overflow in R_PointToAngle at very large draw distances — but it was something that was fixed in pr+ years ago. Are you using a really old version, or plain prboom (not plus), or even boom.exe itself?

Share this post


Link to post

Nope, I was on PRB+2.5.1.4 all along.... I've attached some screenshots of the problem, which looks a lot worse in motion as the whole level appears to shake along the edges.

 

Could an integer overflow explain why none of the masterminds are attacking?

Spoiler

doom01.jpg.dd51ffecdfa8678b623acfe3247bf139.jpgdoom02.jpg.ea3e02da805c58c1fa2905e9c27eac61.jpgdoom04.jpg.d7a8df4c562ef02d4c7ab1db1ce475c0.jpgdoom05.jpg.39f3a8cc9c7914370763f873887eead9.jpgdoom00.jpg.5cb163a355218ad95bf84ca05885d6a5.jpg

Edited by Krull

Share this post


Link to post

@Krull I've had the same issue in Software Mode in two maps I've made with very large open spaces. The geometry ends up freaking out when the player is moving like in your screenshots. My solution was to play in, and recommend, GL mode. :P

Edited by Spectre01

Share this post


Link to post

Hmm ok, so that just leaves the issue of why the masterminds don't attack. I've given them more space and they still do nothing, is ZDoom's AI really so different by comparison? Because on there they tend to work fine.

Share this post


Link to post

Are they set to Ambush and do they attack after you shoot? I've noticed that monsters will not react to you if set to Ambush or if you don't fire when they're really far away.

Share this post


Link to post

You mean deaf? No. In ZDoom the player is immediately showered with bullets and forced to take cover, as intended. In Boom they take no notice unless you idclip up to their level, as if they are unable to look down.

Share this post


Link to post
5 minutes ago, Krull said:

as if they are unable to look down.

You might have inadvertently discovered the problem. The masterminds might be unable to sight the player from that height and angle. And when they can, the player might be too far away. ZDoom's LOS code is drastically different, and can allow the AI to attack in scenarios they normally couldn't.

Edited by Edward850

Share this post


Link to post
On 12/8/2017 at 1:02 PM, Krull said:

I've started testing my boom format map in boom rather than zdoom for the first time, and I'm encountering tons of rendering errors in software mode and issues with thing collision and monster line of sight in software & GL. ZDoom already emulates Boom so I'm wondering what the problem is here?

...

Anyway here's the wad: https://www.dropbox.com/s/b09ynmf9qwgshet/technogoatexorcismUNFINISHED.wad?dl=0

It seems the issue here is that monsters have trouble seeing past such long linedefs, and those outer steps of that central pyramid thing are indeed over 8,000 units long. I'm not sure what exact technical fault is at play here, whether it's the sheer length of the linedefs, the number of long lines that the monsters are attempting to look through, or some other factor, but perhaps someone with more intimate knowledge of the engine code could offer an explanation. I'm no fancy codeographer myself.

However, not all is lost! While screwing around aimlessly, I was able to get the map working in PrBoom+ as it was intended: https://drive.google.com/file/d/1L5Ji_C48aAXYqin3q6QGduJLGmClucfz/view?usp=sharing

 

All I did here was add new vertices along the really long linedefs, breaking up what were once 8,000-9,000+ unit lines into max 1,024 unit lines (the largest grid size that can be set in GZDoom Builder and probably other editors). The army of caged Spider Masterminds now open fire and cut the player to ribbons seconds after entering the level, as expected. As an unintentional benefit, this also helps alleviate (but not fully eliminate) the rendering errors you described in software mode. Hence, the map retains all functionality at no visual cost, if not actually receiving a visual boost because of the change.

 

Perhaps there's a more elegant or even automated way to carry out this procedure, but I'll leave that to someone with more intimate knowledge of mapping to offer an answer here. I'm no fancy mapographer myself.

Edited by Revenant100
2 people like this

Share this post


Link to post

Wow, thanks a lot. I'd just about resigned myself to making major modifications.

Share this post


Link to post

Although the map features lines of sight > 8192 units distance, there is also the problem that several of the spiders (e.g thing 742) are placed in their cages in such a way as they are unable to act - they should be moved so their bounding boxes do not overlap the cage bars or the wall behind. However, more importantly, the bullet (hitscan) range in the original game + traditionalist ports is 2048 units, so most of the time you are well out of range of their attacks.

Share this post


Link to post

I've got a feature request: I like using the advanced HUD, since I've never been a fan of the status bar, but the one thing it's missing is ammo counters for other weapons. The GZDoom alt-HUD is great example of a minimalistic type of HUD which shows everything you need to know. Would be cool if PRBoom+ included ammo counters to the side somewhere.

Share this post


Link to post
On 12/11/2017 at 9:57 PM, Spectre01 said:

I've got a feature request: I like using the advanced HUD, since I've never been a fan of the status bar, but the one thing it's missing is ammo counters for other weapons. The GZDoom alt-HUD is great example of a minimalistic type of HUD which shows everything you need to know. Would be cool if PRBoom+ included ammo counters to the side somewhere.

I know what you mean but I've not really felt the need with the weapon colours for high/medium/low ammo.

Share this post


Link to post

 

Hello. I'm posting this here on the off chance it may be useful to others. It's basically an updated rehash of my older post on this.

 

**Building Latest prb+ (2.5.1.5test 2018-Jan-14 12:06) on Mac OS X 10.13.2

 

1) install xcode and command line tools

 

2) install automake, autoconf, libpng, libsdl2, libsdl2_net, libsdl2_image, libsdl2_mixer  (I use MacPorts for this)

 

3) prb+ configure scripts look in a limited number of places for the GL libraries, and with every OS update Apple loves to move these to new obscure locations. My lazy solution to this is to make symlinks in the directories where ./configure will look that point to where they actually live: (@Jon might find this helpful)

sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers/ /usr/local/include/GL
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/libGL.tbd /usr/local/lib/libGL.tbd
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/libGLU.tbd /usr/local/lib/libGLU.tbd

 

4) if you used MacPorts to accomplish step 2, add the /opt/ directories to search paths

export C_INCLUDE_PATH=$C_INCLUDE_PATH:/opt/local/include
export LIBRARY_PATH=$LIBRARY_PATH:/opt/local/lib

 

 

5) install as per usual

svn co https://svn.prboom.org/repos/branches/prboom-plus-24/prboom2/
cd prboom2
./bootstrap
./configure
make
sudo make install

 

After updating to the latest 2.5.1.5, I can proudly report that an annoying mouse issue that I was having previously seems to have been fixed. So.. thanks! I guess? Or maybe it was an operating system thing (i.e. the SDL2 build not behaving properly on os x 10.10). Either way I'm a happy camper

 

 

 

 

Edited by Ribbiks
6 people like this

Share this post


Link to post

I can't run PrBoom+ 2.5.1.5test on Windows, complains about missing DLL.

Share this post


Link to post
55 minutes ago, Cacodemon345 said:

I can't run PrBoom+ 2.5.1.5test on Windows, complains about missing DLL.

There's a dll with a mildly similar name. Just rename that dll to the one it's asking for.

 

If you don't see the dll, it might be in an older version of prboom+, I dunno :c

Share this post


Link to post
On 1/19/2018 at 9:40 AM, Cacodemon345 said:

I can't run PrBoom+ 2.5.1.5test on Windows, complains about missing DLL.

Rename pcre3.dll to pcreposix3.dll, that way you'll get the test build to work, I have came across no errors when recording or playing demos with the test build.

Share this post


Link to post
On ‎20‎/‎01‎/‎2018 at 9:43 PM, GuyNamedErick said:

Rename pcre3.dll to pcreposix3.dll, that way you'll get the test build to work, I have came across no errors when recording or playing demos with the test build.

Wonderful, thank you so much for a real good tip.

Share this post


Link to post

Always wanted to know, any reason why translucency doesn't work in GLBoom+ but does in PRBoom+? You'd think it'd be the other way around, as I associate translucency with an OpenGL effect xD

Share this post


Link to post

@Bloodite Krypto I asked this way back and somebody linked this .deh addon, which implements projectile translucency in OpenGL mode: trans_on.zip

 

The only issue I've noticed is that if you're behind a translucent wall, i.e. waterfall etc., and being shot with projectiles from the other side; they may not show up. But this happens basically never, so it hasn't been an issue for me. And I have no idea why it's not a core option.

Edited by Spectre01
2 people like this

Share this post


Link to post

Awesome! Thank you :)

 

Can it be placed into 'prboom-plus.wad' so it auto-loads on execution? :o

Share this post


Link to post

That I haven't tried. I usually just select it when the launcher showing a list of wads pops up, along with whatever I'm playing.

Share this post


Link to post

Not sure if this is related but I think projectiles are translucent in complevel 9 but not in complevel 2.

 

There are also these settings in the cfg you can play with:

translucency                  1
tran_filter_pct              66

 

 

Edited by Memfis

Share this post


Link to post

I recently decided to try and install Prboom Plus, mainly due to a recent thread/poll about sourceports usage and I thought I should try and give Prboom Plus a try and I wanted to ask how do I set my configuration so it would best emulate vanilla behavior? I noticed the compatibility option and I set it to v1.9 but I also noticed that you can enable/disable things manually. What is the best and safest way to ensure I'm playing with vanilla setting?

 

I apologize if this isn't the right place for this kind of question but I was reluctant to start an entire new thread just for a simple question.

Share this post


Link to post

As far as the options menu goes: The Doom 2 v1.9, Ultimate Doom, Final Doom, and Boom settings should cover all your bases depending on which wad you play. Leave the rest of the gameplay options as they are by default.

 

Alternatively: You can make a text file, paste something like "glboom-plus -file 50shades.wad -warp 01 -complevel 9 skill 4" in it, save it as a .bat, and play from that depending on the wad. That will also give you vanilla mouse movement via -shorttics.

Share this post


Link to post

@Hells Kitchen The short answer is no. The technology is not quite there yet. You'd have to try one of the more feature-rich sourceports for that.

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