truth and lie about purebasic

[Ralf]

dear fred.
i like the idea behind your nice purebasic lanuage but please remove following marketing texts from your website, because its a lie and not truth!

text from website:
External libraries are fully written in hand optimized assembler for maximum speed and compactness

following libs of the windows version are coded in pure C and not in ASM!

2ddrawing
audiocd
clipboard
console
date
desktop
file
filesystem
font
gadget
help
image
imagedecoder
joystick
keyboard
math
memory
menu
misc2
module
mouse
movie
multimediabase
network
packer
preference
printer
requester
simplelist
sound
soundplugin
sprite
sprite3d
stringextension
thread
window

text from website:
All BASIC keywords are supported

this is not true! where are basic keywords like

Pi()
returns the value of Pi

Sgn (number)
returns the sign of the number argument.

Mod
returns the amount by which a number exceeds the largest integer multiple of the divisor that is not greater than that number.

ASin (number)
returns the smallest angle (in degrees) satisfying the arc sine (inverse sine) of the supplied argument.

ACos (number)
returns the smallest angle (in degrees) satisfying the arc cosine (inverse cosine) of the supplied argument.

ATan (float)
returns the angle from the X axis to a point (y,x).

ATan2 (xvalue,yvalue)
returns the angle from the X axis to a point (y,x).

Exp (number)
Returns the base of the natural system of logarithms e, raised to the power of the supplied argument.

Shl repetitions
performs binary shift left.

Shr repetitions
performs binary shift right.

Very fast compiler which creates highly optimized executables

take a look to the german forum! there are a lot of discussion about the speed of programs created with v4! programs are running with v4 up to 10 times slower as compiled with 3.94!

text from website:
Easy but very fast 2D game support trough dedicated libraries (DirectX, SDL, ...)

SDL support? it is not included to the purebasic package! since v4 people have the possibilty to select between DX7 and OGL subsystems. 2d drawings are not really fast and it can be done faster! an user lib with very fast plot and point routines has been released to replace the very slow inbuild drawing functions! why do not support DX9?

text from website:
Easy and high quality 3D support based on OGRE
quote]

orge may be a nice 3d engine but its not the same as creating easy high quality 3d stuff like in other game/basic dialects for example darkbasic or blitzbasic! no overloaded engine DLL required!

text from website:
Optimal use of the available hardware by using highly optimized (assembly) commands

support DX9+ for optimal hardware use! highly optimized (assembly) commands is a lie!

Source code is portable between AmigaOS, Windows, MacOS X and Linux, for games and applications

AmigaOS is a death project and you have stopped the delevloping years ago! just remove this please as you cant port any small app or game to amiga. afaik porting big and complex programs to MacOS and Linux is only possible with modifying some parts in the code.



purebasic has a nice concept and please looking forward and you will be a star in some years! Sorry for some critical aspects but now we talked about it

[DarkDragon]

Shl Shr: << >>
Mod: %

ATan works fine here
ASin works fine here
ACos works fine here

[thefool]

First of all, Basic Keywords are NOT those you posted. THESE are basic keywords:

Break : Continue
For : Next
ForEach : Next
Gosub : Return
If : Else : EndIf
Repeat : Until
Select : EndSelect
While: Wend

as well as Goto, End and others.

Very fast compiler which creates highly optimized executables

Compare to other languages..

Code: Select all

time1=GetTickCount_()
a=99
For i=1 To 9999999
a=a+1
Next i
time2=GetTickCount_()

MessageRequester("",Str(time2-time1))

I know the above is not a real stress test, but if you run without debugger 4.0 is actually faster.
WITH debugger, 4.0 is a bit slower. WHY? Because it got more checks

About 3d needs an "overblown" dll; The dll is in fact quite small compared to exe's produced by Blitz 3D and so on..


SDL, isnt that for linux? PB Linux uses SDL where pb for windows does not. Logical, isnt it?

[Kale]

orge may be a nice 3d engine but its not the same as creating easy high quality 3d stuff like in other game/basic dialects for example darkbasic

Now that is a lie! 'Quality' is not something i would use to describe Darkbasic!

[Dare2]

Regardless of how it was made, a valid point is made, not so?

PureBasic does not need to be misrepresented or to gain a reputation for misrepresentation, and if there are errors on the site due to legacy, changes of direction, whatever, they should be removed.

[Thomas]

following libs of the windows version are coded in pure C and not in ASM!

Where's the proof for that? And some snippets of 10x slower code. PB was never meant to be another DB or BB. Implementing DirectX 9 commands like those in DarkBasic Pro needs lots of time and manpower. And do you use them? I own DarkBasic Pro and I have to admit I never used those fancy graphics commands because arithmetic is just too slow.

And I'm sure Fred will optimize PB even more for future versions. But one thing hopefully stays true for all versions: PB will never be a bloated dialect with thousands of commands nobody really needs.

For professional looking games you do not use build-in graphic commands but license / write your own engine. OGRE is a good and fast way to learn how basic 3D programming works.

So your criticism is welcome but it seems to be just a shot in the wild. My main complain is that Fred wastes a lot of time developing PB for Linux and OS X but only a minority is really using these OS's. He'd better spend this time working on the Windows version but this is just my personal opinion.

P.S. Did you ever do your own benchmarks for your special programming needs? I did this with arithmetic and arrays. PB was the fastest besides optimized C and assembler.

We are waiting for evidence of your complains.

[Dare2]

I just took a very quick look at the front page.

Only thing on that page that could be out and out wrong is the SDL reference?

Everything else seem either correct or, at worst, a matter of opinion.




Mind you, it might pay to drop the AmigaOs/cross-platform reference as well.

[thefool]

Only thing on that page that could be out and out wrong is the SDL reference?

If you would stop minding your own buissness and used your head a little, you might notice that SDL is for linux only. Why use it under windows when you have dx?

SDL works under linux.

[Fred]

Ralf: you're right about assembly libs, most of them are now in C, as we consider to do a 64 bits version in a near future, and it would be silly to keep all that in asm, as the x86-64 asm isn't the same anymore. Actually only a very few libs are still in x86 assembly. The web page will be changed when v4 will be release to reflect all the changes.

Your other points aren't valids IMHO:

- the compiler is quite fast (at least here). The x10 slowdown is very strange, and i like to have more infos about it, it's probably a bug. If it's a v4 only issue, try to replace the fasm.exe and polink.exe from the one found in the v3.94 package to see if it affects something. Disable all antivirus/firewall or other protections programs

- SDL isn't a lie, it is used on linux (there is no precision about it). Having it on Windows wouldn't bring anything fancy, except extra depencies. The plot support in DX mode is very fast, other 2D functions actually rely on the Windows API.

- You can't compare OGRE with other engines like blitz3d or darkbasic, its features are clearly beyond them. Check the official site and the commercial games release lately to be sure of that (Ankh, Pacific storm, ..). The fact is the PB implementation is somewhat limited, but it doesn't means it's not an high quality 3D engine. The v4 brings some new interesting features tough.

- For the sprite engine, using DX9 won't bring anything new (some hardware will be even slower) against DX7. I suspect the current DX7 drivers to internally fallback to DX9 functions when it's available. Anyway, it will be done in a near future.

- Well, i like the AmigaOS, and i will keep that. Tough a note will be added than source code won't be compatiable seems fair.

It's a good post, we didn't touched the web page text since a while and seems like it needs some update .

[Dare2]

Only thing on that page that could be out and out wrong is the SDL reference?

If you would stop minding your own buissness and used your head a little, you might notice that SDL is for linux only. Why use it under windows when you have dx?

SDL works under linux.

We're still friends, then?

[thefool]

hehe
Sorry got a bit upset there..

[Sebe]

The fact is the PB implementation is somewhat limited, but it doesn't means it's not an high quality 3D engine. The v4 brings some new interesting features tough.

Btw: what's with the BSP support?

[Thomas]

The plot support in DX mode is very fast, other 2D functions actually rely on the Windows API.

Sure it is.

Code: Select all

OpenWindow(0,0,0,GetSystemMetrics_(0),GetSystemMetrics_(1),#PB_Window_BorderLess,"")
ti=GetTickCount_()
StartDrawing(WindowOutput(0))
For y=0 To GetSystemMetrics_(1)
  For x=0 To GetSystemMetrics_(0)
    Plot(x,y)
  Next
Next
StopDrawing()
ti=GetTickCount_()-ti
MessageRequester("Plot Speed","PB needs "+StrF(ti/1000)+" sec for "+Str(GetSystemMetrics_(0)*GetSystemMetrics_(1))+" pixels!")

Ralf: you're right about assembly libs, most of them are now in C, as we consider to do a 64 bits version in a near future, and it would be silly to keep all that in asm, as the x86-64 asm isn't the same anymore.

So you rewrote the libs for the planned 64 bit version? The x86-64 asm is the same as x86-32 asm just some addressing / register enhancements. It's not completely new. The reason might be it's faster to port the libs to other systems like OS X. I'm a bit disappointed about this one.

[Fred]

The x86-64 asm is the same as x86-32 asm just some addressing / register enhancements. It's not completely new.

You should be kidding or didn't look to x86-64 bits assembly code at all. Even the functions call aren't the same anymore (Windows now uses registers instead of the stack to pass functions).

http://www.codegurus.be/codegurus/Progr ... n64_en.htm

Please tell me in which way the code are similars (except the "call MessageBoxA" ).

[Thomas]

You should be kidding or didn't look to x86-64 bits assembly code at all.

I was refering to the asm commands which did not change. The function calls etc. change because of the new address range. Sure there are lots of changes to be made for a 64 bit version but converting asm libs into C libs wasn't cheap either. If you sacrifice speed for portability then you should not blame it on the asm.