altered gameplay behavior in ZDoom

[Graf Zahl]

printz said:

EDIT: can the sound limit be disabled in ZDoom? It's not a gameplay feature per se, but I like hearing all the possible sound.

Not recommended. I understand what you want but it wouldn't work. Some time ago, when ZDoom transitioned to FModEx Randy removed the limit resulting in extremely serious problems coming from ZDoom having a lot more sound channels available than Doom originally. As a result far too many sounds were played, especially on large monster heavy maps. Even on Doom's E2M2 the effect was clearly noticable with far too many imps grunting being audible. In the end it was necessary to reapply the limit to get a more restrained sound field.

Reducing the sound channels is also not an option because FMod then starts getting problems with sound prioritizing and the sound gets choppy.

[Super Jamie]

Graf Zahl said:

The 'bugs' forum is a better place for something that needs to be addressed and shouldn't get lost. Anyway, this will be the next one I'll try to address.

I know, which is why I asked in the thread if I should log it as a bug or not? :) Thankyou for the fix!

[Catoptromancy]

Most epic thread! Good work Graf!

By actually playing zdoom now ill probably find some other things and heres another.

This should add a message in console, not hard crash. A single linedef in void or any linedef that is missing a sector on both sides.
http://ftpusers.coffeenet.org/~cato/wads/linequest.wad

Out of a dozen ports and vanilla.exe, only legacy and zdoom crash. Not being able to open the map seriously changes gameplay.

[Graf Zahl]

That's one of the things I never understood but I never got around changing the code to something that works.

[Vermil]

Graf Zahl said:

Are there really maps depending on this glitch? In all circumstances where I witnessed it it has bad side effects that broke the map in one way or another.

As I stated when I mentioned it. The HTC E3M8 relies on the fact that a bad guy stuck in a ceiling of a sector prevents it from lowering, to prevent the exit teleporter lowering prematurely.

Still as I also mentioned, I've seen ZDoom wads where mappers have placed bad guys in sectors with the same floor/ceiling height and expect them to lower.

[Graf Zahl]

Unfortunately, that one I can't re-introduce. The code that causes the bug is already present in ZDoom for other purposes but the low level checking code has been altered instead. But I can't revert that code without causing much more serious problems elsewhere.

[phi108]

I wonder if the compatibility option for the hitscans blockmap fix could be separate from the bounding box/cross-section hitscan checking option? Right now they are both controlled by COMATF_HITSCAN, but I'd rather play with the cross-section hitscan checking without the blockmap bug, I don't want bullets to go through actors if my aim is perfect.

[Never_Again]

[Graf Zahl]

I think the amount of messages can be made configurable but don't expect me to waste any thought on the menu system.

I'd rather dump it completely and replace it by something better - including real mouse support - if I had just the time for such a task...

[Never_Again]

[Gez]

phi108 said:

I wonder if the compatibility option for the hitscans blockmap fix could be separate from the bounding box/cross-section hitscan checking option? Right now they are both controlled by COMATF_HITSCAN, but I'd rather play with the cross-section hitscan checking without the blockmap bug, I don't want bullets to go through actors if my aim is perfect.

It would make sense; but on the other hand if you multiply compat options too much they become more confusing. Having both compat_hitscanbox and compat_hitscanblock would be confusing.

(Plus, we're running out of flags in the compatmode field... I think there's room just for three more.)

[myk]

Never_Again said:
It would be nice to be able to disable multiple message lines. Picking up four items or more in a quick succession can clutter the screen in an annoying fashion.

Yeah, more so in low-res. I used to use 640x400 at double low detail, with centered messages, but since low detail modes were removed I've reverted to plain 320x200 and left-hand messages, where the four lines are excessive, even when you only get four items.

[Gez]

This here is the reason the number of lines can't be selected:

#define NUMNOTIFIES 4
#define NOTIFYFADETIME 6

static struct NotifyText
{
	int TimeOut;
	int PrintLevel;
	FString Text;
} NotifyStrings[NUMNOTIFIES];

