PrBoom-Plus, ver. 2.5.1.4

[entryway]

K!r4 said:

Yeah it's maybe a driver problem (I have also this kind of gamma problems with few sourceport for Quake).

BTW, do you have the same problem with gzdoom?

[Kira]

It works fine with the latest GZDoom !

[entryway]

K!r4 said:

It works fine with the latest GZDoom !

I had your problem with most versions of gzdoom (had/have no with glboom-plus), but currently I haven't it even with gzdoom, so we wait for Graf.

P.S. From gzdoom:

if (!Windowed && SM14)
{
	// Fix for Radeon 9000, possibly other R200s: When the device is
	// reset, it resets the gamma ramp, but the driver apparently keeps a
	// cached copy of the ramp that it doesn't update, so when
	// SetGammaRamp is called later to handle the NeedGammaUpdate flag,
	// it doesn't do anything, because the gamma ramp is the same as the
	// one passed in the last call, even though the visible gamma ramp 
	// actually has changed.
	//
	// So here we force the gamma ramp to something absolutely horrible and
	// trust that we will be able to properly set the gamma later when
	// NeedGammaUpdate is handled.
	D3DGAMMARAMP ramp;
	memset(&ramp, 0, sizeof(ramp));
	D3DDevice->SetGammaRamp(0, 0, &ramp);
}

So I need to set the gamma 'to something absolutely horrible' before the real values, heh?

[entryway]

Fixed.

[Graf Zahl]

That piece of code is from the ZDoom D3D renderer for 2D graphics. I didn't even know that GL might need it to and this code never gets executed with the GL renderer active.

[entryway]

Graf Zahl said:

That piece of code is from the ZDoom D3D renderer for 2D graphics. I didn't even know that GL might need it to and this code never gets executed with the GL renderer active.

I take it and it works for K!r4

http://pastebin.com/m124954c6

So it is strange why gzdoom works correctly for K!r4 if similar code is not used for GL, but prboom-plus began to work correctly with that. And as I spoke, GZDOOM had this bug for me in many versions, but maybe only on my old Radeon 9800. I do not remember

[entryway]

entryway said:

Apply this patch to your doom2p.exe or doom2.exe and start the demo with modified exe. It should create e6y file in exe's directory. Look into it and use its contents with this test version of prboom-plus.

glboom-plus.exe -spechit magic_from_e6y -file SCI2.wad -deh SCI2.DEH -playdemo S205n546.lmp

Does anybody still have this patch? I want to try to fix new desynch on strain\map22 and need to log some info during playback with strnhack.exe, but I do not want to hack doom2.exe from scratch.

BTW, this desynch affects even chocolade-doom

[CODOR]

entryway said:
Does anybody still have this patch?

spechit_magic.zip

[entryway]

CODOR said:

spechit_magic.zip

Thanks

entryway said:

BTW, this desynch affects even chocolade-doom

I have fixed this bug.

Take a look at the demo. This demo plays correctly in prboom-plus 2.4.8.2 and in the current chocolate-doom, but desynches in the original strnhack.exe. It happens because:

1) P_GiveArmor(player, armortype) is inlined in doom2.exe

2) There are two entries of GiveArmor(*,blue_armor_class) in sources. The first is for MegaArmor and the second is for Supercharge.

3) If you change "Blue Armor Class" value in DEH, then dehacked replaces only first entry in EXE (MegaArmor entrie). So for the second (for Supercharge entrie) we must always use armortype=2 instead of blue_armor_class value from DEH

Chocolate-Doom must apply this fix too

[Graf Zahl]

entryway said:

and the second is for Supercharge.

You mean Megasphere, right?

[entryway]

Graf Zahl said:

You mean Megasphere, right?

Yeah. 200 200

[fraggle]

entryway said:

Chocolate-Doom must apply this fix too

Will do. Thanks for this. One other question: does the same problem potentially apply to the green armor class? I'm currently setting the armor class to the dehacked value when the player picks up either a green armor shirt, or an armor helmet (and currently has no armor). Should that just apply to the armor shirt and not the helmet?

[myk]

fraggle said:
Should that just apply to the armor shirt and not the helmet?

