2 questions: about .dds, and about speed

Author

Message

s_i

14

Years of Service

User Offline

Joined: 23rd May 2009

Location: Russia

Posted: 21st Dec 2014 15:50 Edited at: 21st Dec 2014 15:59

Link

1 question

I have any absolutely white picture (.bmp or .png). After converting it into .dds (using different converters) I have picture with green shade. Why??? This is a problem, because I can not use .dds texture for planet -- because planet will have green snow on the poles.

2 question

2.1) empty 3D-scene --- FPS 2077...2090
2.2) 3D-scene with 3100 square flat semitransparent textured (32x32 texture) objects (instance-copies) --- FPS 176...186

+ Code Snippet

dbMakeObjectPlane (60497, 1, 1);
dbRotateObject   (60497, 90.0f, 0.0f, 180.0f);
dbFixObjectPivot (60497);
dbSetObjectLight (60497, 0);
dbLoadImage ("media\\point.bmp",60497);
dbTextureObject (60497, 60497);
dbGhostObjectOn  (60497, 0);
dbSetObjectTexture (60497, 2, 1);
dbDisableObjectZWrite(60497);
dbPositionObject (60497, 0, 0.0f, 0);
//copies:
for (i=30000; i<=33100; i++)
{	dbInstanceObject(i,60497);
	dbGhostObjectOn(i,0);
	dbPositionObject(i, dbRnd(40.0f)-20.0f,0.0f,dbRnd(40.0f)-20.0f);
}

2.3) 3D-scene with 3100 square flat semitransparent textured (32x32 texture) particles (SPARK plugin, SP_SetQuadRenderer) --- FPS 1848...1885

+ Code Snippet

dbLoadImage("media\\point.bmp",textureSpark2);
void * spark2Group = SP_AddGroup (expolsionPrototype,3100,0,0,0);
SP_SetLifeTime (spark2Group, 10.0f, 30.0f);
void * spark2Renderer = SP_SetQuadRenderer (spark2Group,textureSpark2, 2.42f, 2.42f, 1,1,2);
void * spark2Rgba = SP_AddRGBAInterpolator (spark2Group, SP_RGBA(255,255,178,255), SP_RGBA(255,255,178,255), SP_RGBA(255,76,76,0), SP_RGBA(255,255,76,0));
void * spark2Emitter = SP_AddNormalEmitter (spark2Group, -1, 0.4f, 1.8f, 3100, SP_PointZone(0,0,0), SP_PointZone(0,0,0));

Why scene with SPARK-objects is much faster then scene with DarkGDK-objects??? Why number of objects in DarkGDK is so critical (sensitive)???
My assumption: DarkGDK has uneffective sorting of objects, sorting is bottleneck. More DarkGDK-objects --> more time for sorting. What is your opinion, guys?

Attachments

Login to view attachments

Back to top

Profile PM

The Tall Man

10

Years of Service

User Offline

Joined: 16th Nov 2013

Location: Earth

Posted: 21st Dec 2014 16:04 Edited at: 21st Dec 2014 16:09

Link

Don't know about #2.

For #1, you could try using no texture at all - that defaults to all-white, and probably the fastest. Otherwise, you could use a 4x4 .bmp. I used the Microsoft DirectX texture tool to convert a 4x4 .bmp to .dds as DXT1 (1 bit alpha). Came out white just fine. Showed it in the texture tool program, and captured the screen with another and did a color check: 255,255,255. Although the file size is larger than the 4x4 .bmp itself. Here it is...

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.

Attachments

Login to view attachments

Back to top

Profile PM

s_i

14

Years of Service

User Offline

Joined: 23rd May 2009

Location: Russia

Posted: 21st Dec 2014 16:50 Edited at: 21st Dec 2014 20:01

Link

