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

Translator between Boom generalized linedef <-> corresponding regular linedef?

Recommended Posts

Hi there,

Boom generalized linedef types are basically bit patterns that tells the engine what should happen if the line in question gets used. Since about any combination of actions is allowed, it should be possible to map the entire range of the 141 regular linedef types of Vanilla Doom to the corresponding bit patterns in Boom generalized linedef syntax.

I am sure this has been done before, but could not find concrete examples on the web. I'd highly appreciate any pointers!

Thanks!

- Fabian

Share this post


Link to post

Not the entire range. There are several types of lines which are not represented at all amongst the generalized types. In particular, there is no effort at generalized lighting (was a "Phase 2" goal never realized). There's no custom form of donut action either.

Even then, there are also divergences in behavior where types might seem consistent. Boom generalized floor texture changers have a different (and unfortunate) timing than the normal type. Boom generalized doors do not allow retriggering while they are in action, unlike normal DR doors (this is fixed in Eternity). Monsters don't stick to generalized locked doors like they do to regular ones. Etc.

None of this is helped by the fact that BOOMREF.TXT is incorrect in several locations, due to bugs in the implementation. Generalized walkover crushers do nothing, and several other trigger types have unintended oddities.

Share this post


Link to post
Kappes Buur said:

BOOMREF.TXT which is included in the BOOM202.zip file explains all of that, and more.

Yes, but it doesn't say "regular linedef 29 can be represented by generalized linedef 0xabcdef". This is what i am looking for, if possible for all 141 regular linedefs.

Share this post


Link to post

Depends how accurate you want to be. As Quasar explained, there are behavioral difference between regular effects and generalized effects; and many effects have no generalized variant (lighting, donuts, teleport, exit, texture scrolling).


If you look at ZDoom's xlat files, you'll see a different kind of translation: from regular (and extended) linedef types to Hexen-style parameterized variants. Here's where it gets useful: ZDoom has parameterized specials for each generalized effect: Generic_Crusher, Generic_Stairs, Generic_Lift, Generic_Door, Generic_Ceiling, and Generic_Floor. So if you find Generic_Blah used for a translation of a linedef, it's a linedef that can be translated accurately to a generic effect. Then you can reverse the parameters into bitfield values I guess.

Turns out there's only one:

 40 = WALK,		Generic_Ceiling (tag, C_SLOW, 0, 1, 8)
40: W1 Ceiling To Highest Ceiling => 16448


This is not necessarily exhaustive (there might be other duplicates) or even accurate (ZDoom has had its fair share of incorrect translations, though many have been caught the last few years); but it is a start I guess.

Share this post


Link to post
Gez said:

So if you find Generic_Blah used for a translation of a linedef, it's a linedef that can be translated accurately to a generic effect. Then you can reverse the parameters into bitfield values I guess.


This sounds at least somehow promising.

The background is that I'd like to implement rudimentary support for generalized linedefs in Crispy Doom. I don't strive for 100% compatibility, I just want *something reasonable* to happen whenever a generalized linedef is triggered. For example, in Freedoom2 Map02 there is a switch with a generalized linedef that opens a door. This is really nothing that could not get achieved with a regular linedef. I just need a means to tell the engine "if you find this bit pattern, then forget about the other bits and simply open that door already".

Share this post


Link to post
fabian said:

The background is that I'd like to implement rudimentary support for generalized linedefs in Crispy Doom. I don't strive for 100% compatibility, I just want *something reasonable* to happen whenever a generalized linedef is triggered.

That is not a good idea -- either implemented the whole standard or nothing at all. No-one is helped by half-baked implementations of standards.

Also, expect users will complain at you when the first few maps of a megawad work OK and then a door cannot be opened in MAP04.

Share this post


Link to post

Hm, probably you are right. But, anyway, it would be very interesting to know which generalized linedefs could be translated back into regular linedefs.

Share this post


Link to post
andrewj said:

That is not a good idea -- either implemented the whole standard or nothing at all. No-one is helped by half-baked implementations of standards.

Also, expect users will complain at you when the first few maps of a megawad work OK and then a door cannot be opened in MAP04.

I tend to agree. It's not that hard to add Boom's generalized types. Basically, they're in a separate file, IIRC, and you'll need some "glue" code. The transfer ones, like swimmable water, will require a bit more work, though.

But, basically, after you add support for one of them, you'll need another down the road. It's inevitable. You'll want to play some map that uses one, and be disappointed that you cannot finish the map without cheating.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×