Effects & Algorithms
category: general [glöplog]
Superplek & reed... i'm sorry for my comments......
the only purpose here is not my englich but a little war between OpenGL & DirectX....
Sorry Guys ! :)
the only purpose here is not my englich but a little war between OpenGL & DirectX....
Sorry Guys ! :)
english... sorry...... pffff....... =)
so if i use ogl i'm a loser.
and if i use dx i'm a commie.
hmm... what would i rather be...
loser or commie...
i love useless little nerd fights
like this (my computer is better
than your computer, my os is better
than your os, my api is better
than your api, my dad is stronger
than your dad, my dick is bigger
than your dick, etc, and so forth).
and if i use dx i'm a commie.
hmm... what would i rather be...
loser or commie...
i love useless little nerd fights
like this (my computer is better
than your computer, my os is better
than your os, my api is better
than your api, my dad is stronger
than your dad, my dick is bigger
than your dick, etc, and so forth).
I can't get the opengl init kode below 500bytes or so :(
macaw: then you are doing something wrong :P
dx people: the only argument in favour of dx i heard was "dx rules ogl sucks"... oh not to forget that "opengl is simpler, but directx gives you more flexiblility." which shows that the only person trying for an argument in favour of dx has no clue. (pn triangle support in dx? fences support in dx? quads? fvf have how many 16? possible formats.. if that's the dx idea of flexibility... hrhr.)
btw: "opengl:basic directx:c" at least opengl has no visual basic interface :P And really, since when is HW more transparent in basic than in c? :P
dx people: the only argument in favour of dx i heard was "dx rules ogl sucks"... oh not to forget that "opengl is simpler, but directx gives you more flexiblility." which shows that the only person trying for an argument in favour of dx has no clue. (pn triangle support in dx? fences support in dx? quads? fvf have how many 16? possible formats.. if that's the dx idea of flexibility... hrhr.)
btw: "opengl:basic directx:c" at least opengl has no visual basic interface :P And really, since when is HW more transparent in basic than in c? :P
shiva: d3d support for quads = render 2 triangles. fences = beginscene/endscene, etc
anyway, just use whatever API you want. don't bore me with it. if your demo is cool I couldn't care less what you're using.
and yes, my dick IS bigger.
anyway, just use whatever API you want. don't bore me with it. if your demo is cool I couldn't care less what you're using.
and yes, my dick IS bigger.
stop whining, start coding!
Shiva : Ok, let's try it with some argumentation pro D3D8 at this point. I'm quite sure you've been working with vertex programs und GL excessively, right ? Then you must know that no ARB-standard has been defined yet, that ATI supports the EXT-standard and NVidia has its own NV-standard. What a lovely situation. I have to write the same code at least twice and will have to rewrite it once the ARB-standard is out. Nice. In D3D8, I used the same code for ATI, NV or whatever you want, no problem at all.
I'm getting tired of extension specifications having 200 more pages than the complete OpenGL 1.3 Standard. This might change if GL 2.0 becomes reality, but the situation at the moment just sucks.
I'm quite sure you have access to the newest ATI and NV cards at work, but not everyone has and phone-debugging sucks ass. How can I write fast code for ATI-cards using their specific extensions without access to ATI-adapters ?
I'm getting tired of extension specifications having 200 more pages than the complete OpenGL 1.3 Standard. This might change if GL 2.0 becomes reality, but the situation at the moment just sucks.
I'm quite sure you have access to the newest ATI and NV cards at work, but not everyone has and phone-debugging sucks ass. How can I write fast code for ATI-cards using their specific extensions without access to ATI-adapters ?
"stop whining, start coding!"
Agreed 100%
If you can't honestly decide which is better (DX or OGL), then just make your own API! Then you can really argue.
(/me dons asbestos underwear)
Agreed 100%
If you can't honestly decide which is better (DX or OGL), then just make your own API! Then you can really argue.
(/me dons asbestos underwear)
Now that's an API :
mov ax, 0x13
int 0x10
mov edi, 0xa0000
...
;)
mov ax, 0x13
int 0x10
mov edi, 0xa0000
...
;)
i love brioche <g>.
i dont like french as a language, i prefer dutch because it doesnt have weird looking letters (hi france) nor does it have dots everywhere below and above (hi germany). too bad i dont know anyone who can teach me dutch though..but hey, i found out what TEEF means BY MYSELF!!! $$
OpenGL vs. DirectX....
And i wanted to find some algorithms and coding tricks...
:(
And i wanted to find some algorithms and coding tricks...
:(
I'm coding, there for I exist....
shiva, how about..
- dx is less code (no tons of imports, fewer calls to achieve the same)
- dx is faster (rendering pipeline more suited for todays hardware and less general-purpose)
- dx works on more hardware (Most advanced OpenGL functions, such as multitexturing *cough* are only available via extensions, most of them vendor-specific)
- dx ist MUCH cleaner (extensions again, they just mess up the whole code with gl)
- sidenote: COM is one of the leanest, fastest and easiest to understand/implement component models around, everyone saying something else should either get his dick out of his stuffed penguin or hasn't informed himself (read: has no clue)
- vertex/pixel shaders (which happen to WORK in contrast to ogl vertex program extensions) give much more flexibility, speed and visual quality than glVertex() ever can
shiva, the fact you tried to state for "gl is faster" or "gl is cleaner" really disappoint me. Someone like you should at least have SOME clue about the actual "overhead" of virtual function calls (which is far outweighed by the sheer number of calls needed with opengl). One virtual function call. read. ONE pointer table lookup. That's all your so-called overhead.
And btw, most DX driver routines (apart maybe from d3ddevice8::present) do nothing more than "shove the data into the card", which is far less than all the conversion that has to go on with OpenGL.
Oh, and do I have to mention "Hardware T&L"?
Oh, and do I have to mention "Fast Render2Texture capabilities" ?
Oh, and do I have to mention that vertex shaders work on every card and not only on the few card exposing the right extension?
Oh, and do I have to mention that due to the oh-so-bad lack of extensions, you don't have to code everything three times for different cards?
Oh, and do I have to mention that most 3d cards can't do quads and that they get converted to two triangles or in worse cases a 4-vertex triangle strip anyway?
OpenGL and portability? I laugh. We've come WAY past simple textured shaded triangles, my dear.
Your so-called "facts" may have been valid for DirectX5, but that time has long gone. We're talkling DX8.1 here. Welcome to the real world.
- dx is less code (no tons of imports, fewer calls to achieve the same)
- dx is faster (rendering pipeline more suited for todays hardware and less general-purpose)
- dx works on more hardware (Most advanced OpenGL functions, such as multitexturing *cough* are only available via extensions, most of them vendor-specific)
- dx ist MUCH cleaner (extensions again, they just mess up the whole code with gl)
- sidenote: COM is one of the leanest, fastest and easiest to understand/implement component models around, everyone saying something else should either get his dick out of his stuffed penguin or hasn't informed himself (read: has no clue)
- vertex/pixel shaders (which happen to WORK in contrast to ogl vertex program extensions) give much more flexibility, speed and visual quality than glVertex() ever can
shiva, the fact you tried to state for "gl is faster" or "gl is cleaner" really disappoint me. Someone like you should at least have SOME clue about the actual "overhead" of virtual function calls (which is far outweighed by the sheer number of calls needed with opengl). One virtual function call. read. ONE pointer table lookup. That's all your so-called overhead.
And btw, most DX driver routines (apart maybe from d3ddevice8::present) do nothing more than "shove the data into the card", which is far less than all the conversion that has to go on with OpenGL.
Oh, and do I have to mention "Hardware T&L"?
Oh, and do I have to mention "Fast Render2Texture capabilities" ?
Oh, and do I have to mention that vertex shaders work on every card and not only on the few card exposing the right extension?
Oh, and do I have to mention that due to the oh-so-bad lack of extensions, you don't have to code everything three times for different cards?
Oh, and do I have to mention that most 3d cards can't do quads and that they get converted to two triangles or in worse cases a 4-vertex triangle strip anyway?
OpenGL and portability? I laugh. We've come WAY past simple textured shaded triangles, my dear.
Your so-called "facts" may have been valid for DirectX5, but that time has long gone. We're talkling DX8.1 here. Welcome to the real world.
And did i mention that being bored rocks sometimes? :)
yay, kebby!
- fewer calls? you show me :) ever even heard of doing glDrawElements? [a gl 1.2 feature, for those who still think gl is all about glVertex.. Which is, including VertexArrayRange and Fences extension much much more felxible than any dumb dx vertexbuffer]
The point is, with GL you can choose to have very-simple-very-slow (glVertex) vertex transfers, dx-comparable performance (glDrawElements) or high end, dx suck my dick performance (vertex array range and fences)
- "dx is faster" - NOT!: i really timed some very simple renderings (simple particle systems) gl 1.2 vs. directx 8 (unextended gl, even!) and gl has clearly a ~10% speed advantage. now scale that to complex 3d where you have a bit more state/buffer changes :)
- COM might be a good "component model", but who said such advanced component models are good for everything? :) (read 3D API)
- well, our gl vertex pixel shaders work just perfectly. besides there ARE different vertex program versions in dx, too. it's just you are closer to HW with GL there.
- at least nvidia cards ( read 90% market ) do quads in hw.
still i have to see any card doing the laughable dx point sprites in hw.
anyway, i am bored at the office, too, sometimes :)
- fewer calls? you show me :) ever even heard of doing glDrawElements? [a gl 1.2 feature, for those who still think gl is all about glVertex.. Which is, including VertexArrayRange and Fences extension much much more felxible than any dumb dx vertexbuffer]
The point is, with GL you can choose to have very-simple-very-slow (glVertex) vertex transfers, dx-comparable performance (glDrawElements) or high end, dx suck my dick performance (vertex array range and fences)
- "dx is faster" - NOT!: i really timed some very simple renderings (simple particle systems) gl 1.2 vs. directx 8 (unextended gl, even!) and gl has clearly a ~10% speed advantage. now scale that to complex 3d where you have a bit more state/buffer changes :)
- COM might be a good "component model", but who said such advanced component models are good for everything? :) (read 3D API)
- well, our gl vertex pixel shaders work just perfectly. besides there ARE different vertex program versions in dx, too. it's just you are closer to HW with GL there.
- at least nvidia cards ( read 90% market ) do quads in hw.
still i have to see any card doing the laughable dx point sprites in hw.
anyway, i am bored at the office, too, sometimes :)
blah, i've tried BOTH apis, so some more facts:
- i've NEVER seen opengl outperform well-written d3d or well-written d3d outperform opengl. at least not on my machine. which MAY BE caused by the fact that the bus is a lot more of a problem than your choice of api.
- i don't trust anyone who said "i like gl, AND i timed gl against d3d, and guess what, gl won". if you're more into gl, chances are 99% you won't use d3d as optimal, and vice versa.
- you don't need ADVANCED component stuff for 3d apis, and d3d doesn't use any of the advanced features of COM; what it uses is the language independent object model and ref counting for objects, plus encapsulation in classes that actually make sense, so WHAT?
- there are different vertex program versions in dx, but they are all backwards compatible, and how much you really benefit from the past-1.1 (which is gf3/dx8) vertexshaders is arguable; again, so what.
- radeon8500, geforce3 and the NV2A present in xbox DO point sprites in HW, and they're imho not laughable, but a simple memory/bus bandwidth optimization that MAKES SENSE (16-20 bytes for typical pointsprite FVF vs atleast 20x4=80 bytes for the 4 vertices you need for the equivalent quad, that is 75% bandwith savings, i.e. a serious improvement)
other facts touched in this threadd:
- FVFs are just some flags which you can combine like you want (the only thing that's fixed is the ordering of the fields in the resulting struct, which makes sense)
- Since DX8, you can also use completely freeform vertex formats with the fixed function pipeline
- Hardware T&L is completely supported in both apis
- Multitexturing etc extensions are ARB, unless you want to use some vendor-specific stuff, chances are high what you want is standard.
- For any well-written app, portability will never be the issue, whether you use D3D or OGL is totally irrelevant; when more than 5-15% of your code is full of D3D/OGL calls, you should SERIOUSLY reconsider a better design, since any app that has system or library calls spilled across the whole source will be a hell to port no matter if you use d3d or ogl
now start collecting REAL arguments, please
- i've NEVER seen opengl outperform well-written d3d or well-written d3d outperform opengl. at least not on my machine. which MAY BE caused by the fact that the bus is a lot more of a problem than your choice of api.
- i don't trust anyone who said "i like gl, AND i timed gl against d3d, and guess what, gl won". if you're more into gl, chances are 99% you won't use d3d as optimal, and vice versa.
- you don't need ADVANCED component stuff for 3d apis, and d3d doesn't use any of the advanced features of COM; what it uses is the language independent object model and ref counting for objects, plus encapsulation in classes that actually make sense, so WHAT?
- there are different vertex program versions in dx, but they are all backwards compatible, and how much you really benefit from the past-1.1 (which is gf3/dx8) vertexshaders is arguable; again, so what.
- radeon8500, geforce3 and the NV2A present in xbox DO point sprites in HW, and they're imho not laughable, but a simple memory/bus bandwidth optimization that MAKES SENSE (16-20 bytes for typical pointsprite FVF vs atleast 20x4=80 bytes for the 4 vertices you need for the equivalent quad, that is 75% bandwith savings, i.e. a serious improvement)
other facts touched in this threadd:
- FVFs are just some flags which you can combine like you want (the only thing that's fixed is the ordering of the fields in the resulting struct, which makes sense)
- Since DX8, you can also use completely freeform vertex formats with the fixed function pipeline
- Hardware T&L is completely supported in both apis
- Multitexturing etc extensions are ARB, unless you want to use some vendor-specific stuff, chances are high what you want is standard.
- For any well-written app, portability will never be the issue, whether you use D3D or OGL is totally irrelevant; when more than 5-15% of your code is full of D3D/OGL calls, you should SERIOUSLY reconsider a better design, since any app that has system or library calls spilled across the whole source will be a hell to port no matter if you use d3d or ogl
now start collecting REAL arguments, please
glDisable( GL_USELESS_THREAD );
MessageBox( NULL, "500 glops to SuperPlek :)", "Blah", MB_OK );
PostQuitMessage( 0 );
MessageBox( NULL, "500 glops to SuperPlek :)", "Blah", MB_OK );
PostQuitMessage( 0 );
ryg, everything you have got to spoil.
kb
*goes whining*
kb
*goes whining*
yes i've started a nice discussion after all :)
why i got the feeling that whatever microsoft wants (no matter how poor it is) it always achieves it?
anyway, if loadrunner wants to start with opengl, go on searching (un)official ogl sites/discussion boards(yeah like this one:))/e-magazines/take part in demoparties/talk with experienced programmers and/or sceners/... whatsoever and once you'll know you got through yourself
[and it's the end of this story :)]
anyway, if loadrunner wants to start with opengl, go on searching (un)official ogl sites/discussion boards(yeah like this one:))/e-magazines/take part in demoparties/talk with experienced programmers and/or sceners/... whatsoever and once you'll know you got through yourself
[and it's the end of this story :)]
yeah, ofcourse all d3d users are brainwashed by ms.
this is always the last and most laughable argument in those flamewars.
1. get
2. a
3. life
this is always the last and most laughable argument in those flamewars.
1. get
2. a
3. life
hums about that extensions shit.. there are extensions in d3d aswell, however since the api is so good designed noone ever as far as i know even bothered making any real extensions.. since its all done better "inside" :)
most interesting stuff happens way before pushing your polygons into some api. i guess most of the people here aren't doing interesting stuff, since all you can do is talk about api's.