PrBoom-Plus, ver. 2.5.1.4

[myk]

entryway said:
I am afraid to break something

http://prboom-plus.sf.net/test.zip

There is new config variable render_oldmaps (suggest a better name) for 16 and 32 lightlevels

It looks fine from what I can tell! Maybe render_old_lightmaps? No need to abbreviate what fits fully.

If you like my "status bar extension" idea of using an adjusted FLAT5_4, you could have PrBoom+ search for a flat called STBAREXT and a graphic called BRDR_EXT, and use these instead of the defaults, so people using nonstandard status bars in their mods or their favorite WADs can have a seamless look.

[entryway]

myk said:

If you like my "status bar extension" idea of using an adjusted FLAT5_4, you could have PrBoom+ search for a flat called STBAREXT and a graphic called BRDR_EXT, and use these instead of the defaults, so people using nonstandard status bars in their mods or their favorite WADs can have a seamless look.

I do not see any reasons for using FLAT5_4 instead of GRNROCK for doom2 and FLOOR7_2 for doom.

1. GRNROCK and FLOOR7_2 are already used for background if screenblocks < 10. Different textures for stbar and background frame will look strange.

2. FLAT5_4 is not width-independent, because of strong vertical bricks on it.

[myk]

entryway said:
I do not see any reasons for using FLAT5_4 instead of GRNROCK for doom2 and FLOOR7_2 for doom.

Because the status bar looks ugly with some greenish stuff on the side. The flat is in both IWADs, so it can be used by either game. It's even part of the shareware IWAD.

GRNROCK and FLOOR7_2 are already used for background if screenblocks < 10.

No one uses smaller screen sizes nowadays, and that screen border is a different structure than the status bar, thus colored differently.

Different textures for stbar and background frame will look strange.

Exactly, that's why I'm suggesting to make them more similar :p

That, and with a way to make WADs that change the status bar also look fine (STBAREXT and BRDR_EXT.) And gray and greenish is somewhat tolerable, but then some WADs have red or orange status bars where the colors start to clash in a really bad way.

My theory is that when you change visuals you must make amends so that what's changed looks good with what was already there.

FLAT5_4 is not width-independent, because of strong vertical bricks on it.

It doesn't tile well? I'm not sure what bricks you are talking about, as it's a cement or concrete flat, rather similar to the status bar (probably from the same base artwork or picture):



EDIT: Maybe you were looking at FLOOR5_4? That one has brown rectangular bricks or stones...

[entryway]

-

[HackNeyed]

Perhaps I'm misunderstanding it but wouldn't things be less cryptic if it were labeled as follows.

"render_lightmaps [Doom] \ [PrBoom]"

OR

"render_doom_lightmaps 1" (new default)

Because, from my understanding, render_old_lightmaps 1 means it will use the old prboom method yet render_old_lightmaps 0 will use the new prboom+/old doom.exe method. Confusing I think... or simply confused I am.

Now, for the status bar and hud I like either suggestion by you and myk.

myk said:

They seem more like "not adjusted", "Doom format" and "fit to width".

The option could be just "status bar and menu appearance", if that's not too long.

entryway said something like:

"k-stretched (chocolate)", "4x3 stretched (zdoom)", and "fullscreen (prboom)"

Thanks

[entryway]

HackNeyed said:

Now, for the status bar and hud I like either suggestion by you and myk.

Help me to fix bugs quickly

http://prboom-plus.sf.net/prboom-plus-2.5.0.4.test-win32.zip

Options\General\Status Bar and Menu Appearance: Not Adjusted / Doom Format / Fit to Width

[Never_Again]

[printz]

PrBoom+ 2.5.0.3 goes on with the crashing on my Mac... I was playing on -fast, at E2M7, damnit! I did die twice, in a previous level (E2M6) until then. I haven't noted the crash report, but PrBoom didn't quit with any error. It was a generic crash, but I didn't copypaste it. Still, it's a big bummer (not your port, the crashing).

[HackNeyed]

The only problem I find is that 320x200 and 16:10 and Doom Format together are messed up, though in a slightly different way then before. I get either the following message or image.

I_SignalHandler: Exiting on signal:
signal 11



At least I can select 'not adjusted' or 'fit to width' to get around it.

Otherwise Doom Format could still use Choco quality filtering but I'm happy enough to have 'not adjusted' available.

Thanks entryway!

[ReFracture]

I really like 'not adjusted'. Thanks entryway.

[entryway]

HackNeyed said:

The only problem I find is that 320x200 and 16:10 and Doom Format together are messed up, though in a slightly different way then before. I get either the following message or image.

