EDGE 2.1.0 Discussion [RC-1 Released on 10.3.2018]

[Enjay]

So Voodoo Dolls are supposed to pick up items only when "provoked", or something? They work in 3DGE - they take damage, etc., but I did notice it pick up a medikit (and therefore giving it to the player) when I moved it to the item. So are you saying the Voodoo Doll is spawned in the wrong spot on that map or something? If it can only pick it up when moved and it doesn't start at that point, then that's what I'm assuming. Also, I'm going to *try* and test this with 1.25/1.24 because Voodoo Doll handling was changed twice (with 1.26 and 1.29). Maybe the radius for the BFG pickup is too large and needs to be adjusted.

Players (voodoo dolls and normal players) are only supposed to pick things up when they (the player) are moving. A completely stationary player standing on a pickup should not collect the item. Even a stationary player having items thrown at him (e.g. a script shooting health bonuses at the player) should not pick up the items unless the player is moving too.

In this case, when the map starts the voodoo is stationary but standing within the radius of the BFG pickup. Because the voodoo is stationary, he should not pick up the BFG. When the true player activates the switch in the play area of the map, a crushing ceiling behind the voodoo explodes a barrel. The explosion pushes the voodoo slightly. The voodoo is now moving and picks up the BFG. That's how it is meant to work.

The way it is now in 3DGE, the player gets a BFG right from the outset of the map (because the stationary voodoo incorrectly picks up the bfg) and, on deciding to trigger what should be a nice little treat of getting a hidden BFG at the expense of a little damage much later in the map, only gets the damage and no bfg - and the novel way of getting the unseen weapon becomes a trap instead with no plus-side.

[Graf Zahl]

Voodoo dolls only pick up stuff when they move - just like regular players. Spawn a player onto an item, and he'll only pick it up when he actually moves. As long as he stands still nothing will happen. Same with voodoo dolls.

[Coraline]

That is very interesting. So it's probably more involved - something to do with the player routines then. Weird that this was never noticed beforehand in the port's entire history.

So say something like an Imp shoots health bonuses at the player rather than fireballs...so if the player was stationary he wouldn't collect them until he moved first? So they would just stack? That seems a little... odd from a logical standpoint.

I wonder how to even fix a bug like that. Anyone know off-hand what piece of code controls this behavior in Vanilla (or equivalent port) DOOM?

Obviously on the other end of this, it'd be very easy to do the equivalent in 3DGE without the need for altering the level or using dolls.

EDIT: Grammar Dyslexia

EDIT2: You guys are correct, I just tested this by spawning a player in the same spot as a weapon. But it makes so much more sense this way! =) I kid.

[Graf Zahl]

That seems a little... odd from a logical standpoint.

You ask for logic - in the Doom engine???

I wonder how to even fix a bug like that. Anyone know off-hand what piece of code controls this behavior in Vanilla (or equivalent port) DOOM?

Item pickup is done in PIT_CheckThing. And before you ask, yes, the method is completely and utterly [censored word]. But it's one of the staples of how Doom works.

[Enjay]

So say something like an Imp shoots health bonuses at the player rather than fireballs...so if the player was stationary he wouldn't collect them until he moved first? So they would just stack? That seems a little... odd from a logical standpoint.

Correct. It was actually a very similar situation to that when I first realised that the player needs to be moving to pick things up. I too thought it was odd (and actually, not what I wanted either) but that's how the game does it.

[Coraline]

You ask for logic - in the Doom engine???

Item pickup is done in PIT_CheckThing. And before you ask, yes, the method is completely and utterly [censored word]. But it's one of the staples of how Doom works.

Thanks so much Graf/Enjay, you guys are much appreciated for helping me out and I can't say that enough! I'd like nothing more than to fix these "bugs" and get this thing 100% compatible again, or at least "compatible" enough as to not break maps that exploit original DOOM quirks.

Extremely interesting. So I'm starting from DosDoom 0.653 and moving forward. This "bug?" doesn't exist in 0.653 and behaves normally (player doesn't immediately grab the weapon). Going to move my way up to EDGE 1.24 (or lower - AtomicGamer thankfully has all of these) until I find the one that broke it (or maybe it happened after 0.653 to 1.24, I'll find out soon enough). It can't be an RTS thing from the onset because RTS existed in 0.653 unless something was changed (probably).

It's utterly amazing to see how much has survived into 3DGE since 1998. Literally, some functions are exactly the same as they were written in DOSDoom 0.653, and most of the original DDF and RTS code and files themselves remain somewhat unchanged. So damn cool. I suppose that's why Legacy is so similar to 3DGE in some ways, being that the both started out on the original DOSDoom.

EDIT: If I do fix this thing, I wonder if I should have it as a compatibility option just in case it breaks anything in turn with 3DGE..

[Gez]

Probably a good idea to make it optionable, since it's a behavior that may be desired.

[Coraline]

Probably a good idea to make it optionable, since it's a behavior that may be desired.

Gotcha. And in this case, PIT_CheckThing was replaced (though early early on in DosDoom 0.653) with P_SlammedIntoObject, so that's where I'll start from.

So, interestingly enough, 1.31 is the version that broke this behavior. Just as I thought though, 1.31 introduced a ton of (awesome) shit that messed with compatibility, although I don't think it was intentional.

The WAD I tested it on was a small dinky thing that I created with a chaingun that spawned with the player. All of these except for 1.31 assumes that I move forward first to collect the weapon:

