Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content count

  • Joined

  • Last visited

Posts posted by scifista42

  1. 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.

  2. 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.)

  3. 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.

  4. 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:



    Some nonsense.

  5. 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.

  6. 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.

  7. @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

  8. 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.)

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. 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.