Pages: [1]
  Print  
Author Topic: DDS (DirectDraw Surface) texture loading  (Read 16495 times)
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« 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)
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #1 on: November 14, 2011, 07:55:09 PM »

Any interest in tr_image_dds.c?
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Peter Silie
Member


Cakes 2008
Posts: 610



« Reply #2 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.
Logged
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3775


Trickster God.


« Reply #3 on: November 15, 2011, 05:24:47 AM »

http://en.wikipedia.org/wiki/DirectDraw_Surface
Logged


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
Peter Silie
Member


Cakes 2008
Posts: 610



« Reply #4 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.
Logged
PigCell
Nub


Cakes 2
Posts: 41


« Reply #5 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?
Logged
Peter Silie
Member


Cakes 2008
Posts: 610



« Reply #6 on: November 15, 2011, 03:17:56 PM »

No, it is DDS from Microsoft.
Much superior than this old shity stuff from S3!
scnr Wink

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

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)!
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #7 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
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Peter Silie
Member


Cakes 2008
Posts: 610



« Reply #8 on: November 15, 2011, 04:48:27 PM »

if there are some benefits: implement it
Logged
PigCell
Nub


Cakes 2
Posts: 41


« Reply #9 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.
Logged
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #10 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.
Logged

This space is for rent.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #11 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.
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #12 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.
« Last Edit: March 11, 2014, 03:53:03 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Pages: [1]
  Print  
 
Jump to: