scifista42

Many action specials usable on linedefs have a "Tag" argument. Also, Doom format. I wrote "Line Tag" to drive the point home in as few words as possible.

The worst is "Line Tag" vs "Line Index" vs "Line ID" in Hexen format. They're 3 different concepts!

2 hours ago, Pegleg said:

reward players who explore

This.

I've once made animated flats and animated textures supposed to sync with each other, but abandoned the idea after testing in many different ports and seeing all sorts of inconsistencies in sync.

1 hour ago, GoatLord said:

any given set of XY coordinates defining a sector has a parallel set of coordinates at a higher or lower altitude (Z), thus allowing for height differences. If I have it correct, this second set of coordinates is always parallel as you cannot have any of the vertices alter its X/Y position without altering the corresponding X/Y position of its parallel vertex.

The term "vertex" has its own meaning in the context of the Doom engine. It's not a point on a side of a polygon in 3D space. It's a point in 2D space. It's not a limitation, it's a definition. The word is the same, but the intended meaning is different.

Vertex as a point on a side of a polygon in 3D space is supposed to define a point in 3D space explicitly as x/y/z coordinates. Vertex in Doom is not supposed to define a point in 3D space at all - not by itself alone, that is. Doom engine doesn't define 3D geometry via explicit x/y/z coordinates. It defines 3D geometry as a combination of vertexes (points with x/y coordinates), sectors (floors and ceilings with z coordinate each) and linedefs (connecting vertexes and sectors). This approach comes with its own limitations.

The point is - it's an entirely different concept than using 3D polygons. Some of your statements about the engine make no sense and it might be because you keep thinking of polygons, even though you haven't used that word in this thread yet.

(Also, let's say this again - all players/monsters/projectiles/items/decorations/blood-chunks/bullet-puffs/things in Doom have explicit x/y/z coordinates used for moving and colliding with geometry and each other. I simply can't think of that as not 3D.)

7 hours ago, DynamiteKaitorn said:

I'm not seeing anything on ZDooM wiki.

The wiki does mention here that background image defaults to black and assumes the same size as foreground image, so I assume that's what it is. Make sure the graphic lump/file itself has zero offsets and set the offsets exclusively as DrawBar parameters. If it doesn't help, try setting background image to the same graphic as foreground image.

In every engine, geometry has limitations. In Doom engine, geometry has different limitations for x/y and different limitations for z.

1 hour ago, GoatLord said:

you cannot move coordinates on all three axes simultaneously, just X and Y,

Things in the game move on all 3 axes, floors and ceilings move only on z axis, and walls can't move at all, so what are you talking about?

1 hour ago, GoatLord said:

parallelism

Some nonsense.

51 minutes ago, tempdecal.wad said:

Nothing to cringe about,

There wasn't, but...

54 minutes ago, crazyflyingdonut said:

OH GOD THE CRINGE IS REAL

...now there is.

12 hours ago, zaszthedestroyer said:

i was hoping for a more succinct coding.

ie, A_DELAY, or A_WAIT, or A_PAUSE.

Frame duration not only can be, but even has to be specified on every frame. Nothing could possibly be more redundant in DECORATE than a delay action function.

10 hours ago, zaszthedestroyer said:

what if instead of checking every few minutes, i have the system constantly check (silently) often to see when the health goes down, and then displays a message once it gets too low? it's a different approach, that would not require a timer, only a constant state...

Honestly, I don't understand why did you ever think that checking only once per few minutes was a better idea than this.

3 hours ago, jval said:

I've added merge-sort to the test-case and here are the results:

As we can see, merge-sort is faster than quick-sort, but not that fast as the radix-sort.

Did you do the intermediate step of appending lists with non-overlapping ranges? Because of course that merge-sort won't be as fast as radix-sort if you didn't. When used on vissprite-like data, that step should significantly reduce the number of lists to be merged by the standard merge-sort logic, speeding up the most critical part.

10 hours ago, Empyre said:

The name of the texture is SKY1, but the name of the patch that the  texture is made from is RSKY1.

He was talking about Ultimate Doom though, where the name of the patch is actually SKY1 too.

5 hours ago, Cell said:

    

Right is all four DEM1_* flats put together, left is the texture MARBFACE (patch MWALL4_1).

It's actually vice versa - the left picture shows the 4 flats and the right picture shows the texture.

