Purebasic x64 - A beginners guide for Powerbasic Users.

[Pierre Bellisle]

Theo,

I'm interested to explore the 64 bits world and I see that PureBasic is very interesting.

- Win 64 bit compiler
- Win 32 bit compiler
- Linux compiler
- Mac OS X compiler
- (Amiga compiler)

- Modern IDE editor
- Form designer included (Free PureForm form designer and PureVision form designer if needed at $27.95)
- Easy to use other editor like UltraEdit

- Windows and Console in same package

- Exe creation with no runtime
- DLL creation
- Services creation
- Lots and lots of Librarys are available
- Unicode OK

- Windows Api direct call
- Inline asm

- Great forum with great people (French-Deutsch-English)
- Current information about whats is in developpement is avaiable
- Downloadable beta release

- More than competitive price: €79.00  (USD$108.00) including all update for life.
- Should be easy to convert code I have.

Up to now, did you find any major inconvenient or had any serious deception using it ?

Pierre

[Theo Gottwald]

Pierre, there are more advantages, for example "code building".
The PureBasic IDE supports to build many versions automatically in one step.

From the "compiler construction", PureBasic does not have the perfection from PowerBasic in my personal opinion.
As a result "GOSUB" will not compile into a simple CALL like in PowerBasic.
The String processing is in my opinion not so easy like in PowerBasic.

On the other side, the way PureBasic as a compiler is done, has the advantage, that it supports multiple Platforms.
Even in one Build-Run.

From the x64 alternatives shown here, I would recommend you to take a look on Peles C, if you like the C-Coding style.
And PureBasic if you just don't like C.

To me PureBasic code looks more like C, compared with PowerBasic.
Thats my major reason why i do only use it if i need it.

While coding style is a subjective issue.

These are the two points:
- code style
- compiler architecture

Besides that i can recommend it from my standpoint.

[Edwin Knoppert]

1) Form engine/behaviour sucks completely, for example you address controls on a form by setting the form current (it lacks the hWnd CtrlID logic, i may have missed the point here but i could not make head or tail of this kind of logic).
2) The PureBasic community is big but nearly all hobbyists, reflects directly on #3
3) Huge amount of static link libraries but an important one to you may get abandon'd and it happens that no code is available, using those without source reflects the hobby status imo.

To be clear:
1) The basis of the compiler is that good that i could use it to make my own form engine which appropriate but it can not be shared since no one uses it of course.
2) There are a few very good programmers over there, but they tend to lack professionalism, bit difficult to explain but i left the board due to lack of 'sense' for this.
3) You can't say the developers of PureBasic are lazy, they often bring a new release.
4) License, couldn't be better, it's for life(!)

Personally..? i dislike the language but that's not really relevant but don't expect ordinary BASIC.

[Theo Gottwald]

Yes, I would also agree to that.
The overall "discussion culture" in the PB Forums and also here in "Jose's Forum" is better then in the PureBasic Forums.
I believe that it has to do with the fact that anybody has to give a real name here but not there.

[Patrice Terrier]

I agree with Edwin,

The PureBasic community is mostly hobbyist programmers, no way for a third party addons provider to make a living from it.

Look at their screenshots, and compare this with WinDev applications, and look at the name of the companies using WD, then you will see what professionnal means.

See the testimonials here

now try to find testimonials for PureBasic.

...

[Aslan Babakhanov]

PureBasic is good, but not the best. it's syntax is weird. really weird.
Look at variable/data decalaration (GLOBAL x.l etc...) or absence of SUB MAIN (and other stuff) - they're coming from FASM.

Do not forget that PureBasic is translator (from Pure dialect to Fasm), but not the compiler.
That explaining how small "compiler" may support different OS platforms.

[Theo Gottwald]

You are right Aslan. But as long as there is no PB x64 available, we will take any fish that swims around  .
Besides that the surrounding of Purebasic has its advantages. The build process and auto-versioning for example is very  complete.

[Aslan Babakhanov]

PureBasic' Compiler Options is complete for BASIC compiler. It's really nice.
Couple of weeks ago I had a project for MacOS.
Started to look at different solutions and found that PureBasic is one that can apply to my project.
Tons of features, but lacks with little, but good things that PowerBasic have in its garage. Say, i was unable to produce correct unicode dialog under MacOS X10.4 using standard features. No way to use CHR(&h0234) or CHR(&H02) + CHR(&H34). Only strange workarounds.
 
Pure's form designer doesn't exist under Mac!
So, you have to code dialogs without designer and in addition the autocomplete mechanism is annoying and doesn't complete the commands properly with keyboard - only with mouse.

Good thing, that you can call any COCOA/XCODE functions, therefore importing of Objective C codes is possible with medium transformation.

[Theo Gottwald]

Purebasic 5.20 .... just need it for x64.

17th Sept. 2013


PureBasic 5.20 (all OS)

- Added: Module support for the compiler
- Added: Runtime library
- Added: Dialog library
- Added: GTK3 subsystem for Linux
- Added: DirectX11 subsystem for Windows (doesn't not support the 3D engine for now)
- Added: Named enumeration support to allow continuing a previous enumeration
- Added: JoystickName(), JoystickZ()
- Added: Optional #PB_Relative flag to JoystickX/Y/Z() to have more precise values
- Added: Optional pad number to JoystickX/Y/Z() to handle more complex gamepads
- Added: ZoomSprite() now accepts #PB_Default as Width/Height to reset to initial sprite size
- Added: 'Color' and 'Intensity' parameter to DisplayTransparentSprite()
- Added: ClipSprite() now support #PB_Default for individual parameter
- Added: #PB_Sprite_PixelCollision flag to CreateSprite(), LoadSprite() to enable pixel collision
- Added: Zoom support to SpritePixelCollision() and SpriteCollision()
- Added: OpenGL support for SpriteBlending() (warning, it just wraps OpenGL mode, so it can behave different than DirectX)
- Added: 32-bit support for SpriteOutput() for DX and OpenGL
- Added: #PB_EventType_Focus and #PB_EventType_LostFocus support to EditorGadget()
- Added: #PB_EventType_RightClick support to ListViewGadget()
- Added: #PB_EventType_Change support to PanelGadget() and DateGadget()
- Added: #PB_Prototype and #PB_Module support to Defined()
- Added: All Init() functions can be called more than once without issue (like InitSound(), InitNetwork() etc.)
- Added: #PB_FileSystem_Force support to DeleteFile()
- Added: #PB_FileSystem_NoExtension support to GetFilePart()
- Added: Back color parameter to CreateImage()
- Added: #PB_Entity_NbSubEntities to GetEntityAttribute()
- Added: MeshIndexCount(), SetRenderQueue(), FetchEntityMaterial(), GetMeshData(), SetMeshData()
- Added: CPUName(), Un/BindEvent(), Un/BindGadgetEvent(), Un/BindMenuEvent()
- Added: Previous location is displayed when declaring a structure, interface, prototype or procedure twice.
- Added: 2 license files to easy add the needed information when shipping PB programs (see reference documentation)
- Added: Bool() is now evaluated at compile time if the whole expression is constant
- Added: Debugger check for SortStructuredList() and SortList() to ensure the specified list is of correct type
- Added: Linux executables created on new distribution should still work on old linux.
- Added: #PB_EventType_FirstCustomValue for use with PostEvent()
- Added: CameraFollow(), ExamineWorldCollisions(), NextWorldCollision(), FirstWorldCollisionEntity(), SecondWorldCollisionEntity()
- Added: WorldCollisionContact(), WorldCollisionNormal(), WorldCollisionAppliedImpulse()
- Added: BuildMeshTangents(), MeshVertexTangent(), CopyTexture()
- Added: Pitch(), Roll(), Yaw()
- Added: #PB_Gadget_RequiredSize support for GadgetWidth/Height()
- Added: #PB_Entity_LinearSleeping, #PB_Entity_AngularSleeping, #PB_Entity_DeactivationTime, #PB_Entity_IsActive,
- Added: #PB_Entity_AngularVelocityX/Y/Z, #PB_Entity_ScaleX/Y/Z, #PB_Entity_AngularVelocity, #PB_Entity_HasContactResponse for Get/SetEntityAttribute()

- Optimized: Pixel sprite collision routines are now much faster with DirectX
- Optimized: More peephole optimizations on x64 assembler output
- Optimized: Faster compilation for big programs
- Optimized: Linux build server have been upgraded, now using a better GCC which produce better code.

- Changed: SpinGadget() EventType are now #PB_EventType_Up and #PB_EventType_Down instead of -1 and 1.
- Changed: renamed ZoomSprite3D() to ZoomSprite()
- Changed: renamed TransformSprite3D() to TransformSprite()
- Changed: renamed RotateSprite3D() to RotateSprite()
- Changed: renamed Sprite3DQuality() to SpriteQuality()
- Changed: renamed Sprite3DBlending() to SpriteBlending()
- Changed: renamed the whole 'Module' library to 'Music'
- Changed: renamed Frame3DGadget() to FrameGadget()
- Changed: renamed Frame3DGadget3D() to FrameGadget3D()
- Changed: renamed #PB_Shortcut_Prior to #PB_Shortcut_PageUp and #PB_Shortcut_Next to #PB_Shortcut_PageDown
- Changed: Packer plugin constant renamed to #PB_PackerPlugin_XXX
- Changed: RayCollide() now returns the colliding #Entity.

- Updated: WebGadget() on Windows doesn't needs ATL.dll anymore
- Updated: zlib to 1.2.8
- Updated: pqlib (PostgreSQL) to 9.2.4
- Updated: ziplib to 0.11.1
- Updated: SCNotification scintilla structure

- Removed: Mozilla ActiveX support for WebGadget() on Windows as the last ActiveX version is way too old (2005)
- Removed: Sprite3D library (merged with regular sprite library)
- Removed: Palette library (outdated)
- Removed: RenderMovieFrame() and #PB_Movie_Rendered (outdated)
- Removed: DisplayTranslucentSprite() -> replaced with 'Alpha' parameter for DisplayTransparentSprite()
- Removed: DisplaySolidSprite() -> replaced with 'Color' parameter for DisplayTransparentSprite()
- Removed: DisplayRGBFilter() -> can be replaced with a zoomed sprite with color
- Removed: DisplayShadowSprite() -> can be replaced with DisplayTransparentSprite() with color
- Removed: StartSpecialFX(), StopSpecialFX(), DisplayAlphaSprite(), ChangeAlphaIntensity(), UseBuffer()
- Removed: Carbon subsystem on OS X, it was too old be used with new libs

- Fixed: Many bugs

Commercial GUI Enhancement: Pro-GUI for PureBasic
Real Source
Pure-Area - lots of code snippets

[Edwin Knoppert]

PureBasic' Compiler Options is complete for BASIC compiler. It's really nice.

Note that you can still use the free PBDev tool from my site to get started more easily with purebasic.
Many purebasic fokes don't like it since it generates to much code, go figure..., it's clear that they are hobbyists otherwise they would not compare it based on a few kb.
However once you get the drift you can still move on to plain purebasic code.

[Theo Gottwald]

I am still a bit lost in PureBasic Code, also it does not allow GOSUB in Procedures, which i often use.
On the other side its amazing what they added lately about new features. AND if i need x64 its the thing that is somehow "nearest to Powerbasic"
as i see it.

[Patrice Terrier]

somehow "nearest to Powerbasic"

Yes, tied to one single man, and full of gadgets

[Theo Gottwald]

A lot of "Gadgets" :-). Anyway ... even if Fred wins the Lotto tomorrow, i have a working Purebasic x64 here in my box.
Therefore the "tied to one man" does not look like a problem, as ist not with Powerbasic x32.
The only Problem with PowerBasic is that there is no PBx64. Its not that Bob decided to enter an elevated level.

