Linedef special use in different ports

[zokum]

Kb1: You're misunderstanding the complexity. This would not need any bytecode, virtual machine, or script language. This is by no means Turing-complete. This is a simple keyword based system. All you'd need is a struct that has room for all these fields and extend the 2-3 places in Doom where linedef action lookups occur to also check the dynamic list. Doom already has a nice system for handling all of these things and do just fine across network in most ports. All the clients would need to know is which linedef got triggered and when, or in a more client-server based state machine system, which floor or ceiling is moving where and at what speed or which object got teleported etc.

Today's bit based system relies on cramming all of the info into the existing 8 bits or so used by Boom. My suggestion would merely be a system where you tell the engine which entry in a list of things with a lot more data space than a few bits. By using something as simple as a struct, you could stuff loads of info into relatively few bytes of memory. It's basically a lookup table that points to a much larger bit-flag-like structure.

The struct might have booleans like: floor_direction, requires_blue_key, is_teleport, monsters_can_trigger, coop_mode_required, dm_mode_required, alt_dm_mode_required, gun_triggered, use_triggered, walkover_triggered. It could have value fields like floor_up_speed, floor_down_speed. We just need to define all the keywords we can sensibly think of, and not encode them into a few bits.

This is about as complex as parsing command line parameters and is not hard to do at all.

 

[zokum]

What I suggest would not really be part of the map format, it would just be done in separate lumps in plain old ascii format. The doom map format would not need any changes, all you need is a simple parser for reading the extra linedef special lump. All kinds of tools would be able to edit for this extension just fine. It would be convinient to be able to edit/read this lump from the editor, but not needed. Before editors got support for the Boom system, that was a lot more unwieldy to use than this would ever be.

[Graf Zahl]

This requires some quite extensive rewriting of what the various thinker types can do to handle all the cases.

 

So here's the deal: Do we really need to reinvent this wheel? I guess on the long term roadmap some support for Hexen format will come up inevitably. Adding something along the same lines, but different, will make that job a lot harder in the end.

I think it's better to finalize a standard for the Doom map format first that doesn't add another layer of complexity. If that complexity is later deemed desirable, let's at least do it in a way that most interested ports can build upon what they already have. Right now ZDoom and Eternity already support Hexen type specials, and I believe 3DGE will get them as well.

 

This means that this would be a perfect base for more parameterization upon which some translation feature can build. Whether that uses ZDoom's XLAT which was designed to do precisely that remains to be seen, something simpler may be desirable maybe. But in any case, this approach will most definitely cause less headache than inventing yet another method that doesn't mix well with already established features.

 

[kb1]

On 7/29/2017 at 7:34 AM, zokum said:

Kb1: You're misunderstanding the complexity. This would not need any bytecode, virtual machine, or script language. This is by no means Turing-complete. This is a simple keyword based system. All you'd need is a struct that has room for all these fields and extend the 2-3 places in Doom where linedef action lookups occur to also check the dynamic list. Doom already has a nice system for handling all of these things and do just fine across network in most ports. All the clients would need to know is which linedef got triggered and when, or in a more client-server based state machine system, which floor or ceiling is moving where and at what speed or which object got teleported etc.

Today's bit based system relies on cramming all of the info into the existing 8 bits or so used by Boom. My suggestion would merely be a system where you tell the engine which entry in a list of things with a lot more data space than a few bits. By using something as simple as a struct, you could stuff loads of info into relatively few bytes of memory. It's basically a lookup table that points to a much larger bit-flag-like structure.

The struct might have booleans like: floor_direction, requires_blue_key, is_teleport, monsters_can_trigger, coop_mode_required, dm_mode_required, alt_dm_mode_required, gun_triggered, use_triggered, walkover_triggered. It could have value fields like floor_up_speed, floor_down_speed. We just need to define all the keywords we can sensibly think of, and not encode them into a few bits.

This is about as complex as parsing command line parameters and is not hard to do at all.

Not misunderstanding...just overreacting. Sorry about that. Please see below.

On 7/29/2017 at 7:47 AM, Graf Zahl said:

This requires some quite extensive rewriting of what the various thinker types can do to handle all the cases.

 

So here's the deal: Do we really need to reinvent this wheel? I guess on the long term roadmap some support for Hexen format will come up inevitably. Adding something along the same lines, but different, will make that job a lot harder in the end.