@jval I was originally under an impression that you were doing these tests to improve performance of a specific source port, but since you didn't provide any source port specific info in your last post, I guess you're after solving the problem in general. I'm going to look at it more abstractly, then. The pattern in the data looks very exploitable and makes me think of an algorithm like this:

• As vissprites are being added, store a list of sectors that have at least one vissprite each, and for each such sector, store a list of its vissprites and also store the minimum and maximum vissprite scale of all the sector's vissprites
• Sort the lists of vissprites within each sector, the algorithm may vary for each list depending on its number of vissprites and on the difference between the maximum and minimum vissprite scale in the sector and even on how well the list was already sorted
• Check for pairs of sectors (in the list of sectors with vissprites) where the first sector's maximum vissprite scale is lesser or equal than the second sector's minimum vissprite scale, append the second sector's list of vissprites to the end of the first sector's list, change the first sector's maximum vissprite scale to the second sector's one, and remove the second sector from the sector list
• Merge the vissprite lists of the remaining sectors by mergesort's merging logic

Basically mergesort with an intermediate step of simply appending sorted lists whose ranges of vissprite scales do not overlap.

EDIT: Nevermind, anotak already said it, and with less words, too.

48 minutes ago, anotak said:

you may be able to save time by being aware of how sprites are added, as in, per-sector, and doing the sorting within a sector and then you have separate lists that you can merge more easily by checking their start/end

Open IWAD in SLADE3, sort lumps alphabetically and look at the block of lumps that start with "DS" and have type "Sound (Doom Format)".

You can go to sector mode and select geometry, then go to thing mode and select things, then go to edit selection mode (press E) and move both.

What exactly is the number by which they are sorted? What does it represent, where/when is it computed, where/how is it stored. (EDIT: I just want to understand how does the pattern in the data emerge, whether there would be any advantage in computing/storing additional data along with computing them to be used for the sorting later, also where/how the data is stored may affect performance of different sorting algorithms differently.)

6 hours ago, zokum said:

It should however be possible to programmatically "merge" lines split by trigger lines in the node builder IF the texture alignment is correct. That's a pretty problematic one though, since you'd have to know the width of the texture. That is not a trivial question when custom textures are involved.

Finding texture width is the biggest problem? Come on, you already have so much fancier features.

When using A_Chase inside an attack animation, make sure to use it with appropriate parameters and possibly flags (see here) to prevent it from automatically jumping into melee attack state when coming into melee range or back at the start of the ranged attack animation when randomly deciding to perform another ranged attack despite being in the middle of performing one.

1 hour ago, fraggle said:

I suspect it's maybe related to how Doom changes certain frame speeds to speed up the Demon,

I doubt it, your DEHACKED patch doesn't change any Demon-related frames. However, I can see right away that:

• The patch completely removes Pain Elemental's resurrection animation, which prevents the Pain Elemental from being resurrected as a ghost if its corpse gets crushed into gibs before its death animation completes.
• The patch changes the overall duration of some monster's death animations, which can change at which particular moment they will respawn on Nightmare or otherwise with monster respawn enabled. EDIT: Actually, if there's an Archvile near the monster right when its death animation is about to finish, it can change at which particular moment the monster will be resurrected, on any difficulty level.

5 hours ago, fraggle said:

there's a quirk with Nightmare mode that I haven't quite resolved yet

Maybe I or someone can help, tell us all you know about it.

GZDoom automatically detects when extra rotation frames are included in the wad and automatically uses them alongside the basic 8 rotation frames with the same sprite name. High resolution sprites can be defined in GZDoom either in TEXTURES, or in DECORATE (along with the monster/thing that uses them), or even by putting the sprite lumps/files into hi-res namespace if they're only supposed to replace stock sprites.

The only benefit of setting "Impassable" flag onto lines that already have "Block Everything" flag is that those lines will become bold white in Doom Builder.

To enforce pistol starts, you can use ResetHealth and ResetInventory in MAPINFO map definition, but then you also have to provide map definitions for all maps, which isn't very suitable for a mod that's supposed to be usable with any mapset. Another way is to use an ACS library with a script that calls ClearInventory upon every map start, which I recommend. There might be a DECORATE-only solution, but it'd be hacky and more complicated than the ACS one.

To make a backpack that gives you weapons, create a CustomInventory item that gives you both a normal backpack and the weapons.

Well, instead of including mutually incompatible resources, you can always try the "normal" way to use custom textures: Put the textures directly into your wad via a wad content editor like SLADE3.

Music names can be changed in vanilla compatible DEHACKED too.