DOSDOOM 0.653: Player Pickups are normal.

EDGE 1.24 (win32): Player Pickups are normal.

EDGE 1.25 (GlWin32): Player Pickups are normal.

EDGE 1.26 (GlWin32): Player Pickups are normal.

EDGE 1.27 (GlWin32): Player Pickups are normal.

EDGE 1.28 (GlWin32): Player Pickups are normal.

EDGE 1.28a (GlWin32): Player Pickups are normal.

EDGE 1.29 (Win32): Player Pickups are normal.

EDGE 1.31 (Win32): Player Pickups are -broken-.

So, I now have a very good reference spot (1.29 is still in active development for the Dreamcast port) to fix this issue. Safe to say this bug will be fixed for 1.37. How crazy something this simple drove me so mad.

EDITS: Small facts here and there.

[Enjay]

Cool. Glad you tracked down the point where it changed.

[Coraline]

BUMP. I have a question for the programmers here.

Is it completely necessary to emulate the flat floodfill algorithm that the original DOOM had, at least for OpenGL ports? One ticket to a faster, uncapped framerate for my port is the removal of this part of the code that looks like it's kept for compatibility. Instead of drawing floors and ceilings that way, I was thinking about drawing it as polygons instead.

Would this method seriously break compatibility with existing levels? 3DGE wastes memory with that and I'm thinking a complete removal of it for a different system of drawing floors and ceilings would be much faster, more efficient, and speed things up. I'm not sure if any port does this differently or not, I haven't looked into it much. But I figure I could ask anyway. I'm working with another programmer to get this ported over to the Dreamcast as homebrew for other possible modders and not only would it speed things up tremendously on the SH4 (Sega Dreamcast CPU), it would also speed things up on the PC end. Heavy-weight rendering (map, MD2) will probably have the inner-most loops written in assembly- going to see what the performance looks like with the current OpenGL rendering setup before trying any major changes in how it works, but being able to just dump a couple vertices on the hardware to render flats would definitely be faster than emulating the floodfill algorithm; the main question is by how much..

Betting that it'd be by a lot, but asking around is crucial to avoid wasted work.

[Gez]

My understanding is that the deep water effect used, for example, in MAP02 of TNT relies on it.

[Enjay]

Yes, I'm not a programmer but I am aware of this feature being spoken about in relation to vanilla mapping hacks/effects so changing it would probably break those.

[Graf Zahl]

The filling is needed, but it's not needed to do an actual floodfill for it.

In 99.9%& of all cases it's enough to draw the flats as subsector-based polygons and then do a postprocessing step to flood the gaps. But with a few simple tricks it can do with polygons, too.

GZDoom uses a stencil to get a perspectively correct flat into the gap:

- first draw the stencil.
- then project a flat into the hole.
- last delete the stencil and restore the depth buffer.

The stencil is needed so that the depth buffer won't get messed up.
On a normal map the performance impact is minimal. But beware: It won't be able to catch all cases. The more extreme hacks won't display properly, but fortunately those are rare.

[Coraline]

BUMP again. Just another update:

Releasing 1.36F next week, which will finally be the last version in the 1.36x series. In this version, inputs have been fixed for the second player, and I've added two more ACTION buttons for the player to use (ACTION3 and ACTION4) for scripted/etc stuff. Also aforementioned bug first reported by Enjay is fixed here that broke Voodoo-Doll maps (by replacing the whole voodoo doll spawn with a custom RTS script). More Heretic fixes are applied here, mostly relating to visual stuff that was broken before (menus, HUD, etc).

Major things coming for 1.37 is, wait for it...framerate interpolation, which means 3DGE will finally run at 60FPS! Really wanted to get everything unhooked to reduce input lag and judder, but 3DGE uses Eular integration, so changing the timestep will affect the physics. Which sucks, but at least this port will run smooth for all the people who wanted it for so long. So there's that.

Also, simple Doom Legacy-like decals will be supported (and not lame hacks). Thinking about making these changeable via Images.DDF but not sure how high that demand would be.

Heretic support will be fully-realized by 1.37 as well. Which means things like Inventory management will be working, which can finally replace the ACTION 1-4 buttons (that I'm currently hacking up to support a sort of wannabe-inventory subsystem).

I've been really thinking about changing the DOOM sky code to a shader-based system straight out of Quake 3, to support the scrolling-based skies that engine utilized. I also like the style that GZDoom uses (looks a lot like Daikatana's sky stuff). This would eliminate the user's ability to use a custom DOOM-style FSKY, but that was a crappy system and being an OpenGL port, Quake3-based skies or skyboxes are so much more natural.

And finally, MD5 rendering will replace MD3 rendering (since MD3 filesize and loading slows things down). Having MD5 use skeletal-based animation will eliminate huge sizes for models anyways since MD3 store the model separately each frame. MD2 support will stay in the engine for models with less than ~100 frames or static stuff, ideally. Fog will also be working.

Now I just need to find someone willing to import ACS as either a compliment or replacement to RTS, but I'm not sure how this would affect the current userbase of the engine. I really want to add the basic ACS/Decorate alongside the existing DDF and RTS to expand the port's usability and ease-of-access. Linked portals would be nice, too.

[ibm5155]

it may sounds dumb, but I'm always curious about why people make alot of ports instead of everyone fix/make a single one (or two) :S
Well, MD5 models well be really welcome, even more from people that're converting md5 models to md3 D: