PrBoom-Plus, ver. 2.5.1.4

fraggle said:

PrBoom+ runs weird on retina display Macs. See here for a screenshot. That was with -width 800 -height 600 on the command line. Looks like it's running at 800x600 but the window is 1600x1200.

Probably because of outdated (?) SDL in Mac build? In any case I can't do anything with that, because I am not a Mac user. PrBoom+ itself has no any resolution restriction.

How am i able to get this hud in prboom/glboom?

http://www.youtube.com/watch?v=AHbJthh-Hyw

I wasn´t able to find any setting...

xAn said:

How am i able to get this hud in prboom/glboom?
http://www.youtube.com/watch?v=AHbJthh-Hyw
I wasn´t able to find any setting...

Keep pressing F5 until it fits. Alternatively, set "hud_num 8" in prboom-plus.cfg.

Thank you, that did it.

Hey entryway, I have a few things I'd like to bring up.

I seem to recall that there was discussion about adding support for the OPTIONS lump from Eternity. Was that so? If it is so, is that a feature that is still on the horizon? For my uses in particular, I replaced the automap background color with a darker red (for a tweaked COLORMAP) in one of my projects. I didn't realize it was the color for the automap background at the time, but I was able to fix it in Eternity with the OPTIONS lump. Although I'm certain it would be a useful lump for other reasons, of course ;)

A while back I brought up an issue I was having with palette entry 255 and a new color palette that I'm using for a project. You can read my original thread here and also my post in this thread here. This apparently is less of a bug and more of a feature request. That is, to allow the use of palette entry 255 as a useable color in sprites/graphics/textures. You didn't say if that would be a feasible change or not in your response to my original request, so I wanted to bring it up again.

There's also the odd sky alignment issue which I also brought up in this post. Where it appears that the horizon of the sky isn't aligned properly when using tall skies. From your test, it appears that the problem still exists in MBF. But from my tests it seems to have been fixed in WinMBF. Hopefully that didn't confuse you; I didn't test the skies in MBF, only WinMBF. To clarify, I think the desired behavior is to have the sky appear as it does in the Eternity engine as shown in the screenshot in your post. Again, I wasn't sure if you said that this was a bug and, if so, if it would be fixable. So I just wanted to bring it up yet again.

Ok, the last item I wanted to bring up is in regards to viewing different skies at the same time in GlBoom+. Referencing this post yet again, there is a test map along with two screenshots of this behavior. In the software renderer, it is possible to view multiple skies at the same time. However in the gl renderer, you can only view one sky at a time. It seems to pick the sky that is closest to the player and then will render that sky texture across all skies. Note that this is using the MBF sky transfer special.

Let me know if you need any clarification on any of these issues!

The MBF options lump is insufficiently careful over which user choices it allows the level designer to override. I don't know if it was deliberately overlooked or just forgotten when LxDoom/early PrBoom merged in MBF but I'm glad the feature never made it across. I can imagine no end of abuses you could do with it but no valid use cases that can't be covered by putting "this wad needs comp_telefrag=1 to run correctly" or what have you in the text file.¹

Mechadon: for your specific example I guess you changed palette entry 247 (mapcolor_back default) to something other than black, noticed the automap became unreadable, then changed mapcolor_back to something else via the options lump? In order for that to make sense, you have to assume that all players of your wad also have kept all default automap colour settings. However, in actuality, if the user also changed mapcolor_back (and others), your override may likely make his automap unreadable, and there's nothing he can do besides changing all his other colours or hacking your wad to fix or delete the options lump...

—
¹ I think being forced to complevel 2 or 9 against my wishes is just as abusive as being forced to have putrid automap colours, I know others (myk!) will disagree here though...

RjY said:

