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

scifista42

Members
  • Content count

    14067
  • Joined

  • Last visited

About scifista42

  • Rank
    Why don't I have a custom title by now!?

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. scifista42

    Add TID

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

    Add TID

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

    Secret levels

    This.
  4. scifista42

    Doom Art

    https://www.doomworld.com/forum/10-creative-works/
  5. scifista42

    Post Your Doom Picture (Part 2)

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

    A quick thought on the "Is Doom 3D" debate

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

    Black Bar When rendering Foreground HP Bar

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

    A quick thought on the "Is Doom 3D" debate

    In every engine, geometry has limitations. In Doom engine, geometry has different limitations for x/y and different limitations for z. 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? Some nonsense.
  9. scifista42

    Add TID

    There wasn't, but... ...now there is.
  10. scifista42

    Decorate time delay(timer)

    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. Honestly, I don't understand why did you ever think that checking only once per few minutes was a better idea than this.
  11. scifista42

    Potential for improvement in vissprites sorting

    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.
  12. He was talking about Ultimate Doom though, where the name of the patch is actually SKY1 too.
  13. scifista42

    Things about Doom you just found out

    It's actually vice versa - the left picture shows the 4 flats and the right picture shows the texture.
  14. Good to see you posting again scifista42!

     

  15. scifista42

    Potential for improvement in vissprites sorting

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