You can always change the NUMNOTIFIES define and recompile, but the code probably ought to be rewritten to use a dynamic system so that the number of lines can be changed during game.

[Spleen]

Pretty minor, but the lighting curve is different in ZDoom than in Vanilla DOOM. Go up next to a wall in an extremely dark sector in ZDoom, then in Vanilla or Chocolate DOOM, to see what I mean.

There's still no chance of BOOM Tranmaps being implemented, is there?

[Gez]

Spleen said:

Pretty minor, but the lighting curve is different in ZDoom than in Vanilla DOOM. Go up next to a wall in an extremely dark sector in ZDoom, then in Vanilla or Chocolate DOOM, to see what I mean.

It's normal, ZDoom doesn't use the COLORMAP but instead compute all that stuff on the fly.

Spleen said:

There's still no chance of BOOM Tranmaps being implemented, is there?

They are at the moment about as implemented as they're ever going to be I suppose: ZDoom looks at the white and black index on the palette, look how they are affected by the TRANMAP, and extrapolate based on that. It supports simple and additive translucency modes; but does not support any of the wackier effects you can get with it.

The reasons for the no haven't changed since then (it would not work with non-paletted graphics (which ZDoom support, even if it displays them in paletted colors), it would not work with the OpenGL renderer, and it would not work with a hypothetical possible future 32-bit software renderer), so I don't see why the decision would change.

[myk]

Spleen said:
Pretty minor, but the lighting curve is different in ZDoom than in Vanilla DOOM. Go up next to a wall in an extremely dark sector in ZDoom, then in Vanilla or Chocolate DOOM, to see what I mean.

Oh, that... see this post.

[Spleen]

Gez said:

It's normal, ZDoom doesn't use the COLORMAP but instead compute all that stuff on the fly.

Huh, has it changed since 2008?

myk said:

Oh, that... see this post.

Hmm, interesting, thanks!

[Graf Zahl]

Spleen said:

Huh, has it changed since 2008?

No. The colormaps are still being used. That effect is caused by a different table which is larger in ZDoom. But please don't ask me to change it. I won't touch the software rendering code.

Gez said:

The reasons for the no haven't changed since then (it would not work with non-paletted graphics (which ZDoom support, even if it displays them in paletted colors), it would not work with the OpenGL renderer, and it would not work with a hypothetical possible future 32-bit software renderer), so I don't see why the decision would change.

The main reason for not implementing the tranmaps is the palette lock. I can't imagine anything worse to stall future progress than a feature that's this inherently bound to the specific palette.

Also, let's not forget that PrBoom's GL renderer also can't make much sense of it - for the exact same reasons that will keep this out of ZDoom.

[Spleen]

Graf Zahl said:

No. The colormaps are still being used. That effect is caused by a different table which is larger in ZDoom. But please don't ask me to change it. I won't touch the software rendering code.

Ok, I won't, and thanks for answering!

[Gez]

My bad, it does use it. Well, it seems it does actually use the colormap for lighting, but not for special effects (like invulnerability). HacX's blue colormap for invulnerability is not used in ZDoom.

Nevertheless, Doom has light increments of 16 (even though the colormap has 32 maps for light levels, allowing increments of 8) and ZDoom uses light increments of 1; so while it does use the colormap, it does not use it the same way.

[printz]

Never_Again said:

It would be nice to be able to disable multiple message lines.

Relatedly, can pick-up messages be set to display every time an item is picked, and not streamline when they're simultaneous? I like to know how many items I have picked up.

[Graf Zahl]

The main reason this is not done is because it'd flood the console and add a large number of messages simultaneously would cause the game to hang for a moment.

Also, such things are not what this thread is about. I'd like to address gameplay issues that are noticable, not do some tinkering with the user interface.

For the rest, please use the Feature suggestions forum.

[kristus]

Besides, Doom was originally gonna have multiple message lines anyway. But they removed that functionality since the way they had done it, it was taking over the status bar whenever you picked something up.

[myk]

