7 linedefs tech demo map for Doom 2 (1285 bytes)

[zokum]

Almost all of the original doom maps also have such lines, they're not that uncommon. The real savings are found in control sectors that manipulate how far a floor goes etc. These don't need to be rendered at all.

All in all with trigger lines that are intra-sector, two sided lines that will only be seen from one side and control sectors, you can probably save a fair amount of segs in many maps. This is a part of mapping that isn't all that well explored or known about.

[Graf Zahl]

2 minutes ago, zokum said:

 This is a part of mapping that isn't all that well explored or known about.

 

Well, considering that the largest vanilla compatible map I have seen (AV's Misri Halek) has 24458 sidedefs, coming nowhere near the limit, amd a map like BTSX II's Unstable Journey clocking in at a mere 18000  is that really this surprising? These are both huge levels that take an eternity to play through. And both have very little in the form of control sectors, monster closet or intra-sector triggers.

Any map with a higher number of sidedefs has done so by adding more detail and become limit removing or Boom compatible at least.

 

There simply had never been any need for this kind of space saving. In general you can assume that a regular node build will produce ~20-25% more segs than sidedefs - unless you got a perfectly grid-aligned orthogonal map - so you'd need to be able to eliminate several 1000's of sidedefs from the equation before you got a payoff. Isn't this a little bit unrealistic?

 

As I see it, even when the seg limit is exhausted the sidedef limit will be so far away that there's no need to do these things - you still should have regular sidedefs to spare aplenty.

[Linguica]

Do those maps use sidedef compression though? That's the fly in the ointment that already screws up the traditional view of how a Doom level is built - people long ago realized that sidedefs are literally a list of properties, and there's no need to have different ones for every linedef with the same properties.

 

On 7/2/2001 at 8:59 AM, DeePTeam said:

Packing sidedefs does make a huge difference in map size. This step is reversable. It DOES extend the size of the level you can make - typically by at least 30 percent. You -have- to reverse it to be able to edit without introducing too many problems. Just be aware that it's possible to make a packed level you can't unpack:))

[zokum]

7 minutes ago, Graf Zahl said:

 

Well, considering that the largest vanilla compatible map I have seen (AV's Misri Halek) has 24458 sidedefs, coming nowhere near the limit, amd a map like BTSX II's Unstable Journey clocking in at a mere 18000  is that really this surprising? These are both huge levels that take an eternity to play through. And both have very little in the form of control sectors, monster closet or intra-sector triggers.

 

Misri Halek was limitd by the blockmap, and was slightly scaled down due to this. To this day I regret not talking more with Malde and Johnsen about this and taking a more active part in AV other that looking at it and saying nice and showing them some of my stuff. I could perhaps have helped them with this map. With better blockmap building av map20 goes form ~65k to around 53k. And this is without marking lines as non-collidable, which the map has plenty of.

I don't think the 20-25% more segs is very realistic. With the experimental vertex-pair based node builder i managed to build most Doom 2 maps with 0-3 splits. A more correct estimate might be 2-10% for a complex map and a good node builder. My code doesn't handle large maps well. With a better algorithm for picking partitions this should become a non-issue.

The way I map I tend to use a lot of control sectors, gobbling up a lot of sidedefs and linedefs :D

[zokum]

I don't think they use sidedef compression. The map I released has an example of an extreme form of sidedef compression not available in any tool. That might limit the amount of needed sidedefs a lot more. That depends on whether there are many different values for Y-alingment used or not, as that is not compressable. My casual inspection of maps seem to indicate that changes in X-offset is lot more common from sidedef to sidedef than Y-offset.

[Graf Zahl]

The numbers were without sidedef compression, even if the maps have it. The tool I use counts number of linedef sides, not actual sidedefs.

With sidedef compression the number of Misri Halek goes down to less than 12000, less than the number of linedefs, so we are very, very far away from any limit here - with regular sidedef compression in the game I think you'll never run out of sidedefs before hitting the blockmap or seg limit.

 

 

 

[zokum]

42 minutes ago, Graf Zahl said:

The numbers were without sidedef compression, even if the maps have it. The tool I use counts number of linedef sides, not actual sidedefs.

With sidedef compression the number of Misri Halek goes down to less than 12000, less than the number of linedefs, so we are very, very far away from any limit here - with regular sidedef compression in the game I think you'll never run out of sidedefs before hitting the blockmap or seg limit.

You're probably correct about most maps. For me a consideration is also if the maps would run in doom2.exe, mostly for purist reasons :)

It would be interesting to see if the original maps would run in jaguar doom with enough compression.

[andrewj]

8 hours ago, Linguica said:

people long ago realized that sidedefs are literally a list of properties, and there's no need to have different ones for every linedef with the same properties.

There are a few cases where sidedefs need to stay unique (not shared) :

1. scrolling walls -- sharing that sidedef can cause walls to scroll that are not meant to, or walls scrolling faster than normal since multiple lines modify the same sidedef
2. switch textures -- activating the switch can change walls that are not intended
3. EDGE has a scripting ability to change textures on walls (maybe ZDoom ACS has it too?) and that can affect unintended walls if the sidedef is shared.

[zokum]

7 minutes ago, andrewj said:

There are a few cases where sidedefs need to stay unique (not shared) :

1. scrolling walls -- sharing that sidedef can cause walls to scroll that are not meant to, or walls scrolling faster than normal since multiple lines modify the same sidedef
2. switch textures -- activating the switch can change walls that are not intended
3. EDGE has a scripting ability to change textures on walls (maybe ZDoom ACS has it too?) and that can affect unintended walls if the sidedef is shared.

Actually, if you have multiple lines with scrolling walls that can be compressed, one could just remove the extra type 48 linedefs. One type 48 linedef could scroll 1 sidedef and say 30 segs instead of having 30 scrolling linedefs scroll one sidedef and segs. I think it should be possible to get over the "limit" on the amount of scrolling walls.

Switches are important, but I reckon most compression tools only compress on walls that have no special. That fixes all of these problems. The sidedef of a line with a type can be flagged as do-not-compress.

[andrewj]

9 minutes ago, zokum said:

Actually, if you have multiple lines with scrolling walls that can be compressed, one could just remove the extra type 48 linedefs. One type 48 linedef could scroll 1 sidedef and say 30 segs instead of having 30 scrolling linedefs scroll one sidedef and segs. I think it should be possible to get over the "limit" on the amount of scrolling walls.

Yeah, poking around the DOOM source code just now and I noticed that limit of 64 scrolling walls (I_Error if exceeded) -- ouch.

 

glbsp supports compressing ("packing") sidedefs, but it is not enabled by default, and it does skip sidedefs belonging to a line with a non-zero special.

[ketmar]

13 hours ago, Graf Zahl said:

BTW: Doesn't work in EDGE and k8vavoom either - not that it surprises me.

yeah, k8vavoom forces node rebuilding, it never uses nodes from a wad. so any BSP trick will be dead on arrival.

 

[andrewj]

1 hour ago, ketmar said:

k8vavoom forces node rebuilding,

Does it rebuild the PVS too? I thought that would be too slow to do on each level load.

[ketmar]

1 hour ago, andrewj said:

Does it rebuild the PVS too? I thought that would be too slow to do on each level load.

PVS is absolutely not needed anymore. it might had some limited use for SW rendering (yet i doubt it too), and might sped up LOS checks with BSP, but Janis ditched SW renderer in original Vavoom, and i replaced BSP LOS with blockmap LOS. tbh, k8vavoom cannot even load PVS anymore, i killed that code for good. it still can *use* it, though (and can do very rough PVS building on startup), but i'll prolly remove that code soon.

 

i don't know if PVS was actually usable for anything, because on my core2duo glvis couldn't even finish building PVS for Ultimate Doom E1. it worked for 3 or 5 hours, and didn't finished.

 

p.s.: and thanks again for AJBSP! i replaced glBSP with AJBSP in k8vavoom, and it works like a charm! ;-)

 

