PrBoom-Plus, ver. 2.5.1.4

[myk]

Ah, I missed something:

Mike.Reiner said:
Out of curiosity, what is your control scheme?

I use "WESD" with Novert, like this:

W: strafe left
E: forward
S: backward
D: strafe right

Space: run (my thumb is over this)
Control: use (I hit it with the palm of my hand)

I've swapped the Q and console (~) keys to avoid accidentally quitting during recording. Doom quits instantly with it while -record is used. This may sound ironic given what I argued regarding key mapping, but I don't really think unusual mapping is necessarily evil, just that in Doom and Boom compatibility they shouldn't be part of the standard engine behavior to encourage that people play more or less with a certain range of settings, as people have done for years.

~: turn left + strafe (for sr50)*
Alt: turn right (to be used with left mouse to sr50 in the other direction)

* In Q's place.

Right mouse: fire
Left mouse: strafe (also double-click use)

I even made an alias for double-click to work in ZDoom engines and the like where the left button serves as jump instead of strafe, as well as another alias for ~ to work as above. A is scoreboard, C is chasecam, Q is the console, and Y is team talk.

The rest are standard Doom settings (1-8: weapons, T: talk, Tab: automap, F: follow mode, C: clear marks, &c)

I used the default controls, but unlike the smarter players, I used ALT to strafe, and never < or >, so I didn't have the control that others did,

I did that too. I think it's pretty easy to start that way, and even retain that configuration for a long while if one isn't in touch with more players, especially experienced ones. Things like demos and online play make one improve configs quickly (or how to use strafe to full effect), to survive and because one learns from the others.

[ReFracture]

I actually caught that before you made a new post for it. :P

Odd control setup, but I suppose whatever suits you is proper. Easier access to some of the weapons I imagine.

[HackNeyed]

myk said:

Unlike the more rarely used mouse drivers, Novert is a DOOM specific tool that was widely used popular places like COMPET-N and the online Deathmatch scene. If you don't include extra key options you leave things like they were with the DOS executables (Doom and Boom, at least). It's still possible to change them, but it's up to the user to get any apps (drivers, TSRs, OS programs) to do so. This makes them non-standard and secondary.

...

The fun is in using a certain set of physical and coded possibilities to play, which allows a good degree of competitiveness and comparability.

myk said:

A reasonable possibility, other that sticking to Boom behavior in general as PrBoom is more or less doing, would be to enforce engine-specific configuration ranges per compatibility level. This would allow more casual players to choose a wider range (in compatibility level -1 and such), even more liberal than Boom's, and would offer speed runners the input setups of the engines they record for. Most speed runners would thus likely use Doom-compatible input settings, because that's the common denominator.

I couldn't come up with a better word then elitist when it sounds like users can either use the functions provided by the original standard way of defining settings (that you enjoy working within) or they can just forget about playing or recording at your preferred complevel unless they seek out external programs. Of course all doom2.exe speed runners would use Doom-compatible input settings but under your rules nobody else gets the option for more at the complevel they enjoy.

You might be talking about competitiveness and comparability between this engine vs that engine to some extent but what about just giving everyone the option to set up their controls however suites them best and using their in game performance as THE benchmark. COMPET-N doesn't allow ports and I can respect that but then it hardly matters what you can do in a port since it is already disqualified. Again I'm not saying we should even add new functions, 'single click to use' is already programmed into the game.

I can see somewhat where you are coming from though. Back in GoldenEye on the N64 my friends and I used to play the hell out of it and one of them is left handed and I am right handed so he had to take his thumb off the movement controls to reload or change weapons where as I was free to move (ie dodge) while reloading and changing weapons. I thought that was unfair however since he was way better then the rest of us I just considered it a small handicap in our favor. Still, a more 'fair' solution would have been to have those buttons on the other side of his controller so we all had the same options of usable input that fit us individually. Even though some of us were better with the analog stick then others, well, that couldn't be helped but at least it would have been slightly more about our skills in game then about our skills at groping a controller.

I'll admit I was annoyed when I switched from playing Halo where the X button reloads to playing Mercenaries where the X button chucks grenades. I know it was partly my fault for not adapting more quickly and that's why I blew up stuff I intended to shoot but it brings about my point that the less you have to think about 'how to do' the faster you can get into just doing it and reach the gameplay.

