PrBoom-Plus, ver. 2.5.1.4

[entryway]

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

The latest dev build and change log:
http://prboom-plus.sourceforge.net/history.html

Edited March 14, 2017 by entryway

[Fredrik]

Cool.

Speaking of nothing, do you plan to record episode 2 or continue your max run of Doom 2 soon? :)

[Grazza]

OK for me so far, though I needed to use my existing .cfg file (rather than the one supplied or letting the program create it from scratch).

BTW, the prboom.cfg included in the zip has the gamespeed (realtic_clock_rate) set at 110, which is surely an oversight.

I haven't tested it for recording so far though (and probably won't have time to do so for quite a while).

[entryway]

Grazza said:

BTW, the prboom.cfg included in the zip has the gamespeed (realtic_clock_rate) set at 110, which is surely an oversight.

Thanks

[entryway]

Fredrik said:

Speaking of nothing, do you plan to record episode 2 or continue your max run of Doom 2 soon? :)

do it yourself. it's easy. it is only necessary to start.

[Janizdreg]

So is this smpeg.dll thingey actually necessary for something or is it just a remainder from the old(er) PrBoom versions? ;)

And BTW, thank you for your awesome work on PrBoom - the latest version of your modification has become my port of choice for pretty much all of my Doom play.

EDIT: Just found a bug... if a new game is started while a demo is playing the game speed & walkcam settings are carried over to the single player game.

[entryway]

Janizdreg said:

So is this smpeg.dll thingey actually necessary for something or is it just a remainder from the old(er) PrBoom versions? ;)
EDIT: Just found a bug... if a new game is started while a demo is playing the walkcam settings are carried over to the single player game.

Thanks. I've reuploaded fixed version.

And BTW, thank you for your awesome work on PrBoom - the latest version of your modification has become my port of choice for pretty much all of my Doom play.

Me too :)) I use only ZDoom and mine GLBoom.

[Grazza]

entryway said:

I've reuploaded fixed version.

The new version of the source is bloated by the inclusion of a long demo (30cmvi.lmp). At least, I presume it isn't now part of the source code. :p

[entryway]

http://www.geocities.com/e6y/files/doom/my/prboom226_6.zip

Changes:
(-) smooth movement: doors activated by lines of the generalized types were not interpolated
(-) mouselook & fov: bugs in sky rendering

[entryway]

http://www.geocities.com/e6y/files/doom/my/prboom226_7.zip

Changes:
(-) smooth movement: "I_SignalHandler: Exiting on signal: 11" bug during rendering of the first frames of heavy scenes (after opening doors)

[Pirx]

entryway said:

(+) full mouselook and FOV in GLBoom (without compatibility loss)

now that's great news.

btw, does it finally play back the alien vendetta demopack correctly?

[Janizdreg]

A little suggestion: add an option for not drawing the player gun sprite in the freely rotatable & player locked view mode.

Also, would it be difficult to add a ZDoom-style chasecam demo playback view mode? Personally I'd love to see one implemented into PrBoom.

[Grazza]

Torr Samaho said:

btw, does it finally play back the alien vendetta demopack correctly?

AFAIK Andrey hasn't made any changes to demo compatibility.

Which one(s) failed? In which version(s) of Prboom? I don't recall problems playing back AV demos. Are you using the right version of the wad (there were two releases, the initial release in late 2001 and the final one in late 2002)?

Janizdreg: There is a chasecam in Eternity and in Prboom 2.3.x, so there may be some ready-made code that could be borrowed.

BTW, I've been finding 226_7 pretty stable, so the various changes since 226_3 have mostly solved whatever the problems were w.r.t. my system.

[entryway]

Janizdreg said:

A little suggestion: add an option for not drawing the player gun sprite in the freely rotatable & player locked view mode.

I agree with you. It is my mistake. I thought that nobody uses the camera mode.

[Janizdreg]

Found another bug: run the game with the -nomusic parameter, start a new game (via the menu) and either kill yourself or start a new game again and the music will start playing.

[entryway]

tnx

[VinceDSS]

Grazza said:

The new version of the source is bloated by the inclusion of a long demo (30cmvi.lmp). At least, I presume it isn't now part of the source code. :p

how funny, this is the 30uv max I did with Xit Vono. At least I know one person watched it besides me and Vono :)

[Kristian Ronge]

Hey, don't say that... I watched it, and found it to be very enjoyable. Only, too bad it desynched PrBoom on map30. :-(

[entryway]

prboom226_8.zip could be found on:
http://www.geocities.com/e6y/doom.html

Changes:
(-) found another bug: run the game with the -nomusic parameter, start a new game (via the menu) and either kill yourself or start a new game again and the music will start playing. (Janizdreg)
(*) not drawing the player gun sprite in the freely rotatable view mode (Janizdreg)
(-) smooth movement: interpolation did not work for moving platforms after savegame load
(-) GLBoom bug: wrong display of a middle texture if it exceeds the boundaries of its floor and ceiling. See http://www.geocities.com/e6y/files/doom/my/bugs/index.html

[Grazza]

Shouldn't this be prboom226_9 (or at least prboom226_8a), to distinguish it from the prboom226_8 that you made available in April?

[entryway]

Grazza said:

Shouldn't this be prboom226_9 (or at least prboom226_8a), to distinguish it from the prboom226_8 that you made available in April?

Accessible for all? I dont remember that I did it. In any case - I've made this version yesterday.

(-) GLBoom bug: wrong display of a middle texture if it exceeds the boundaries of its floor and ceiling

If this works correctly, I think we should send the patch to the prboom devs.

[Grazza]

entryway said:

Accessible for all? I dont remember that I did it. In any case - I've made this version yesterday.

It was on your site, even if you didn't make a post about it here. The exes are dated 5th April, and I've been using it for more than a month. No big deal, just I nearly didn't bother downloading this new version, assuming I already had it.

[entryway]

In the version dated 5th April I have corrected defects found by Janizdreg.

[entryway]

prboom226_9.zip
(-) bugs in the new algorithm of middle textures drawing

[entryway]

prboom226_10.zip
(+) GLBoom: detail texture support for walls and flats. Requires hi-end systems.
http://www.geocities.com/e6y/files/doom/my/detail.html

[Opulent]

interesting, looks good.

I don't know much about such things, but are these standard GL functions, or card specific(ATI or nVidia, etc..)?

[Grazza]

Works nicely for me (P4 2200 MHz; 128MB nVidia GeForce 4). I'll try it with my notebook (newer, more powerful; totally different graphics card) later and let you know if there are any performance issues.

BTW, one feature that I'm sure would be welcomed in your version is a fix for the "monster_avoid_hazards" issue (see this post) so that it works correctly without needing the workaround described there. Another nice fix would be for it screwing up the header info if you record with MBF compatibility (I've reported both these in the Prboom sf forums).

[entryway]

Opulent said:

I don't know much about such things, but are these standard GL functions, or card specific(ATI or nVidia, etc..)?

I am also have a little understanding of programming OpenGL\DirectX. Detail texture's support is implemented via multitexturing if VideoCard supports it (http://www.delphi3d.net/hardware/extsupport.php?extension=GL_ARB_multitexture), or by two-pass method for any other cases.

[Grazza]

OK, I've tested it a fair bit both on my desktop machine and my notebook (Centrino/Dothan 1.8, ATI Radeon Mobility 9700), and there is hardly any effect on performance. Any reduction in framerate is marginal (about 1% perhaps).

Maybe it looks a bit too grainy sometimes though. Are they any settings that affect the way it works, or is it all or nothing? And of course on some textures it just looks odd - you don't expect, e.g., brushed metal to look bumpy close-up. Presumably that couldn't be changed without some very clever programming though.

Overall, it's a good effect, and for now my default setting is to have it turned on.

[entryway]

Grazza said:

OK, I've tested it a fair bit both on my desktop machine and my notebook (Centrino/Dothan 1.8, ATI Radeon Mobility 9700), and there is hardly any effect on performance. Any reduction in framerate is marginal (about 1% perhaps).

p4 3.4 + Radeon 9800Pro
glboom.exe -timedemo lv28-304.lmp

screen_width             1024
screen_height            768
gl_tex_filter_string     "GL_LINEAR_MIPMAP_LINEAR"
gl_tex_format_string     "GL_RGB5_A1"
use_fullscreen           1
render_usedetail         0
render_usedetailwalls    1
render_usedetailflats    1

= 570 FPS

render_usedetail         1

= 430 FPS