DDS Support

[Spintz]

^^^ Exactly why I didn't want to answer.

[Spintz]

Moreover, you can also get slightly better results for the first case when using 'const s32', because the parameter is not changed.

Are you serisouly suggesting this :

Code: Select all

void func( const s32 )...

[vvv]

I do not know how did you got any performance gain. Using constant reference for type with size less than pointer size is strange (and on 64 bit reference would be bigger than value for s32). On 32 it can not give you any advantage at all, more than that MSVC and G++ on windows generate worse code for const reference on 32bit type. You do additional operation on every method access.

(about good practice using (const s32 a = 10) in constructors is not good practice at all. it can do different things on different comilers (yeah i know that daemon3d is not suuposed to be using any other compiler than one on your system, but anyway)).

Your benchmarks were wrong for some reason, maybe caching, maybe some specific result. See bellow:

Code: Select all

 1 int ref(const int & a){
 2         return a + 1;
 3 }
 4 
 5 int val(const int b){
 6         return b + 1;
 7 }
 8 
 9 int main(int argc, char ** argv){
10         int a = 1;
11         ref(a);
12         val(a);
13         return 0;
14 }

------------- MSVC -------------------
cl.exe /G7 /Falist1.as a.cpp

?ref@@YAHABH@Z PROC NEAR				; ref
; File c:\temp\de\a.cpp
; Line 1
 ....
; Line 2 
	mov	eax, DWORD PTR _a$[ebp]
	mov	eax, DWORD PTR [eax]
	add	eax, 1
; Line 3
	pop	ebp
	ret	0
...
?val@@YAHH@Z PROC NEAR					; val
; Line 5
	push	ebp
	mov	ebp, esp
; Line 6
	mov	eax, DWORD PTR _b$[ebp]
	add	eax, 1
; Line 7
	pop	ebp
	ret	0
...
------------- G++ MinGw ------------------------

g++ -S a.cpp

__Z3refRKi:
	pushl	%ebp
	movl	%esp, %ebp
	movl	8(%ebp), %eax
	movl	(%eax), %eax
	incl	%eax
	popl	%ebp
	ret
	.align 2
.globl __Z3vali
	.def	__Z3vali;	.scl	2;	.type	32;	.endef
__Z3vali:
	pushl	%ebp
	[b]movl	%esp, %ebp
	movl	8(%ebp), %eax
	incl	%eax[/b]
	popl	%ebp
	ret
	.def	___main;	.scl	2;	.type	32;	.endef
	.align 2

[Spintz]

The important stuff here is the DDS support. I refuse to discuss/argue this anymore. If you don't like the const& args, then change them.

[vvv]

The important stuff here is the DDS support. I refuse to discuss/argue this anymore. If you don't like the const& args, then change them.

No problem. I just tried to get if you have any reasonable reason for using them. Just if it is smth I donno. Anyway thanx for answer.

[hybrid]

Are you serisouly suggesting this :

Code: Select all

void func( const s32 )...

Yes. As you might know, parameters are just ordinary variables for the function. They also have to be treated as such. And hence, once you know that any kind of variable is const you can declare it as such and get some better optimization. It's only little difference in this example, but it's noticeable with optimization stages 1 and 2 with gcc (O3 makes all variants exactly the same).

[robmar]

So its 4 years later, what happened to DDS support?

I have some nVidia HLSL shaders that use DDS, can I just convert em to PNG using the Adobe nVidia plugin?

Or is there critical file data needed from the DDS?...

[Nadro]

Yes, you can convert it to png, because inside a shader a dds textures works like each other.

BTW. Compressed Textures support will be available in Irrlicht v1.9 (I'll do it when OGL ES2 driver will be fixed).

[hybrid]

You can also just enable the DDS support in Irrlicht and load the DDS textures.

[robmar]

Fabulous, its in the config header I suppose?

I´ve noticed the dds files can be 400% larger than PNG, so is there a big benefit using them?

[CuteAlien]

The point of dds is their compression - so not sure why they are larger. You can enable the dds-loader to load and use them. But they are then decompressed in mainmemory by Irrlicht before sent to the card. So the real feature - sending compressed dds to the card without decompressing in memory is not possible. So given that the real point of using them is not supported I would always convert them to another format (unless it's too much work or another good reason) to avoid the stupid patent troubles around the decompression algorithm (read about it on the net if you care about such stuff).

So what we need for real support is having either a texture-class for dds or a flag (or better an enum) in the texture to set the information that it's a compressed texture. And that should then be passed to the driver (and vendors all bought the patent license to my knowledge and can the legally decompress it on the card).

[serengeor]

Fabulous, its in the config header I suppose?

I´ve noticed the dds files can be 400% larger than PNG, so is there a big benefit using them?

Probably there is:

Direct3D implements the DDS file format for storing uncompressed or compressed (DXTn) textures. The file format implements several slightly different types (DXT1, DXT2, DXT3, DX4, DXT) designed for storing different types of data, and supports single layer textures, textures with mipmaps, cube maps, volume maps and texture arrays (in Direct3D 10/11).

(Quote from: http://msdn.microsoft.com/en-us/library ... le_Layout1 )

[CuteAlien]

@serengeor: Yes, there is - if that would be supported. But as I just wrote that isn't the case so far, so he get's nothing of that stuff. Also I'm pretty certain it was supported by directx before dx10.

[AReichl]

Mein letzter Stand war, daß sich Apple und HTC "gekloppt" hatten und als Ergebnis das ganze Patent hinfällig geworden war. Was das konkret bedeutet, habe ich aber noch nicht herausbekommen.

AUßERDEM macht es einen Unterschied, ob man die Textur auf der Harware entpacken läßt ( kein Patent-Problem ) oder durch den Softwarealgorithmus ( Problem ).

[AReichl]

soorry - in english now:

To my knowledge Apple and HTC had a "dispute" and as a result the patent is obsolete. But i didn't yet found out what it means in detail.

And CuteAlien is right - if decompressed on the hardware, then there are no legal problems.