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

Chocolate Strife Development

Recommended Posts

NOTE (added 2017): This is an old thread, and Chocolate Strife is now complete and included in Chocolate Doom releases. See the website for more details, and report Chocolate Strife bugs on the Chocolate Doom wiki.

 

This thread can serve as a place to post messages about Chocolate Strife development, which should be kicking off for real very soon. Kaiser and I will be systematically transforming Doom into Strife using all of the information available from our reverse-engineering project under the Strife branch in the Chocolate Doom repository.

I myself have a question that needs fraggle's attention. I need to copy the files from strife-branch/doom into a new strife-branch/strife directory. Should the copy be done maintaining SVN revision history information, or simply as a plain file copy and addition of the files as new to the SVN repo? I am not sure which is more semantically correct.

Edited by fraggle : Add note, since this thread appears prominently in Google results for "Chocolate Strife"

Share this post


Link to post

Oh man this is going to be quite fun. May I ask a question--- Will this implementation still not have Deathmatch support?

Share this post


Link to post
Csonicgo said:

Oh man this is going to be quite fun. May I ask a question--- Will this implementation still not have Deathmatch support?

It will be 100% like the DOS exe, and the DOS exe has Deathmatch support. I think you meant to ask if it will have cooperative support, and the answer to that is no, it will not. If the problems of Strife cooperative have a solution, that will be for me to figure out in Eternity, not here.

Share this post


Link to post
Quasar said:

If the problems of Strife cooperative have a solution, that will be for me to figure out in Eternity, not here.

ZDoom solved some of them already (e.g., conversations are now possible in multiplayer). But the largest problems for Strife coop cannot be solved on the engine side, since they're map issues.

Share this post


Link to post

Thanks Quasar for all the work, chocolate Strife is going to be great!

Sorry, i'm going off-topic about Strife coop, which is beyond the goals of Choco-strife:

Then this may be a place where, if there is enough demand for strife cooperative, a "community official" patch could be released for the IWAD, that generates a different IWAD with maps modified for cooperative, or that uses the IWAD to make a PWAD with new coop-friendly maps.

The patching would be necessary because you probably shouldn't just release all strife maps modified. Someone could just modify them all for coop and use a comparison tool to make a patch containing of the differences between the IWAD and coop-modded IWAD. Less file size, and legal.

But this would all be for hypothetical ZDoom/Eternity coop support.

Share this post


Link to post

Can't wait! As I've stated many times before, when you actually made the branch :P (sometime last year..)

Share this post


Link to post

Great to hear you're starting on this!

Quasar said:

I myself have a question that needs fraggle's attention. I need to copy the files from strife-branch/doom into a new strife-branch/strife directory. Should the copy be done maintaining SVN revision history information, or simply as a plain file copy and addition of the files as new to the SVN repo? I am not sure which is more semantically correct.

It should be done as a SVN copy, retaining the revision history. I can do it for you if you want (not sure how you'd do it in TortoiseSVN)

Share this post


Link to post
fraggle said:

Great to hear you're starting on this!

It should be done as a SVN copy, retaining the revision history. I can do it for you if you want (not sure how you'd do it in TortoiseSVN)

Done. TortoiseSVN added support for Ctrl+C and TortoiseSVN->Paste actions a few versions back that do this exact operation :)

Share this post


Link to post
Quasar said:

It will be 100% like the DOS exe,

Should some of the engine accuracy findings to make Choco-Strife 100% correct be carried over to SvStrife as well? Things such as wrong door sounds, health not activating automatically, lack of jump air control forward, which last time I ran SvStrife were issues.

Just so that there'll be both a vanilla and a (pr)boom version for Strife to be played.

It would be interesting to add .SEH support -- maybe this patch format survives, unlike .HHE and .HEX :)

Share this post


Link to post
fraggle said:

You didn't do it right. I'll fix it now.

EDIT: fixed.

Oh, sorry. Didn't know you could copy a directory in that fashion. In fact IIRC, the Windows version has problems with that kind of operation so I probably couldn't have done it at all. Feel free to fix anything I have done wrong, because you know more about SVN than I do.

I had some property conflicts the other day when doing a merge from raven-branch so I acted as conservatively as possible and kept the property values as merged from raven-branch. They are probably wrong though, and should be manually fixed.

Share this post


Link to post
printz said:

Should some of the engine accuracy findings to make Choco-Strife 100% correct be carried over to SvStrife as well? Things such as wrong door sounds, health not activating automatically, lack of jump air control forward, which last time I ran SvStrife were issues.

Just so that there'll be both a vanilla and a (pr)boom version for Strife to be played.