p.p.s.: also, k8vavoom can cache built BSP (and PVS, if there is any), and it caches precalculated lightmaps too. so even in the worst case you have to do it only once.

Edited February 3, 2020 by ketmar

[Graf Zahl]

6 hours ago, andrewj said:

There are a few cases where sidedefs need to stay unique (not shared) :

1. scrolling walls -- sharing that sidedef can cause walls to scroll that are not meant to, or walls scrolling faster than normal since multiple lines modify the same sidedef
2. switch textures -- activating the switch can change walls that are not intended
3. EDGE has a scripting ability to change textures on walls (maybe ZDoom ACS has it too?) and that can affect unintended walls if the sidedef is shared.

 

All correct. ZDoom of course has the ability to change textures on the fly - it's a feature inherited from Hexen.

There's also a few other things, like attaching decals to a wall, that require unique sidedefs. So ZDoom had to add a sidedef decompressor to make them unique again. Which obviously means you'll never experience any sidedef compression artifacts in any ZDoom-based engine.

 

4 hours ago, ketmar said:

yeah, k8vavoom forces node rebuilding, it never uses nodes from a wad. so any BSP trick will be dead on arrival.

 

I found that to be a very problematic approach from the start because several maps depend on quirks in their BSP so GZDoom always kept the original map's BSP around for play-related uses (P_PointInSector) and rebuild the BSP for rendering, unless the map already comes with GL nodes.

[ketmar]

9 hours ago, Graf Zahl said:

I found that to be a very problematic approach from the start because several maps depend on quirks in their BSP

yeah, i know about possible problems with that. so be it: those maps are broken, and not supported in k8vavoom. any BSP trick will make the engine (and both renderers) go mad anyway, so there is no reason to jump through hoops only to find out that everything is broken. so i chose to force BSP rebuilding. keeping two BSPs is a mess, and lucky me: i don't have to support every map out there.

[zokum]

On 2/3/2020 at 6:29 PM, ketmar said:

yeah, i know about possible problems with that. so be it: those maps are broken, and not supported in k8vavoom. any BSP trick will make the engine (and both renderers) go mad anyway, so there is no reason to jump through hoops only to find out that everything is broken. so i chose to force BSP rebuilding. keeping two BSPs is a mess, and lucky me: i don't have to support every map out there.

That's a fair enough attitude, but to me your engine is no longer Doom compatible :). It's Doom-derived.

[ketmar]

6 hours ago, zokum said:

but to me your engine is no longer Doom compatible :). It's Doom-derived

it is fairly hard to draw the line between being compatible, and being derived. but yeah, i stated it right in the description, so people will know what to expect:

 

i must admit that i am not trying to make k8vavoom compatible with as many pwads as possible. that is, compatibility is "good enough" to play many different pwads, but AI, LOS checking, collisions and such are not set in stone. so if some map rely on exact engine behavior, it may, or may not work, and i may, or may not fix it.

 

actually, that was even more the case with Vavoom. funny enough, i greatly improved compatibility with vanilla instead of destroying it. but it was an accident. ;-)

 

we have alot of different sourceports, with different goals and features, including "purist ports". k8vavoom is how i see the "Doom game of my dreams". if other people enjoy it, great. if not... ok, i won't push k8vavoom down their throats (or up their asses ;-).

 

tl;dr: you're prolly right. ;-)

Edited February 8, 2020 by ketmar