ECWolf 1.1.1 - Advanced Wolfenstein 3D Source Port

Oh no, more trivial stuff!

The 'YEAH!' ending on E1 and E5 doesn't quite work properly; the camera swings around while stuttering, and never pans back quite far enough. BJ jogs on the spot for a bit before jumping up.

EDIT:
Also some weirdness regarding Mutants; they seem to occasionally switch to Officer sprites for a few frames when viewed from the back angles.

Share this post


Link to post
BaronOfStuff said:

The 'YEAH!' ending on E1 and E5 doesn't quite work properly; the camera swings around while stuttering, and never pans back quite far enough. BJ jogs on the spot for a bit before jumping up.

Fixed. Didn't think of this consequence when making the AI behave a little more Doom like by default (that is implementing non-fast monsters).

BaronOfStuff said:

Also some weirdness regarding Mutants; they seem to occasionally switch to Officer sprites for a few frames when viewed from the back angles.

Fixed. I noticed this in Wolf3D, but apparently I forgot to transfer the fix to Spear of Destiny. (Although it was correct in SDMMAP despite the mutant not actually being in the game.)

Edit: Just so you know, I'll be building 1.1.1 tomorrow.

Share this post


Link to post

I think I've found the cause of the 'linedancing' bug I mentioned in a PM -- enemies on 'patrol' will apparently stop moving when they collide with a stationary enemy, making no attempt to move around it whatsoever. Losing their sight/hearing seems to be a side-effect -- they'll only react to being attacked, and then continue as normal.

I can't confirm that this is 100% the reason for such odd behaviour, but this video shows what I mean.

Share this post


Link to post
BaronOfStuff said:

I think I've found the cause of the 'linedancing' bug I mentioned in a PM -- enemies on 'patrol' will apparently stop moving when they collide with a stationary enemy, making no attempt to move around it whatsoever. Losing their sight/hearing seems to be a side-effect -- they'll only react to being attacked, and then continue as normal.

