-
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.
-
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!
-
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.
-
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.)
-
Black Bar When rendering Foreground HP Bar
scifista42 replied to DynamiteKaitorn's question in Editing Questions
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. 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.
-
There wasn't, but... ...now there is.
-
Decorate time delay(timer)
scifista42 replied to Hitscanning_scumbag's question in Editing Questions
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. -
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.
-
*** The "ask a miscellaneous editing question" thread ***
scifista42 replied to baja blast rd.'s topic in Doom Editing
He was talking about Ultimate Doom though, where the name of the patch is actually SKY1 too. -
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.
-
Open IWAD in SLADE3, sort lumps alphabetically and look at the block of lumps that start with "DS" and have type "Sound (Doom Format)".
-
Doom Builder X 2021.1 (September 20) - map editor
scifista42 replied to anotak's topic in Doom Editing
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.