Warp3D and ARGB textures

Since they are in the card's native format, if I create W3D_A8R8G8B8 texture objects, will they be uploaded into the video RAM unmodified by the driver? I'm asking this, because I'd like to implement texture compression support in MiniGL, and I thought of using ARGB to pass through pre-compressed data through the Warp3D driver.

@BSzili

How would you decompress said textures after 'upload'? Unless w3D can use then in compressed form it strikes me as the minigl code would promptly drag the data back into main memory or at least require slow CPU access across the PCI interface , resulting in dreadful performance...

@broadblues
That's easy: I wouldn't. The S3TC algorithm is supported by the hardware (by the Radeon cards that is). The whole point is passing the data through Warp3D into the video RAM unmodified, so it can be decompressed by the hardware during rasterization.

@BSzili
Warp3D knows three compressed texture formats, namely:
W3D_COMPRESSED_R5G6B5, W3D_A4_COMPRESSED_R5G6B5, W3D_COMPRESSED_A8R5G6B5.

At least on the R200 (I'm only speeking for that one) those directly corespond to:
DXT1, DXT3, DXT5

And as far as I can see those pass right through (of course, that was the idea ).

Some notes (that shouldn't come as a surprise but anyway):
Make sure that you have automatic mipmap generation disabled since otherwise AllocTexObj will fail.
Also note that UpdateTexSubImage will fail on textures with that format.

Did I try it? No

@Daytona675x
I saw those formats in the header, but I didn't connect the dots that they are the DXTn formats. I should've guessed from the alpha sizes... :)
The UpdateTexSubImage could be worked around in MiniGL, but it will probably become even more expensive than creating a new texture.

edit: Are the compressed formats supported by the R200 driver too? I get W3D_TEXFMT_UNSUPPORTED for all of them.

GetTexFmtInfo?
Looks like this one has never been updated to return "okay" if you ask for the compressed formats (it also doesn't return okay for some other formats which are actually supported through internal conversion). Fixing However, texture creation should work nevertheless.

@BSZili
Okay, fixed that but did not test anything. Please check your mail.

@Daytona675x
Thanks, now it reports W3D_TEXFMT_ARGBFAST for all of the compressed formats. I needed GetTexFmtInfo, because MiniGL uses it to determine which formats are actually supported by the driver. I'll test if I can use compressed textures in Warp3D.

edit: What do you know, it actually works! :P The alpha channel seems to get lost somewhere in the conversion, but it's probably some mistake I made. Time to add a compressor to MiniGL.

@BSzili

Quote:
Nice! Have you noticed any performance improvements?

If you have some simple test code, please send it to me. I never implemented compressed texture support in the W3D_SI driver because I had nothing to test it with (and the documentation doesn't say anything about compressed textures).

Hans

@Hans
I haven't really checked the performance, but it makes the texture uploads less bus-heavy, which is not a bad thing. I'll make a modified version of Cow3D to see if it's any faster, and send it to you.

edit: I just checked the framerate differences. Without texture compression I get 60 FPS, with texture compression I get 61. Not a significant difference, but it's definitely not slower. My goal was to reduce the bus load and conserve VRAM. The latter is not a huge concern on Radeon HD cards, but the former could still have some merit even there.

@BSzili

Speed improvements are always welcome, good job

As i'm here i have a bug to report: with MiniGL 2.20 and early version I have some problems with the HunoPPC version of PrBoom Plus (OpenGL settings only), as you can see we still have rendering issues with the sky in background (and still also a problem with the trasparence effects)

http://s000.tinyupload.com/index.php?file_id=16072589085825220168

@samo79
S3TC won't likely give you any speed benefits. The 1 FPS increase is probably the result of rounding up some small difference. It's all about using the quarter of memory for storing textures.
I can't seem to download anything from OS4depot right now, so I can't test PRBoom+.

@BSzili

Check PM

Got it, and see the problem. Is it the same with the old MiniGL?

@BSzili

Well with the old 2.5 it was even worse !
Since MiniGL 2.14 Hans added a few modifications that solve certain problems related to the triangles (infact PrBoom before was completely unplayable in OpenGL mode) however as you can see not all issues were fixed ...

http://www.hyperion-entertainment.biz ... ranches/updates-kc/README

(see the changelog part of the internal release 2.14)

I was interested in whether glCopyTexSubImage2D (which is used for the screen wipe effect), was fixed during the RGBA->ARGB migration, but apparently not. It probably uses the wrong color format resulting in swapped color channels.
The enemy transparency effect is some lingering GL state change.
No clue about the sky yet, and since this is yet another closed source port of an open source game, I can't experiment by quickly recompiling it. Oh well.

edit: I fixed the screen melt issue. The bug that caused the mess with the transparent enemies was already fixed in r485.

@BSzili

Awesome ! Meantime i just open a thread in his forum, see:

http://hunoppc.amiga-projects.net/con ... s-prboom-plus-opengl-mode

So to sum, the trasparence issue is now fixed but still only the problem with the sky right ?
If so would be great ... i just retested the old PrBoom version (availible OS4Depot) and in general there are no problem in OpenGL except for the sky, here both version seems having the same problem ...

@samo79
The transparency is fixed, but it was done by me after 2.20 was released, so it's still be broken in the version available on OS4Depot.
I think I found out why the sky is broken. I suspect it's GL_EYE_PLANE and GL_TEXTURE_GEN_Q missing from MiniGL. I'll do an intentionally broken port for AROS to see if I'm right, and then try to implement them.

@BSzili

Big thanks
Once done i have another question related to another game (Frogatto), not a bug but a question related to the game running on the latest MiniGL 2.20 compared to the old 2.5 ...

@samo79
GL_EYE_PLANE can now be correctly set, but I couldn't fix glTexGen*(), so the default sky remains broken. As a workaround gl_skymode can be changed to a different type in the cfg file. Or you can just turn the mouselook on, which will change the sky type automatically in the default mode.