It would be interesting to add .SEH support -- maybe this patch format survives, unlike .HHE and .HEX :)

I don't really see why people will carry on using SvStrife as Choco Strife should provide a superior, more accurate experience and will still contain Kaiser's expertise. But if he wants to update it, and he certainly hasn't said he has any intention of doing so, that is of course his perogative.

Resources will not be diverted out of this project to make it happen, if you're suggesting that.

Share this post


Link to post
Quasar said:

Oh, sorry. Didn't know you could copy a directory in that fashion. In fact IIRC, the Windows version has problems with that kind of operation so I probably couldn't have done it at all. Feel free to fix anything I have done wrong, because you know more about SVN than I do.

That was the only problem as far as I could tell. As I said before, I don't see how you'd do a directory copy like that with TortoiseSVN (is it smart enough to let you just copy and paste the directory?). Maybe Graf Zahl is right and there's a menu option that I missed. I did figure out that you could probably achieve the same thing by doing a rename and then reverting the deletion of the old name.

Doing it this way is better because it means that the strife directory retains the history from the doom directory and also inherits the mergeinfo property needed to do merges.

Anyway, it should be all good to go now.


I had some property conflicts the other day when doing a merge from raven-branch so I acted as conservatively as possible and kept the property values as merged from raven-branch. They are probably wrong though, and should be manually fixed.

The property conflicts are because of a script I wrote called branch_helper that helps manage Subversion branches and tags. They hold the location of the parent branch and last update revision. I fixed them already but don't worry about doing more merges yourself if you want.

Merging will be slightly complicated in this situation because you'll need to do it in two stages: first do the main merge from raven-branch, then merge raven-branch/src/doom onto strife-branch/src/strife. That way you'll keep the strife directory up to date with any fixes that get applied to the doom directory.

Share this post


Link to post
printz said:

It would be interesting to add .SEH support -- maybe this patch format
survives, unlike .HHE and .HEX :)



Very unlikely. You'd lose ZDoom + child ports and Vavoom and with it a significant portion of the potential player base - espcially if Kaiser does not update SVStrife.

DEH survived because every self respecting Doom source port supports it out of necessity but concerning SEH it's already too late for that. You can't expect that an EXE hacking format that's only supported by one port has any chance of widespread use.

Besides, let's talk again in 5-10 years when there's maybe 10 finished Strife releases available...

Share this post


Link to post
printz said:

Just so that there'll be both a vanilla and a (pr)boom version for Strife to be played.


Boom version of Strife? Doesn't exist. There's no Boom version of Heretic or Hexen either.

If by that you meant to say "limit removing with some features added", then you have ZDoom and Vavoom. One day, presumably, you'll have Eternity. Eternity might be the best candidate for building a stable, backward-compatible democode for Strife, but don't expect a Strife demo scene to ever appear.

As for SEHACKED, frankly, we're far past this stage. Except for Chocolate Strife by its very design, all source ports that do or will support Strife have superior custom content definition methods.

Share this post


Link to post
fraggle said:

The property conflicts are because of a script I wrote called branch_helper that helps manage Subversion branches and tags. They hold the location of the parent branch and last update revision. I fixed them already but don't worry about doing more merges yourself if you want.

Merging will be slightly complicated in this situation because you'll need to do it in two stages: first do the main merge from raven-branch, then merge raven-branch/src/doom onto strife-branch/src/strife. That way you'll keep the strife directory up to date with any fixes that get applied to the doom directory.

I figured it was something like that.

Merging from doom to strife is likely to be difficult once the major changes start, as there will be more and more conflicts to resolve. I suppose this means it would be best to #if 0 or simply leave dead any modules that Strife doesn't use, as opposed to deleting them outright?

Just as an example, Strife has no intermission whatsoever, and there's not even any trace of it in the decompilation, meaning they removed wi_stuff.c entirely. If the state of Raven's source dirs is any indication to go by, I'd imagine their directory probably still contained the dead wi_stuff.c though, so having it around might actually be more rather than less authentic ;)

Share this post


Link to post

You might find that you're hugely overestimating how much work it would be to resolve any potential merge conflicts. I doubt there will be that many difficult conflicts to resolve. Changes merged to files that were deleted get discarded in Subversion, so the wi_stuff.c thing is a non-issue. Secondly, remember that the actual game code hardly ever changes much in Chocolate Doom due to the nature of the project; I don't anticipate any major changes in the future that are likely to conflict with what you're doing. Most changes to the game code consist of demo compatibility type stuff.

So basically, don't worry too much about it. If we encounter problems I'm sure we can resolve them (I've been resolving merges from trunk to raven-branch for a while now, and that's much more difficult). Go forth and hack, and don't bother wasting time with any #if 0 tricks :-)

