W.C.A.T. - WC1 DOS Overhaul Mod [Beta v0.8 R4 Released]

OMG, this is the MOST AWESOME THING EVER!!! Wing Commander 1 is my favorite game of all time, and yet in the 35 years I've been playing it, I've never had the chance to experience the game at the speed it was supposed to be played! (I started on a 386-25, maybe a little slow, and quickly graduated to a 486-33/66, which of course was way too fast unless I turned off the turbo or disabled the cache or whatever I did back then) And the joystick support is incredible! I got a Logitech Extreme 3D Pro off of Amazon and I'm able to use both the throttle and the twist-to-roll features.

Seriously, this is incredible work. I can't believe you managed to patch the game binary like this with no source code and no recompilation. Thank you so much!
 
Okay, this is probably the most minor thing that could still be fixed in the game, but it's bothered me for 35 years. :)

Iceman isn't really sure what planet he's from.

Whenever he marks a kill in the game, he exclaims "That was for Vega nine". However according to his background story (and a conversation he has with the player in the bar) his planet was Vega VII, not Vega IX.

If you could replace "nine" in the game's code with "VII. " that would be pretty cool. :)

Not sure how to fix the issue with Spirit telling you "There was no need to praise me over the Colonel" after the first mission, when in fact the praise that you give her is in the *second* mission. I mean I suppose you could swap the text that Spirit says in the debriefing for the first two missions?
 
I really appreciate the kind words, folks. :) I'm glad people are enjoying it.

I'm hoping to get some time over the weekend to make some more progress.

I strongly recommend to avoid the feature creep and not go to deep with this project.
Regarding the localisation it might be post-1.0, we'll see. The biggest aspect of it is logistical rather than technical - although the technical aspect isn't zero either of course.

If there are other translations floating about, please let me know - I have French, Spanish and German mods, although I don't believe the German one covers SM2... Unfortunately non-Latin-script languages (e.g. CJK) may have to wait for Confederation, but I'm looking at setting something up so we can have translations ready in advance (for any WC game / fan project) if folks are keen to contribute. More on that another time; I still have some specifics to figure out.

I'll definitely have a proper look at Wing Commander II once this all stable. It might take a while though, just like this one did, although hopefully not nearly as long. It's definitely possible, just a matter of time really. And yeah, I obviously have other WC projects I'd like to get back to. It'll be really nice just being able to write code and compile it. :D Something which takes 5 minutes there probably takes days here...

Whenever he marks a kill in the game, he exclaims "That was for Vega nine". However according to his background story (and a conversation he has with the player in the bar) his planet was Vega VII, not Vega IX.

If you could replace "nine" in the game's code with "VII. " that would be pretty cool. :)

Not sure how to fix the issue with Spirit telling you "There was no need to praise me over the Colonel" after the first mission, when in fact the praise that you give her is in the *second* mission. I mean I suppose you could swap the text that Spirit says in the debriefing for the first two missions?
I'm happy to change stuff like that; honestly I'm not sure I ever noticed the Iceman one! I'll double-check the details; it may actually be easier to change Iceman's conversational dialogue to Vega IX instead... If anyone has any other thoughts let me know. I'm sure Spirit's one is possible to remix somehow; I'll take a look.

My thinking for WCAT is that I'm happy to fix mistakes in the content, or things which were clearly intended to be one way, but ended up not being "finished" (like the Hornet cockpit transparency)... I'm honestly tempted to fiddle with quite a bit of stuff, dialogue included, but I'll leave that for optional Confederation mods, so folks can pick and choose their own mix of original content vs fan content. :)

Anyway, if anyone spots any other errors, typos or whatever else, do let me know.
 
I started a new game the other day, while monitoring 3D prints. The approach I took: if I die, I redo the mission but immediately eject. No do-overs. Fun. Some of those Scimitar missions are a little more challenging! Just finished it off.

