VM incompatibilities with anisotropic filtering patch and improvements with ongoing development

Thilo Schulz arny at ats.s.bawue.de
Fri Apr 28 21:06:56 EDT 2006


Hello,

With the latest patch introducing anisotropic texture filtering an 
incompatibility to the old VM files has been introduced, too.

The glConfig structure that is being passed to these parts has been changed to 
add info about the status of anisotropic filtering. The original VMs of 
course do not mirror that change.
This is problematic because the complete glConfig struct gets written to 
address space managed by these VMs that calculate with a lower bytecount for 
the glConfig structure und overwrites data.

For instance, in q3_ui/ui_local.h it overwrites the variables:
        qboolean                        debug;
        qhandle_t                       whiteShader;
in the uiStatic_t struct.

As soon as you enable anisotropic filtering using the old VMs the debug value 
gets overwritten and the menu is suddenly displayed in debug mode.

Now there are two ways to fix the problem:
1. move the
        qboolean                                textureFilterAnisotropic;
        int                                             maxAnisotropy;
variables from the glconfig_t struct to another one
2. create a compatibility struct with the old data layout from the original iD 
vm's and use this structure as base for writing to the VM's memory
3. Get all modders on the world to patch their VMs with the same modifications 
we did to ioq3.

The third possibility is of course not really feasible.

My suggestion would be to use possibility #2 and let it compile in 
compatibility mode per default and adding support in the Makefile for 
compiling with support for an updated version of the virtual machine code.
This way we don't break compatibility and are not as much limited by the 
original VMs while at the same time not giving up any compatibility.
People that release stand-alone versions of their games with the ioq3 engine 
are much more likely to impelement changes/improvements to their versions. As 
I see it right now, we need to do some "dirty hacks" already because of this 
limitation.
What's your opinion?

-- 
Thilo Schulz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20060429/0b43755f/attachment.pgp>


More information about the quake3 mailing list