ECWolf

Weblog ECWolf ECWolf Wiki
Release Notes

General Notes

Known Issues

Are you still working on this?

Yes! I have no plans to discontinue this project. If you have any doubts, look for activity in the repository and check the projects page on my weblog.

Backwards Compatibility

ECWolf is designed to allow complex mods to be created without source code editing. While this should imply that your mod will run on future versions of ECWolf, I can not promise this for the 1.x series. There are simply too many partial implementations for me to keep full compatibility and continue to move the port forwards. I plan to start serious backwards compatibility efforts with ECWolf 2.0.

With that said, I will say that even in the case of breakage it should not be too much work to port mods to newer versions as they are released. I do not expect any radical changes to occur to the API during development, so let me offer some tips on how to help ensure your mod is forwards compatible (note these tips may change at any time): On the Wiki

Will ECWolf play Wolf4SDL mods? (Or other source modifications.)

For the most part: no.

It is important to understand that most Wolf4SDL "mods" are not mods in the same sense as most other games. Most of them run their own fork or source port (which they all call Wolf4SDL) so it would be nearly impossible for ECWolf to run any of them out of the box. To put it in simplier terms: If you can't download the source from the Wolf4SDL website and use that to run the "mod" then ECWolf can not support it.

There are, however, some really common editing constructs (the third map plane for floor/ceiling textures for example) that ECWolf can support. If a mod is simple enough it's possible that a only minimal compatibility file is needed.

What's with the fast hitler fireballs?

While most people probably don't remember it now that computers are able to run the game at 70fps, the fireballs were intended to move much faster. The speed of the fireballs depended on the frame rate such that a faster frame rate slowed them down. It is obvious that id would not have noticed the issue as computers at the time could only reach in "the teens." (source @ 11:00) Furthermore, when recording or playing back a demo, vanilla locked the game to 17.5fps. ECWolf can not implement the fireballs as frame rate dependent as it would mean it would be impossible to write proper net code in the future.

If you find this reasoning unacceptable, then you are free to customize your play experience as you like. Create a decorate.txt file with the following contents and load it with ECWolf to slow them down to 70hz speed:

actor SlowFireball : FireBall replaces FireBall
{
	// Set this to some value between 1.5 to 9 at your preference
	speed 1.5
}

For those who want a more technical explaination of the bug. The fireballs accidentally had their movement function in the slot that got executed every frame change instead of every tic. Due to the adaptive frame rate, the projectiles would move at their speed (9 in ECWolf units) times the number of tics passed during the frame the function was called. At 70fps, that multiplier was always 1 thus dividing the speed by 6.

Isn't BJ supposed to be breathing on the intermission?

Indeed he is, and in the Wolfenstein 3D shareware and Spear of Destiny he does. However, id software accidentally made both frames of animation identical in the latest version of the Wolf3D data files. There is nothing ECWolf can do about this short of providing the missing graphic. The animation is still technically happening so if you grab the image from Wolf3D or Spear of Destiny it will work.

There's a bug in the game data (see above). Will you fix it?

Alternatively: Will you include extra game data for multiplayer?

In general the answer is no. I've found that even some of the small changes that ZDoom does (alpha transparency on some things, crouch sprites, etc.) cause minor cosmetic issues in old mods. While I don't think ZDoom did the wrong thing at the time, I do think there is a learning opportunity here that it is better to leave things be and let users add the extra bits themselves with mods (something that was not always possible at the time ZDoom added some of the features in question). These issues become even more apparent if you look at Zandronum (previously Skulltag) which took this to an extreme. This isn't a hard rule but in general don't expect ECWolf to change the game's content.

One notable exception to this rule is the "Read This" in Wolf3D which was restored mostly because many mods use the feature and it was one of the reasons the older Apogee release was considered superior to the Activision release.

Roadmap

While I'm not able to commit to any set schedule for releases, I would like to go over the direction of the port. For the 1.x series the focus will mostly be on bug fixes including fixing the known issues stated above. There will of course be new features added in over time, but it's still going to be a mostly 2-dimensional engine.

For the 2.x series I'll be trying to add support for playing the Mac version of wolfenstein. In addition I'll be looking to add many of the missing features that prevent me from having a stable API. Particularly adding a proper Z-axis. The idea going forwards would be to add support for one wolfenstein engine game per major version. (I know you're all waiting for Blake Stone.) Here's the list of Wolfenstein engine games that are planned to be supported as well as how much information I have towards supporting them.

Past version 2.0, if you would like your favorite game to be supported sooner, then feel free to do the reverse engineering work and send me your findings. If someone were to do this, please note that I'm interested in how the actors worked in the original games, not exactly how they can be emulated with the current feature set. Rise of the Triad will probably be one of the last games supported (if at all) due to it vast number of changes. ECWolf will be getting a lot of similar features, so we'll see.

There are no plans to support reading the roms of console versions of Wolfenstein 3D (similar to how Doom 64 Ex works), but that's not to say I would be against implementing it upstream if it can be done cleanly. There's also a slight possibility of running off the iPhone port's data, but given that the data is distributed with the source, that may not be a good idea.

The 3D games using earlier versions of the engine Hovertank and the Catacombs games may get supported. However, the focus is to do the games directly based of Wolfenstein 3D first.

Can I help?

Of course. Even if you can not code, spread the word, or email me for a wiki account and help document the modding features.

If you can code, I'm willing to review any patches sent my way. Just fork the repository and send pull requests. If you feel like tackling some major issue (sound code, net code, or new renderers), please contact me so that I can keep track of progress.

The main rule I have is that if you submit a new renderer it must be optional and contain no features that aren't present in the 8-bit software renderer (with exception to higher color depths). You can, of course, send me renderers with such features and lock them behind compile time options, but by default all renderer options should be equal.

Super 3D Noah's Ark Notes

You do realize you can't just re-release without permission right?

I have licensed the game from Wisdom Tree and have negotiated a generous profit split.

The game crashes a lot in ECWolf for Windows

This is because the game uses MIDI music and SDL_mixer MIDI code has many issues. The best solution to this problem is to download the SC-55 music pack. Either the Vorbis or FLAC pack will work and should be stable.

 

© 2004-2017 Braden "Blzut3" Obrzut