| These questions and answers are taken from the readme.txt
file in the archive. They provide a quick answer to most things in an easily
digestible form.
They overlap somewhat with the explanation of the
changes that were required.
Top of page
Q: When compiling the .qvm files using the batch files
I get warning messages. What gives?
These error messages are caused by "issues" within either the Borland header
files or the Q3 source.
limits.h:31 Character constant taken as not signed
The header file is intended to detect whether the data type char is
signed
or unsigned.
ui/ui_ingame.c:103 warning: Conversion of 'pointer to void'...
ui/ui_ingame.c:107
ui/ui_atoms.c:739
ui/ui_atoms.c:742
Compiler is warning of a non-portable pointer conversion. Not a problem
with BC++ or the Quake VM.
Anything else is something you've introduced!
Back to Some Questions answered
Top of Page
Q: Can I build the DLLs into another directory?
Yes! Open the project options dialog Options|Project... and select
Directories.
Change the final output directory to the absolute/relative path you want.
e.g. changing to ..\ compiles directly to the Quake3 directory.
Remember: paths are relative to \Quake3\source.
Back to Some Questions answered
Top of Page
Q: Why create the \borland directory?
It keeps the modifications that I've had to make to the supplied files
away from the source distribution as much as possible.
It also invites others to work in the same way; and for Borland, Microsoft,
and other compiler tools to co-exist side by side and work with the same code source.
Back to Some Questions answered
Top of Page
Q: What is borland_hack.c for?
When running cgamex86.dll there was the occasional hang that wase cleared
by pressing ESC twice. It was always reproducable in the same places by
running a timedemo of demo001.dm3.
What was happening was that the math library was generating an error
dialog. borland_hack.c traps the error before the dialog is shown
and "fixes" it by, effectively, ignoring the problem.
The problem was created after a call into trap_CM_BoxTrace()
returned a null vector when a unit vector was expected. It only appears
to occur in the CG_PlayerShadow() function.
A bug report has been sent to id.
It appears that the Microsoft based builds of this .dll pass over this
error silently.
Back to Some Questions answered
Top of Page
Q: What are the DEF files for?
The Borland compiler places an underscore (_) in front of every name generated
that uses the C calling convention. The new .def files rename these exported
functions to remove the underscore so Q3 can bind to the DLLs.
Back to Some Questions answered
Top of Page
Q: Can I get some more performance out of these DLLs?
If you have TASM try removing the C_ONLY define in the Compiler|Defines
of the project options. I don't have TASM so this is untested.
Compile using the Intel optimizing compiler, and use Pentium scheduling.
Turbo Debugger doesn't work too well on these builds because of the way
the Intel compiler moves code around.
Back to Some Questions answered
Top of Page
Q: Why are the QVM files a different size to those distributed
by id?
I suspect that this is caused by differences in the implementation of the
header files by Microsoft and Borland. Presumably static data is included
in the QVM files, and if the Microsoft headers use more static data then
this will be reflected in the size of the QVM.
Back to Some Questions answered
Top of Page
Q: How do I change the directory the QVM files are built
to?
Modify the cgame.q3asm, game.q3asm and ui.q3asm
files. In each case the first line (beginning with -o) contains the destination
directory of the QVM files.
Back to Some Questions answered
Top of Page
Q: What's with all those -Dxxxxx things in compile.bat
They pass defined constants to lcc.exe, the equivalent to #define xxxxx
in C source code or header files.
Borland header files use predefined constants that match the requirements
of the compiling model. These are all defined in <_defs.h>,
so that file is bypassed by defining ___DEFS_H and appropriate
definitions are supplied instead.
Back to Some Questions answered
Top of Page
Q: How do I debug using these DLLs?
This is not straight forward.
Quake3 is a demanding executable, any number of problems can arise depending
on the implementation and stability of your sound drivers, GL drivers etc.
I have found that the following works most of the time:
1) Compile your DLL's and move them to the \Quake3 directory.
2) Open a windowed DOS box in your Quake3 directory.
3) Run Turbo Debugger, TD32.EXE QUAKE3.EXE
4) Quake 3 should start OK, if not jump to step 7.
5) If your .dll's are crashing then generate the event that causes the
crash. The machine should appear to lock solid. Press Alt-Enter to
get to the debugger.
6) If Q3 locks during startup then try Alt-Enter to get to the debugger.
Quit the debugger.
7) Do a full reboot of the machine to avoid any instability.
Any enhancements/improvements
to this method are invited, particularly on how to attach to DLL's
loaded using LoadLibrary().
To generate your own crash deliberately insert the code:
*(long*)(-4)=0;
This is a one time only crash, and can't be recovered from.
Back to Some Questions answered
Top of Page
|