Fixed, but, of course, patches look like shit if you try to use 4x3 (Doom Format) for them with forcing 320x200 as 16x10, because of downsampling

[ReFracture]

http://img233.imageshack.us/img233/5797/secrett.jpg

1680x1050
16:10
Not Adjusted

[entryway]

Mike.Reiner said:

http://img233.imageshack.us/img233/5797/secrett.jpg

1680x1050
16:10
Not Adjusted

fixed

1680x1050, software, "Not Adjusted" fixed also

[entryway]

No bugs with "wide" and "scaling" code? I'll release then

[ReFracture]

entryway said:

No bugs with "wide" and "scaling" code? I'll release then

Sorry, I haven't really had the time to do much testing, but from what I was playing earlier today I haven't seen any other issues.

[HackNeyed]

entryway said:

No bugs with "wide" and "scaling" code? I'll release then

My tests havent turned up any more bugs. Thanks.

[entryway]

The new version of PrBoom-Plus is available:
http://sourceforge.net/projects/prboom-plus/

Change Log

2.5.0.4 @ 2009 Oct 08

[+] Full support for wide resolutions. Aspect will be detected automaticaly, but you can force any ratio from the GUI.

[+] Options\General\Status Bar and Menu Appearance: Not Adjusted / Doom Format / Fit to Width.

[+] Added a -nocheats command line parameter and a deh_apply_cheats config variable to disable applying cheats from dehacked files.

[+] Added a key binding option for mouse look.

[+] Added a "map_grid_size" config variable.

[+] Added a "linear mipmap" texture filtering mode.

Less aggressive patch correctness checks. Makes sense for OBITUARY, where for some patches there is no column beginning exactly at the end of the column directory.

More permissive cheats handler for non-Boom complevels. The following DEH cheats now work:

No Clipping 1 = !@#$%^&*() - you can't move in Boom with such a cheat
No Clipping 1 = bb - works incorrectly in Boom
No Clipping 1 = b/b - does not work at all in Boom, but works in vanilla

Making a short sequence on a cheat with parameters (idclevXX) will not work in vanilla (0-6) and lxdoom (10) complevels, as in the respective engines.

Ignores sprite lumps smaller than 8 bytes (the smallest possible) in size - this was used by some dmadds wads to mark 'empty' graphic resources. Now you can play 22ventry.wad.

The Boom DEH parser has been restored. You can force it only for demo playback with -boom_deh_parser command line switch.

[-] Fixed a crash on wads with incomplete REJECT table. (introduced in 2.5.0.2)

[-] Fixed an incompatibility with Boom if you have player_bobbing 0 in cfg. (introduced in PrBoom 2.2.2) As a result, there is now a desynch on sewv12r-2135.lmp. Use -emulate 2.2.2 .. 2.5.0.2 for the old buggy behavior when playing such demos.

[-] Fixed a crash related to A_BFGSpray with NULL target when using dehacked patches - discovered with insaned2.deh (thanks CSonicGo and fraggle). Certain functions assume that a mobj_t pointer is non-NULL, causing a crash in some situations where it is NULL. Vanilla Doom did not crash because it lacked proper memory protection.

[-] Fixed a crash (division by zero) in Boom HUD code for "Max ammo = 0" in a DEH.

[-] Fixed flats drawing on a Mac in case of render_precise 1.

[-] Fixed an overflow of the mapnames array (-iwad tnt.wad -file ht.wad -warp 33)

[-] Avoids z-fighting between grid and walls on automap in GL mode. (introduced in 2.5.0.3)

[-] Fixed a vanilla automap grid bug: losing grid lines near the map boundary. (from EE)

[-] Fixed an issue where walls look full-bright from close up. Added a "render_old_lightmaps" config variable for 16 (old) or 32 (new) lighting levels.

[-] Fixed an issue with fake floors. See the colored room in boomedit.wad, as an example. (introduced in 2.5.0.2)

[-] Hi-res textures in TGA format are now loaded from PWADs.


Full Change Log

[Doom_user]

When starting a 2 player coop game, player 2's uniform will be gray for a fraction of a second, then turn green and remain that way for the remainder of the game.

Is this a bug or the correct behavior?

[myk]

It's a bug that's been there for a long time. The PrBoom player color scheme was wrecked at one point. I think someone tried to add 8-player support or something and changed it and made it buggy. Not only does it apply the colors incorrectly, but it also applies strange color ranges. I think it's using an RGB scheme like ZDoom does (to support more colors), which is incompatible with what Doom, Boom and MBF do. They apply palette swapping, instead. I think the original colors should be restored, as I don't see the point in adding more player support. That should be left to multiplayer-oriented engines, like Odamex.

[HackNeyed]

There seems to be a problem with Arch-Vile flames and uncapped fps. It's not new but I never thought it was so bad until now.

I finally had some free time tonight to make some demo runs on ht map05 and it is really hard to spot the Arch-Vile's attack. With an fps of 112 in that area the flame animation often fails to render properly giving me very little, if any, warning. The Arch-Vile can see me and attack when I can not see it from in front of the hangman gallows with the Hell Knight and 2 Barons. Since I can't hear the flames over the sound of the plasma rifle it makes seeing the flames very important.

When software is capped to 35 they show up as intended. When I use GL with vsync (60) or increase the software resolution until the frame rate is around 61-55 they nearly show up as intended.

My first thought to fix it is to simply allow a software cap of 70 fps. Maybe even doubling the length of time each flame is displayed when the frame rate is doubled?

This could be the menu entry...

Frame Rate Cap: Normal (35) / Double (70) / None (Uncapped)

What does anyone think? Can it be done? Is there a better way?

[Never_Again]

[Gez]

Never_Again said:

When firing the super shotgun, there is a very thin wide garbage-colored
line across the barrels. Only appears with the following filter option:

That's right at the bottom border of the flash sprite for the SSG.

[entryway]

Never_Again said:

When firing the chaingun, there is sometimes a short light horizontal line
right over the flash fire. Curiously, the line appears and disappears as
you move around a level.

When firing the super shotgun, there is a very thin wide garbage-colored
line across the barrels. Only appears with the following filter option:
General / Display Options / Drawing of Patch Edges = Sloped

This is prboom bug. Exists even in old 2.3.1 which is parent of true color rendering and filtering/sloped stuff

[ReFracture]

Found an issue with The Ultimate Doom when using 'not adjusted'.

http://img2.imageshack.us/img2/5367/bug1n.jpg

http://img261.imageshack.us/img261/5615/bug2l.jpg

http://img185.imageshack.us/img185/6168/bug3q.jpg

[entryway]

Mike.Reiner said:

Found an issue with The Ultimate Doom when using 'not adjusted'

Stat screen animation with The Ultimate Doom and background for parade of monsters after MAP30 when using 'not adjusted' are fixed.

[HackNeyed]

PrBoom-Plus 2.5.0.5.test crashes when I attempt to play a demo by launching the .lmp file. Using new or old sdl files does not matter. When I use the 2009-Oct-16 1541 build it works, when I replace it with a newer version I get this error.

"I_SignalHandler: Exiting on signal: signal 11"

Also, -complevel, -iwad, and -file commands work however adding -skill 4 or -warp 07 result in the above error even for version 2009-Oct-16. So I seem to have this error with all 2.5.0.5.test versions.

[entryway]

Try the latest 2.5.0.5.test @ 2009-Oct-23 16:25 with "-devparm" if you still have "Signal 11" message and give me drwatson log (in case of NT based OS) or at least address of crash. glboom or prboom? cfg?

btw, it's absolutely amazing, the latest sdl_mixer 1.2.9 does not work at all for me.

[HackNeyed]

I'm running XP and used -devparm and am having difficulty finding the drwatson log. My crash.zip holds my .bat, prboom-plus.cfg, stdout.txt, and the (empty?) stderr.txt

AppName: prboom-plus.exe AppVer: 0.0.0.0 ModName: prboom-plus.exe
ModVer: 0.0.0.0 Offset: 0007c23d

crash.zip

[entryway]

HackNeyed said:

I'm running XP and used -devparm and am having difficulty finding the drwatson log.

<Win+R> drwtsn32 <Enter>

By default log is here:
"C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson\drwtsn32.log"

If it is not installed: drwtsn32 -i

p.s. Why do you use 32bit? It does nothing (except slowdowns) without filtering. Looks like your crash is in V_UpdateTrueColorPalette. Attach drwatson log for details.

[HackNeyed]

-EDIT2-

I ran drwtsn32 -i as soon as I read your post and then ran prboom and it crashed... when I run drwtsn32 and click view log I get this text which I have copy/pasted to a .txt file here.

But that was when I was running 32bit.

-EDIT-

entryway said:

p.s. Why do you use 32bit? It does nothing (except slowdowns) without filtering. Looks like your crash is in V_UpdateTrueColorPalette. Attach drwatson log for details.

That was my glboom config where I was testing things and just left it at that and renamed it back to a prboom config.

So, hmm, switching to 8bit lets my .bat run with -skill and -warp but loading .lmp still crashes with the signal 11 error. First I used the auto loading then added the .lmp to the bat with -devparm but it wont generate another drwtsn32.log.