Idea: support for TSR drivers and device emulators.
  • Earlier I was experimenting with USB joystick support in the wing commanders. Surprisingly some of the USB solutions worked "out of the box" for Wing1 and Wing2 (https://www.bretjohnson.us/). Wing3 & Wing4 had more sophisticated joystick detection routines and did not believe I had anything. I think these USB solutions are just throwing values at the expected addresses in a way that doesn't have the signature of a real analog stick. Do you think it would be feasible to add support for Bret's USB joystick drivers to WCAT? I am hoping it would just involve adding an option to be a little more forgiving if a joystick isn't properly detected.
  • Here is a longshot: I have this weird thrustmaster with WIn95/98 support, but not dos support. It uses the 15 pin port, but it does not encode the stick in standard analog. I think it's some proprietary digital thing. I assume this is not likely to be supported in WCAT?
  • I tried WCAT with sbemu (https://github.com/crazii/SBEMU), but it also didn't detect the non-existent hardware. Think this might be in the cards?

Cheers, and thanks again for such a vital project.
 
I am hoping it would just involve adding an option to be a little more forgiving if a joystick isn't properly detected.
I'll test it myself, but if it's set up to simulate a joystick on 201h (not BIOS), there's not much else I can do. The "protocol" is dead simple; you write to the port, which tells the joystick to reset, and then you literally just count up until some bits are set (one per axis). That's it; that's how you both detect it and read it. If the bits aren't set within any viable counter value then there's no usable data. The documentation implies it's only been tested with EMM386...?

I tried WCAT with sbemu (https://github.com/crazii/SBEMU), but it also didn't detect the non-existent hardware.
I don't think I'm doing anything weird to detect Adlib support (I think the current version says "Sound Blaster required", but it only actually requires OPL). Having said that, like the joystick TSR both of these require I/O virtualisation provided by EMM386 - so it makes sense if USBJSTIK is failing, SBEMU will also fail... I'm not sure where the problem lies, all I can say is that the Sound Blaster Live in my Pentium 4 also requires I/O virtualisation via EMM386, and that works fine. Either way I think I have a machine I can test SBEMU on, so I'll test it out at some point.

I have this weird thrustmaster with WIn95/98 support, but not dos support. It uses the 15 pin port, but it does not encode the stick in standard analog. I think it's some proprietary digital thing.
I'm looking at supporting the Thrustmaster protocol (along with CH and possibly Sidewinder); I can't promise it'll work out but I'm going to have a go. :)
 
So I've been playing with this mod, and I just finished the original Vega campaign. I'm still super impressed with this work.

I have a question about how you figured out the correct timings by adding a speed limiter. Is there a specific maximum frame rate in Wing Commander 1? For modern 3D games, you can either put a hard upper limit for the frame rate (like 60 fps) or run it unlimited, but either way, the game still runs at the "correct" speed overall by calculating the delta time based on the system clock for each frame, and then figuring out how far all the ships would have traveled in that time. I think I'm explaining that correctly, but if I'm not, please let me know.

Does the same principle apply for this fix?

One thing I noticed is that in the second-to-last mission, the Gratha attacking the Tiger's Claw seemed to be way more aggressive than I remember, to the point where the Claw actually blew up the first two times I played that mission, which had never happened to me before (I once lost the Claw in Secret Missions 1, but there were a lot more Gratha.) The "Save the Ralari" mission was completely impossible, as I would hear the impact shots from the Gratha and five seconds later the Ralari was destroyed -- it was never an easy mission by any means, but I do remember beating it a few times on my 386.

Is it possible that the game designers themselves never even tested their own game at its "correct" speed?
 
I did have another look at the Comms menu on my P4 and I think the menu was just changing quickly as I would hit a number, and the response wasn't what I was expecting. As in, I'd hit 2 to talk to the enemy target, but my wingman would respond. But after closely watching the Comms menu, it seems to be working fine and I'd just assumed it was a speed sensitivity issue.

Yes, when the mouse and joystick are both enabled, the mouse drifts to the upper left, but only in the menus. In game, the mouse sorta still works and it doesn't drift to the upper left.
 
Does the same principle apply for this fix?
It's essentially an upper frame rate limit, built around dividing down the vertical refresh rate (WC runs at 70Hz). I did a lot of work in figuring out the correct rate, but in the end it turns out there's only one division which works; the ones either side are very obviously too fast or too slow.

Wing Commander operates like most pre-3D console/arcade games, which are written with the assumption that the framerate is always exactly a fixed value; any slowdown means slow-motion. Making the game deterministic (any RNG aside) like this has lots of advantages, e.g. in terms of math - and thus performance and/or stability - but has obvious issues if you don't manage it properly; which they didn't...

It's a side note, but most modern games/engines don't use delta times because they have their own severe issues; they instead run logic/physics at a fixed rate and interpolate the world for whatever framerate. That way you can be deterministic and run at any framerate without issue; best of both worlds.

Is it possible that the game designers themselves never even tested their own game at its "correct" speed?
It's pretty surprising, but it certainly seems to have been the case. Because the game logic is tied entirely to the framerate, the behaviour of the AI etc. is exactly the same regardless of how quickly or slowly you're actually seeing those frames. Running on a faster machine doesn't give the AI more cycles to work or anything like that. If the game's running at a slideshow you have more time to think, but that's it. :D

On the flipside that's also why previously you'd get shot at super quickly by an enemy fighter after passing them; as you pass them and can only see space, the framerate jumps up and they rapidly turn to shoot at you...

I'm working on a combat difficulty setting which you can change any time in the launcher. I'm not 100% set on the details yet though, but it will change the AI behaviour in various ways.

Yes, when the mouse and joystick are both enabled, the mouse drifts to the upper left, but only in the menus. In game, the mouse sorta still works and it doesn't drift to the upper left.
Cool yep - this should be fixed in the next release I hope. You can turn up the deadzone percentage as a temporary fix, but it's not ideal...
 
Last edited:
It's essentially an upper frame rate limit, built around dividing down the vertical refresh rate (WC runs at 70Hz). I did a lot of work in figuring out the correct rate, but in the end it turns out there's only one division which works; the ones either side are very obviously too fast or too slow.

That's interesting -- what happened to those of us running on 60 Hz refresh rate VGA monitors back in the day, I wonder?

So what was the actual dividing factor you used, and what is the actual frame rate of the game now? I used to think I was good at estimating frame rates for 3D games, but I can't quite figure it out.

It's pretty surprising, but it certainly seems to have been the case. Because the game logic is tied entirely to the framerate, the behaviour of the AI etc. is exactly the same regardless of how quickly or slowly you're actually seeing those frames. Running on a faster machine doesn't give the AI more cycles to work or anything like that. If the game's running at a slideshow you have more time to think, but that's it. :D

On the flipside that's also why previously you'd get shot at super quickly by an enemy fighter after passing them; as you pass them and can only see space, the framerate jumps up and they rapidly turn to shoot at you...

That's wild-- I never knew that happened. But if a higher framerate makes the enemy ships turn faster, it seems like maxing it out would benefit the AI in the sense that they would turn towards, say, the Tiger's Claw much faster than in the old days when the framerate had dropped. Could this explain the fact that the Claw seems to get blown up more easily now?
 
what happened to those of us running on 60 Hz refresh rate VGA monitors back in the day, I wonder?

So what was the actual dividing factor you used, and what is the actual frame rate of the game now?
There's actually no such thing as a 60Hz VGA CRT - they all supported a range of refresh rates depending on the mode. Mode 13h is 70Hz - some games used a tweaked mode to run at 320x200@60Hz, but this was only properly supported on later (S)VGA monitors. Like Wing Commander, Doom uses mode 13h (technically the planar "Mode Y" variation), and halves the refresh - so 35Hz maximum. For Wing Commander I'm halving it again, so 17.5Hz. It seems like a low number but consistency is the key; and it's not that low considering the era of game.

As I've mentioned elsewhere supporting higher framerates for spaceflight is technically possible, but there's so many values which would need to be changed; velocities, turn-rates, animation rates, AI logic counters, timing for comms, etc. etc.

But if a higher framerate makes the enemy ships turn faster, it seems like maxing it out would benefit the AI in the sense that they would turn towards, say, the Tiger's Claw much faster than in the old days when the framerate had dropped. Could this explain the fact that the Claw seems to get blown up more easily now?
Before the speed fix, when the framerate is high, you're essentially playing the game on fast-forward, when it's low, you're playing in slow-motion. That's the only difference. The spaceflight/AI is untouched besides the optional control stuff and asteroid difficulty. There's nothing to change the AI logic based on the frame-rate; the game will run as slow as needed to run the AI for each frame. If you manually edited a recording of unpatched Wing Commander to play back at 17.5Hz, the output given the same keyboard inputs (and same random seed) would be identical in WCAT.

The game's just really hard sometimes. :D I'm hoping the difficulty setting will help make it more reasonable - there's definitely missions where I know I only got through due to luck...
 
Last edited:
I tried WCAT with sbemu (https://github.com/crazii/SBEMU), but it also didn't detect the non-existent hardware. Think this might be in the cards?
I finally got JEMM working (enough) on a machine so I could test SBEMU and yeah, it doesn't work here either...

I suppose it's because the launcher tests if OPL is actually present, and SBEMU isn't responding properly - which seems really weird since it's apparently based on DOSBox's OPL3 code, and that works fine.

I'll continue looking into it; worst case the next release won't throw an error if the detection fails, you'll just get no audio in the launcher. The game itself still works fine.
 
OMG this is amazing, thank you so much for doing this! I've been hoping someone would take on this project, since Wing Commander 1 is one of my favorite DOS games. Its sensitivity to CPU speed has always been frustrating, so seeing a fix is incredibly exciting.

The fact that your solution works on both real hardware and in emulation is fantastic. The launcher is top notch, it blends perfectly with the game's UI, and the quality of life options are outstanding. Being able to toggle the MT32 option without digging into the config file is especially awesome.

I've tested it on my Pentium 133 MHz and so far it has run flawlessly. I will report back if I run into any bugs.

I had told myself I would focus on playing games I have never tried before, but between XWVM and now this, I guess that plan is out the window. 😉
 
Just like to add, excellent work and so impressed I was, that I donated!

My website covers getting a variety of flight/space sims working on Win10 and I've recently added another guide covering the WC1 DOS with the WCAT mod and Kilrathi Saga + WCDX.

I've also added what I think is an appropriate method for using the DOS Secret Missions 1.5 mod with the DOS + WCAT and KS + WCDX versions.

I covered using a custom DOSBox Staging install (v0.82.1) and I've tweaked your example Staging config to use the Staging 'out of the box' crt emulation, versioned MT32 roms and some other minor tweaks. I also kinda cover using the bundled DOSBox Staging with retail disks/cd (well really their disk/cd images).

If you're interested, you can find the articles here:
and here:

Would be interested in your opinion, any mistakes or errors I may have made and hopefully if the Secret Missions 1.5 advice is ok?
 
An excellent write-up, and thanks! :D

I honestly struggled with some of the DOSBox Staging configuration; their documentation in some instances was just outright incorrect, and I had to dive into the source code to figure what the actual options were expected to be. The worst one was the mouse capturing on startup - every single piece of documentation/advice I saw around the place was incorrect. :p I'll have to do a review of the other settings you're suggesting, I can justify some of my decisions but others may need looking at again!

Secret Missions 1.5 is a tricky one; I've personally never played it, and that's partly because I've heard it's very buggy. I'm not sure what the reality of it is. It's something I've had on my list to investigate, and potentially add proper support for, but it's been low priority since I've been expecting issues in the mod itself.

The main issues with modding the data files with WCAT are two-fold; firstly, WCAT modifies many of the data files to fix issues - this doesn't really apply to SM1.5 though since it's changing the content anyway.

Secondly and more importantly here - WCAT expects the data files to be of a known version for patching - so when updating to a new version with modded files present, it will see unrecognised files and patching will fail.

A quick addition to your write-up for SM1.5 could advise people to make sure they return to the original GAMEDAT before updating WCAT. They'd also then need to recreate the SM1.5 GAMEDAT with the newly-updated base game files. I'm sure it could be streamlined with a batch file or two...

Anyway at some point I'd like to take a look at SM1.5, and if it's stable enough (or can be made stable fairly easily) then I may add direct support for it. :)
 
An excellent write-up, and thanks! :D
My pleasure and thanks for the comments, they are extremely useful and I hadn't considered the WCAT upgrade issues, so I'll definitely have to add your comments to the Secret Missions 1.5 article. 👍

I can definitely understand the DOSBox Staging settings experience, sometimes a couple of minor version changes can make a significant change to a DOSBox config. I used to always specify the integer_scaling in the [render] section in guides but then defaults changed and I could rely on the default integer_scaling setting and omit it going forward. I've kinda done so many now a lot of it seems fairly straightforward (to me, but not others) which was one of the reasons for the website, to help make config easier for others. But my suggested changes weren't anything major just minor tweaks really. 👍

So thanks once again and keep up the great work, it's really appreciated!

I hadn't heard Secret Missions 1.5 was buggy, but I'm far far from knowledgeable about it, but due to some earlier Mac emulation work I did, I've got Super Wing Commander (Mac version) running under emulation, so maybe something for a future guide!
 
Last edited:
I found a weird oddity that may explain some people's experience with random joystick de-calibration after leaving the laucher, at least for me. I'm running dosbox-staging on fedora linux. I find 60000 cycles allows the game to run great, but as soon as I leave the launcher and enter the game it jumps down to 3000 cycles and the cursor gets stuck in the top right corner until I raise the cycles again to 60000. I can't think why it jumps down like that...
 
Is that using my config? I've never seen this happen but that would certainly explain if it's happening under DOSBox... I'll have to re-verify I'm covering the bases to stop the cycles being adjusted on-the-fly, which should never need to be done. Any sort of non-fixed cycles will cause joystick drift just due to how analogue gameport joysticks work (e.g. "auto" or "max" cycles will cause severe joystick issues, in any game) - i.e. the (virtual) CPU speed need to be consistent or the count when testing the axes will change.
 
Last edited:
Is that using my config? I've never seen this happen but that would certainly explain if it's happening under DOSBox... I'll have to re-verify I'm covering the bases to stop the cycles being adjusted on-the-fly, which should never need to be done. Any sort of non-fixed cycles will cause joystick drift just due to how analogue gameport joysticks work (e.g. "auto" or "max" cycles will cause severe joystick issues, in any game) - i.e. the (virtual) CPU speed need to be consistent or the count when testing the axes will change.
It sounds like it the DOSBox Staging [cpu] section cpu_cycles_protected is set in the config to something suitable high but cpu_cycles has been left unspecified, which will default to 3000. If you set both to something suitably high then everything should be good.
 
Back
Top