I get the following results
Bmax 0.9319 secs
PB 1.3940 secs
I don't like tests like this, I prefer real world tests with lots of things going on at once.
I think we will be in for some interesting times now that processors are moving over to duel core+
BlitzMax for Windows
I have BMax and PB and use them both (although PB, as someone else mentioned, is a much more complete product).
BM has very poor documentation if you ask me. You will not complain about PB's after you sift through BM's!
BM uses OpenGL to render its graphics. This has the advantage of being easy to implement cross-platform, but has the disadvantage of being slow on some poorly supported systems (The same game may get 300 fps on one system and 10 fps on another with the same processor speed!)
Sound support is very rudimentary at the moment.
BM is modular, and as such needs additional modules to support 3D, GUI, etc internally. Some unofficial modules have been released that support various things like ODE, DirectX, etc. Out of the box, BM is fast and pretty stable, but does not do nearly as much as PB does.
You can do Inline asm with BM...sort of. If it is included as inline in your external c code it will be included. It's a little more work, but has the advantage of allowing all versions to include inline asm, even the mac version (as long as the mac c compiler supports inline asm -- haven't tried this).
BM is "fully" object aware (methods, functions within types, etc). But lack of good documentation can be very frustrating when you're trying to figure out the syntax of how to do certain things. Thank goodness for forums!
Until the GUI module and much better documentation is finished, however, I will consider BM unfinished.
Still looking forward to PB 4.0!
Russell
BM has very poor documentation if you ask me. You will not complain about PB's after you sift through BM's!
BM uses OpenGL to render its graphics. This has the advantage of being easy to implement cross-platform, but has the disadvantage of being slow on some poorly supported systems (The same game may get 300 fps on one system and 10 fps on another with the same processor speed!)
Sound support is very rudimentary at the moment.
BM is modular, and as such needs additional modules to support 3D, GUI, etc internally. Some unofficial modules have been released that support various things like ODE, DirectX, etc. Out of the box, BM is fast and pretty stable, but does not do nearly as much as PB does.
You can do Inline asm with BM...sort of. If it is included as inline in your external c code it will be included. It's a little more work, but has the advantage of allowing all versions to include inline asm, even the mac version (as long as the mac c compiler supports inline asm -- haven't tried this).
BM is "fully" object aware (methods, functions within types, etc). But lack of good documentation can be very frustrating when you're trying to figure out the syntax of how to do certain things. Thank goodness for forums!
Until the GUI module and much better documentation is finished, however, I will consider BM unfinished.
Still looking forward to PB 4.0!
Russell
*** Diapers and politicians need to be changed...for the same reason! ***
*** Make every vote equal: Abolish the Electoral College ***
*** www.au.org ***
*** Make every vote equal: Abolish the Electoral College ***
*** www.au.org ***
This is more likely a driver problem and not an opengl problem.BM uses OpenGL to render its graphics. This has the advantage of being easy to implement cross-platform, but has the disadvantage of being slow on some poorly supported systems (The same game may get 300 fps on one system and 10 fps on another with the same processor speed!)
As far as I'm concerned one of BM's biggest problems is it does not (and poss will never) support successive array elements, eg, for creating & manipulating VBO's. All work-arounds for this result in a performance hit. Pity.
One problem is that BM is trying to be as cross-platform as possible, while still allowing Mark Sibly (the lead programmer) to update everything as painlessly as possible. This results in some performance hits as you say, because each version is not as 'native' as it could be.
The bit about the OGL drivers is true, but is still a problem because some venders have better support for OGL than others. So even if you have the latest driver for your card that may or may not be a solution to speed problems.
However, I'm pretty sure BM is open enough that a solution can be found in other ways. For example, I'm sure there's a way to get the address of vid memory, etc and do it your own way.
In the meantime, some preliminary dx9 modules have been released.
Russell
The bit about the OGL drivers is true, but is still a problem because some venders have better support for OGL than others. So even if you have the latest driver for your card that may or may not be a solution to speed problems.
However, I'm pretty sure BM is open enough that a solution can be found in other ways. For example, I'm sure there's a way to get the address of vid memory, etc and do it your own way.
In the meantime, some preliminary dx9 modules have been released.
Russell
*** Diapers and politicians need to be changed...for the same reason! ***
*** Make every vote equal: Abolish the Electoral College ***
*** www.au.org ***
*** Make every vote equal: Abolish the Electoral College ***
*** www.au.org ***
Amiga5k, the only way you are going to see such a reduction in fps is if a software renderer is being used. Granted some gfx card/notebook makers do drag their heels with driver updates but performance differences between dx and opengl has never been an issue for me, not least because I never use dx
It just ain't x-platform.
Re bmax's performance and my comment above, it has nothing to do with bm being x-platform. It is because the type of access required does not fit with the way Mark wants bm to handle things (also suspect it's a practical issue because it was never designed-in at the start). It is a very basic (no pun intended) thing to provide structured access to consecutive memory. Regardless, when a point of style/ideals is put before practical needs of the programmer I quickly bow out.

Re bmax's performance and my comment above, it has nothing to do with bm being x-platform. It is because the type of access required does not fit with the way Mark wants bm to handle things (also suspect it's a practical issue because it was never designed-in at the start). It is a very basic (no pun intended) thing to provide structured access to consecutive memory. Regardless, when a point of style/ideals is put before practical needs of the programmer I quickly bow out.
@dmoc: I have not seen this kind of performance hit personally, because my gfx card handles OGL beautifully (on par with dx). However, many people on the Blitz forums have complained about huge differences in performance with different cards/drivers. Don't know what to tell you beyond that, other than I suppose it's possible that some older cards actually use OGL software routines to emulate what the newer ones do in hardware.
As for your second point, unless you have been conversing with Mark directly, I don't think it's fair to say what he has or hasn't done in the implementation of graphics routines in BM. From my experience, Mark has always put speed near (or at) the top of his priority list. Who knows what features and\or speed improvements will be added by Mark in the future?
Currently, all of the demos that come with BM run quite fast on my particular system, so I'm satisfied with it overall (other than the above-mentioned poor documentation, etc).
Russell
As for your second point, unless you have been conversing with Mark directly, I don't think it's fair to say what he has or hasn't done in the implementation of graphics routines in BM. From my experience, Mark has always put speed near (or at) the top of his priority list. Who knows what features and\or speed improvements will be added by Mark in the future?
Currently, all of the demos that come with BM run quite fast on my particular system, so I'm satisfied with it overall (other than the above-mentioned poor documentation, etc).
Russell
*** Diapers and politicians need to be changed...for the same reason! ***
*** Make every vote equal: Abolish the Electoral College ***
*** www.au.org ***
*** Make every vote equal: Abolish the Electoral College ***
*** www.au.org ***
On this specific point, yes.unless you have been conversing with Mark directly
PS: Don't get me wrong, I'm not knocking bm in general and I'm sure it will be perfect for most games and I am impressed with the Irrlich mod someone has done. But I also don't rely too much on demo's as an indication of how a compiler will scale up.
PPS: Wouldn't it be great if Mark and Fred got together and created the ultimate fast and flexible BASIC
