OpenArena Message Boards

OpenArena Contributions => Idea pit => Topic started by: fromhell on October 03, 2011, 11:45:04 AM



Title: DDS (DirectDraw Surface) texture loading
Post by: fromhell on October 03, 2011, 11:45:04 AM
XReaL has it sort of but it's too tied to its wacky renderer and not very portable, and its software decoding is questionable. Darkplaces has it and it also has a patent-dodging software decoder in its loader, but I find it hard if not impossible to port it over

tr_image_dds.c plz!?


BTW, the old maps dmmq3dm1-2-3-4-5-6. have DDS textures, so we have our examples already, though ultimately DDS and OA would be used to cut size for the entire game (and make loading much faster on modern hardware that supports it (which is like nearly every card made after Jan 2000)).

Xonotic already does it (But in a strange way - i'd like to NOT have dds textures stored in the dds/ folder)


Title: Re: DDS (DirectDraw Surface) texture loading
Post by: fromhell on November 14, 2011, 07:55:09 PM
Any interest in tr_image_dds.c?


Title: Re: DDS (DirectDraw Surface) texture loading
Post by: Peter Silie on November 15, 2011, 03:21:42 AM
I even do not know, what you are talking about so..... YES! XD
To be honest: i am not familar with DirectDraw Surface so i will be quiet now.


Title: Re: DDS (DirectDraw Surface) texture loading
Post by: Neon_Knight on November 15, 2011, 05:24:47 AM
http://en.wikipedia.org/wiki/DirectDraw_Surface


Title: Re: DDS (DirectDraw Surface) texture loading
Post by: Peter Silie on November 15, 2011, 07:49:33 AM
Oh: S3TC.
I thought it was protected by patents (reason why Mesa3D can not use it)?
ps: as long as this is no prob for OA and saves mem/disk space it could be fine.


Title: Re: DDS (DirectDraw Surface) texture loading
Post by: PigCell on November 15, 2011, 01:02:50 PM
Oh I remember the old ZTN maps using those. I remember back then they touted it as a means of delivering high-resolution textures on their graphic cards, which other vendors couldn't do back then. My question: What would be the advantage of lossy compression via .dds over .jpg or .png? Modern graphic cards can store way more textures than we can currently offer in OA and older ones run decently with picmip. Certainly, converting the bulk of the textures to .jpg would have the same effect of reducing the package size, no?


Title: Re: DDS (DirectDraw Surface) texture loading
Post by: Peter Silie on November 15, 2011, 03:17:56 PM
No, it is DDS from Microsoft.
Much superior than this old shity stuff from S3!
scnr ;)

Dunno what modern gpus can do with jpg or any other compressed, lossy format but as long as it is fine for oa, the developers should give it a try.
If it is just a "me too" which nobody uses, they should drop it (or if the code is already done, just implement and say "me too" ;) ).

Anyway: i am neither a developer nor a graphic artist. if there are some benefits: implement it (even if my paint does not support dds iirc)!


Title: Re: DDS (DirectDraw Surface) texture loading
Post by: fromhell on November 15, 2011, 04:35:59 PM
Certainly, converting the bulk of the textures to .jpg would have the same effect of reducing the package size, no?

You can't alpha channel a JPG
There are more alpha textures in OA than there are those without it


Title: Re: DDS (DirectDraw Surface) texture loading
Post by: Peter Silie on November 15, 2011, 04:48:27 PM
if there are some benefits: implement it


Title: Re: DDS (DirectDraw Surface) texture loading
Post by: PigCell on November 15, 2011, 05:12:58 PM
You can't alpha channel a JPG
There are more alpha textures in OA than there are those without it

True, I guess I underestimated how many of them there are. I suspect splitting off the alpha channels into different files and rewriting shaders accordingly would be more work than implementing .dds. Unless that format comes with its own drawbacks. I have no experience with it. If radiant and shader files can be used as usual it'd be a nice addition and one could transition gradually.


Title: Re: DDS (DirectDraw Surface) texture loading
Post by: grey matter on November 17, 2011, 02:58:17 PM
When it comes to file sizes; I'm not entirely certain whether using a texture format with better compression is a real gain. All those shiny textures will usually be put in pk3, which in turn can be compressed as well. I do not know whether the image formats differ regarding their size in vram, but on disk it might be better to simply use something better then good ol' deflate.

PNG is good as well and already part of ioquake3. Using the right tools (optipng, pngcrush, pngrewrite etc.) and some time you can get small file sizes as well. Even better, reduce number of colours manually beforehand, which saves space with most image formats.

If there are unkown or small benefits, do not waste your time with it. It needs testing, documentation and optimization.
More general optimizations; like using less and smaller textures, low-poly models etc. should bring more benefit, at the impact of more work.


Title: Re: DDS (DirectDraw Surface) texture loading
Post by: fromhell on November 18, 2011, 06:35:15 AM
PNG has this 'takes forever to load' problem. Also DDS in most cases can be smaller than PNG (some loss, though)

A DDS texture would load faster than just loading .jpg/tga into DXT1/5. It already comes compressed, ready to fit into the VRAM.

I beeleeeiiiiive the patent issue around DDS only covers its decoding. Most hardware since 1999 support it natively through driver, if you don't support DXT1 anyway you're probably going to need to use picmip 1 for OA anyway either way with that small video memory, to not notice DDS decoding artifacts.


Title: Re: DDS (DirectDraw Surface) texture loading
Post by: fromhell on March 11, 2014, 10:29:01 AM
I'm slowly working on support for this BTW, using pieces of the Xreal code.  Pieces in particular are just header loading.  I'm going to leave the software decoding out since that's potentially legally iffy.



EDIT: Here's a screenshot of DMMQ3DM1 running under OA.  Note that this is the original DDS only version, no external TGA/JPEG packs are loaded.