Yeah, if you set the AC of the normal armor to 2 the armor bonus by itself still uses AC 1.

[entryway]

fraggle said:

One other question: does the same problem potentially apply to the green armor class? I'm currently setting the armor class to the dehacked value when the player picks up either a green armor shirt, or an armor helmet (and currently has no armor). Should that just apply to the armor shirt and not the helmet?

Yes, you are right.

You can download this archive and apply gac.deh to doom2.exe and watch the demo. In doom2 you will die at the end, but in prboom and chocolate you don't.

Must be fixed.

[chungy]

Is there any possibility of getting a scaler similar to Chocolate Doom?

Specifically, something that will accept non-integer scalings, perform aspect correction and all that jazz. For example, if I need/want to set the fullscreen mode to 640x480 but retain the same look as 320x200 would give, I can't do that in PrBoom+... (this is particularly important with my laptop, which for no reason doesn't support 320x200 or 640x400).

[entryway]

MikeRS said:

For example, if I need/want to set the fullscreen mode to 640x480 but retain the same look as 320x200 would give, I can't do that in PrBoom+...

You can give only 640x400, 960x600, etc from 320x200 by means of render_screen_multiply variable, but your request can be coded easily I think

MikeRS said:

this is particularly important with my laptop, which for no reason doesn't support 320x200 or 640x400).

Why you simply do not want to use 640x480? Yesterday I fixed scaling bug for pacthes. Small HUD elements now look clear in 640x480 in software mode

http://prboom-plus.sf.net/patches_before_after.png

[chungy]

Because I'm looking to being able to play the 320x200 experience in PrBoom+ even if I can't use either 320x200 nor 640x400 directly... plus, 640x480 was only an example and it was too bad it happened to be a 4:3 resolution. I was thinking along like the lines of Chocolate Doom as well where I'm able to set it to 1280x800 for my native laptop screen resolution, and it'll pillarbox the image to retain the game's 4:3 aspect.

Probably a bit much to ask I'm sure, but I thought I might as well throw it out in the air so long as I can't do it myself.

[Csonicgo]

I had a display driver that did this. turns out it was fixable by modifying the registry.


Mike, is your display adaptor "Unichrome" by chance?

[chungy]

Nope, Intel GM965/GL960

In particular, xrandr says this:

LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800       59.9*+   60.0  
   1280x768       60.0  
   1024x768       60.0  
   800x600        60.3  
   640x480        59.9

If I had the VGA connected, it wouldn't make any difference, nor will editing xorg.conf to include 320x200 and 640x400 modes (i've tried it already).

[HackNeyed]

That scaling fix sure is better then it was though its still kinda blotchy. Thanks for working on it. :)

*moved from wrong topic* In the 2008-Jul-22 0223 test release using glboom-plus or glboom-plus_icc there is no change when I adjust the gamma in GLBOOM mode and there are also 32 steps in the adjustment as their are for GZDOOM and MIXED modes, not the 4 steps as there has been for GLBOOM mode.

Otherwise I do love this port and think everyone is doing a fantastic job.

...

I don't know if this is the place but if I may mention a couple things I would like to see added to help my setup and maybe others. I think similar sugestions have been made and are not a priority but here goes.

To run HACX my command line looks like this...

-iwad DOOM2.WAD -complevel 2 -save HACX -file HACX\HACX.wad -deh HACX\HACX.deh

Instead of a single "default_compatibility_level" in the config maybe allow a default_compatibility_level setting for each iwad so the config could look like this...

default_compatibility_level_for_DOOM.WAD 2
default_compatibility_level_for_DOOM2.WAD 2
default_compatibility_level_for_DOOMU.WAD 3
default_compatibility_level_for_TNT.WAD 4
default_compatibility_level_for_PLUTONIA.WAD 4

and my glboom config could just be all 9s or -1

Coupled with the above another feature that I would like to see would be for the launcher to act more quake like. Have it scan all sub folders for wads compatible with Doom or Doom2 and show\hide folders that contain compatible/incompatible wads for the currently selected iwad as it does now for pwad and deh files in the run folder. Then when you select a folder to run it will load all wads and dehs found inside and use that folder for the -save folder command (and maybe, maybe not copy the current prboom-plus.cfg to that folder for a per folder custom config\control like quake does since mouse look might be good for some wads but not most or custom screen sizes etc... ) To save some start up time a list of files and folders could be saved in a txt file that could be updated with a "scan" button when the user has added or deleted content.

