[Français]

NEWS
INTRODUCTION
TERMINOLOGY
THE SOURCE CODE
THE BUGS
TUTORIALS
DOWNLOADS
THE AUTHOR
  THE BUGS: "RELEASE FOR FOX" COMPILATION

Every common Visual C++ user that tried to make the game work in this mode of compilation experienced the same problem. This page will explain what compilation modes are, what's the problem with it here, to finally give you my solution to the matter.

1) Compilation modes

In Microsoft Visual C++, you can compile your source code in 2 different & common modes:
  • Win32 Debug mode
  • Win32 Release mode
In the first case, the developper can put parts of code only used for debug purposes. These parts will automatically be included in the application (during pre-processing stage). For instance, AvP uses this mode to add new console commands that won't be present in the public version...

In the second case, no debug stuff will appear because it will concern the public version of the application. So in our example, the added console commands are present in the code, but won't be in the game.

The other use of these compilation modes is to customize the projects. For instance, you can decide to generate debug informations in the "Win32 Debug" mode and not in the "Win32 Release" mode. All is a matter of project organization.

Note that you can create other compilation modes if you wish...

Now in the case of AvP, Rebellion dudes gave us 3 compilation modes that are:
  • Win32 Debug
  • Win32 Release
  • Win32 Release For Fox
We won't discuss the role of each compilation mode here (this will be covered in the "Source Code" sections). Let's just say that the "Win32 Release" mode can be considered as another "Win32 Debug" mode. Which leads us to say that if you want your game to be the final release, you must compile it with the "Win32 Release For Fox" mode.

2) The "Win32 release For Fox" bug

The bug appears if you try to run the application in the "Win32 Release For Fox" mode, under Windows 98 only. The significant clue on the bug is that if you compile the application in the other modes, no bug appears: which means that there are portions of code that aren't present or different in both Debug modes.

After a personnal session of study of the code and a debug in assembly language, I discovered that the "bad guy" (this is the term I will employ in the next) was the call to the function "ToAscii" in the win_proj.cpp file (in the procedure "MakeToAsciiTable"). What I experienced in my source code modifications to find the bug was that when I added instructions around the "bad guy", sometimes, it worked ! Strange bug huh ?!

3) My solution

What I finally understood of all this was that the application crashes because of compiler optimizations on the "MakeToAsciiTable" code (keep in mind that it works in the Debug modes: these ones aren't as optimized as the Release mode).

So here's the code to add (in blue) to correct the thing:
#pragma optimize("", off)

void MakeToAsciiTable(void)
{
WORD output;
for (int k=0; k<=255; k++)
{
ksarray[k]=0;
}

for (int i=0; i<=255; i++)
{
for (int s=0; s<=255; s++)
{
if(ToAscii(i,s,&ksarray[0],&output,0)!=0)
{
ToAsciiTable[i][s] = (unsigned char)output;
}
else
{
ToAsciiTable[i][s] = 0;
}
}
}
}

#pragma optimize("", on)

This will simply tell the compiler to disable optimizations on the procedure.

Please note that I'm very proud of my discover, because I work on it since 2001 and despite the fact that it took a long time to find, I helped the first AvP mod - i.e. Cancer Black made by Eldritch & the AMP team - (and maybe future mods) to be compatible with Windows 98.

Note: the funny thing to remark here is that both the compiler & the "ToAscii" function are Microsoft home made ! So there's an incompability between things that should be compatible ! Anyway, I've got nothing against Microsoft: "error is human".