I know we aren't going to agree totally and indeed we don't have to either. I think it comes down to where we draw the line. We both enjoy the classic game, bugs and quirks and all. However you see the interface as a part of the gameplay and as another part to 'overcome' if I my stretch a bit where as I see the interface as a means to reach the gameplay that is 'buried' behind it.

This reminds me of a discussion I had with a co-worker on videogames that soon turned into a deadlock discussion of faith, purity, integrity and duality. I said there was nothing wrong with being a good person and playing a game where aside from teamwork and strategy the goal was to kill other digital players even if 'death' and 'harm' were being used in a form of entertainment. She however felt that there was a disconnect there and that purity and integrity were more easily defined when a person is both good in the real world and good in their fantasy world. Now I can agree with that to some extent but aside from the politicians that speak of family first and have a secret lover on the side I feel that it is an overly specialized view that doesn't leave much room for the rest of the world or indeed what makes us human and interesting and individual.

[TimeOfDeath]

I'll probably get made fun of for this, but how about an option to disable infinitely tall actors? Not necessarily for older maps (unless the author says it ok) but the authors of new maps could build their maps to use this option. Like doom2 format slaughter maps.

[ReFracture]

TimeOfDeath said:

I'll probably get made fun of for this, but how about an option to disable infinitely tall actors? Not necessarily for older maps (unless the author says it ok) but the authors of new maps could build their maps to use this option. Like doom2 format slaughter maps.

I've often wondered what is required for such a thing to happen. I've always thought that if such features were ever implemented in PrBoom, that it should only be enabled for wads designed for it. As in, the wad has a lump similar to ZDoom's MAPINFO, that PrBoom could read, and if permitted, enable such features.

But PrBoom+ has a goal of maintaining compatibility, so I don't thing such a thing would ever happen. I'm not really sure if you could implement such a feature without breaking it.

[entryway]

Options\General\COMPATIBILITY WITH COMMON MAPPING ERRORS\Walk under solid hanging bodies?

Allows the player to pass under hanging objects in tall sectors that would otherwise block movement. (Not available for recording, playback or with demo_compatibility.)

[ReFracture]

entryway said:

Options\General\COMPATIBILITY WITH COMMON MAPPING ERRORS\Walk under solid hanging bodies?

So is that the same as not having infinitely tall actors? As in, you could run under caco demons and what have you?

[entryway]

Mike.Reiner said:

you could run under caco demons?

Ah... no, of course. It's only for hanging bodies. Does TimeOfDeath want to walk under cacos in Doom? :) Is it possible in ZDoom? I even did not think about such natural behaviour...

[ReFracture]

ZDoom fully supports limited height actors.

[TimeOfDeath]

Yes, I'd like to walk under and over monsters in PrBoom-Plus. :)
It's not a big deal, I just thought it might be a neat feature for prboom plus, where you can still have the classic Doom feeling but also walk over/under monsters.

Last year I wanted to convert some of my spam maps into Doom2 format maps, but I hated playing it with infinitely tall actors, so I gave up.

[myk]

You could try the Eternity Engine for that. It offers something pretty similar to PrBoom but incorporates many Heretic-like features.

[ReFracture]

I've actually been playing quite a bit of eternity lately (since quasar was looking for people to test out a beta) and it's pretty neat stuff.

[Grazza]

I don't see that this sort of thing (or other Hexen stuff) should introduce compatibility problems, as long as it is optional and not for recording or playback below current complevel.

[tatsurd-cacocaco]

I have two anxious things from previous prboom+ version. (Using win32)

One: A behavior of teleport effect is odd on complevel 4. (Final Doom's doom2.exe)
Two: Status bar depend on light level of the secter. (This occur glboom only)

Can these be fixed?

[myk]

tatsurd-cacocaco said:
One: A behavior of teleport effect is odd on complevel 4. (Final Doom's doom2.exe)

That's actually normal. The releases of Final DOOM that were shipped with a DOS executable (instead of Doom95, or in addition to it) include an executable that is slightly different than the one for DOOM II. Compatibility level 4 emulates this DOS executable, which includes that glitchy teleport behavior (as well as lost souls bouncing like in Doom95). With Final DOOM you can use compatibility level 2 if you want to avoid this glitch (force it in the CFG or the command line).

Many Final DOOM demos on compet-n are recorded with the Final DOOM executable, while some are recorded with the DOOM II executable (true v1.9).

[entryway]

tatsurd-cacocaco said:

Two: Status bar depend on light level of the secter. (This occur glboom only)

send me your stdout.txt

and

do you have the same bug with gl_compatibility 1 in cfg?

[tatsurd-cacocaco]

myk said:

That's actually normal. The releases of Final DOOM that were shipped with a DOS executable (instead of Doom95, or in addition to it) include an executable that is slightly different than the one for DOOM II. Compatibility level 4 emulates this DOS executable, which includes that glitchy teleport behavior (as well as lost souls bouncing like in Doom95). With Final DOOM you can use compatibility level 2 if you want to avoid this glitch (force it in the CFG or the command line).

Many Final DOOM demos on compet-n are recorded with the Final DOOM executable, while some are recorded with the DOOM II executable (true v1.9).

Myk, Thank you for answering. I don't know it. When I bought Final Doom, Doom95 was included in it.

I said:

Two: Status bar depend on light level of the secter. (This occur glboom only)

For example, this my video from 40 seconds. (Using ver. 2.4.8.2)

entryway said:

send me your stdout.txt

OK! here

entryway said:

do you have the same bug with gl_compatibility 1 in cfg?

Yes, I tried it just now.

[entryway]

tatsurd-cacocaco said:

For example, this my video from 40 seconds. (Using ver. 2.4.8.2)

Your report about of such bug is the second. In both cases on board Intel is used. Also I think you have the same problem with all known versions of vanilla glboom. Correct?

EDIT: Fixed?

[HackNeyed]

entryway said:

Your report about of such bug is the second. In both cases on board Intel is used. Also I think you have the same problem with all known versions of vanilla glboom. Correct?

That reminds me. I also get a similar glitch with most Quake exes on a laptop with integrated Intel graphics, only their status bar is always black unless firing a weapon. Some ports have an obscure config setting that fixes it but messes up other stuff when used on a computer that doesn't require the fix.

Also I'd been meaning to ask you, Entryway. Could we please have an option (in the config) to not scale the status bar? In PrBoom 2.02 if I add -width 640 -height 400 to the commandline the status bar is rendered at half size. Sure MBF scales the status bar when set to "high res" and none of the other 'dead engines' PrBoom supports ever had a "high res" option so it isn't even really a cosmetic compatibility but I like it at half the size for a compromise between the informative status bar and the Boom full screen overlay and I sometimes miss that accidental feature from the original PrBoom. Thanks for all of your work either way.

[tatsurd-cacocaco]

entryway said:

Your report about of such bug is the second. In both cases on board Intel is used. Also I think you have the same problem with all known versions of vanilla glboom. Correct?

EDIT: Fixed?

It is all correct. I use Intel core2 Duo now. I tried all version of glboom and glboom+ when starting to make videos. However, such a bug was found all of them.
I have confirmed that it was fixed just now.
Ohhhhh, Great job! Thank you very much.

[entryway]

Does anybody want to tell me, what is broken with this EXE?
http://prboom-plus.sf.net/glboom-plus_stencil.zip

Test level is in the archive. Should look like:
http://prboom-plus.sf.net/stencil.avi (3.5 Mb)

Eternal.wad should look much better now. Especially map28, heh.

P.S. Thanks GrafZahl for the formula in DrawFloodedPlane

[HackNeyed]

Ok, I just had the weirdest glitch I've seen yet. I was playing Alien Vendetta map 5 in PrBoom+ 2.5.0.1.test with complevel 2 and after being bitten by a pinky daemon while on an upward moving lift I was able to walk through walls as long as I didn't have to step up in floor height and so could the monsters but not even splash damage would kill them and I still had alot of health that kept me alive for awhile until the hurting floor I had stumbled on killed me. Simply respawning didn't fix it. Weird.

[Grazza]

Sounds like an intercepts overflow.

[Csonicgo]

Hi,

I use an old laptop to play old games but I still have 3d Acceleration with ATI Rage Pro Mobility... Pr-Boom seems to run great with it! The only exceptions is drawing skys and Spectres are "black"

here are 2 screenshots with examples


bad skys
http://img231.imageshack.us/img231/5449/doom01yq4.png

bad spectre
http://img379.imageshack.us/img379/1470/doom06hq5.png

SDL OpenGL PixelFormat:
    SDL_GL_RED_SIZE: 5
    SDL_GL_GREEN_SIZE: 6
    SDL_GL_BLUE_SIZE: 5
    SDL_GL_STENCIL_SIZE: 8
    SDL_GL_ACCUM_RED_SIZE: 0
    SDL_GL_ACCUM_GREEN_SIZE: 0
    SDL_GL_ACCUM_BLUE_SIZE: 0
    SDL_GL_ACCUM_ALPHA_SIZE: 0
    SDL_GL_DOUBLEBUFFER: 1
    SDL_GL_BUFFER_SIZE: 16
    SDL_GL_DEPTH_SIZE: 16
    SDL_GL_MULTISAMPLESAMPLES: 0
    SDL_GL_MULTISAMPLEBUFFERS: 0
    SDL_GL_STENCIL_SIZE: 8
GL_VENDOR: Gareth Hughes, Leif Delgass, Jos� Fonseca
GL_RENDERER: Mesa DRI Mach64 [Rage Pro] 20051019 x86/MMX+/3DNow!+/SSE
GL_VERSION: 1.2 Mesa 7.0.3-rc2
GL_EXTENSIONS:
	GL_ARB_imaging
	GL_ARB_multisample
	GL_ARB_multitexture
	GL_ARB_transpose_matrix
	GL_ARB_vertex_buffer_object
	GL_ARB_window_pos
	GL_EXT_abgr
	GL_EXT_bgra
	GL_EXT_blend_color
	GL_EXT_blend_minmax
	GL_EXT_blend_subtract
	GL_EXT_clip_volume_hint
	GL_EXT_compiled_vertex_array
	GL_EXT_convolution
	GL_EXT_copy_texture
	GL_EXT_draw_range_elements
	GL_EXT_histogram
	GL_EXT_packed_pixels
	GL_EXT_polygon_offset
	GL_EXT_rescale_normal
	GL_EXT_separate_specular_color
	GL_EXT_subtexture
	GL_EXT_texture
	GL_EXT_texture3D
	GL_EXT_texture_edge_clamp
	GL_EXT_texture_object
	GL_EXT_vertex_array
	GL_APPLE_packed_pixels
	GL_IBM_rasterpos_clip
	GL_MESA_ycbcr_texture
	GL_MESA_window_pos
	GL_NV_light_max_exponent
	GL_NV_texgen_reflection
	GL_OES_read_format
	GL_SGI_color_matrix
	GL_SGI_color_table
	GL_SGIS_generate_mipmap
	GL_SGIS_texture_edge_clamp
GL_MAX_TEXTURE_SIZE=512
using GL_ARB_multitexture
using GL_EXT_blend_color
Using GL_NEAREST for normal textures.
Using GL_NEAREST_MIPMAP_NEAREST for mipmap textures.
Using texture format GL_RGBA4.

[entryway]

Csonicgo said:

bad skys

how about glboom+ and

gl_compatibility 1
gl_drawskys 2

in cfg?

[Csonicgo]

entryway said:

how about glboom+ and

gl_compatibility 1
gl_drawskys 2

in cfg?

Glboom+? can I compile this in linux?

I use Glboom lighting model.
Gl_compat is 1, and gl_Drawskys wasn't in config. I put it in and set it to "2" and now the sky looks great! thanks!

Spectre is still dark.

[entryway]

Csonicgo said:

gl_Drawskys wasn't in config. I put it in and set it to "2" and now the sky looks great! thanks!

You should know it is not the best solution. With gl_drawskys 2 prboom will draw skybox around a level instead of main algo and this method has defects you can see immediately on map12 at doom2.wad. I implemented this method for voodoo in 2.4.8.3

[Csonicgo]

entryway said:

You should know it is not the best solution. With gl_drawskys 2 prboom will draw skybox around a level instead of main algo and this method has defects you can see immediately on map12 at doom2.wad. I implemented this method for voodoo in 2.4.8.3

I understand. The Chipset in this laptop is very peculiar in how it implemented things; and apparently id software and other companies knew about this. I was told that Quake 3 has a lot of "if rage" like code in it so that people with said card families could play quake 3 with the correct effects. It's hard to troubleshoot something like this when it's the card or its drivers (or a combination of both) being the main problem.

I should be happy that it works in the first place, the Windows drivers for this chipset didn't even include OpenGL support, just Direct3D, and even it wasn't "finished". With Linux I am finally able to use the laptop's graphics card somewhat. Perhaps I could get a screenshot of the different blends my card can do, since I ran a lot of Mesa Test programs when compiling video drivers.

Bottom line, it's an old old chipset (7 years!) and getting updated drivers (especially in the FOSS world) for old hardware can be quite the challenge. But... workarounds are always awesome. :-)


EDIT: I did some googling for "Mesa DRI Mach64" and found immediately that there are serious driver errors that shouldn't be there. just listen to this garbage:

1) Only the first triangle is drawn from display lists (it's used for printing fonts).

2) When large polygon which is partially offscreen is being drawn, it's incorrectly clipped. Visible part of it contains "holes" and texture coordinates are sometimes set to random values.

Bummer.

[entryway]

Csonicgo said:

I was told that Quake 3 has a lot of "if rage" like code in it so that people with said card families could play quake 3 with the correct effects.

Some of them:

// ragePro systems can't fade blends, so don't obscure the screen
if ( cgs.glconfig.hardwareType == GLHW_RAGEPRO ) {
	return;
}

alpha = p->alpha;

if ( cgs.glconfig.hardwareType == GLHW_RAGEPRO )
	alpha = 1;

So I think your accelerator just can't handle a transparency. As workaround you can create following DEH (spectre is without "Partial invisibility") and use it in your cfg in this way: dehfile_1 "for_rage.deh"

Patch File for DeHackEd v3.0

# Note: Use the pound sign ('#') to start comment lines.

Doom version = 21
Patch format = 6

Thing 14 (Spectre)
Bits = 4194310

Maybe I'll do some workarounds for Rage Pro in prboom+ later

[Csonicgo]

Yeah, that's the weirdness of it all-- Rage Pro Mobility M-1 (which is what I have) did have alpha transparency...

Name	RAGE MOBILITY-M1 AGP 8X
Total Video Memory	8162KB
Total Texture Memory	6242KB
Minimum Texture Resolution	1 * 1
Maximum Texture Resolution	1024 * 1024
Maximum Texture Blending Stages	2
Maximum Texture Coordinates	2
Bus	PCI
Manufacturer Identifier	0x00001002
Chipset Type	0x00004C52
Subsystem Identifier	0x80AF104D
Chipset Revision Level	0x00000064

Supported features:
Transformation and lighting in hardware	No
16-Bit Rendering	Yes
24-Bit Rendering	No
32-Bit Rendering	Yes
Textures In Single Pass	2
Driver can disable VSync by software request	Yes
Edge Antialiasing	No
Subpixel Accuracy	Yes
Point Sampling	Yes
Point Sampling With Mip-Mapping	Yes
Bilinear Filtering	Yes
Bilinear Filtering With Mip-Mapping	Yes
Trilinear Filtering	Yes
Anisotropic Filtering	No
Specular Gouraud	Yes
Vertex Fog	Yes
Range Fog	No
Table Fog	Yes
W-Fog	No
Alpha Blending	Yes
Vertex Alpha Blending	Yes
Vertex And Texture Alpha Blending	Yes
Additive Alpha Blending	Yes
Multiplicative Alpha Blending	Yes
S3 Texture Compression	No
DX6 Bump Mapping	No

This just keeps getting weirder...

Edit: and even weirder. I'm reading on a troubleshooting site that Vertex alpha is broken in OpenGL, but NOT in Direct3D on this card. That makes absolutely no sense. :P