This happens in vanilla too besides the loss of hearing/sight part. (The linked commit is after the build I sent you so it should be fixed.) I did my best to ensure the pathing breaks at the correct tiles, so the only difference should be the direction the sprite is facing (ECWolf uses the monster's angle to determine sprite direction, vanilla used the movement direction).

Easy way to notice this is to start vanilla Wolf3D on Death Incarnate and warp to episode 1 floor 2. Turn on noclip and go to the large room before the exit. The dogs will catch up to the guards and stop moving.

Edit: ECWolf 1.1.1 builds are up.

Share this post


Link to post

Good stuff, just a few things that got my attention which are thankfully pretty minor and don't break regular play:

  • Ending the game with F7 causes it to freeze (but not via the menu).
  • DeathCam sequences start/end too early (no time to admire your handiwork -- usually got a couple of seconds after the last death frame, in ECWolf it's as soon as the last frame plays).
  • Hitler's death animation doesn't display the last frame.

Share this post


Link to post

...and something else about DeathCam -- unlike vanilla (where the episode would end), the next map loads but is literally unplayable. You can't move, no HUD weapon displays, DeathCam text is still on-screen... in other words, DeathCam remains active. You can still access the menu though, so it's not a crash.

Not really an issue regarding the original maps as there are no 'DeathCam Bosses' present before the episode endmaps to cause such a situation, but it may become a problem for future mods.

Share this post


Link to post

Great work! This was a long-time coming.

EDIT: Graphics are scattered all over the place, I don't know where to start.

EDIT:

Blzut3 said:

How did you obtain your data files? ECWolf requires the Activision (aka GT #2 IIRC) release to work properly. If you do not have this release you can download the patch utility on my website and that should solve the issue.

Proper md5sums for the latest version of Wolf3D are available on the wiki.

Ah.

Share this post


Link to post
Technician said:

EDIT: Graphics are scattered all over the place, I don't know where to start.


Start by using Blzut's patcher utility, downloadable from the same place as ECWolf.

The Wolfenstein engine doesn't use named lumps like the Doom engine. Instead, it identifies its data by using offsets or indexes; which are hardcoded in the engine. E.g., instead of having code that says "display TITLEPIC in full screen", it has code that says "display the 53rd picture in full screen". (I didn't bother checking the actual value; it's probably not 53, but you get the idea.)

And of course, different versions of Wolfenstein have their data in completely different order, creating a joyously incompatible mess. You can use doom2.exe with doom.wad or doom1.wad; you cannot use the Spear of Destiny exe with Wolfenstein data file, demo or full.

Share this post


Link to post

The game works fine after the patch. In fact, I wasn't prepared for how well this port works. So far my only complaint is the player runs way to fast for the confinements of the maps.

Also, if the pistol would continually fire when the mouse was held down would be nice, too.

Share this post


Link to post

The Wolfenstein player has always run really fast.

Also, the auto-fire for the pistol will not be added because it wasn't in the original game. If you want it you can make a PWAD or pk3 replacing the pistol DECORATE code.

Share this post


Link to post
Technician said:

So far my only complaint is the player runs way to fast for the confinements of the maps.

Woolie Wool said:

The Wolfenstein player has always run really fast.


Try straferunning! ;)

Share this post


Link to post

I forgot how frustrating these early maze-style FPS are without automaps. This game's level geometry and textures are not unique enough for me to remember where the fuck the locked door is once I've found the key.

EDIT: IIRC, didn't BJ have a breathing animation during the intermission screen?

Share this post


Link to post

An automap would be a great feature. One that displayed the wall tiles (and floor tiles if extant) would be really cool.

Share this post


Link to post
Technician said:

IIRC, didn't BJ have a breathing animation during the intermission screen?

Why yes he did. :P

Share this post


Link to post
Technician said:

EDIT: IIRC, didn't BJ have a breathing animation during the intermission screen?

Not in the latest version he doesn't. ;) Technically the animation is still there, but the second graphic was replaced with a copy of the first (or vice versa, I forget). To fix this all you need to do is load a wad with a fixed L_GUY1/L_GUY2.

Edit: I should mention that due to bugs like these I seriously considered using the Apogee release instead of the Activision release, but using the Activision release means that ECWolf can load the data from Steam without any effort on the user's part. I think that outweighs the few minor graphical issues.

Share this post


Link to post
jute said:

An automap would be a great feature. One that displayed the wall tiles (and floor tiles if extant) would be really cool.

If he adds an automap, I hope it's optional. I'm used to playing Wolfenstein without a map. If any advanced ECWolf mods were designed for a map, good for them.

Blzut3 said:

Not in the latest version he doesn't. ;) Technically the animation is still there, but the second graphic was replaced with a copy of the first (or vice versa, I forget). To fix this all you need to do is load a wad with a fixed L_GUY1/L_GUY2.

This is most odd. I compile my AutoWolf as an Activision executable, and in my case the main character does breathe on intermission.

Share this post


Link to post
printz said:

If he adds an automap, I hope it's optional. I'm used to playing Wolfenstein without a map. If any advanced ECWolf mods were designed for a map, good for them.

I do have plans to make have an automap since the Mac version has one.

Don't worry, it won't be any more forced than it is in Doom. :P

printz said:

This is most odd. I compile my AutoWolf as an Activision executable, and in my case the main character does breathe on intermission.

Then, using the same data, he should breathe in ECWolf. Try running the patch utility (from the command prompt so you can see the output), see if what it, if anything, identifies your version as. (The first line will be what was detected, the last will be what you end up with and should always be the activision release.)

If I load vgagraph.wl1 over the wl6 files the breathing works just fine so it's definitely an issue with vgagraph.wl6. (I don't think this would have any adverse effect either, but I could be mistaken.)

Share this post


Link to post

Indeed, my Wolfenstein won't work with the Apogee preprocessor macros (just CARMACIZED, not GOODTIMES). Note that my "signon" screen shows the GT Interactive Software logo (same company who distributed Ultimate Doom in England), not AcTiVisioN. Or is the signon screen executable-specific (and thus part of the Wolf4SDL distribution) and not WL6-specific?

Share this post


Link to post

It's not my project, but, if it were, I'd probably be looking at replacing that lame form of resource management via direct indices with some kind of indirected lookup table. Then you could have one lookup per known resource file version and all this mess could be avoided. Then in the future, rather than changing 500 places in the code to reference a different resource, just change the indirection table.

Share this post


Link to post
printz said:

Indeed, my Wolfenstein won't work with the Apogee preprocessor macros (just CARMACIZED, not GOODTIMES). Note that my "signon" screen shows the GT Interactive Software logo (same company who distributed Ultimate Doom in England), not AcTiVisioN. Or is the signon screen executable-specific (and thus part of the Wolf4SDL distribution) and not WL6-specific?

There are three releases of 1.4 as far as the WL6 files are concerned. Since the signon is in the exe they of course will all differ there.

  • Apogee 1.4 and Apogee 1.4g
  • GT#1 and ID
  • GT#2 and Activision
IIRC Wolf4SDL uses the same binary for the last two so it would seem the chunks are in the same order and thus would be compatible. Of course I can't comment on the actual differences there since the patches were generated by Adam Biser and are one way.

Quasar said:

It's not my project, but, if it were, I'd probably be looking at replacing that lame form of resource management via direct indices with some kind of indirected lookup table. Then you could have one lookup per known resource file version and all this mess could be avoided. Then in the future, rather than changing 500 places in the code to reference a different resource, just change the indirection table.

ECWolf uses the resource code from ZDoom, so you could run the Apogee release by simply editing the WL6MAP.txt in the ecwolf.pk3. (Nothing is looked up by index.) Doing detection at run time, while possible, really isn't in my interest though as it, in my opinion at least, just creates more variables with next to no benefit. If I were to also extend support to 1.1 and 1.2, it could also create issues with multiplayer in the future.

Share this post


Link to post

It doesn't have to be very complicated: you could compute the data file's checksum and use the appropriate map file for known values; defaulting to the GT2/Activision one if the value isn't known (assume it was modded).

Share this post


Link to post
Gez said:

It doesn't have to be very complicated: you could compute the data file's checksum and use the appropriate map file for known values; defaulting to the GT2/Activision one if the value isn't known (assume it was modded).

Like I said, it can be done. Maybe I'll reconsider in the future. At the moment though I don't really see a benefit. Given that the patch utility is there and works on all platforms, the only time there is a real problem is if someone is trying to use a modified data set. Which you already stated I would have to assume modded sets are the Activision release anyways.

Edit: And then that open a whole new can of worms when someone goes to mod using traditional tools and suddenly a small change causes the whole thing to break. All I see is support nightmare. :P

Share this post


Link to post

Since everyone is doing the "if it were me" thing, here's my take:

Do a MD5 of each resource against a hashed lookup number to name. Then, internally, convert the file into a WAD. Better yet, just make the patcher create a WAD using the same technique. (Of course, I have no idea what I'm taking about :) Probably would be a can of worms.

Anyway, great job! It's been a long time since I played Wolf. This ought to be fun!

Share this post


Link to post

Do the resources for Wolfenstein differ from version to version? Is there some way to just compile the resources into a wad, something like the WAD generator included with Doom64EX?

I probably sound like I'm talking out of my ass due to my ignorance but...

Share this post


Link to post
kb1 said:

Do a MD5 of each resource against a hashed lookup number to name. Then, internally, convert the file into a WAD. Better yet, just make the patcher create a WAD using the same technique. (Of course, I have no idea what I'm taking about :) Probably would be a can of worms.

That is an interesting take. Matching with lump hashes would solve some issues, but it would break vanilla mods unless a hybrid of the current method is used. Not to mention I would need a copy of every version to get the hashes which I do not have. All I have is the Activision release (which came with RtCW).

Technician said:

Do the resources for Wolfenstein differ from version to version? Is there some way to just compile the resources into a wad, something like the WAD generator included with Doom64EX?

ECWolf processes the vanilla data and maps all the chunks to names based on a txt file in the pk3. Externalizing this wouldn't make sense as it adds an extra step to "purchase on Steam and then run the exe." ;)

Again, the real question is what benefit does it provide to support the old versions?

Share this post


Link to post

Speaking of "download and run", by default the .SOD files in the Steam version of Spear of Destiny are actually for Episode 3. Spear's data files use the .SD1 extension. Its launcher changes the extension of whichever episode you choose to play to .SOD. Not sure if you want to handle checking that on your end or not, but I figured I'd bring it up in case you weren't aware.

Share this post


Link to post

Are you sure about that? I know the launcher does renaming since it's the same deal for the Super CD, but I would think the default state would be to have the original missions as .sod? I could probably do some magic on my end if that really is the case.

Share this post


Link to post

(Meanwhile, back in Testing Land)

More minor nonsense, possibly regarding incorrect sprite references in the DECORATE stuff:

This cage looks suitably Hellish, but it's the wrong object.


It's supposed to be a blood fountain.


Apparently containing Hitler's head?

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