Mechadon: for your specific example I guess you changed palette entry 247 (mapcolor_back default) to something other than black, noticed the automap became unreadable, then changed mapcolor_back to something else via the options lump? In order for that to make sense, you have to assume that all players of your wad also have kept all default automap colour settings. However, in actuality, if the user also changed mapcolor_back (and others), your override may likely make his automap unreadable, and there's nothing he can do besides changing all his other colours or hacking your wad to fix or delete the options lump...

Yea, that's pretty much what happened. Although now that you mentioned it, I didn't give any thought to how that works with players that use custom automap colors. Basically all I really wanted to do was change the background color back to the default color (but using a different palette index, in this case index 0). But of course that's just the default automap color scheme. I don't want to force a particular color if a player is using a custom automap color scheme, but you are right in that the OPTIONS lump isn't that flexible.

At least in my particular case, it isn't a huge problem. The color I replaced at index 247 is a really dark red. So at worst it makes the automap slightly brighter, but it is still useable.

I can't say I have any opinions either way regarding the other facets of the OPTIONS lump though. It seems like potential for abuse depends more on the modder/mapper. Ideally its use would only enhance the experience for the player. But again, I guess it just depends on how its used.

Mechadon said:

Let me know if you need any clarification on any of these issues!

It's enough, thanks, but currently only fabian works on prboom-plus, heh. Issue with different skies in skydome mode should be fixed of course, I'll do.

entryway said:

It's enough, thanks, but currently only fabian works on prboom-plus, heh.

*cough* new releases attract more coders *cough*

ETA: current, as in 2.5.1.4-test, which er, I appreciate isn't the version this thread is about. Sorry about that.

I notice in the current changelog:

* Brown color for weapons that cannot be fired on weapon HUD widget.

This doesn't work as well as it might because it's commented out in hu_stuff.c, perhaps because it shows when a weapon has zero ammo not when it has insufficient to fire.

However, in 2010 I sent a patch to prboom and prboom-plus which does this and also turns the colour blue or bright blue (the same colour as used for >100 health/ammo) if the weapon has full ammo. prboom accepted it into trunk, but never released another version AFAICT.

I've rewritten it for the current prboom-plus: it can be found at http://www.chiark.greenend.org.uk/~damerell/games/ammocount.patch

This improves on the current code in prboom-plus, I believe, both by showing when a weapon has full ammo and by showing brown colour when the weapon has insufficient ammo to fire, not when it has zero ammo.

It doesn't affect the traditional status bar, just the HUD, for three reasons.

1) It's not a lot of use because the traditional status bar displays ammo counts for all weapons anyway.

2) It's also not a lot of use to recolour the ammo count for the current weapon for no ammo or full ammo, since you can see the ammo count on the screen in big fat numbers. The use is in knowing if a weapon you aren't using can be fired (the difference between 40 energy cells and 39, or 1 rocket and no rockets, is quite important) or if it has full ammo (so as to consider using some up).

3) The traditional status bar uses code which is cleverly optimised so that numbers are only redrawn when they - not their colour - changes. This means that if you have 39 cells / 1 shell and switch back and forth between the BFG/plasma or shotgun/SSG the colour will come out wrong, and this can't be fixed without a lot more work or abandoning that optimisation.

Is it so important to have another (blue in your patch) color for full ammo? Not sure there is big difference between 600 and 599 or 100 and 99, heh.

entryway said:

Is it so important to have another (blue in your patch) color for full ammo? Not sure there is big difference between 600 and 599 or 100 and 99, heh.

I find it useful, yes, for the reason described above; suppose I'm not very short of ammo, but there might be a dry spell coming up. (For example, remember 20 years ago, the shock of the early levels of Episode 2 when your fire discipline had only been trained by Episode 1 - for a player of that skill, there's a real drought around E2M4 [1]). I'm tooling around with the shotgun, because I'm a Doom 1 sort of chap; but if I see the chaingun or plasma rifle have a full load, I know it's time to switch to one of them and use up some of its ammo, so as not to waste any ammo pickups I find for them.

