Bug: CreateTexture()

[Korax]

I've encountered a bug with using CreateTexture().
It seems like the engine doesnt always create the size texture you are requesting.

I'm writing a Quake (emulator) using C# and I have encountered some problems with textures not having the standard quake 32, 64, 128 type sizes.

More specifically the "Quake" name at the beginning of the game. (start.bsp)
My game engine loads directly from the BSP and passes all the data to TV3D.
In this case, I have to create the textures since the texture data comes right from the bsp and not load from a file.

Bsically in this case the "Quake" logo texture is 288x64, but the engine creates a texture size of 512x64.

Heres the lines of code in question:


int TexWidth = vBsp.vWorldModel.textures.width;
int TexHeight = vBsp.vWorldModel.textures.height;

int NewTexture = CProgram.vTextures.CreateTexture(TexWidth, TexHeight, false, vBsp.vWorldModel.textures.name);

MTV3D65.TV_TEXTURE tvt = CProgram.vTextures.GetTextureInfo(NewTexture);
if (vBsp.vWorldModel.textures.name == "quake")
{
    System.Diagnostics.Debug.WriteLine(TexHeight);
    System.Diagnostics.Debug.WriteLine(tvt.Height);
    System.Diagnostics.Debug.WriteLine(TexWidth);
    System.Diagnostics.Debug.WriteLine(tvt.Width);
}


It outputs as follows to the console:
64
64
288
512

I know my data is correct, Ive cross-referenced all the input data being sent to TV3D with data generated by Quake, and on my side its a 100% match, which makes this a bug in TV3D.

This is a showstopper for my project if this wont be fixed in the release.
This will be a huge project and could help put TV3D further on the map.

Let me know if you need a screenshot of this.
Take a look at my "Emulating Quake" journal http://www.sagamedev.com/developerjournal_post.aspx?journalid=28

[jviper]

It appears that your graphics card does not support texture sizes that are non power of 2. 288 is not a power of 2, but 512 is, and 512 would be the next power of 2 from 288. Don't know if there is much you can do about this.

[Raine]

I just loved Quake and I hope you will be able to finish your project. I will be sure to check its progress!

As for your problem, you could implement some kind of texture manager.

 - Load the original texture
 - Check the loaded texture size
 - Calculate the size delta and store the UV values (derived from the original tex. size)

Other solution:

 - a texture atlas (with the proper padding space between texs)

You could then have a custom DrawTexture method taking in account the UV info you've stored
hth

PS: How will you go about QuakeC?

[SylvainTV]

Yep. The engine only loads/created textures with a 2^n size. All non 2^n numbers are upped to  the next 2^n number

The 3d cards don't support well 2^n except in some conditions anyway, so it's better to avoid them totally.

I think you should unfortunately expand your non 2^n texture data to 2^n texture data.

[Korax]

One of the first questions coming to mind was how to manage QuakeC.

The quick answer is, we're not sure yet, either we will write code simmilar to Quake's original C code, or we will be re-writing all the QuakeC code over to LUA, we still need to check which method would be the most productive and correct way to follow.

I can't really avoid this as its the original Quake data I'm dealing with.
So I need to expand the non 2^n texture data to 2^n texture data.

I'll probably be running into this quite a lot with the original Quake data.

So I'm guessing what would be needed is to shrink or stretch the dimension in question to the closest base?

Suggestion, would it be possible to have an overload for this function with an enum for example having the following values: None, Nearest, Bilinear (etc?).

If you use this overloaded function TV3D would then check your input image data and scale it up or down to the closest base?

It should be alot more graceful than just using the next base, even though in this case 256 is closer than 512.

Just me suggesting, but you should decide if this is a useful addition or not as you know the engine far-far better since you are the developers of it.

As for progress:
I've finished off animated textures and perfect rendering of Quake skies.
At the moment I'm busy implementing the client structures.

[Raine]

This is a bit harder than it seems. I don't really remember how level editing worked; I don't know if brushes store UV info as well.

In any case, you should already have all the data to solve the problem; original tex size and loaded tex size. you can derive all the uv coords you need in order to show the texture properly. I think the textures are padded with black / transparent pixels?


As for QuakeC, mods such as Zerstorer (with the accented o in the middle) were just amazing... managing to get such pieces of art running would be simply amazing

http://www.gue-tech.org/quake/qcrm/qcrm.pdf

[Korax]

Its working!!

It was quite tricky, like you said.
I had a look at the resampling functions in Quake1, Quake2 and Quake3 and adopted the method Quake3 uses.

I wrote a resampling function that firstly checks for non-pow2 textures, if it finds pow2 it just returns the data as-is, if not, it resamples the texture and stores the new dimensions into worldmodel texture variables: scaled_width, scaled_height.

If the texture was pow2 width == scaled_width, height == scaled_height, if not, they will differ. "width" and "height" will retain the original sizes while the scaled versions will keep the new texture values. the scaled versions are used with all the texture perations there-after, like sending the texture to TV3D etc, while the original values are used to calculate the UV coorinated.

Yes, that needs to be calculated like this:
_mvertex.TextureU = (_mvertex.Vx * texinfo[dfaces.texinfo].vecs[0, 0]
+ _mvertex.Vy * texinfo[dfaces.texinfo].vecs[0, 1]
+ _mvertex.Vz * texinfo[dfaces.texinfo].vecs[0, 2]
+ texinfo[dfaces.texinfo].vecs[0, 3])
/ textures[texinfo[dfaces.texinfo].miptex].width;

_mvertex.TextureV = (_mvertex.Vx * texinfo[dfaces.texinfo].vecs[1, 0]
+ _mvertex.Vy * texinfo[dfaces.texinfo].vecs[1, 1]
+ _mvertex.Vz * texinfo[dfaces.texinfo].vecs[1, 2]
+ texinfo[dfaces.texinfo].vecs[1, 3])
/ textures[texinfo[dfaces.texinfo].miptex].height;

The UV coords must remain the same, that why we need the original texture sizes.

I'll check out that QuakeC stuff.

[SylvainTV]

Glad you got it working. Yea maybe a function in TV is missing to create a texture from data that is not 2^n but well There are always alternatives !

[Korax]

Heres a screenshot of TV3D now rendering the resampled "quake" texture correctly.
So this was my bad, the engine does the right thing.



By the way, where can I find some documentation for download on 6.5 ?
It quite hard trying to figure out how to do things.. I havent worked with 6.3 previously.

Also, what is the possibility of TV3D being compatible with the xbox360 in the future?

One of my project goals is bringing Quake to the xbox360 or higher, which is one of my main reasons dumping Quake's original OpenGL engine and using a managed .NET language like C# in this case.

[vsleepy]

great project, loved quake!

[newborn]

Wow! Now I feel old...

By the way, where can I find some documentation for download on 6.5 ?
It quite hard trying to figure out how to do things.. I havent worked with 6.3 previously.

There is no 6.5 docs yet.

Also, what is the possibility of TV3D being compatible with the xbox360 in the future?

Unless TV3D switches to XNA, chances are slim.