[Theo Gottwald]

The Blog from Fred shgows interesting aspecrs of developement:

PureBasic Blog

[Theo Gottwald]

The Modules that he has implemented in this PureBasic Version are possibly just those that i asked Bob for, to implement for several Years ...

Another thing i have found today is that PureBasic has nothing like
SELECT CASE AS LONG.
In this case an IF ... ELSEIF ... Construct will be the right choice i guess.

Also a SELECT CASE AS CONST$ ...  is just not available outside PowerBasic.
While i often use them. PureBasic also has no Register Variables.
 
While i have seen other Goodies today that PowerBasic doesn't have.
And the Licence is s o unbeatable that i believe anybody will get one.
It something like a "Lifetime Licence".

That was a very good idea from Fred to make it like that.

However because of a historically wrong decision in the past, PureBasic ist still
- hold your breath - a a "Stack Call based" Single-Pass Compiler.

Thats definitely not state of the art. You need all the declare stuff that was removed from Powerbasic in Version 9. And at this time i do not see any hope they even thing of this is a problem. As a result you can not:
- use GOSUB and RETURN in Procedures
- not allowed to Jump out (Using Gotoi) of a FOR .. NEXT or SELECT CASE etc.
- need to DECLARE Procedures if they are out of order

and they still do not have the fabulouse string engine from Powerbasic.
But who has?