1) Yes, DxTex.exe works correctly! I found it now in ''C:\Program Files (x86)\Microsoft DirectX SDK (August 2007)\Utilities\Bin\x64'' folder. But other converters (including Nvidia's tool) give green shade. Thanks a lot!

P.S. The file size is larger because mipmap was generated.

Back to top

Profile PM

The Tall Man

10

Years of Service

User Offline

Joined: 16th Nov 2013

Location: Earth

Posted: 21st Dec 2014 17:43 Edited at: 21st Dec 2014 17:49

Link

Actually no they weren't - I didn't generate mipmaps. I knew I forgot something! The larger size is probably because of the file headers. Anyway... glad it works for ya!

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.

Back to top

Profile PM

s_i

14

Years of Service

User Offline

Joined: 23rd May 2009

Location: Russia

Posted: 21st Dec 2014 20:00 Edited at: 21st Dec 2014 20:04

Link

We were wrong! Look at the file sizes:

dds by DxTex.exe with mipmap -------------------------- 1024 Kb
dds by DxTex.exe ------------------------------------------ 769 Kb
bmp by Paint.NET ------------------------------------------ 769 Kb
dds by Paint.NET R8G8B8 --------------------------------- 769 Kb
png by Paint.NET ------------------------------------------- 626 Kb
dds by Paint.NET DXT1 with mipmap (green shade) --- 171 Kb
dds by Paint.NET DXT1 (green shade) ------------------- 129 Kb

Conclusion: DxTex.exe generates R8G8B8, not DXT1.

dds R8G8B8, png, jpg consume equal size of RAM-memory and videomemory (tested).
dds DXT1 consumes approximately 8 times less RAM-memory and videomemory (tested)... but has green shade.

How to generate dds DXT1 without the green tint?

Back to top

Profile PM

The Tall Man

10

Years of Service

User Offline

Joined: 16th Nov 2013

Location: Earth

Posted: 21st Dec 2014 22:07 Edited at: 21st Dec 2014 22:08

Link

From within the tool:

Menu -> Change Surface Format -> DXT1 (or anything you'd like).

What I uploaded was 4x4 DXT1 with no mipmaps, 136 bytes. Mipmaps would add about 20 bytes or so to the file size.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.

Back to top

Profile PM

s_i

14

Years of Service

User Offline

Joined: 23rd May 2009

Location: Russia

Posted: 22nd Dec 2014 00:22 Edited at: 23rd Dec 2014 21:33

Link

''Alice in Wonderland. Step-by-step.''

Introduction.
0.1) made white squaere in Paint.NET (or any other editor), save as picture.png
0.2) open it in DxTex.exe --> No green shade
0.3) Menu -> Change Surface Format -> ''Four CC 4-bit: DXT1''
0.4) Save as picture.dds

Way 1.
1.1) Open picture.dds with XnView viewer --> Green shade
1.2) Don't believe your eyes. Made screenshot screen.png
1.3) Open screen.png in Paint.NET --> Green shade

Way 2.
2.1) Open picture.dds in Paint.NET --> No green shade
2.2) Open picture.dds in DxTex.exe --> No green shade
2.3) Alice felt dizzy...

Way 3.
3.1) Install dds plugin into Windows for Explorer's thumbnails
3.2) Look into FreeCommander's thumbnail of picture.dds --> No green shade
3.2) Alice doesn't know how to be...

Way 4.
4.1) Use picture.dds for skybox in DarkGDK game --> No green shade
4.2) Don't believe your eyes. Made screenshot screen4.png
4.3) Open screen4.png in Paint.NET --> No green shade
4.4) Use picture.dds for texturing box in DarkGDK game and picture.dds for skybox --> No green shade, absolutely white screen!

Epilogue.
E.1) Alice realized that the Cheshire XnView v2.04 led her in the wrong way.

Update (23 dec 2014): XnView v2.25 gives green shade too.

Back to top

Profile PM

The Tall Man

10

Years of Service

User Offline

Joined: 16th Nov 2013

Location: Earth

Posted: 22nd Dec 2014 00:36 Edited at: 22nd Dec 2014 00:37

Link

LOL!

I have seen the white rabbit become ill - certain distributed .dds files with a funky-green shade in DarkGDK. So I know it happens... Glad it's apparently not this time

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.

Back to top

Profile PM

Rudolpho

18

Years of Service

User Offline

Joined: 28th Dec 2005

Location: Sweden

Posted: 23rd Dec 2014 12:16 Edited at: 23rd Dec 2014 12:18

Link

Quote: "Why scene with SPARK-objects is much faster then scene with DarkGDK-objects??? Why number of objects in DarkGDK is so critical (sensitive)???
My assumption: DarkGDK has uneffective sorting of objects, sorting is bottleneck. More DarkGDK-objects --> more time for sorting. What is your opinion, guys?"

It could be that to a certain extent, however I would guess that those particle objects use fewer, larger vertex buffers that maybe contains up to 1024 (or any other number really) of quads each. At the time of issuing a draw call you can tell it to only draw the first X number of vertices, but it will still only issue a single draw call per group of quads. As you suggest, these quads wouldn't be sorted in with the DGDK objects either (or so I guess). For the DGDK quads they all exist as a 4-element vertex buffer that needs to be drawn separatedly.

I don't know about the DDS files but you are presumably using some kind of destructive compression when getting the smaller file sizes. As such it makes sense that the original colour cannot be properly restored, however you would think that it should at least be able to restore full white. I'm guessing the green channel may have lower resolution in the compressed format because it is deemed to contribute less to the perceived colour or something like that.

Back to top

Profile PM Email Website

Sorry your browser is not supported!

Dark GDK / 2 questions: about .dds, and about speed

Attachments

Attachments