I think it's better to finalize a standard for the Doom map format first that doesn't add another layer of complexity. If that complexity is later deemed desirable, let's at least do it in a way that most interested ports can build upon what they already have. Right now ZDoom and Eternity already support Hexen type specials, and I believe 3DGE will get them as well.

 

This means that this would be a perfect base for more parameterization upon which some translation feature can build. Whether that uses ZDoom's XLAT which was designed to do precisely that remains to be seen, something simpler may be desirable maybe. But in any case, this approach will most definitely cause less headache than inventing yet another method that doesn't mix well with already established features.

 

@Graf Zahl and @zokum I agree about not reinventing the wheel, at this early stage. I have been considering an extremely simple translation layer where needed, that sits in front of XLAT, XG, LINES.DDF, or whatever. But what made me overreact was your idea (zokum) of "yet-another-Doom-reworking" (even though it's an interesting idea). I get what you're trying to do, but I have to fit this thing into a box, if I am ever going to get past step 1. Once this first step is over, we have access to all sorts of ideas on how to improve things: UDMF, for instance. I have to be concerned with compatibility first, which means all the Boom linedefs must stay. I suppose you could devote a range of linedefs as customizable. But, that has to be a later feature.

 

I didn't mean to jump on your idea like that. It's just that, in these recent threads, quite a few large new systems have been discussed, and I hate having to shoot them down/delay them. I try to be kind, or "diplomatic" about it, while trying to explain why, but text hides my meanings and intentions.

 

[zokum]

Fair enough kb1, as for reinventing the wheel, what we got now is a horrible square wheel, I just want a nice small round one. As for ZokumBSP i just added another one: 1084 - Do not render seg on the backside. This one is very useful for a lot of cases, and I even added some code that allows you to auto detect where this behaviour would be nice, like sky sectors with 0 height. I plan to have it togglable as part of the geometry pass that is done before blockmap, node and reject. Default will be off.

 

As for how efficient this is by mere auto detection, doom2.wad:

MAP01           Old       New    %Change    %Limit   Time Elapsed
   Linedefs:    381 =>    381    100.00%     1.16%     0.000 secs
   Sectors:      59 =>     59    100.00%     0.18%
   Nodes:       185 =>    184     99.46%     0.56%     0.017 secs
 * Segs:        611 =>    602     98.53%     1.84%
MAP23           Old       New    %Change    %Limit   Time Elapsed
   Linedefs:    391 =>    391    100.00%     1.19%     0.000 secs
   Sectors:      69 =>     69    100.00%     0.21%
   Nodes:       185 =>    185    100.00%     0.56%     0.022 secs
 * Segs:        580 =>    567     97.76%     1.73%

And a few extremely cherry picked ones in av.wad:

MAP12           Old       New    %Change    %Limit   Time Elapsed
   Linedefs:   3193 =>   3193    100.00%     9.74%     0.001 secs
   Sectors:     596 =>    596    100.00%     1.82%
   Nodes:      1489 =>   1475     99.06%     4.49%     0.487 secs
 * Segs:       5071 =>   4953     97.67%    15.12%
MAP16           Old       New    %Change    %Limit   Time Elapsed
   Linedefs:   3110 =>   3110    100.00%     9.49%     0.001 secs
   Sectors:     482 =>    482    100.00%     1.47%
   Nodes:      1746 =>   1704     97.59%     5.18%     0.627 secs
 * Segs:       5299 =>   5055     95.40%    15.43%

I just want a bit of linedef speicals range reserved for mapper stuff, custom behaviour and scripting. All ports can utilize it, but not for anything in-built. If we all agree on a range for this, things will be much more future proof. The example I gave was just to show there is merit for such a system.

I have many more planned, and since this is the documentation thread, this stuff might be of interest to ports that want to optimize without relying on the vanilla data formats so much.

 

 

[kb1]

Come on, man...it ain't horrible. It was considered "awesome" a few years back.

 

Great job on the reductions! Yes, I'll make sure you've got plenty to work with. It's kinda interesting: No one really needs to know that these linedefs are "pre-compiled", so to speak. You might have to get the other BSP devs to consider these as well. (I hate incompatibilities, if you couldn't already tell :) Someone missed a great opportunity for a custom title for me...