[Apologies for the very long Coder Diary, so long that I am having to split it into several different posts. The issue is huge!]
Coder Diary #16 -- Adventures in Bug Fixing, Part 1
<emoticon>
And now, the announcement you've all been waiting for:
[*]The "skittish unit", dithering back and forth bug -- fixed!
...
Not!!
[:-]
</emoticoff>
Seriously, fixing this one bug was near the top of my personal wish list. But this goes to the heart of the A/I processing, not something I understand at all well just yet. I figured that, with imperfect understanding, there was too much risk of my fixing this, breaking that. Of fundamentally breaking the game A/I.
As an A/I player, I am as interested as anybody in seeing this fixed. It will get fixed, of that I can assure you. Just not yet.
Happily, there are a good number of other bugs that did get fixed...
[*]The legacy code persistent IF crosshair bug -- fixed!
From the very beginning of the Campaign Series, how many times have we seen this?
In the screenshot, indirect fire into that one hex is concluded, but the crosshair hasn't cleared. In the impending release, it will be!
[*]The edmap (and also?) horizontal banding and saw-tooth screen edge legacy bug -- fixed!
If you have run edmap (efmap.exe, wfmap.exe, rsmap.exe), maybe you have seen something like this:
Note the saw-tooth map edge. The horizontal banding. And other glitches, like the 1-1/2 square cursor.
This problem may affect only certain graphics cards and/or buggy graphics card drivers in combination with this or that version of Windows patched or not to one Service Pack or another... It's hard to say.
But if your rig and setup shows this problem, most likely the new release will have solved it.
Which brings us to Windows 8*. One of the Dev Team members runs Windows 8. He was reporting graphics glitches, especially when running several game EXEs simultaneously and attempting to resize them. As it happens, he had activated some Windows compatibility options that were contributing to these problems. When he switched them off, most but not all of his graphics problems cleared.
Strangely, however, he reported that, with several game EXE windows open, when he attempted to access some Facebook pages using Mozilla Firefox, this would corrupt the CS game windows! Observe:
An obvious "fix": Don't do that! [:-] [Don't access the problem Facebook pages when running the game. Or switch to a different web browser. But see below.]
Still, it's a problem we tried to solve ... but in the end just couldn't. So I implemented a new Redraw Display (Alt-D) menu selection (hot key), for hopefully fixing any graphics glitches and map display corruption.
A copout? If so, we're in good company. Witness this graphics corruption in Google Chrome (running on Fedora Linux):
If the geniuses at Google can't get it right, I'm to feel embarrassed for the same failure?
What's the solution to this graphics corruption? A page reload. We've come to accept this sort of thing. We think nothing of it.
Indeed, in earlier versions of IE there was an explicit control button for refreshing and hopefully fixing corrupted displays. Much like the CS' new Redraw Display (Alt-D) menu selection (hot key)!
I think there is no shame if I add a similar work-around in the CS EXEs.
Another legacy code graphics bug:
In the top panel, the RS Bootcamp4.scn in ZoomIn25 (3-key) display mode as displayed in CS 1.04 and before. In the bottom panel, as you will see it in the impending CS release.
This is an extremely difficult problem to fix. It's a case of fix one thing, break another. The cures can be worse than the disease. See the ugly black gashes in the top display? Maddeningly, they often appear when I attempt this or that "cure". For yet unknown reasons, they can be difficult to avoid.
I have attempted to isolate the problems by introducing three new graphics files: Gray3d.bmp, Gray4d.bmp & Gray5d.bmp. By means of careful pixel by pixel editing of these new gray shader image BMPs, and maybe also some coding cleverness, it is possible to mitigate if not quite (yet) solve these vexing graphics issues. Yes, this game's graphics engine is really showing its age!
Fortunately:
[*]By far, most scenarios are daytime scenarios. Night shader graphics glitches don't come into play.
[*]In EF & WF, the relatively few night scenarios typically don't have open water, are land-bound only.
[*]Most of the problems, what relatively few there are, are in RS. The problems only reveal themselves in night scenarios, showing open water, and in ZoomIn50 (2-key) and the little used ZoomIn25 (3-key) modes.
So all in all, maybe not that big of a deal.
I have said
Overhauling the games' graphics engine is on the to-do list. Just not this time.ORIGINAL: berto
Sorry, guys. Improved graphics are not the focus of the impending release. It's beyond our time and capabilities (30,000+ graphics and sound files!). With the help of Slitherine and Lordz Studio, maybe next time.
Other bug fixes:
[*]A legacy bug involving BunkerMorale (bunkers were mistakenly using TrenchMorale) -- fixed!
[*]Many legacy date-related bugs in both code and data -- fixed!
[*]For nations ID#s & Msg* strings, many omissions, inconsistencies, and other faults -- fixed!
But please note: No French or German versions of the game for the impending release. Not enough time or Team expertise. For future releases.
[*]Erroneous "slots" and/or "slot" designations for several nations: Australia, New Zealand, Communist Vietnam, Communist China, South Africa, Philippines, etc. -- fixed!
[*]Several problems involving gliders -- fixed!
[*]The Variable Visibility (optional rule) changing Visibility each phase, more than once per game turn -- fixed!
[*]A bug involving potential crashes when selecting/deselecting Background Music or Background Sound.
Here's a screenshot from that debugging session:
To the right, in black, a Cygwin terminal window. Circled in red, the third and fourth lines in sounds.dat.
To the left, in the Visual Studio display, you can see where the sounds.dat lines 3-4 numbers have been assigned to elements 23 through 29 of the _movement[] array!
Above, you can see where _assault, _load, _mine, _backg[0], _backg[1], _backs, _neutral are therefore assigned, not with the lines 3-4 numbers, but numbers in sounds.dat lines 6 and beyond, what are then supposed to be the _defeat[], _draw[], and _victory[] data. Which is why we all lost background sounds & music for a while there.
And on an on...
[to be continued]
