PrBoom-Plus, ver. 2.5.1.4

[Csonicgo]

entryway said:

Thanks. Fixed.

I've noticed that my framerate has gone up significantly over the past few months as well, it's really noticeable on old hardware. What GL improvements have you done and are planning to do?

[entryway]

Csonicgo said:

I've noticed that my framerate has gone up significantly over the past few months as well, it's really noticeable on old hardware. What GL improvements have you done and are planning to do?

Are you sure? Which version do you use? glboom-plus.exe or glboom-plus_fast.exe? The second one is about 15% faster on my core2.

How many fps you have with current exe and 'old' exe (without wiping)?
http://prboom-plus.sf.net/epic.zip
glboom-plus -nosound -geom 640x480 -window -file epic.wad -timedemo epic.lmp

Do not try it with glboom or very old glboom-plus. It's much slower. No sense and I know it.

I have these results:

glboom 2.5.0         - 127 fps

2.4.3.1              - 144 fps
2.4.8.2              - 180 fps
2.5.0.1              - 202 fps
2.5.0.1.fast         - 231 fps

2.5.0.2.beta.nofast  - 205 fps

[Csonicgo]

oh dear, I think I may have been taken the wrong way :-)

I wasn't saying that performance has dropped, In fact, it has gotten better!

When I started using Prboom+ there would always be a long wait time to cache levels and lots of swapping. I have a very low end system so I expected this to happen. However as time went on ( I follow the SVN revisions and compile them ) I noticed better performance and suddenly one day, no swapping. When my computer was using swap my framerate would take a dive with the I/O of the disk. Now that PrBoom+ doesn't swap as much anymore ( or at all) on my machine I can play a lot faster now.

I can even use detail textures!


However I will post results of the old prboom+ with the SVN if I can.

[Andy Olivera]

Grazza: Yes, I'm still interested in getting the v2.2.6.2(or thereabouts) code. If you could eMail it to me(or post it here) whenever you get a chance it would be greatly appreciated. Thanks!

[Grazza]

Sure. Nudge me at the end of January if I haven't sent it by then; it might slip my mind as I am liable to be a bit zonked after the NZ-UK flights.

I'll also try to get back on top of other prb+ matters once I am back (documentation and -auto patterns).

[entryway]

The latest beta of PrBoom-Plus has support for High Quality Scaling and "In-Wad Hi-Res". You can test these features right now.

[Csonicgo]

entryway said:

The latest beta of PrBoom-Plus has support for High Quality Scaling and "In-Wad Hi-Res". You can test these features right now.

Holy crap! that's pretty awesome. It works great on the RAGE PRO M as well!

Still having the weird sky warping madness when gl_drawskys is set to 1. 2 is an ok setting but it's still slow as all hell when there are a lot of segs in view. I found that gl_Drawskys set to 0 is tolerable when playing Episode 1 of Doom, but the other episodes look a little funky with a white sky. :p

EDIT: I got in contact with the coder of the drivers for RAGE PRO M (X DRI) and his testing box went on the fritz while developing workarounds for the main issues of the chipset (Forcing the card to use functions only Direct3D could seem to access with the windows drivers, like fog and alpha blending). A replacement is coming, but it'll take a while.

[entryway]

Csonicgo said:

Still having the weird sky warping madness when gl_drawskys is set to 1. 2 is an ok setting but it's still slow as all hell when there are a lot of segs in view

Is it better with gl_drawskys 3?
http://prboom-plus.sf.net/glboom-plus_drawsky3.zip

[Csonicgo]

entryway said:

Is it better with gl_drawskys 3?
http://prboom-plus.sf.net/glboom-plus_drawsky3.zip

...

YES

[ReFracture]

entryway said:

The latest beta of PrBoom-Plus has support for High Quality Scaling and "In-Wad Hi-Res". You can test these features right now.

I've been playing with that build of PrBoom-Plus for a few days now. Pretty sweet stuff.

[Hitherto]

Demo footer feature is really cool thing, with great potential. Cheers.

[Luke Annett]

Any plans to support mouse wheel weapon switching? Or is there a way to do it automatically?
Another thing is it possible to make the right hand mouse button single click use? The forward movement before using can be annoying...

Other than that, great source port. It is by far the fastest and looks great without changing the flavour of doom too much. Great work!!

[entryway]

Luke Annett said:

Any plans to support mouse wheel weapon switching?

Not in 2.5.0.2 release. Currently I want to fix all potential bugs which are not present in 2.5.0.1. Do you know any? Also I should test some new features (mostly it's about demo footer) more precisely before releasing.

[darkreaver]

Ok.

Im about to throw out the most noob question ever. Lets go!

How exactly can I change map when Im playing in glboom-plus/prboom-plus? Im used to just typing "map mapXX" in a console.

Yes I know its a question worthy of every facepalm there is =)

edit: it might not be the right thread to ask this tpe of question though hehe

[myk]

idclevXX

[darkreaver]

K, thnx =)

Great work with PrBoom+! Its my fav port these days.

[TimeOfDeath]

[WH]-Wilou84 pointed this out about rising stairs in another thread - rising stairs that build from both ends (like in eternall map25) behave differently with complevel 9. Is this intentional?

[myk]

It should be. That's one of the reasons why one needs to apply either the stair-building setting or a particular compatibility level for various existing maps, either way.

[TimeOfDeath]

Ok thanks, I see the stairbuilding compatibility option now, but does the default complevel override the extra compatibility options? I tried playing a map in complevel 9 with the stairbuilding comp option on but the stairs acted as if the stairbuilding option wasn't on. I'm trying to record a demo with complevel 9 (to avoid overflows) and the stairbuilding option on. If that's not possible, what other complevel would you recommend to use for a normal doom2 format map and to avoid overflows (with the stairbuilding option left off)?

There's a stairbuilding option in ZDoom, but it doesn't change how the raise-from-both-ends kind of stairs behave.

[myk]

TimeOfDeath said:
Ok thanks, I see the stairbuilding compatibility option now, but does the default complevel override the extra compatibility options? I tried playing a map in complevel 9 with the stairbuilding comp option on but the stairs acted as if the stairbuilding option wasn't on. I'm trying to record a demo with complevel 9 (to avoid overflows) and the stairbuilding option on. If that's not possible, what other complevel would you recommend to use for a normal doom2 format map and to avoid overflows (with the stairbuilding option left off)?

Yeah, compatibility levels override the settings for Doom and Boom (except a few aesthetic ones that don't affect demos). For MBF and above, any settings available to that version may be toggled.

This reminds me, I found a bug in compatibility level 7 (Boom's Doom compatibility, which I've recommended in the past... too bad, it seemed promising but has failed to deliver), so don't use it: monsters get stuck like in MBF when resurrected by arch-viles (possibly with respawn as well, though I haven't checked that).

The problem you're having is what I dislike about the multiple individual settings MBF introduced. They are prone to cause confusion that generates bugs during play and to complicate consistent demo recording. They would be better if they could be set easily, as per dmflags in Quake and ZDoom. Then you could run the game like this:

PrBoom -compflags 7689220

Demos could be of the current PrBoom version (or any version that supports the individual settings), applying the corresponding settings. I think we should insist upon a remedy of that sort.

You might also have some luck asking the ZDoom devs to apply a 0-1-2 setting for the stairs, to make that behave just like Boom if the setting is 2. I'm guessing they might do it if they find this problem likely or to be present in other WADs.

So, as things are currently, you'll have to stick to 2, use 9 and break ZDoom, or use the individual settings, which the players will have to mess with before recording.

There's a stairbuilding option in ZDoom, but it doesn't change how the raise-from-both-ends kind of stairs behave.

Yeah, it seems that for the most part ZDoom behaves like Boom, except in this sense you've found here. With the compatibility enabled, it behaves like Doom.

[Andy Olivera]

ToD: When you say "to avoid overflows", do you mean Spechits and Intercepts? If so, you can disable the emulation while still using -complevel 2. That way, there's a chance it may play back in v1.9, anyway. If that's what you're shooting for, that is.

[myk]

I'd use that only if discounting Doom (and Doom+) and such completely. My response to that is usually, why use the format or nomenclature of something to produce something incompatible with its behavior? PrBoom itself shouldn't have a problem either way, unless the all-ghosts bug pops up, which becomes more likely with increasing number of things crawling about a level and more so if the level is also detailed. If you use emulation the only problem in regard to Doom+ in many maps may also be intercepts, which isn't raised at all (to keep backward compatibility with Doom).