Yeah, as seen in the beta. Although, if you think about it, an engine like ZDoom needs multiple lines of messages even less than the original because you can always pull the console down and see all or most of the message history. Multiple lines certainly don't hurt in head-to-head multiplayer, though, where quick frags and maybe flag messages come and go very fast. Doom does have a way to see the very last message displayed, by pressing Enter. (This key also enables the console in the beta.) ZDoom doesn't have that function, but naturally doesn't need it, as the Quake-style console plays that role and more.

[HackNeyed]

Graf Zahl said:

The idea here is to address the big gameplay issues that keep certain people from using ZDoom.

Thank you Graf! I'm really liking the adjustments and new/updated compat modes.

I only have a few annoyance with ZDoom anymore but they are mostly UI (Alt Hud not really scaled in 640x480, no Map##: Name in Automap overly without Alt Hud) or binding related (rebind Follow Mode in standard Automap).

The only kind of gameplay related one I can think of is restoring the ability to switch to empty weapons (using the keyboard) so the player can have their weapon of choice ready when they grab the ammo as they step into a trap though I doubt it's worth the trouble anyway.

Thanks again for the compat stuff though.

[Spleen]

HackNeyed said:

Alt Hud not really scaled in 640x480, no Map##: Name in Automap overly without Alt Hud

Hmm, perhaps it's possible to change these things by making your own SBARINFO. Not sure exactly how powerful it is.

HackNeyed said:

The only kind of gameplay related one I can think of is restoring the ability to switch to empty weapons (using the keyboard) so the player can have their weapon of choice ready when they grab the ammo as they step into a trap though I doubt it's worth the trouble anyway.

Interesting, it seems like Skulltag has this option but ZDoom does not.

[Graf Zahl]

HackNeyed said:

The only kind of gameplay related one I can think of is restoring the ability to switch to empty weapons (using the keyboard) so the player can have their weapon of choice ready when they grab the ammo as they step into a trap though I doubt it's worth the trouble anyway.

Thanks for reminding me. Yes, that should also be addressed.

[Quasar]

If the blockmap fix can be reasonably made optional in ZDoom, does it mean I might have a chance of allowing this fix in EE as well? My previous research on it was not promising, as it's not a "shallow" fix at all - every caller of P_BlockThingsIterator gets a near-total refactoring :/

Any tips you can give me on what code to look at or any tricks or caveats that are involved in this would be greatly appreciated.

[scalliano]

HackNeyed said:

The only kind of gameplay related one I can think of is restoring the ability to switch to empty weapons (using the keyboard) so the player can have their weapon of choice ready when they grab the ammo as they step into a trap though I doubt it's worth the trouble anyway.

Make it a switchable option, though. Nothing worse than switching to a weapon only for it to switch to something else when you hit the fire button.

[Graf Zahl]

Quasar said:

If the blockmap fix can be reasonably made optional in ZDoom, does it mean I might have a chance of allowing this fix in EE as well? My previous research on it was not promising, as it's not a "shallow" fix at all - every caller of P_BlockThingsIterator gets a near-total refactoring :/

Any tips you can give me on what code to look at or any tricks or caveats that are involved in this would be greatly appreciated.

I only added the option to PathTraverse which uses the blockmap in a completely different fashion. It doesn't set up an external double 'for' loop around the BlockThingsIterator call which made the whole thing a lot easier to code. However, it isn't that hard. The only thing about the setups that needs to change is to make MAXRADIUS not a constant but something more like

#define MAXRADIUS (comp_hitscan? 0 : 32)

and you should be good to go.
After that the only difference is that BlockMapIterator needs to implement the node list to allow linking an actor into multiple blocks and an optional check for this option to skip actors that don't have their origin in the current block.

What I can't say though is how such a change would impact demo compatibility. It is conceivable that the order in which actors are linked in the blockmap is no longer the same which might cause problems. So you'd most likely need a fallback for demo playback that preserves the old method completely.

scalliano said:

Make it a switchable option, though. Nothing worse than switching to a weapon only for it to switch to something else when you hit the fire button.

Already added. ;)