Share this post


Link to post
Gez said:

Boom version of Strife? Doesn't exist. There's no Boom version of Heretic or Hexen either.

Wait, SvStrife, which I know is based on PrBoom, has all those extended and generalized linetypes removed for Strife? I thought it had them..

As for Sehacked, I mentioned it as a feature that Strife1.exe "supports", so Chocolate Strife (if this is how it will be called) could support it too. Gokuma I'm not sure if he's here to comment on this.

Share this post


Link to post
printz said:

Wait, SvStrife, which I know is based on PrBoom, has all those extended and generalized linetypes removed for Strife? I thought it had them..

As for Sehacked, I mentioned it as a feature that Strife1.exe "supports", so Chocolate Strife (if this is how it will be called) could support it too. Gokuma I'm not sure if he's here to comment on this.

SvStrife implemented Strife directly over BOOM with what I would have to describe as very little regard for resolution of the conflicts between the two's line specials, bit flags, etc. We have since discovered things in Strife such as the 25% translucency line flag that would cause additional conflicts.

On the issue of SeHackEd, consider that Chocolate Doom already has a DeHackEd parser, and SEH patches are in the exact same format as DEH patches. This really doesn't give me a lot of excuse to not keep the DeHackEd system functional. If Chocolate Strife is to do EVERYTHING that you can do with/to the DOS EXE, in the same way Chocolate Doom functions, then arguably it should indeed support it. Whether or not people want to USE it, due to the compatibility issues it represents with advanced source ports, is their own business - it's not any different than with the vanilla EXE, the way I see it.

Share this post


Link to post
printz said:

Wait, SvStrife, which I know is based on PrBoom, has all those extended and generalized linetypes removed for Strife? I thought it had them.

That's not the question.

You think in term of modding features. Then you can as well say that Vavoom or ZDoom are the PrBoom of Strife. They have all these things, and more.

But in term of niche, and of popularity? Boom is a standard for Doom modding. There's no standard for Strife modding. In fact, there's practically no Strife modding at all. The last time I've seen a mod in development for Strife, it was a Skulltag deathmatch thing...

Share this post


Link to post
Quasar said:

On the issue of SeHackEd, consider that Chocolate Doom already has a DeHackEd parser, and SEH patches are in the exact same format as DEH patches. This really doesn't give me a lot of excuse to not keep the DeHackEd system functional. If Chocolate Strife is to do EVERYTHING that you can do with/to the DOS EXE, in the same way Chocolate Doom functions, then arguably it should indeed support it. Whether or not people want to USE it, due to the compatibility issues it represents with advanced source ports, is their own business - it's not any different than with the vanilla EXE, the way I see it.

Wow I didn't realize that THIS was going to be put in.. :O Oh my god I cannot wait for chocolate strife...

Share this post


Link to post
Quasar said:

I don't really see why people will carry on using SvStrife as Choco Strife should provide a superior, more accurate experience and will still contain Kaiser's expertise. But if he wants to update it, and he certainly hasn't said he has any intention of doing so, that is of course his perogative.

Resources will not be diverted out of this project to make it happen, if you're suggesting that.


The possibility of me revisiting SvStrife is nil. But it would still be nice to have a 'pure' strife port without the limitations. But who knows.

Share this post


Link to post
Kaiser said:

The possibility of me revisiting SvStrife is nil. But it would still be nice to have a 'pure' strife port without the limitations. But who knows.

I wonder if entryway could be coaxed into creating a Strife+ exe. The work we did with the reverse engineering ought to make such an effort relatively trivial, in fact.

Share this post


Link to post

I think it may be of interest to have a new forum in place in regards to ChocoStrife development. Especially when there are times where we don't have access to IRC. It would also be helpful to know who is assigned to doing what as well as discuss any complexing issues and whatnot.

Share this post


Link to post
Quasar said:

On the issue of SeHackEd, consider that Chocolate Doom already has a DeHackEd parser, and SEH patches are in the exact same format as DEH patches. This really doesn't give me a lot of excuse to not keep the DeHackEd system functional. If Chocolate Strife is to do EVERYTHING that you can do with/to the DOS EXE, in the same way Chocolate Doom functions, then arguably it should indeed support it. Whether or not people want to USE it, due to the compatibility issues it represents with advanced source ports, is their own business - it's not any different than with the vanilla EXE, the way I see it.

If you want to support SeHackEd patches, I'll refactor the current dehacked code into common and game-specific parts (on raven-branch). Probably makes sense anyway, that way I can add HHE support as well :-)

Share this post


Link to post
Guest
This topic is now closed to further replies.
×