truth and lie about purebasic

[nco2k]

@Thomas
full ack!

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...

well its not a waste, but its slowing down the pb windows version progress, indeed.

@Ralf
purebasic is small, fast and easy to use, thats all truth you need.

c ya,
nco2k

[Psychophanta]

You can't compare OGRE with other engines like blitz3d or darkbasic, its features are clearly beyond them.

I can't understand that. Does it mean OGRE is much more quality?

[Fred]

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.

Actually there is also the amount of time involved to maintain all these asm codes. It already take much more time to maintain an asm source against a C source, and it thinks the gain is minimal, especially with libraries like 'gadget', 'window', 'menu' which spend most thei time (99%) in the function calls. Optimizing the remaining 1% is just silly. Now, imagine with x86 and x86-64 versions. 2 times more time. And what if we want to do a WinCE version ? Rewrite all in ARM assembly ? Or do a C version along the 2 asm versions ? Then, when we fix a bug, we have to patch 3 files ? It's getting silly, we are not a big company and we better focus on code quality and new features. Also think than the code is written in straight C (not C++) which produce very, very good code. I closely examined the output, and there is not a lot of room for most of optimization. When we decided to move the asm codes to C, i wasn't that happy, you can believe me (regarding all the time spend on them). But it is just common sens.

[Nik]

I must admit taht I think Fred is absolutely right in doing the libs in C, he can develop the faster find bugs easier, port them easier and then the 64 bit thing.
About the DirectX7 support I think the issue with LoadWorld() is the most important, I also think that DX9 would be cool because I suspect some opf our Gurus around her to then use their fancy dirctX API tricks within a normal PB Game.
As for the Speed in V4 I think it's absolutely wrong to say that it is slower, the function calls (needed mostly for well structured code) are a lot faster in version 4.0, as prototypes are compared to CallFunctionFast(), arithmetic is still beeing improved I think because there are some servere bugs at the moment which is sad, but I am optimistic that Fred will have fixed them for the final.

[Fred]

On a side note, it doesn't means than all the libs commands will be in C starting from now. If a particular function is really slow and can perform much better in asm, it will worth the work. But it will be more on 'command' basis than on 'library' basis. The new .desc file actually supports asm command inside a C lib, so it will be probably the way to go in the future.

[Fred]

Thomas:

Code: Select all

InitSprite()


Width = GetSystemMetrics_(0)
Height = GetSystemMetrics_(1)

OpenWindow(0,0,0,Width,Height,#PB_Window_BorderLess,"")
OpenWindowedScreen(WindowID(0), 0, 0, Width, Height, 0, 0, 0)

DisableDebugger

ti=GetTickCount_()
StartDrawing(ScreenOutput())
For y=0 To Height-1
  For x=0 To Width-1
    Plot(x,y, 0)
  Next
Next
StopDrawing()
ti=GetTickCount_()-ti

EnableDebugger

FlipBuffers()
MessageRequester("Plot Speed","PB needs "+StrF(ti/1000)+" sec for "+Str(GetSystemMetrics_(0)*GetSystemMetrics_(1))+" pixels!")

DirectX plot means you use a sprite or screen output, and the Plot(x,y,Color) command.

[rsts]

(snip)
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.

Actually, I don't believe any of those were part of Dartmouth Basic, the original Basic, and if we're just talking "basic" in general (e.g. all permutations), there are many keywords that are not supported.

I knew when I saw this post early on, it would generate quite a bit of discussion.

Note to Fred - no need to "defend" PureBasic - go back to working on PB4

cheers

[Thomas]

It already take much more time to maintain an asm source against a C source, and it thinks the gain is minimal, especially with libraries like 'gadget', 'window', 'menu' which spend most thei time (99%) in the function calls. Optimizing the remaining 1% is just silly.

If it's just function calls and similar stuff then you're right. Time critical commands should still be done in handoptimized assembler if there is a substantial gain but most libs are not time critical, agreed. Maybe you should just state "highly optimized libraries" on your homepage.

It's getting silly, we are not a big company and we better focus on code quality and new features.

Good to hear that there will be many new features for the next versions.

About the DirectX7 support I think the issue with LoadWorld() is the most important, I also think that DX9 would be cool because I suspect some opf our Gurus around her to then use their fancy dirctX API tricks within a normal PB Game.

Uhm, what are you guys expecting from build-in DirectX 9 commands? Miracles? The graphics commands of PB are very limited and if they use DX7 or DX9 makes no difference. If you want cool effects you have to directly call the DX functions and that can be done already.

[thefool]

Those are not keywords. FOR is a keyword, REPEAT is a keyword. Do you get it?

[Psychophanta]

"Then" is a keyword

[Thomas]

DirectX plot means you use a sprite or screen output, and the Plot(x,y,Color) command.

Windows: DirectX 7 is used for sprite handling which allows your programs to use hardware acceleration if available.

Linux: SDL (Simple Directmedia Layer) is used to manage the sprites. This allows your programs to use hardware acceleration if available.

MacOS X: OpenGL is used to manage the sprites which allows to use hardware acceleration.

Is there a hint somewhere that without a screen normal drawing without DX is used? Maybe that would reduce confusion. As you can see the plot command is fast as lightning.

[Fred]

Note to Fred - no need to "defend" PureBasic - go back to working on PB4

You're right, but it's always nice to explain why we did such or such choices .

[thefool]

"Then" is a keyword

Okay you got one
That brings us back to the track that purebasic isnt basic


FRED:
I think, to satisfy the basic hungry users you should do this:

REQUIRE line numbers on every line!
REQUIRE the LET keyword when dealing with variables
Make pb slower and only support console!


that would help..

edit:
I forgot that you should make windows api much harder to call to, and get rid of that annying inline assembly

[Fred]

As you can see the plot command is fast as lightning.

True, 0.016 secs here to fill a 1152x864 32 bits screen isn't bad .

[thefool]

As you can see the plot command is fast as lightning.

True, 0.016 secs here to fill a 1152x864 32 bits screen isn't bad .

as a non graphic programmer, may i ask why the screen is gray, and not black, when using the opengl subsystem?