Page 2 of 3
Posted: Thu Mar 13, 2008 1:09 pm
by Spintz
^^^ Exactly why I didn't want to answer.
Posted: Thu Mar 13, 2008 1:14 pm
by Spintz
hybrid wrote: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 :

Posted: Thu Mar 13, 2008 1:15 pm
by 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
Posted: Thu Mar 13, 2008 4:50 pm
by 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.
Posted: Thu Mar 13, 2008 5:10 pm
by vvv
Spintz wrote: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.
Posted: Thu Mar 13, 2008 10:48 pm
by hybrid
Spintz wrote:Are you serisouly suggesting this :

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).
Re: DDS Support
Posted: Thu Jan 03, 2013 7:07 pm
by 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?...
Re: DDS Support
Posted: Thu Jan 03, 2013 7:13 pm
by 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).
Re: DDS Support
Posted: Thu Jan 03, 2013 9:01 pm
by hybrid
You can also just enable the DDS support in Irrlicht and load the DDS textures.
Re: DDS Support
Posted: Thu Jan 03, 2013 10:24 pm
by 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?
Re: DDS Support
Posted: Thu Jan 03, 2013 10:45 pm
by 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).
Re: DDS Support
Posted: Thu Jan 03, 2013 11:30 pm
by serengeor
robmar wrote: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 )
Re: DDS Support
Posted: Thu Jan 03, 2013 11:53 pm
by 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.
Re: DDS Support
Posted: Fri Jan 18, 2013 4:14 pm
by 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 ).
Re: DDS Support
Posted: Fri Jan 18, 2013 4:28 pm
by 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.