Wcdx - Kilrathi Saga for modern Windows

This is amazing, and I'm super ultra thankful that you made this patch. I honestly have a nicer time playing KS WC1 on my modern PC than DOSB0x+original WC because the game speed never works quite right for some reason. This patch just made me all excited about replaying WC1 again!
Glad to hear it!

It's worse then the GOG/Origin version, and worse then I remember it when buying KS, and found out the T-shirt listed as inside the box was missing from the package.
I didn't get a T-shirt, either, but I don't remember that being listed. I'll have to check my box. I do still have the wall calendar, though; it becomes useful again every twelve years, and in between, the center portion can be used as a poster.

I didn't play it much because of the music bug, and a pentium-class machine with an (emulated) roland gave more atmosphere anyway...
Well, I hope my work is changing that. I've always found Oldziey's renderings to be the best versions of the WC1/2 scores, and I think the updated sound effects work quite well with the old game. One thing that bothers me is that the game doesn't wait for the music to finish before moving on to the next scene (for instance, I'd like the briefing to last until the end of the briefing music before moving on to the scramble scene). I may eventually get around to fixing that, but it's a low-priority item.

I managed to replicate it twice during my "trial run". I'll try again this week and list you the event logs during the crash, as well as the system specs...
Great, thanks.

Dos versions of Wing1 and Wing2 displayed the "mouse-over" correctly, whatever you used as pointing device as far as I can remember...
OK, I'll add that to the list of things to fix. From my earlier cursory (hah!) explorations, I think this one should be pretty easy.

I haven't been here for a long time, but this woke me up - so I tried the PC Gamer WC1 version (copied wc1 folder from unzipped download directory) with 1.2beta1 on a Windows 8.1 rig; and I get:

C:\wc1>wcpatch Wing1.exe Wing1_wcdx.exe
failed opening file: iostream stream error
Hmm... that's an interesting error. I've been meaning to revamp wcpatch to give some better error messages. Whatever's going on, wcpatch is having trouble opening the file. It could be a permissions issue or a sharing issue, or something more esoteric. For instance, this could happen if some other application was holding the file open (perhaps your zip file program). You can simply try again. If it doesn't work, try renaming Wing1.exe or moving it to a different location first; your user Downloads directory is a good safe bet. If none of that works, try extracting the secret missions pack into a different location (or even a different disk). Something along those lines will work.

Thanks for the great work anyway, always good to see someone polishing up the classics.
Thanks for trying it out; give it another shot and let me know if it works.
 
Just a quick teaser, a screenshot from minutes ago:
planet.png

This and some other small fixes will be in the next (beta) release; I should have it ready in a few days.
 
Hey Stinger,

Excellent work! You have solved something that no one else has.
This really makes the KS version of WC1 finally the superior version.

What was the issue with the Planets?
 
You are effectively removing any inhibitions I had about replaying the Kilrathi Saga series. My last run at the Kilrathi War was using the DOS games but I wanted to go the Windows route this time. The space background data and music bugs were the only thing turning me off to it. I'm finally eager again to get back out there.

Thank you so much for your dedicated bug hunting.
 
What was the issue with the Planets?
This one was interesting.

The PLANETS.VGA file (like the other VGA files) is a resource archive containing several image sets. The first image set (which I've dubbed the Space Junk image set) contains all of the normal floating debris images as well as the images for the individual stars that you see in the space backdrop (38 images in all). All of the other image sets contain only a single image; each of those is a planet or nebula or other large object (hereafter referred to only as planets). Of particular importance is that each planet image is alone in its image set.

The CAMP.00X files are resource archives. The first resource contains nothing but planet information, with four entries for each system. Information for a planet is stored in four two-byte values, in this order: Planet index, yaw, pitch, and roll. The index indicates which planet image should be used, with the special value -1 indicating that the slot is empty. The yaw, pitch, and roll values (given in degrees) determine where the planet should appear in the stellar backdrop. (The roll value is ultimately useless, but it's there anyway.)

The game keeps track of several space objects (up to 64, apparently). Each individual star is one such object, and so are the planets. Each object has a number of properties, including (among other things) orientation, position, a pointer to the image set, image index, and type. Stars are type 2; planets are type 3. For objects of type 2 (stars), the game doesn't keep track of the image set on a per-object basis. This is because the image sets are loaded on a per-object basis; if the game kept track of the image sets for individual stars, it would end up loading several copies of the image set in memory, one for each star. The game therefore has special handling for these objects, making the assumption that the image index refers to an image in the Space Junk image set. (This apparently also happens for type 4 objects, but I haven't bothered to figure out what those are yet.)

For whatever reason, possibly just because it was the expedient thing to do, the navigation crosshair (nav point indicator) is classed as a type 3 object, just like planets.

At draw time, the code cycles through all of the visible objects and draws them. For objects of type 2, 3, and 4, the game ignores orientation data and simply draws the image with no scaling or rotation. (You can see this by looking at the stars and planets as you roll your ship: the positions will change, but the orientations will remain the same.) The game checks to see if the object is the navigation crosshair; if it is, the game draws the image indicated by the object's image set and image index. If it isn't, the game uses the Space Junk image set instead, and therein lies the bug: All type 3 objects that are not the navigation crosshair are drawn using the Space Junk image set. Recall that each planet image is the only image in its respective image set; each planet, therefore, has an image index of 0, indicating that the game should use the first image in the image set. The game therefore loads the first image from the Space Junk image set and draws it where the planet should be.

The fix was very simple, once I understood what was going on. Instead of checking if the current object is the navigation crosshair, I just check to see if the object type is 3. If it is, I use the object's specified image set; if not, I use the Space Junk image set.

I would be very interested to know how this bug was introduced; it doesn't seem like the sort of thing that the KS developers should have been touching.
 
Last edited:
You are effectively removing any inhibitions I had about replaying the Kilrathi Saga series. My last run at the Kilrathi War was using the DOS games but I wanted to go the Windows route this time. The space background data and music bugs were the only thing turning me off to it. I'm finally eager again to get back out there.
Glad to hear it!

Thank you so much for your dedicated bug hunting.
You're welcome!
 
Planets, yay!
Every series in the campaign shows a different set of planets in the background, so this is finally receiving the love it deserves ;)
Thanks! Until I started this project, I honestly had no idea how many issues the Kilrathi Saga versions had, despite having played through them numerous times over the years. I feel like the game would have greatly benefited from another month's development time, or perhaps just more thorough testing. That said, I love the enhancements that went into the Kilrathi Saga, so I feel this game is long overdue for its time in the spotlight.
 
[Stingers amazingly detailed response]

Many thanks for the explanation. Your knowledge of the inner working of the game is amazing! Are you using Ollydbg or something similar?
Again, what you have done here is fantastic.
 
Until I started this project, I honestly had no idea how many issues the Kilrathi Saga versions had, despite having played through them numerous times over the years.

When all is said and done, I would be very curious to see that list of issues. :)
 
Amazing work Stinger! I look forward to having some free time and playing this. :D

I seem to recall there was an issue when transferring a pilot from WC1 to SM1 or SM2 where Spirit would die in the middle of the game for no reason at all. Was this fixed with your Transfer patch?

My one wish would be a way to save your character after the Final mission of WC1 and SM1 so that we can transfer our character with all our medals and kills that we received from the final mission. Is this something that can be done?

Thanks for all your hard work. :D
 
Last edited:
I seem to recall there was an issue when transferring a pilot from WC1 to SM1 or SM2 where Spirit would die in the middle of the game for no reason at all. Was this fixed with your Transfer patch?

Also would happen with the WC2 transfer program as well. :D
 
Congrats to Stinger for this awesome patch, I just played some missions with the 1.2-beta installed and it works great so far!

I also have a (possibly rather dumb) question: would it be possible to coax the D3D-renderer into using an aspect ratio of 8:5 instead of 4:3 (like some sort of letterbox-effect) without too much hassle?

I'm asking because the original 320x200 graphics look a bit vertically stretched at 4:3, and unfortunately Windows won't let me use a screen resolution that would fit aspect-wise because my monitor apparently only supports a selected few resolutions that are all 4:3
 
When all is said and done, I would be very curious to see that list of issues. :)
At some point I may go back and figure out an in-depth list of all of my changes, but really they're mostly mundane. A lot of it revolves around the original devs being new to Windows programming and making assumptions about the level of access that users have. For instance, the game stores some data in the registry (volume settings) in HKEY_LOCAL_MACHINE, which isn't writable for normal users, and even when only reading from the registry, the game requests total access, which fails. I have a partial fix in place that relocates the reads to HKEY_CURRENT_USER and limits the access rights requested, but it doesn't do much good if those keys don't exist yet.

