DDS textures for AC + DDS loader (source modified)
#1
Hi, this is me again with patches for the graphics in AC:)

Today I want to introduce you dds textures. Dds is an old format for textures and has one big advantage: dds uses 8 times less memory, than jpg! In other words you can use 512x512 texture instead of 256x256 without performance kick. How? Modern graphics cards (Geforce 2 and newer:) can store compressed dds textures directly in video memory. So engine even doesn't have to decode texture: just read data and send it to video card.
More about DXT compression look in Google.

Advantages:
  • Good quality lossy compression. Dds texture also may be compressed with zip.
  • FAST loading (much faster than jpeg or png), now AC switches between maps in a flash
  • Pre-rendered mip-maps stored in dds file (also loads faster), better quality of mip-maps
  • 8 times less video memory needed (my AC mod uses only 90 mb)
  • Faster rendering (less memory needs to be readed)

I used Nvidia Texture Tools to convert almost all AC textures into dds format. I also ported Cube's 2 dds loader for cube 1 engine. You don't need to modify maps: if texture has name "texture.jpg", engine first looks for "texture.dds" and loads it, if "texture.dds" loading failed, loads "texture.jpg".

Dds textures, patches and modified source applied: just compile.
Based on AC 1.1.0.4 release.
Full AC with textures, modified source, patch: ***removed***
Patches only (for source 1.1.0.4, for developers): http://ompldr.org/vYWp1dw
Thanks given by:
#2
Veeery nice, I'll try it :)
Thanks given by:
#3
(27 Sep 11, 12:24PM)RPG Wrote: In other words you can use 512x512 texture instead of 256x256 without performance kick.
Only partially true. Texture compression can't do anything about texel fill rate, which is probably the limiting factor for most people running AC. But the texture loading is much faster ofc, since the engine doesn't have to reformat or uncompress anything.

(27 Sep 11, 12:24PM)RPG Wrote: I also written dds loader for cube 1 engine.
Uh, you did? Don't you think you forgot to mention something there?
(In case you're talking about this patch)
Thanks given by:
#4
(27 Sep 11, 04:06PM)tempest Wrote: Only partially true. Texture compression can't do anything about texel fill rate, which is probably the limiting factor for most people running AC.
Okay, so why, if some people have troubles with running AC (due to fill rate), most mapmodels in AC have textures 512x512 or even 1024x1024?

I think dds 512 will be a little bit slower than 256 jpg, but faster than 512 jpg.
Also there is such thing as mip maps, so you mustn't care about fillrate: mip maps keep amount of textels on the screen less as possible.

I dont see any problen: dds textures may be easily scaled down, if your computer too old:)

(27 Sep 11, 04:06PM)tempest Wrote: Uh, you did? Don't you think you forgot to mention something there?
AC based on cube engine, or not? Didn't understand you.
Thanks given by:
#5
(27 Sep 11, 04:53PM)RPG Wrote: I dont see any problen: dds textures may be easily scaled down, if your computer too old:)
There is no problem, I just wanted to make sure people wouldn't drop in 4096² DDSs and then complain about things getting a little slow ;)

(27 Sep 11, 04:53PM)RPG Wrote:
(27 Sep 11, 04:06PM)tempest Wrote: Uh, you did? Don't you think you forgot to mention something there?
AC based on cube engine, or not? Didn't understand you.
People around open-source project are quite touchy about giving each other (and each other's projects) credit where it is due. In this case, instead of "I wrote ...", "I backported ... from Cube 2" would probably be more appropriate. Just a heads up :)
Thanks given by:
#6
A pixel is a pixel, no matter where it comes from.
Load faster, yes. Run faster .... no.

Loading all textures from either tiff's or dds or jpg's or bpm or whatever format does not change one bit of actual memory usage. A 256² at 24bit colour depth always takes up 196.6 KB in the video card's memory.

Still a cool patch. You're not supposed to put it in a package like this, but whatever. I let my predecessors worry about that.
Thanks given by:
#7
Quote:People around open-source project are quite touchy about giving each other (and each other's projects) credit where it is due. In this case, instead of "I wrote ...", "I backported ... from Cube 2" would probably be more appropriate. Just a heads up :)
Ok, I understand that. Yes, dds headers I took from Cube 2, and dds loader from my 2D engine:)

Quote:There is no problem, I just wanted to make sure people wouldn't drop in 4096² DDSs and then complain about things getting a little slow ;)
No, I sure, nobody wants to include 4096 texture. But 512 is more suitable resolution for walls and floors. Dds may help to reduce memory usage.

Quote:Loading all textures from either tiff's or dds or jpg's or bpm or whatever format does not change one bit of actual memory usage. A 256² at 24bit colour depth always takes up 196.6 KB in the video card's memory.
JPG = 24bit / 1 pixel
PNG = 32bit / 1 pixel
DDS = 64bit /16 pixels - significantly less memory usage, so video card reads this texture from memory much faster. This is native format for textures, stored in video memory.
Quote:DXT1 (also known as Block Compression 1 or BC1) is the smallest variation of S3TC, storing 16 input pixels in 64 bits of output, consisting of two 16-bit RGB 5:6:5 color values and a 4x4 two bit lookup table.
© Wiki.

Also, enabling texture compression in Cube 2 increases my fps (I have only 128 Mb video memory and more textures could be loaded into the cache with compression).

Quote:You're not supposed to put it in a package like this, but whatever
This package contains 60 Mb of dds textures (all AC's textures were re-compressed).
Thanks given by:
#8
RPG you forgot to account for the dither rendering and spooling that will go into exasperating 1/10th of 100 bits per block in the upper cache (video) overhead queue table once the full weight of all the re-compressed data is returned to its original state be that of jpg, tiff, dds, it will degrade video memory as each clock cycle takes a chunk of bytes and makes it unusable once the whole package is rendered on screen.

Food for thought.
Thanks given by:
#9
Oh well.

Thanks given by:
#10
Thank you! I'll try it.
Thanks given by:
#11
http://graphics.stanford.edu/projects/fl...mpression/

Just check yourself: dds version faster from 10 to 20%. Video cards since GeForce 2 can easily render compressed data.
Thanks given by:
#12
Is this an option that can get changed? Because some old video cards wouldn't be able to do it ;)
Thanks given by:
#13
Some old cards? Even Voodo card can do this. But I think AC will be very slow on Voodo card:)

If not, I can try to make dds unpacker on CPU to send to GPU only RGB data. But first, we should find people, that have card without texture compression.
Thanks given by:
#14
Or you can toggle the option.

Does the image start as DDS on the HDD? Or does it change along the way from jpg (hdd) to DDS (memory) and the processor reads it from there?
Thanks given by:
#15
I prefer first: dds on hdd, and there is no jpg's. This makes texture loading faster
Thanks given by:
#16
DXT texture compression/decompression is patented, so many open source drivers simply do not support it at all because they simply can't. Cube 2 includes backups of EVERY DXT-compressed texture for this very reason, because there is no guarantee the DDS texture can be safely used.
Thanks given by:
#17
This is sad ... But I can not play the Cube 2 without proprietary (nvidia) drivers: even a lightweight AC with OpenSource drivers has about 4 fps. What about Intel GMA: it's OpenSource driver supports DXT, but Cube engines very slow on my Intel GMA (while HalfLife 2 runs without problem: 30-60 fps). How powerful must be video card to play Cube 2 with opensource driver?

However, this patch will load jpg, if dds is not loaded. But you can't remove jpg's in this case. Hopefully, most drivers, that can give good performance for Cube, supports compression.

In Linux works only one rule: if you want to play, use only the proprietary driver.

Fortunately I have good card and good drivers to play AC or Cube 2 in Linux:)
Thanks given by:
#18
(30 Sep 11, 09:58AM)RPG Wrote: This is sad ... But I can not play the Cube 2 without proprietary (nvidia) drivers: even a lightweight AC with OpenSource drivers has about 4 fps. What about Intel GMA: it's OpenSource driver supports DXT, but Cube engines very slow on my Intel GMA (while HalfLife 2 runs without problem: 30-60 fps). How powerful must be video card to play Cube 2 with opensource driver?

