Unused Strife feature identified

I'll just let the picture speak for itself mostly:



Flag 2048 is NOT without a purpose. It is a flag for what Strife considers normal translucency (25% fg, 75% bg). 4096, which is currently known as "translucent" in UDMF, is the analog of the MVIS flag for thing types, and represents 75% fg, 25% bg.

The code from Hex-Rays reveals this definitively:

  if ( *(_BYTE *)(curline->linedef + 17) & 8 )
    colfunc = lucentcolfunc;
  if ( *(_BYTE *)(curline->linedef + 17) & 0x10 )
    colfunc = (void (*)(void))R_DrawMVisTLColumn;

linedef+17 is the second byte of line_t::flags, so shift the values up 8 bits to get the actual flag values of 0x800 and 0x1000 respectively.

heh, I gave up figuring that one out years ago. Good to see some of Strife's mysteries are being solved..

Yay Quasar. It's neat to see all these little mysteries get solved.

I gotta note that SoM, who was feeling especially observant, noticed that the translucent column drawer functions in Strife clip off the very top and bottom pixels of the texture at the edges of the screen.

Why? I determined that Rogue copypasta'd R_DrawFuzzColumn to use as a template for their two translucent column drawing routines. R_DrawFuzzColumn clips off the top and bottom pixels if they are touching the edge of the framebuffer so that it can do its scrambling voodoo. This wasn't necessary for Rogue's translucency though, so they either plain forgot to remove these checks, or simply never really understood what they did in the first place ;)

The question is: Is this worth supporting in ports or would it make more sense to have mappers use the generic translucency feature? After all there's not a single map using this.

Strife is sort of a special case due to the fact there are pretty much zero mods for it, and the few levels that do exist are known to stick to the well-known feature set.

The main reason I pointed this out is that 1. it's never safe to assume something has no function until you examine all codepaths and 2. I have interest in trying to create a "Choco" Strife port that will be as close to 100% accurate as possible. The only real thing it's waiting on is sorting out how we have to do it to keep it all legal.

Quasar said:

Strife is sort of a special case due to the fact there are pretty much zero mods for it,

3, to be precise. ;)

The main reason I pointed this out is that 1. it's never safe to assume something has no function until you examine all codepaths and 2. I have interest in trying to create a "Choco" Strife port that will be as close to 100% accurate as possible. The only real thing it's waiting on is sorting out how we have to do it to keep it all legal.

Ok - but it you do that and support these features they will have to be supported in ports as well eventually - or they'd lose compatibility.

So even for a 'Choco Strife' - would it make sense to support things that were never used at all?

Graf Zahl said:

The question is: Is this worth supporting in ports or would it make more sense to have mappers use the generic translucency feature?

Could it be handled by xlat?

Graf Zahl said:

So even for a 'Choco Strife' - would it make sense to support things that were never used at all?

They were never used but existed. I'd keep them if I were in charge.

And what's the driving factor for "chocolate" compatibility? Full demo support, and the preferably exact behaviour in interactive mode? I know Eternity cheats this a bit by disabling little Boom enhancements only for demos.

Graf Zahl said:

Ok - but it you do that and support these features they will have to be supported in ports as well eventually - or they'd lose compatibility.

Not any more than they are already missing from vanilla Strife. "Choco" Strife would just be a vanilla Strife capable of running unassisted on modern platforms. It would serve as a sort of documentation and usable base source for other ports. They can take or leave as much compatibility as they desire, which is what we've done with every other game.

For example, ZDoom, EE, and Doomsday all cause Heretic current to move voodoo dolls immediately rather than only if they have some momentum already. This technically creates a compatibility issue. But the fact is, no extant Heretic maps made before a couple weeks ago ever tried to use voodoo scripting. Interest in this has only just now arisen, and it happened via interest in the vanilla game engine. My point? People are still using those things and expecting modern ports to behave in a manner that's at least somewhat consistent. If the vanilla engine supports something, people may yet discover it and decide to (ab)use it.

Quasar said:

For example, ZDoom, EE, and Doomsday all cause Heretic current to move voodoo dolls immediately rather than only if they have some momentum already.

Not just Voodoo dolls - it also affects players which get teleported into current - and AFAIK Hexen shows the same behavior.

Maybe a compatibility option is needed.

You're the man, Quasar!!! I'm glad you're figuring these functions out... ammmm, btw, I'd like to know something...

1) How many more functions/codepointers (still don't know what codepointers are) are missing?!

2) If you could say a value, from 1% to 100%, regarding the strife engine status, how many would it be!? I mean, how many % is already known from the engine... and what's still left to discover...

Thank you for keeping up the great work on such a great game!!!

Bruno Vergílio said:

You're the man, Quasar!!! I'm glad you're figuring these functions out... ammmm, btw, I'd like to know something...

1) How many more functions/codepointers (still don't know what codepointers are) are missing?!

All of the codepointer functions have been identified. There are less than 30 functions in the entire Strife portion of the code that remain unidentified (we are not working on the DMX/libc/Watcom crt0 portions obviously).

Codepointer, btw, is DeHackEd slang for the pointers to action routines that are stored in the states table in the Doom engine. Most people call these action functions these days; I still prefer codepointer even though it's a bit incorrect, simply because I grew up on DeHackEd ;)

Bruno Vergílio said:

2) If you could say a value, from 1% to 100%, regarding the strife engine status, how many would it be!? I mean, how many % is already known from the engine... and what's still left to discover...

Thank you for keeping up the great work on such a great game!!!

This is very hard to do because while we know what most of the functions are supposed to be doing, the why's and wherefores of them doing it are in some cases quite foggy. Watcom knew how to make a real mess of some of the code, and as I've said previously, some of it was obviously a mess long before the compiler even touched it. So percentages are too hard to quote anything on. I would say we have enough of an understanding at this point to recreate the game from scratch using a vanilla base source though.

The main problems are the parts of the "code" that are really data (mobjinfo, states, sliding door tables, terrain type structures, etc.) which are pretty much impossible to recreate entirely from scratch. They have to come from somewhere, and that somewhere needs to be a GPL-compatible code base.

It's really a shame we have to keep dodging all these licensing complications even though Doom itself is GPL >_< I doubt the legal spider webs surrounding the fall of Velocity and Rogue will ever go away. Even though my effective recovery of the lost source code should be seen as a gift, the legal system still insists on full protection for all orphaned works.

Bruno Vergílio said:

1) How many more functions/codepointers (still don't know what codepointers are) are missing?!

Codepointers, or actor function, or action function, etc. are the functions used by actors (monsters, weapons, decorative items...) in their states. "Codepointer" just means it's a pointer to some code, in this case to the functions that they can call.

The list of original codepointers can be seen in INFO.C, right near the beginning, just after the sprite array. Here are the first few from Doom:

void  A_Light0();
void A_WeaponReady();
void A_Lower();
void A_Raise();
void A_Punch();
void A_ReFire();
void A_FirePistol();
void A_Light1();

There's more than 80 lines of those so I'm not pasting them all. Heretic, Hexen and Strife have their own lists of codepointers, some are the same, some are different, some are new, some are missing, etc.

In ZDoom's DECORATE, they can be called by the same name they had in C, but in Eternity's EDF they lose the A_ prefix.

Mmmm Thanks for the info Quasar... I hope you get to these remaining functions very soon, good luck... ammmm, one thing... I'm pretty sure someone already had this idea, but, I hope it's not dumb...

http://www.mobygames.com/developer/sheet/view/developerId,9814/

This link sends to the page of JAMES MONROE, the guy who programmed strife, looks like he's still working on games, and is working at raven's... so ammmm, would it be possible to email raven or even him, and ask for some info!? I know it's been already 13 years, but he may remember some stuff you may have missing... so, it's just an idea, if it's too dumb sorry, but that's all I could come up with... cya!!

Quasar said:

The main problems are the parts of the "code" that are really data (mobjinfo, states, sliding door tables, terrain type structures, etc.) which are pretty much impossible to recreate entirely from scratch. They have to come from somewhere, and that somewhere needs to be a GPL-compatible code base.

All these things can be externalized to text files, however. So they don't have to be part of the code itself, and thus can avoid having to be under the GPL.

Can reverse-engineered code even be GPL'd or is it still under the original license?

We don't intend to use any of the reverse-engineered code :)

As for contacting James Monroe about it, it might be worth somebody's time to try, but it won't be me. I already used up all the good will I had with those guys getting the Heretic and Hexen code GPL'd :P

Kaiser happens to personally know the other guy who worked on Strife, who has even previously said that the source *might* exist on some moldy old disks in his basement. But evidently he couldn't be arsed to try finding it :P

I've tried to prod various people into asking the people that might be able to give us permission to just directly release the results of the reverse engineering as GPL code, but nobody can be bothered it seems. Just like with the Raven thing, either I take it upon myself, or it doesn't get done. This time, I'm not gonna stick my neck out I'm afraid.

Quasar said:

Just like with the Raven thing, either I take it upon myself, or it doesn't get done. This time, I'm not gonna stick my neck out I'm afraid.

On the other hand I suppose it has to be done by someone who has some port programming cred.

(I'd like to see the Shadowcaster source released (I'd just want to play that game without getting a transfer stack overflow every five minutes, even if it's less annoying in DOSBox than it was in DOS back in the days) but I don't think I have a snowball's change in hell to ever obtain it. So it'll just remain a pipe dream.)

If anybody DOES contact James Monroe at some point, it would make sense to ask him about GPLing ACC too. It's kind of silly to have a compiler for the scripting language for a GPL game under a non-free license.

ZDoom could probably benefit from this, since Randy asked me about it during the Heretic/Hexen GPL drive. Unfortunately at the time I felt it was a bad idea to add any more requests, since it looked so unlikely at the time that we would even get as much as we did.

EE might have benefitted from this too a few months ago, but we've already moved on to a bigger and better idea for our ultimate scripting solution...

Well, I can try to email Raven and ask for some questions, but just don't know some of these, so, Quasar, give me a list of questions about this gpl stuff (I don't understand it much, sorry) so that I can send them to him... I'll send some more too... about the source code, who is this guy kaiser talked with? maybe I can talk with him too... for now I'll try to get any emails from raven guys that worked up with strife... let's what I can get from them...

Graf Zahl said:

Can reverse-engineered code even be GPL'd or is it still under the original license?

I believe to be absolutely safe you'd have to use a clean room approach to avoid copyright issues. E.g. Someone does the reverse engineering, writes a spec, then someone else does the implementation based on the spec. On the other hand, ScummVM is GPL, despite being uncleanly engineered and having a far higher profile than a Strife engine would do, so perhaps it doesn't matter.