The issue you'll have messing with overflow emulation settings is that players tend to forget they removed them, later unnecessarily creating incompatible v1.9 demos, so it's better to stick to overflow emulation always. The only (rare) occasions where you'd really need to disable OE is in cases where people accidentally or purposely removed it.

Hopefully PrBoom+'s new demo footer code will take care of overflow emulation so that when playing back demos without it it's not necessary to change one's own settings. Granted, this doesn't affect older demos, which won't ever have that extra data.

[wazzup]

Hey,
I love how glboom-plus works now, it looks fine now where are graphical glitches from the original games. It becomes my favorite sourceport.
Still, I have a glitche in the first map of AV : the secret to the mega-health looks wrong. I've noticed this with previous versions of the sourceport and differents graphic cards (I'm currently on a Geforce 9600 gt with the latest drivers and directx 9.0c).
Is it possible to fix this ?

[entryway]

wazzup said:

Is it possible to fix this ?

It's possible :)

[wazzup]

Great :D Could you tell me how this bug works please ? I'm interested about why the open gl makes this here with this trick in the doom engine.

[entryway]

The new version of PrBoom-Plus could be found on:
http://sourceforge.net/projects/prboom-plus/

Change Log

2.5.0.2 @ 2009 May 09

[+] Support for DeePsea's tall patch method: Now it's possible to use patches of any height.

[+] Support for hi-res textures in wads. You should place them between HI_START/HI_END markers.

[+] Fog in "gzdoom" lighting mode.

[+] High Quality Resize modes. Scale2x/3x/4x are supported. Thanks to Benjamin Berkels.

[+] An alternative way of sky drawing was added. "Sky Mode: Skybox". It's slower than the "Standard" method, but looks better if you use mouse look. Also, it's the only way to see skies properly on old hardware, like 3Dfx Voodoo Graphics, ATI 3D Rage Pro, and others which don't support "Environment Mapping".

[+] Added a "gl_clear" config variable for clearing the screen between frames. This is only necessary when developing a map, to see HOMs.

[+] Added a "gl_ztrick" config variable for very old hardware, like 3Dfx Voodoo, NVidia RIVA128, etc. If this toggle is enabled the game will not clear the z-buffer between frames. This will result in improved performance (~10%) but might cause problems for some display hardware. Makes sense with gl_compatibility 1 and gl_clear 0. Do not use it with TNT2 or better, as performance will be slower.

[+] Now PrBoom-Plus can save all necessary playback information at the end of demos without loss of compatibility. With such demos you just need to type "prboom-plus demoname" or click on a demo from your browser, archives manager or explorer and prboom will make any additional work by itself without any assistance. PrBoom-Plus will check for a demo footer and if it is present, will read which IWAD, PWAD and DEH files were used for recording, will try to download necessary add-on files from the Internet and will play the demo for you.

Currently, PrBoom-Plus saves the following information (with demo_extendedformat 1):

* VERSION - version of DemoEx format (1.0)
* PORTNAME - port name and version (PrBoom-Plus 2.5.0.1)
* PARAMS - iwad, pwads, dehs and critical for demos params like -spechit
* MLOOK - mouse look data

For the automatic downloading of files, one must specify the getwad_cmdline parameter in the PrBoom-Plus config file. Examples:

* getwad_cmdline "D:\games\Doom2\getwad\getwad.exe"
* getwad_cmdline "C:\my_cool_app -download_pwad_from_somewhere %wadname% -here c:\doom2"

[+] PrBoom-Plus can now apply Boom colormaps to hires resources.

[+] Supports independent OpenGL filtering methods (nearest, linear, etc) for textures, sprites and patches.

[+] It's now possible to change screen resolution from the GUI.

[+] An option to see any monsters that are still alive through walls. By default it's toggled with "Numpad /". It has two modes: All sprites with living monsters or living monsters only. Works only in GL mode.

PrBoom will attempt to play a DEMO4 lump present in a wad immediately after DEMO3, but without exiting with the "W_GetNumForName: DEMO4 not found" error that the Plutonia and TNT executables get. This makes sense for Plutonia 2, which includes a DEMO4 lump that is played back during the demo cycle by vanilla Plutonia.

"PrBoom-Plus" title instead of "PrBoom" on the CREDITS screen page.

Doesn't alter the default skill level when the difficulty skill is selected from the New game menu. An explicit default skill option was added instead, shoehorned into the misc section of page 2 of the General menu.

Smoothing for the edges of textures with holes. (And not only for sprites, as before.)

Screenshots in "gzdoom" lighting mode use current gamma.

Reconfiguration in menu.

Better and faster mipmapping for modern hardware. Support for GL_ARB_TEXTURE_NON_POWER_OF_TWO extention.

Two service variables for developers were added: gl_color_mip_levels and gl_fog_color.

PrBoom-Plus doesn't use detail texture over hires textures.

Textures are reloaded after changing the "Override PWAD's graphics with Hi-Res" option.

Smart algorithm for more seamless flats drawing. In some situations this removes seams from hires flats (between sectors 125 and 126 on map20 @ doom2.wad, etc).

Speed improvement in OpenGL mode.

Can play any episode with The Ultimate Doom, Final Doom, Doom95 and DosDoom compatibilities and -warp command line switch. Now you can play E5M1 @ 2002ado.wad with "-warp 5 1 -complevel 3". The (vanilla) Ultimate Doom executable also allows this.

Some interpolation code was optimized. This fixes slowdowns on the beta of ndcp2.wad map02.

Speed improvements. Some timedemo examples for my hardware (Intel Core2Duo 3.0, NVidia GeForce 8800 GTS):
Command line: [port] -geom 640x480 -window -nosound -file [pwad] -timedemo [demo]
Files: epic.wad, epic.lmp, nuts.wad, nuts.lmp, dv.wad

                          epic.wad   nuts.wad   dv.wad
glboom  2.5.0             126        53         560
glboom+ 2.5.0.1           234        130        640
glboom+ 2.5.0.1.fast      277        134        705
glboom+ 2.5.0.2           362        149        834

prboom  2.5.0             174        115        400
prboom+ 2.5.0.1           158        114        382
prboom+ 2.5.0.2           191        121        424

[-] Fixed a rare wrong sprite rotation glitch when render_paperitems is 0.

[-] Avoids segfaults on levels without nodes, and refuses to load maps with an incomplete pwad structure.

[-] Avoids segfaults with unknown patch formats, and checks if the patch lump can be a Doom patch.

[-] Gets rid of a line of graphics on some middle textures with holes. Sector #42 on gravity.wad as an example.

[-] Doesn't render holes between flats and walls in some situations, on some hardware. Sector #557 @ map21 @ pl2.wad. GLBoom-Plus now renders per linedef instead of per seg. Performance has increased a little as a bonus. Also, some small texturing glitches are gone. See linedef #361 @ bbb.wad, as an example.

[-] Gets rid of a half-pixel mismatch on seams between identical and correctly aligned textures in GL. This was an old GLBoom bug which is now fixed.

[-] Fixed incorrect flipping for "Transfer Sky Texture" actions (272 <-> 271) in OpenGL.

[-] Fixed issue with near-clip plane. Works only on NVIDIA.

From PrBoom
- Don't set default skill level from the new game menu. Added explicit default skill option.

[myk]

The automap in PrBoom+ is filled in regardless of what mode you're in. This changes game dynamics from the usual behavior in Doom and Boom (or PrBoom). In the original, the automap is not too useful for navigation during exploration, discouraging the player from being in automap mode while discovering new areas. While minor, that limitation can be considered a game feature and there is no need to invariably disrupt it in an engine that is otherwise so capable at behaving like the originals (either Doom or Boom).

Is there an option to disable this? I didn't see any info in usage.txt nor an option in the Automap menu. There's an automapmode CFG setting but that seems to be there to add map rotation, overlaying and grid.

[entryway]

myk said:

The automap in PrBoom+ is filled in regardless of what mode you're in. This changes game dynamics from the usual behavior in Doom and Boom (or PrBoom).

What? IIRC, an automap in prboom-plus is similar to prboom. What version or prboom+ do you use? Few years ago prboom-plus had bug in automap code.

[myk]

I'm using GLBoom+ 2.5.0.2 (but in software mode). What I mean is that if you go into automap mode and move or turn the player, unexplored parts of the map are drawn. If you go into automap mode in PrBoom 2.5.0, Boom or Doom, the map is not drawn when you move or turn, and only when you are in your first-person view.

[TimeOfDeath]

Is it possible to make an optional kills counter that acts like zdoom's and doesn't break demo compatibility? ex: When an archvile revives a monster, it gets added to the kill counter as a new monster - can only get 100% kills, not 100+.