Chocolate Strife Development

THis sounds awesome. I loved stife and would love to have a Chocolate option.

Monster bump to let everybody know that development has started in earnest now. DOOM-specific stuff is starting to disappear from the src/strife folder at an increasing rate.

:D

Cool, maybe one day I might make a 'vanilla' strife map using this port just for kicks once its finish :D

And we seem to have hit our first (minor?) roadblock. I've implemented the crossfade screenwipe routine exactly as it is in the executable, but when testing this with custom XLATAB lumps built on the DOOM palette, the game goes into an infinite loop. It gets to a certain point where the foreground pixel is not equal to the background pixel, but the tranmap keeps returning the same foreground pixel value for pretty much every pixel on the screen. This means it'll never end, since Rogue coded the thing so that the wipe continues if any pixel on the screen isn't equal to the background pixel.

I don't understand how this ever worked. Is the Strife XLATAB lump specially constructed to make sure it can't reach this steady state without running the screen pixels all the way down to the background color, somehow?

It's stupid to code it like that anyway, vanilla accuracy or not. You should abort at the latest if you see that no pixel has changed.

Graf Zahl said:

It's stupid to code it like that anyway, vanilla accuracy or not. You should abort at the latest if you see that no pixel has changed.

I know it's *stupid* but the point of this project is to stick as closely to the binary code as possible (otherwise what's the point, right?) I obviously cannot do that if the code just won't work for whatever reason. I am trying to come to an understanding of *why* it is doing what it's doing, because to me it doesn't make sense.

If you edit Strife1.wad to use your custom XLATAB (and PLAYPAL if needed), does the original exe go on an infinite loop too?

If so, I don't see where the problem is. People just shouldn't use bogus lumps.

I've analysed the XLATAB lump and can say that every combination of starting color and mixing (background) color will converge to the mixing color in enough steps.

begin  Same rows: 0
pass  1 Same rows: 0
pass  2 Same rows: 0
pass  3 Same rows: 0
pass  4 Same rows: 0
pass  5 Same rows: 0
pass  6 Same rows: 1
pass  7 Same rows: 4
pass  8 Same rows: 20
pass  9 Same rows: 95
pass 10 Same rows: 157
pass 11 Same rows: 203
pass 12 Same rows: 239
pass 13 Same rows: 250
pass 14 Same rows: 256
pass 15 Same rows: 256
pass 16 Same rows: 256

This cannot be an accident, I think the program they made to make the XLATAB lump had specific logic to ensure this. It would explain why the image of the XLATAB data looks weird (odd diagonal bits in each rectangle).

Gez said:

If so, I don't see where the problem is. People just shouldn't use bogus lumps.

From the last post I deduce that the lump the code was written for is bogus. :D

Graf Zahl said:

From the last post I deduce that the lump the code was written for is bogus. :D

To say the least 6_9

Bah, you want to do a chocolatey thing, you do a chocolatey thing. Strife was in many respect a big hack job (like Doom itself was, heh), and I guess it makes sense that the developers tailored what they did to what they wanted to achieve, rather than to absolute standard of high stability. It was intended as a self-contained game, not a standard platform.

In that respect, that their crossfade algorithm trusted the source data to allow it to work makes sense to me. I don't see how that is worse than accepting 0-tics states (which can also lead to the engine freezing with an infinite loop).

If people use a lump that freezes the game, then it's their own fault, not the game's fault. The engine was not written with the intention of getting garbage data, but the specific data that Rogue created for it. You could just as well put garbage map lumps, there's no sanity checks on any of them either. Game expects data that works, give it data that works, even if you think it would have been more elegant if it were different.

Reminds me of the fun I had the last few days on http://thedailywtf.com ... :P

Gez said:

Bah, you want to do a chocolatey thing, you do a chocolatey thing. Strife was in many respect a big hack job (like Doom itself was, heh), and I guess it makes sense that the developers tailored what they did to what they wanted to achieve, rather than to absolute standard of high stability. It was intended as a self-contained game, not a standard platform.