Add some -skill and -warp and -record command boxes and one may never need mess with the command lines or clunky launchers again if they like.

[entryway]

HackNeyed said:

*moved from wrong topic* In the 2008-Jul-22 0223 test release using glboom-plus or glboom-plus_icc there is no change when I adjust the gamma in GLBOOM mode and there are also 32 steps in the adjustment as their are for GZDOOM and MIXED modes, not the 4 steps as there has been for GLBOOM mode.

fixed

[Karnizero]

Is "Flashing HOM Indicator" working at PrBoom+, software mode and/or GL mode?

If so, how to activate?

[GreyGhost]

Don't know if it's working - look in the General options.

[Karnizero]

GreyGhost said:

Don't know if it's working - look in the General options.

I have already activated at General Options, but it seems not to work.

I have started PrBoom+ (both OpenGL and Software modes) with "-devparm" parameter.

@ entryway: would be possible to change the HUD distribution as in Eternity, in future versions?

[entryway]

Karnizero said:

I have already activated at General Options, but it seems not to work.

I have started PrBoom+ (both OpenGL and Software modes) with "-devparm" parameter.

"Flashing HOM indicator" option does nothing (fixed). Currently you can use tnthom cheat to see HOMs in prboom-plus.exe

Karnizero said:

@ entryway: would be possible to change the HUD distribution as in Eternity, in future versions?

It always was as in Eternity. Or you speak about state with big numbers without status bar? If so, then NO, I do not want/like that style

[Karnizero]

entryway said:

"Flashing HOM indicator" option does nothing (fixed). Currently you can use tnthom cheat to see HOMs in prboom-plus.exe

Ok, thanks for tip, but... how about if that option turns on and off that cheat? That sounds more as a mapping feature than a cheat.

entryway said:

It always was as in Eternity. Or you speak about state with big numbers without status bar? If so, then NO, I do not want/like that style

I mean this: http://xs129.xs.to/xs129/08312/hudoption771.png

So you get this instead of this.

I also hate those Big red number without status bar ;P

[entryway]

Karnizero said:

Ok, thanks for tip, but... how about if that option turns on and off that cheat?

It is already fixed
http://prboom-plus.sourceforge.net/history.html

Karnizero said:

So you get this instead of this.

Press F5 few times. There are three HUD styles

[chungy]

Yeah, that's not an Eternity thing... it goes back to the original Boom.

[HackNeyed]

While messing around with “boom_compatibility_compatibility” I noticed that on map 30 of the TNT iwad the stairs to the red key are broken just as they are in “boom_202_compatibility”. However, in prboom202 setting orig_doom_compatibility to 1 in the config fixed the stairs and allowed me to access the red key in this demo I recorded and the demo will play back fine in both prboom202 and boom202 but when played in prboom-plus the stairs fail to reach the top and the demo desynchronizes.

TNTcomp.lmp

And in the last few prboom-plus' the save and load menu's have gaps in the boxes.

gaps.jpg

Also lastly, I think this has been a problem for a long time but when I bind “Setup” to a key, like the ~ key it works until I quit prboom-plus and then is unbound the next time. I guess it isn't being saved in the config. Though of course binding to the mouse wheel and extra buttons would be a far more useful thing to get working.

Thanks.

EDIT: My demo also plays fine in Eternity v3.33.50-win32

[entryway]

HackNeyed said:

And in the last few prboom-plus' the save and load menu's have gaps in the boxes.

fixed

HackNeyed said:

While messing around with “boom_compatibility_compatibility” I noticed that on map 30 of the TNT iwad the stairs to the red key are broken just as they are in “boom_202_compatibility”. However, in prboom202 setting orig_doom_compatibility to 1 in the config fixed the stairs and allowed me to access the red key in this demo I recorded and the demo will play back fine in both prboom202 and boom202 but when played in prboom-plus the stairs fail to reach the top and the demo desynchronizes.

fixed too