Purpose a new way to store gfx data

For code related discussions and questions
Post Reply
User avatar
Crymson
Trained
Trained
Posts: 289
Joined: 18 Mar 2010, 21:08

Purpose a new way to store gfx data

Post by Crymson »

Looking at the future for trunk, it looks like the move to a new container format for the data is needed.
Once we have normal maps and other data it will be a big pain in the ass if we use the current way to load the graphics.

I would like to purpose a switch to the .dds format for all our graphical needs. It is widely supported.

There is some free code for the loader here, http://www.mindcontrol.org/~hplus/graphics/dds-info/

If we make the switch, we can then have textures, masks, and normal maps, and mip maps, and even compress the data to a format that is ready for the gfx hardware. No need to keep doing that bandwidth wasting crush for pngs all the time!

Can I write a .dds loader and make a patch, or is this not wanted?
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: Purpose a new way to store gfx data

Post by Per »

There are some complicating factors. First, DDS uses lossy compression, and so we need to store originals separate. Second, you have less choice in programs that can modify the textures if you use DDS. IIRC, even GIMP out of the box does not support DDS. That is probably because of the third problem, which is that DDS employs some patented algorithms that some programs/drivers may not support. In particular, we need to make sure that we do not cut off support for the open source drivers on Linux, and I'm not sure they support loading the DDS formats directly.

Last time I looked into using the DDS format, there were too many open questions like the above, so I gave up on it. But if we find some answers, perhaps we can make some progress.
User avatar
Crymson
Trained
Trained
Posts: 289
Joined: 18 Mar 2010, 21:08

Re: Purpose a new way to store gfx data

Post by Crymson »

Your right about gimp, that needs this, http://nifelheim.dyndns.org/~cocidius/dds/
I don't see how the linux open source drivers can't support a openGL 1.1 call, it needs GL_ARB_texture_compression, and if cubemaps are used, then GL_ARB_texture_cube_map is needed, but that is a openGL 1.3 call.

For the lossy argument, is that really needed? I noticed the original game data had lossless audio files, and were converted to a lossy format.

Your own code already checks for GL_ARB_texture_compression.

Code: Select all

Index: lib/ivis_opengl/screen.c
===================================================================
--- lib/ivis_opengl/screen.c (revision 10453)
+++ lib/ivis_opengl/screen.c (working copy)
@@ -197,7 +197,8 @@
  debug(LOG_3D, "  * Rectangular texture %s supported.", GLEE_ARB_texture_rectangle ? "is" : "is NOT");
  debug(LOG_3D, "  * FrameBuffer Object (FBO) %s supported.", GLEE_EXT_framebuffer_object ? "is" : "is NOT");
  debug(LOG_3D, "  * Vertex Buffer Object (VBO) %s supported.", GLEE_ARB_vertex_buffer_object ? "is" : "is NOT");
- 
+ debug(LOG_3D, "  * NPOT %s supported.", GLEE_ARB_texture_non_power_of_two ? "is" : "is NOT");
+ debug(LOG_3D, "  * texture cube_map %s supported.", GLEE_ARB_texture_cube_map ? "is" : "is NOT");
  glGetIntegerv(GL_MAX_TEXTURE_UNITS, &glMaxTUs);
  debug(LOG_3D, "  * Total number of Texture Units (TUs) supported is %d.", (int) glMaxTUs);
User avatar
Buginator
Professional
Professional
Posts: 3285
Joined: 04 Nov 2007, 02:20

Re: Purpose a new way to store gfx data

Post by Buginator »

Added you patch, since I thought we checked for those...

For dds format, I was playing around with it in the past. I agree that the current way is less than optimal.
and it ends here.
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: Purpose a new way to store gfx data

Post by Per »

Flank4 wrote:I don't see how the linux open source drivers can't support a openGL 1.1 call, it needs GL_ARB_texture_compression, and if cubemaps are used, then GL_ARB_texture_cube_map is needed, but that is a openGL 1.3 call.
You cannot load DDS files with GL_ARB_texture_compression (which is also not 1.1). You need glCompressedTexImage2D with GL_EXT_texture_compression_s3tc, which is not part of the standard. See http://en.swpat.org/wiki/OpenGL_3 for more info.
i-NoD
Code contributor
Code contributor
Posts: 318
Joined: 30 Nov 2008, 00:42
Location: In the middle of nowhere

Re: Purpose a new way to store gfx data

Post by i-NoD »

Buginator wrote:Added you patch, since I thought we checked for those...
*cough* GL_ARB_texture_cube_map is in 1.3 standard, so this check is useless for trunk which is almost at 1.5 level as a minimum. *cough*
As for GLEE_ARB_texture_non_power_of_two, there is already check for more recent GLEE_ARB_texture_rectangle...

Anyway, those debug strings are useless as they aren't included into report file... it's better to check some online OGL level db..
User avatar
Buginator
Professional
Professional
Posts: 3285
Joined: 04 Nov 2007, 02:20

Re: Purpose a new way to store gfx data

Post by Buginator »

i-NoD wrote:
Buginator wrote:Added you patch, since I thought we checked for those...
*cough* GL_ARB_texture_cube_map is in 1.3 standard, so this check is useless for trunk which is almost at 1.5 level as a minimum. *cough*
As for GLEE_ARB_texture_non_power_of_two, there is already check for more recent GLEE_ARB_texture_rectangle...

Anyway, those debug strings are useless as they aren't included into report file... it's better to check some online OGL level db..
:hmm:
I guess so. :oops:
and it ends here.
Post Reply