In that respect, that their crossfade algorithm trusted the source data to allow it to work makes sense to me. I don't see how that is worse than accepting 0-tics states (which can also lead to the engine freezing with an infinite loop).

If people use a lump that freezes the game, then it's their own fault, not the game's fault. The engine was not written with the intention of getting garbage data, but the specific data that Rogue created for it. You could just as well put garbage map lumps, there's no sanity checks on any of them either. Game expects data that works, give it data that works, even if you think it would have been more elegant if it were different.

Exactly. You pretty much get it. It's why I'm not at liberty to just change it willy-nilly. It's just a damn shame it's not going to work because it means I cannot fully test the crossfade until we have the IWAD fully loadable.

Thank god I don't have to bother with such crap... :P
(and thank god that probably nobody will ever replace that lump in a PWAD...)

What prevents you from testing with the XLATAB lump extracted from Strife1.wad?

Well it's calculated for the DOOM palette, not the Strife palette, so I'd have to load the Strife palette as well. Of course this will turn everything into technicolor puke, but I guess it's the price to be paid.

You could load Harmony as a PWAD then. It's in Doom format and its palette is very close to Strife's. (The sprites will be glitchy and oversized because they are tall patches scaled down in DeHackEd, but that's not too much of an issue.)

Alternatively, you can take doom2.wad in SLADE3, mass select all lumps, and convert them to the Strife palette. (First, from top to end of patches into Doom Graphics with Strife palette, then from end of patches to end of file into Raw Graphics with Strife palette as well.) You can now put the Strife palette, colormap and XLATAB in that too, and save your special strifed-up Doom2 test IWAD. Should be done in 15 seconds.

(Note that to edit an IWAD, you need to set your SLADE3 preferences not to lock IWAD entries. It's in Editor -> Preferences -> Editing.)

I am surprised you're still using the doom wad to test this. When I did svstrife, the first thing that I did was to make sure it uses strife1.wad as the main iwad and then I would just attach any existing doom lumps that were still required at the time.

Heh, I made myself a doom2s.wad with Slade as I explained above, and then ran through MAP01 to see how palette-raped it looked. It's amusing.

Little gallery of screenshots

What's striking is that the blood is caught in the "always bright" red range, as are the two lighted panels of the switch, and a few other things. The overall ambiance is a lot more red and green. It's rather amusing overall.

Here's my own custom XLATAB built for the DOOM palette, which some logic to ensure convergence to any background color (well it passes the same test I ran before with the lump from Strife).

http://oblige.sourceforge.net/files/XLA_DOOM.zip

First official Choco Strife screenshot! Not too pretty, but it's something ;)

And, the beginnings of Spiderman Doom!

Surprisingly, live imps don't look too bad in the Strife palette.

Gez said:

Surprisingly, live imps don't look too bad in the Strife palette.

Yeah they put on their little red imp suits. All that's missing is a pitchfork that they could jump around poking people with in time to the music track from Alien Vendetta MAP01.

New Shot. The IWAD is now loadable:

Yay!

There's a minor inconsistency both in SvStrife and (as I remember) in ZDoom. The chalice. All in all the trick may be useless (governor still finds out), but still. When I got the chalice from the vault, I didn't enter the tavern. Instead, I dropped it on the broken window next to Harris, in order to pick it up when I get inside. Neither in SvStrife nor in ZDoom could I drop it on the fence. It always fell on the floor. Vanilla Strife allows me to drop it on the fence. Even if it's useless in that case, it might be worth supporting for whatever quest-ridden mods appear.

I can see why this needs to be addressed in a Chocolate engine.

However, how could this be of any use to a mapper if it makes the mod incompatible with the physics code of all other engines?

Basically we are putting the binary code into Choco Doom with as little interpretation or fixing as possible. If it doesn't work perfectly after that process is finished, we will try to figure out why (up to the point of going insane at least).

In other words our *intent* is 100% compatibility. Whether or not that is humanly attainable has yet to be demonstrated.