DDS textures for AC + DDS loader (source modified)

[RPG]

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

[Dementium4ever]

Veeery nice, I'll try it :)

[tempest]

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.

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)

[RPG]

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:)

Uh, you did? Don't you think you forgot to mention something there?

AC based on cube engine, or not? Didn't understand you.

[tempest]

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 ;)

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 :)

[makkE]

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.

[RPG]

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:)

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.

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.

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).

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).

[Bullpup]

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.

[makkE]

Oh well.

[samsattF]

Thank you! I'll try it.

[RPG]

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.

[Ronald_Reagan]

Is this an option that can get changed? Because some old video cards wouldn't be able to do it ;)

[RPG]

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.

[Ronald_Reagan]

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?

[RPG]

I prefer first: dds on hdd, and there is no jpg's. This makes texture loading faster

[eihrul]

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.

[RPG]

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:)

[eihrul]

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.

[RPG]

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.

[eihrul]

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.

[makkE]

RPG, please package it as a patch, don't distribute full packages. Read the docs. Thanks.

[RPG]

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?

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?

[V-Man]

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.

[RPG]

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