Another example: The original KS executables have a debug console that you can access by putting a special string in WINGCMDR.CFG and then pressing the tilde key while in the game. That debug console does some not-nice things, including installing a keyboard hook that intercepts all key presses (from all processes) just in case you happen to hit a key combination that it recognizes. Nobody would ever run across this in normal usage (you have to enable the console in WINGCMDR.CFG to get this behavior), and with my patch I doubt the console would work anyway, so I just removed it entirely by getting rid of the console creation function invocations.

A third example: The game registers a cleanup function to run at exit via the C atexit() routine. Then, sometimes (only sometimes), the game calls that cleanup function explicitly before exiting, resulting in two calls to the cleanup function. My fix is to get rid of any explicit calls to the function.

I suspect the debug console wasn't meant to be shipped with the game. It's probably supposed to be for debug builds only. So why is it there? Because the KS executables are the debug builds! The code very clearly has not been run through an optimizing step, and nearly all of the functions have thunks. The executables themselves are around 750KB in size; I suspect they would be less than a quarter as large if they'd been built in release mode. On the one hand, it's wasteful, but on the other it gives me plenty of room to insert my own stuff.
 
I seem to recall there was an issue when transferring a pilot from WC1 to SM1 or SM2 where Spirit would did in the middle of the game for no reason at all. Was this fixed with your Transfer patch?
I've never heard of this bug, but if you can give me reproducible steps, I can look into it. I'm starting to think I should set up some kind of bug tracker.

My one wish would be a way to save your character after the Final mission of WC1 and SM1 so that we can transfer our character with all our medals and kills that we received from the final mission. Is this something that can be done?
It's already on my to-do list; I've been wanting to do that one for a while, but I need to spend more time exploring the code so I can better understand how to pull that off. There are some gameflow issues as well; I guess the game can just go back to the barracks after the ending sequence, but I need a way to communicate to the user that saving the game at that point is different from saving it any other time.

Thanks for all your hard work. :D
You're welcome!
 
Congrats to Stinger for this awesome patch, I just played some missions with the 1.2-beta installed and it works great so far!
Thanks!

I also have a (possibly rather dumb) question: would it be possible to coax the D3D-renderer into using an aspect ratio of 8:5 instead of 4:3 (like some sort of letterbox-effect) without too much hassle?

I'm asking because the original 320x200 graphics look a bit vertically stretched at 4:3, and unfortunately Windows won't let me use a screen resolution that would fit aspect-wise because my monitor apparently only supports a selected few resolutions that are all 4:3

I'm intentionally not supporting that mode. The game was very much intended to be played at 4:3, since that's the aspect ratio that all monitors had when the game was released. The game has non-square pixels, as did all games running at 320x200 back then. (Denis can certainly confirm that, if you ask.) We've gotten used to seeing screenshots using square pixels, which effectively distort the image from how it was actually intended to be viewed by stretching it horizontally. I find that ugly, and it's a pet peeve of mine. (I also get annoyed when I see 4:3 content stretched to 16:9 on modern televisions.) One of my specific goals with this project was to make sure that people would experience the game in the aspect ratio that the game was designed for.

All of that said, I do intend to eventually add support for things like filtered scaling modes for those who prefer less pixelated (but blurry) graphics. Such support will most likely come in the form of a config file. If enough people really want to play the game stretched, I could add an option to do that. Such an option won't come quickly, will be undocumented (except in this thread), and will likely have a discouraging name like UseWrongAspectRatio=true.
 
I seem to recall there was an issue when transferring a pilot from WC1 to SM1 or SM2 where Spirit would did in the middle of the game for no reason at all. Was this fixed with your Transfer patch?
I've never heard of this bug, but if you can give me reproducible steps, I can look into it. I'm starting to think I should set up some kind of bug tracker.
Ok Wingnut, I need some help here. Was this in WC1 when transferring a character into SM or was this in WC2 when transferring a character into SO? And do you remember the mission where it rears it's ugly head? I have encountered it like many of you but I don't remember which, I though it was in on of the SM's .

Edit
After a quick search in I found the Overflow Bug mentioned here. And another bug as well. I hope this helps
 
Last edited by a moderator:
After a quick search in I found the Overflow Bug mentioned here. And another bug as well. I hope this helps
It does, thanks! It'll probably be a while before I get around to this one, but at least it's now documented here so I won't forget it.

Has anyone encountered this issue in KS before?
 
Last edited by a moderator:
Back
Top