However, this patch will load jpg, if dds is not loaded. But you can't remove jpg's in this case. Hopefully, most drivers, that can give good performance for Cube, supports compression.

In Linux works only one rule: if you want to play, use only the proprietary driver.

Fortunately I have good card and good drivers to play AC or Cube 2 in Linux:)

Those are D3D. Intel's OpenGL support is REALLY bad. I mean, not REALLY bad, I mean, like, REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY --- woo, I need to take a typing break --- REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY bad. It's not that the hardware can't handle it so much as that Intel can't write an OpenGL driver to save themselves.
Thanks given by:
#19
So, most game engines have to implement OpenGL and D3D renderers... Of course, most gamers don't use GMA, but most notebooks and netbooks have Intel GMA inside. I prefer to play on machine with GeForce:)
eihrul, what do you thik about decompressing DXT format on CPU if driver doesn't support it? DXT is a simple format and it can be easily decompressed. I can try to write simple decompressor, so if system doesn't support dds, engine will send to card pure RGB/RGBA. In this case we avoid OpenSource driver limitations and keep pre-generated mip-maps advantage of dds. Also we don't need to include jpg/png into package like you do in Red Eclipse.
Thanks given by:
#20
(30 Sep 11, 11:44AM)RPG Wrote: So, most game engines have to implement OpenGL and D3D renderers... Of course, most gamers don't use GMA, but most notebooks and netbooks have Intel GMA inside. I prefer to play on machine with GeForce:)
eihrul, what do you thik about decompressing DXT format on CPU if driver doesn't support it? DXT is a simple format and it can be easily decompressed. I can try to write simple decompressor, so if system doesn't support dds, engine will send to card pure RGB/RGBA. In this case we avoid OpenSource driver limitations and keep pre-generated mip-maps advantage of dds. Also we don't need to include jpg/png into package like you do in Red Eclipse.

You don't avoid limitations, because this is exactly the limitation. You CAN'T decode on the CPU without violating the patent.
Thanks given by:
#21
RPG, please package it as a patch, don't distribute full packages. Read the docs. Thanks.
Thanks given by:
#22
Quote:You don't avoid limitations, because this is exactly the limitation. You CAN'T decode on the CPU without violating the patent.
Ok. OpenSource drivers just pass compressed texture to video card - there is no patent limitations. So this is why my dds textures works well on GMA hardware/Mesa driver.
Thus there are only people whose hardware does not support texture compression (Riva TNT, Rage). How fast is Cube on these cards?

Quote:RPG, please package it as a patch, don't distribute full packages. Read the docs. Thanks.
Please, tell me, how can I include these dds textures into path?
Thanks given by:
#23
My other computer has a Rage card, and averages between 90-120 fps. It hardly ever has glitches or stalls on features like dynlight.
This one has an integrated Intel graphics card, but it also has no problem with dynlight. It averages 150 fps.
Thanks given by:
#24
Strange. My GeForce 6600/P4 3.2 GHz gives me ~100 - 190 fps. 20 fps on GMA 4500/Core 2 duo 2.2 GHz - notebook a little bit stronger thah PC
Thanks given by: