PureBasic Forums - English

dagcrack wrote:I agree, you can't do those kind of comparisons.

Of course I can do it
I use two progs which put/moves sprites on screen.
And I compare only the results: FPS and CPU usage (not more).

And here the next version (v0.1a)
[ADD] Mousewheel for DeltaFPS

File:1->OpenGLvsPB_v0.1a.zip

You cant for this reason: on each of this "systems" different things are going on.


If you wanted to do a real benchmark, you'll go with equal code for GL and DX. all by your own, with no third-party libraries (bloat-adders in this case).

Thats why I say "you can't" because its pointless in the current form to do a benchmark.

As for a "user" benchmark, where you want to see whats faster for your program with what you are given (the sprite lib and the ogl context)... Okey then, go on.


But as people keeps comparing DX with OGL, I keep on getting mad!


We'll see with upcoming crossplatform DX builds how good it performs against OGL... I wouldnt, anyway, move to DX unless I have more than a real cause. Yes, I'm all comfy and warm since a long time with OGL, any problems?



As for the real discussion: DarkDragon more likely means that you cant compare "PB" with OpenGL! because its a very -very- stupid comparison, PB is NOT a graphics rendering context, its not at all that. PB's sprite3d lib: It's just wrapping a few DX calls and thats about it. No heros required for that, no mysteries.

It might work better for you, but you wont get crossplatform.

Even if you save 10 or 20fps, you'll still get no crossplatform.
Even if you didnt want crossplatform, you wont ever get it with the current DX version that is being used..!

HA!

There aint much to code about sprites... You just need an eye view matrix, and perform your billboarding calculations... As for each "sprite", graphically talking its just a quad (2 tris). You can already do this on your GPU for saving some of this calculations (if not all of them on some cases)... But still, your comparison is a null to me!

Also: you're using a non power of 2 texture....
If you're going to use your own OGL context, this translates to: you will have to resample the image (most engines does a nearest power of 2 call, then they super-sample the image, the result is a blurry image that might be taking more ram that you ever needed or wanted).

OGL wont do it for you as far as I know.

Also if you're about to make a benchmark... dont use any type of text displaying.. Just run a test for XX seconds with a set amount of objects being displayed, stop it and get to measure the time it took to render an X amount of frames....

The graphical output is totally different from each test, this is no way a valid benchmark.. Anyway I get the same speed results (in your poor fps counter). However it depends a lot on the gpu, if it was optimized for OGL or DX, the drivers mosty, etc.

dagcrack wrote:As for a "user" benchmark, where you want to see whats faster for your program with what you are given (the sprite lib and the ogl context)... Okey then, go on....

I am on it (here)

Yes but as far as your tests are not equal, they are void... At least to my opinion they are!.

By the way, I hope that you're not using gl_begin / gl_end for making up your quads... because as you should know, thats the slowest form of feeding data to OpenGL .

dagcrack wrote:Yes but as far as your tests are not equal, they are void... At least to my opinion they are!.

By the way, I hope that you're not using gl_begin / gl_end for making up your quads... because as you should know, thats the slowest form of feeding data to OpenGL .

Maybe you should write your OpenGL variant and put it here for comparing

I could, in fact its there.. but legally that wouldnt be possible (to share with public).

Just dont forget to make the tests equal.. including the texture filtering methods used... because thats very important in this case. (if you'll be using mipmapping, both tests must use same amount of mip levels, etc).

dagcrack wrote:I agree, you can't do those kind of comparisons.

It's like comparing myself with an asshole, I'll beat you up!.

Woot!!! You agree on me? This can't be dagcrack :roll: .

[EDIT]

DarkDragon more likely means that you cant compare "PB" with OpenGL! because its a very -very- stupid comparison, PB is NOT a graphics rendering context, its not at all that. PB's sprite3d lib: It's just wrapping a few DX calls and thats about it. No heros required for that, no mysteries.

Yes yes, but it's stupid because you don't know what's behind the wrapper: It needs a linkedlist(or stacklist or whatever) which has the identifier of the sprites in it. They can make it a bit slower and I'm sure for every sprite3d there's a check which element is current.

And as you are talking about billboards for 3D Sprites: It's just orthogonal view with quadplanes on it . This Sprite3Ds aren't real 3D with perspective view. And even the z value is just a fake to the textures w(iirc) coords.

The results of this test - as well as information on how both versions got implemented - are of interest to me, so perhaps we can redefine the original challenge to read:

"implement two programs using PB that need to show 'this and that' RESULT, one version using the PB Sprite3D library, the other version using OpenGL"

As others have pointed out above, both systems are very different, so I find it rather amusing to want to enforce implementations that create their ENDRESULT in the same manner.

More interesting would be to free up the programmer from any further constraints, to learn which implementation & rendering platform is the fastest in producing identical endresults.

Let's use the advantages of either platform and see which one wins... I think this is why IceSoft put up this challenge in the first place.

@DarkDragon;

This is gonna sound stupid, but I wasn't aware, or maybe i'm thinking about it differently, that DirectX was native to windows? I've always thought that DirectX was added in and then it exploited the native portions of windows.

@ everyone else;

So which is better then OpenGL or DirectX? Yes, this is a loaded question but I don't see where there is a major difference in the final outcome as both produce the same outcome just differently. Anyway, I did 860 on screen at 80 FPS on an ATI 800 series card.

SFSxOI wrote:So which is better then OpenGL or DirectX?

What's better, a VW Golf or a Porsche 911?
Pizza or Steak?
Roses or orchids?
Girls or boys?
...

There's no such thing as "better", it always depends on your needs, liking,
given hardware support, etc....

* buys popcorn, pulls up a chair and settles in to watch the shootout *

Well, yeah....but...i always see these debates regarding OpenGL vs DirectX, with people on both sides claiming that one is 'better' then the other, so everyone can't be wrong and right at the same time as they all obviously see one as 'better' then the other. So your saying that is just all depends on an intangable? If its intangable then how do you produce code or hardware for something that can not be defined? I'm not so sure that some programmer or hardware designer sits down one day and says to the company that pays for everything "I dont have a reason for using OpenGL and I can't define why we need to use it and I can't explain to you why we need to use it and its just my personal preference and I can't tell you a reason why we need to hire an OpenGL programmer when we have DirectX programmers galore...but please give me the money for this multi-million dollar project". OK so it depends on likes and dislikes then.

Hmmm, OK, good enough i guess, i'm out.

(@Dare2 - while your getting the popcorn, get me a coke and some juju b's)

traumatic wrote:

SFSxOI wrote:So which is better then OpenGL or DirectX?

What's better, a VW Golf or a Porsche 911?
Pizza or Steak?
Roses or orchids?
Girls or boys?
...

There's no such thing as "better", it always depends on your needs, liking,
given hardware support, etc....

SFSxOI wrote:[...] If its intangable [...]

I didn't say it's intangible, it's just a pointless discussion.

There're pros and cons on both sides - that's it.
Both are rendering pipelines (well, ok, DX is more than just that - I'm
presuming we're talking about Direct3D - anything else would make even
less sense), both will help you get the job done.

One is available on several OS, the other isn't.
One is plain C, one is based on COM.

Which approach do you like more?

This topic must have been discussed about a zillion (+/- 10.000) times all
across the internet, believe me, there's no conclusion about any pipeline
being the "better".

Some examples, just for the sake of completeness:

Need cross platform support?
Use OpenGL

Using DInput and DSound already?
Use Direct3D

Target market use professional GFX cards?
Use OpenGL

Don't like MS?
Use OpenGL

Like the concept of vertex buffers more than display lists?
Use Direct3D

etc. etc. etc.

Really, no need to get popcorn.

SFSxOI wrote:get me a coke and some juju b's

* Passes the coke and juju b's. *

PB's Sprite3D doesn't have to be DX. You can use, subsystem: opengl.