(Arguably it ought to display when a large ammo box for that weapon would be partly wasted, but having the indicator turn blue at 80 (or even 81) shotgun shells etc. seems a bit arbitary.)

I certainly think it doesn't do any harm - I doubt anyone is going to complain about being told that they have full ammo - and the patch also fixes the display of unfirable weapons, which surely is desirable in and of itself. It doesn't do a lot in modern slaughterfest feast-and-famine where every encounter begins with a megasphere and a bushel of rockets, but that's not the only way the game plays...

I think I also have a couple of bugs to report but one of them needs some screenshots. :-/

[1] Especially if you don't know the secrets; not only because there's less ammo, but because you probably don't have a backpack, so the distance between full and empty is halved.

damerell said:

but if I see the chaingun or plasma rifle have a full load, I know it's time to switch to one of them and use up some of its ammo

Ok, thanks. Applied.

damerell said:

(Arguably it ought to display when a large ammo box for that weapon would be partly wasted, but having the indicator turn blue at 80 (or even 81) shotgun shells etc. seems a bit arbitary.)

I'd suggest to turn it blue when the ammo amount exceeds the value of maxammo without a backpack, i.e. 200, 50, 50, 300.

and the patch also fixes the display of unfirable weapons, which surely is desirable in and of itself.

without question

entryway said:
Ok, thanks. Applied.

Excellent, thank you!

fabian said:
I'd suggest to turn it blue when the ammo amount exceeds the value of maxammo without a backpack, i.e. 200, 50, 50, 300.

I considered that in 2010. It is neatly analogous to the situation with health and armour, but also mostly uninformative - if you don't have a backpack it never happens (or if "equals or exceeds", it is precisely equivalent to a full-ammo display) and if you do have a backpack it's about the same as having an extra colour but being forced to fit everything into the bottom 50%.

The thing about health and armour is, you have a natural level for health - 100% - and also there's a transition in your ability to collect pickups; you can't collect stimpacks and medikits above 100%, you can't collect green armour above 100% [1]. The only transition in your ability to collect ammo is at full ammo.

So, that's why I didn't do it. :-)

[1] I know you know this, but I'm trying to explain why I think "blue from 101%" makes sense.

damerell said:

I considered that in 2010. It is neatly analogous to the situation with health and armour, but also mostly uninformative

I see it slightly different. :) To me, blue indicators do always mean "more than usual" and as long as you did not pick up the backpack you cannot carry more than the "usual" amounts of ammo.

One of my bugs is just how the software renderer is at high resolutions.

The other one is as follows, and I'm afraid it's a bit tl;dr.

As far as I can make out from the source, the "doom_weapon_toggles" option ("Enable fist/chainsaw and shotgun/SSG toggle" in the menus) does nothing at all.

The weapon selection logic in g_game.c is suboptimal (that in p_user.c is compelled to be that of DOOM.EXE for compatibility reasons), partly because of the nonexistence of that toggle.

The difficulty is that we have a "fist or chainsaw" key and a "chainsaw" key, a "shotgun or SSG" and a "SSG" key, a certain vestige of DOOM.EXE's logic, effectively two "fist" weapons (berzerk or not), and the weapon preference list is overloaded:

If I list the SSG ahead of the shotgun, it means all three of "If I select best weapon, prefer the SSG" (probably true), "If I run out of ammo unexpectedly, prefer the SSG" (also probably true, that's a crisis situation) "even if I have only one shell" (what??), "If I press the shotgun-or-SSG key, even though I have a perfectly good SSG key as well, give me the SSG, so I have no way of getting to the shotgun in a single weapon switch" (gah no!)

The fist-or-chainsaw logic makes more sense in that mostly it assumes you always prefer the chainsaw to the not-berserk fist, which I think is practically always true unless you're so desperate for ammo you're pinkbeast-dancing on -fast - but it also has the same problem, list "chainsaw" preferred to "fist" and you can't get to the berserk fist without two weapon switches.

I suggest the following, which I'll gladly code up except for the compatibility wrappings which I don't understand, and invite comment on the options that spring to mind:

First, make the toggle do something. Secondly, arrange that the out-of-ammo code will never switch to an SSG which has insufficient ammo. (This is a simple bug where P_SwitchWeapon is called and checks, returns "ordinary shotgun", but then the code fiddles with the answer because it acts as if you pressed the "shotgun-or-SSG" key).

With the toggle OFF:
There are four keys, "fist", "chainsaw", "shotgun", "SSG". They select those weapons. They never, ever, toggle.

Option 1: That, except if not berzerk, "fist" gives you the chainsaw if you have it and are not wielding the chainsaw or fist. If you are wielding the chainsaw, it gives you the fist. If you are using the fist it does nothing. (Effectively, it toggles one way).

Option 2: That, except if the SSG is not in the game, "SSG" gives you the shotgun.

Option 3: That, except if you don't have the chainsaw when you ask for it, you get the fist; if you don't have the shotgun you asked for, you get the other one.

With the toggle ON:
All four keys toggle fist/chainsaw or shotgun/SSG. All four keys select the other weapon of the type if that's all you've got, or if you only have one shotgun shell and you're not already using the single shotgun (1).

Option 1: The "fist" key gives you the chainsaw if not berserk.

... or finally, add an "always prefer chainsaw to non-berserk fist" option which controls the operation of Options 1 above.

(1) Doom never stops you taking out a weapon with no ammo in order to admire it - er, as you run desperately towards its ammo, in order to save a weapon change later - so the code should not stop you doing that; but it should check you really meant it and wouldn't rather just fire a shotgun shell.

I thought a bit more about this, and found another infelicity. Suppose my order of weapon preferences says "fist" (which is implicitly "berserk fist") > "pistol" > "chainsaw".

If I get to that point in the list with pistol ammo in stock, but am not berserk, the result is the chainsaw arrives, overriding the fist, even though I listed the pistol as a higher preference.

Looks like prboom never checked doom_weapon_toggles variable in place where it should be in G_BuildTiccmd and always thinks it is enabled. Any reasons for that? I've checked Eternity code, it uses doom_weapon_toggles in corresponding place.

I was thinking about how to fix this. I think part of the difficulty is that experienced users are naturally accustomed to the existing behaviour, where one key brings up the shotgun in Doom I and the SSG in Doom II. Conversely someone coming to Doom fresh would look at it and go "wait, there are two shotguns, two shotgun keys, and both keys bring up the same weapon? You people are insane."

(As an aside, I think I remember some source ports where double-tapping 3 got you the single shotgun with one weapon change, which was an improvement.)

I propose the following (to be clear, I propose to implement it if you think it is wise):

When P_SwitchWeapon is called, nothing is allowed to fiddle with the result. P_SwitchWeapon regards "fist" in the weapon preferences as meaning "berserk fist". It tries "non-berserk fist" as a last resort. This fixes the "SSG comes up with one shell" and "I prefer pistol to chainsaw, but I got chainsaw anyway" issues.

Edited to delete the rest of half-baked proposal. This needs more thought.

I'm getting intermittent (roughly every two hours) crashes on a self-compiled prboom-plus 2.5.1.4 on Debian stable:

I_SignalHandler: Exiting on signal: Segmentation fault
I_ShutdownMusic: removed /tmp/prboom-plus-music-N9ToTT
I_ShutdownSound:

What other information would be useful?

Would it be possible to make it so hud elements can have their positioned modified? Or have the texture on the left and right of the status bar removed?

As you can see in these two shots, when playing in a surround resolution with three panels (5760x1080) the text messages are at the far top left and hud elements when not using the status bar are in the extreme corners too. Having them brought into the center area would be very convenient.

http://i.imgur.com/VvqxuJa.jpg

http://i.imgur.com/r2R0o8l.jpg

damerell said:

What other information would be useful?

You could try to get a core dump by setting "ulimit -c unlimited" before running prboom-plus. Once it crashes, the core file will be in your working directory. You can then load this core file together with your prboom-plus binary into gdb via "gdb ./src/prboom-plus /path/to/corefile" and type "run" to get it running. Once it crashes, type "bt" to get a backtrace of the segfault. This backtrace could be helpful.

In most cases, the information in the backtrace will be more insightful if you rebuild your sources with CFLAGS="-O0 -g", e.g. by passing this variable to ./configure and then running make over the source again.

Oddly, even with "ulimit -c unlimited", I don't get a core, which is a bit mysterious.

However, I can attach gdb to a running prboom-plus, and presumably next time it dies I might learn something there...

...except that since I started doing that it has quite persistently declined to die. My perception was that the crashes only happened after playing a few maps in series without quitting or reloading; at the moment, I'm playing the later levels of DooM II which don't really allow me to do that, so perhaps I'm just not tickling the behaviour that does it. I'll report back.

I'm trying to use .patch files with PrBoom but I can't seem to get them working. Could you tell me how to use them? Thanks.

Platinum Shell said:

I'm trying to use .patch files with PrBoom but I can't seem to get them working. Could you tell me how to use them? Thanks.

If we are talking about the same thing, you need to apply them to the source code and compile afterwards.

fabian said:

If we are talking about the same thing, you need to apply them to the source code and compile afterwards.

I was afraid of that...I haven't the faintest idea how to do that.

entryway said:
Is it so important to have another (blue in your patch) color for full ammo? Not sure there is big difference between 600 and 599 or 100 and 99, heh.

Talking about ammo colors in the HUD, one thing I think could be changed is the effect of the backpack. Ammo beyond the standard levels should be blue like in the armor and health bars, so that red, yellow and green are always consistent and you don't get different depletion rates per color with and without the backpack. I assume this would come with an option, since users are used to the current behavior and might want to stick to it.

myk said:

Talking about ammo colors in the HUD, one thing I think could be changed is the effect of the backpack. Ammo beyond the standard levels should be blue like in the armor and health bars, so that red, yellow and green are always consistent and you don't get different depletion rates per color with and without the backpack. I assume this would come with an option, since users are used to the current behavior and might want to stick to it.

Yes, this! I meant to say the same a few posting before but failed to put it into such clear words.

fabian said:

Yes, this! I meant to say the same a few posting before but failed to put it into such clear words.

I understood you as meaning the same thing, although myk saying that you don't get different depletion rates per color with and without the backpack does state a clearer motivation.

As previously mentioned, I feel this sort of conceptual neatness (although I appreciate the idea of seeing it as fixed depletion makes it not just conceptual neatness - whether I have a backpack or no, what I care about when low on ammo is how much is left, not how much I could pick up) is not nearly as useful as knowing when a weapon actually has full ammo, and certainly not worth abandoning half the potential indicative range. I also think it's a bit dubious because IME one has a backpack nearly all the time.

But I suppose the point of options is to have everyone get what they like, so I suggest (and if I have the time, propose to implement) three options:

1) Current behaviour. Ammo green/yellow/red is across the current capacity, blue is "full ammo".
2) Armour [1]/health behaviour. Ammo green/yellow/red is across the non-backpack capacity, blue is 100% or more (not "more than 100%", because then it doubles as a full-ammo indicator for people without backpacks).
3) Intermediate. Green/yellow/red is across the non-backpack capacity, but blue always means "completely full". (This is conceptually messiest, but also potentially most useful - when the ammo indicator turns red, I always have the same amount of ammo for the weapon involved, backpack or no; but I get the full-ammo indicator that was my original motivation).

[1] In passing I should mention I was also considering changing the colour of the armour indicator (optionally) to indicate whether one has green or blue armour protection, since that is a piece of information the player can know but which isn't displayed on the HUD.