Interactive PowerBasic Forum

Normally I'd not look around and just do everything in Powerbasic.
Coming to a project where i need a x64 executable and DLL, I had no other choice then to look around.

I could have choosen for example "Pele's C" - its freeware and people like it. Anyway, personally I do not like C and all this stuff, this time I decided to stay with Basic.

So I remembered that I have a Purebasic licence for long time (since 30.01.2001).
Just never used it really, because I had PowerBasic.

So this time I had to go through this and learn "BASIC from New" to be able to make also x64 excutables and DLL's.

So i updated for the actual Version which is 4.31 and checked - yes there is also a Version of Purebasic x64 included in the Package. And its still the same licence which i bought 2001.

So the first Point goes to Purebasic. Purebasic is really a cheap thing, seeing that for the same licence, you never need to pay for Updates and you even get a basic Visual Designer included in the package.

Fine, so having no choice, I started to take a deeper look. The first days I was lost as a Powerbasic-Fan because the Syntax is quite different. But lets start with the Purebasic-Basics.

The first thing to know is that you have to install the PureBasic 4.31 x64 on a 64 bit OS.
You can't simply compile a x64 executable on a 32-bit OS. You may be able to do so with Visual Studio, but not with Purebasic.

The next thing to know is that the compatibility between the Purebasic x32 and the Purebasic x64 is suprisingly good.
Assume you have the PureBasic x64 in a Virtual Box installed under a X64 OS.
Then you just drag the code-files there - compile it new - and voila its now an x64  - DLL or executable.

One thing to watch for when transfering code from x32 to x64 are Pointers into memory:
The LONG-Datatype will stay as 32 bit when you just copy the code. This may crash on a 64 bit OS, because Memory needs 64 bit for adressing. Therefore better use the Purebasic INTEGER Datatype. This one will automatically change from 32 to 64 bit dependent on where you compile it. So using Pointers, you need to use the INTEGER Datatype. As a Powerbasic user, don't intermix with the INTEGER from Powerbasic which is a signed 16 bit Datatype.

So we come to the first issue which is the Purebasic Editor. The Purebasic Editor in 2001 was really a mess.
I remember when I mailed with "Fred" the creator of Purebasic:

Quote> - there is no UNDO button.

   Yes it's missing.. I think I will add undo feature very soon..

At that time the Powerbasic Editor was already a fine tool as stable as it is today. But since then things greatly changed.
The original Powerbasic Editor did not change that much, but the Purebasic Editor made its way to a professional and reliable tool.
We must say taht Powerbasic Users will use SED and will then have a comparable Surface to the actual Editor that is included with PureBasic.

Everything is there, what we would expect from an Editor - and a lot more.
Some parts are still a bit more complex to realize then with Powerbasic (couldn't find a simple #COMPILE DLL that will do this).

Some parts are much easier then with Powerbasic -for example adding resource, Icons and a file-description.
Even a automatic Increasing of Built Numbers is there. In short just looking at the editor Purebasic will get another point.

Coming to the language itself, Purebasic was going (and maybe in some parts is still going) from a better Macro-Assembler to a real Hi Level language.

You can see the actual evolution in the Purebasic Forums at several place (http://www.purebasic.fr/german/viewtopic.php?f=6&t=19566).

Also means, Code you wrote with an older Purebasic version (old is maybe 3.9) can not compile with a newer version (new is 4.3) without significant changes. Still new datatypes are added to complete the compiler, and some things are just still missing.

About code-backwards-compatibility the point goes to Powerbasic. You can just compile old code with the new Powerbasic.
Even code from 2001 will mostly work without many changes.

Even Example code which is delivered together with the Purebasic package may not compile with the same version.
Something that will definitely not happen with Powerbasic.

In my next Post we'll just take a closer look at the Code-differences between Powerbasic and Purebasic x64 to help those who need to make something in x64 "to get the drift" while staying with Basic.

My first experinece with Purebasic was "Where is my SUB MAIN()" ?

The answer is very simple - there is none!

Anything you write in the Editor is automatically inside the SUB MAIN (implicite).
Thats a disadvantage for somebody coming from Powerbasic, as the code just doesn't look as clean as we are used to it.

But knowing that it is like that, you just live with it.
Where is my SUB MAIN() ? Anywhere outside of a PROCEDURE.

So we start declaring our Variables. In Powerbasic we would write:

GLOBAL T01 AS LONG,T02 AS STRING

In Purebasic it looks like this:

GLOBAL T01.l,T02.s

Which is somehow the same, less to write, maybe not as good readable, but no problem, so long you do not intermix "." and ",".

A bigger difference is with Pointers and structures.
Assume you have a structure in Powerbasic and you want to rebuilt the same structure in Purebasic.

While you would write in Powerbasic:
TYPE DATA
 a(9) AS LONG
  rft(10) AS STRING*256
END TYPE
LOCAL D01 AS DATA
You will be able to access your

D01.a(9)=1
Which won't work like this in Purebasic.

This time you need to write more:

Structure DATA
  a[10].l
  rft.s{256}[11]
EndStructure

And the first thing you see is, that while in PowerBasic all "Ends" are separate from the thing they end:

QuoteEND IF, END SELECT, END SUB

In Purebasic all "ENDs" are always together as a single word:

QuoteEndIf, EndSelect, EndProcedure

and the second thing you see, is that you have to add one more element to the Array to get the same number of elements.
Which is just true in structures, but not in normal Arrays. So better keep these special rules in mind.

Now take a look at the fixed lenght string in the Array and you see that the readabilty of the Purebasic code is a thing of discussion. At least for us long time Powerbasic users.

Saying that we come to pointers. In Purebasic the "*" in a Pointer-declaration is a part of the name.
Means a variable "*POI" is another variable then "POI". They would be declared like this:

GLOBAL POI.l,*POI.i
To get a value out of a Pointer you will take PeekL() and PeekQ()


xpos=PeekL(@*Point\x)


or use constructs with Unions like this


Structure Point64
 StructureUnion
   p.POINT
   q.q
 EndStructureUnion
EndStructure

Procedure.l EventHoverGadget()
 GetCursorPos_(cursor.POINT64)
 hndl = WindowFromPoint_( cursor\q )

For me this is far from the readablitiy of Powerbasic code, but still much better then C. But this may be a thing of behavior.
There is another thing, which is  a bit different in Purebasic. As you can see, API calls always end with an underscore, to make a difference to user procedures and Purebasic commands:

hndl = WindowFromPoint_( cursor\q )

Like in old times before Powerbasic 9, all Procedures must be in the right sequence or you need to declare them first, because there is no second Pass in the Purebasic compiler. This is a issue, which makes me wonder because they implemented a lot of things into Purebasic ... even a OGRE-based 3D Engine, but no second pass.

Also actually there are MACROS which may be used for some sort of "OOP" (http://drac.site.chez-alice.fr/Tutorials%20Programming%20PureBasic/indexTutorials_en.htm) but there is no real Object-Implementation like the one in PB 9.
Actually the Points for the compiler go to Powerbasic. But i have no doubt that we'll see things like a second Pass in one of the next Updates.

Another thing i missed in Purebasic are Procedure-LOCAL LABELS. I can define Labels in Purebasic. But they are always GLOBAL.
The fact that Labels are generally GLOBAL looks to me like a problem for complex projects.

I can make a GOSUB LABEL. I even have a FAKERETURN to take the return-adress from the stack when i want to jump back via a GOTO, for example in case of an error (nice Feature). But only in the "SUB MAIN" which is outside of any Procedure. Why not inside Procedures?

And then MACROS. No LOCAL labels. No MACROTEMP. How can i use a Jump inside an MACRO, if i do not have MACROTEMP ?
Maybe there are tricks out there at least they are not explained in the help for MACROS. And thats the place where i expect these things.
There may be chances to do such things inside the underlying Assembler. But actually we are talking only from the Purebasic compiler.

About the general stability, i can say that all things i did until now (while its not much code) worked really fine.
The possibility to just compile something for 32 and 64 bit is also a nice thing.

So after all i can recommend PureBasic for x64 things.

The editor is well done, the language has gone through many evolutions since 2001 - while from my point of view its not yet where Powerbasic is, in terms of code-quality and Syntax-Design, and COM Objects.

But then there are other things which are great features. For example - the compiler leaves out unused PROCEDURES from the final executable. So you can load all your libraries and the code will not blow up unnecessary. You can compile residents and these will just work as internal commands.

And this is my last tip for today. I hope this will help you to get a good start into Purebasic x64. If you already use it and you have more comments for Powerbasic users, post them here.

;Resident File
; Example from the Purebasic Forums
; Save as myres.pb in \PureBasic430\Compilers Folder
; use CMD and change (CD ..) to that folder.
; type: "pbcompiler myres.pb /resident myres.res"
; copy the resulting "myres.res" into the "\Resident" Folder
; restart Purebasic
; the structures are now available in the Tools-Help
; the MACROS can be used like builtin commands.

Macro MakeLong(low, high)
 low | (high<<16)
EndMacro

Macro LowWord(Value)
 Value & $FFFF
EndMacro

Macro HighWord(Value)
 (Value >> 16) & $FFFF
EndMacro

Structure char_array
 c.c[0]
EndStructure

Structure strg_array
 s.s{1}[0]
EndStructure

Structure Point64
 StructureUnion
   p.POINT
   q.q
 EndStructureUnion
EndStructure

Here is another good tip. A completely free Book for Beginners (http://www.purebasic.fr/english/viewtopic.php?t=37059).

Another funny thing is  - wether a problem or by concept -  Purebasic 4.40 does not have the ability to make FOR ... NEXT LOOP with non Integer values.

For this you need to use If or carefully selected REPEAT UNTIL Loops.
Therefore care must be taken when transfering code from other languages to Purebasic 1:1.

See here:
http://www.purebasic.fr/english/viewtopic.php?f=13&t=40282

For a Powerbasic user this is just funny ,and shows where both systems have their strenghts and weaknesses.

I needed to do x64 stuff these days again. And doing so i had the chance to take a closer look at the actual PureBasic.
Here are some things i want to share with you.

First i thought of making a nice GUI.

Great, unlike in PowerBasic there is a Visual Designer included in PureBasic.

So i gave it a try and made a very simple form having nothing else then a treeview in it.

Doing so i realized that this thing doesn't work (at least under 7/x64).
The generated code doesn't compile. It brings error, even syntax errors!

Nice to look at - doesn't work.

Ok, so i needed to look around a bit, and as we have QTab as a free Visual Designer for PowerBasic,
the PureBasic People have PureFORM from here:

http://gnozal.ucoz.com/PureFORM.zip

there is even a manual available here:

http://gnozal.ucoz.com/PureFORM/PureFORM_Manual.htm

this thing works and produces fine code that compiles without changes under PureBasic x64 and also without changes under PureBasic x32.

Here is another Hint, for PowerBasic users who use PureBasic x64.

In PureBasic all API Calls end with an "-". Example:

SendMessage_(hTreeView, #TVM_HITTEST,0,Result)

don't forget that underscore or you may end up with a PureBasic command with the same name and another functionality.

Example: IsWindow() and IsWindow_()

The first one works only with PureBasic internal Handles, and the later one is the expected API call.

After all my actual tests, PureBasic compiled fine and worked without problems.
It has support for x64, unicode, DirectX and much nore already builtin.

The compiler-options about resources and Executable/Project/building are far ahead of any Editors we currently have for PowerBasic.

There are easy ways for adding Icons, increasing Build-Numbers, you can compile many different targets - at the same time and save all that as "Project settings". And much more.
In short: the PureBasic IDE is very good and beats the PowerBasic IDE with AutoCompletion and a lot nice features easily.

Having said that, the PureBasic Syntax is still (and this will never change) more like "C" then like BASIC.
But it develops in a good direction to my No. 2 Compiler after PowerBasic and my favourite x64 compiler.

Quote from: Theo Gottwald on September 30, 2011, 10:12:16 AMOk, so i needed to look around a bit, and as we have QTab as a free Visual Designer for PowerBasic,
the PureBasic People have PureFORM from here:

http://gnozal.ucoz.com/PureFORM.zip

there is even a manual available here:

http://gnozal.ucoz.com/PureFORM/PureFORM_Manual.htm

There is also PBDev (http://www.hellobasic.com/download.aspx) which is free and very good.  PureVision (http://www.reelmedia.org/purevision/) costs money, but is very popular.

I have tried PureVision and it did not work for me, so i can'trecommend it.

Thanks for the Link for PBDev/PureBasic, it seems to work fine also.

Quote from: Theo Gottwald on October 04, 2011, 05:19:18 PM
Thanks for the Link for PBDev/PureBasic, it seems to work fine also.

One thing worth noting with PBDev.  Although there is no license included with the latest version, when the free version was first posted on the forums, it was free only for non-commercial use.  Commercial use required a purchase of a license.  I have no idea what the status is now, but if anybody is using it for commercial purposes, they might want to double check with the author to make sure they don't inadvertently step on any toes.

There is no way anymore to use it commercially.
I left it online until the website is being terminated in 2014 (or before)
PwrDev has support until 2014, PBDev not.
PureBasis looks complete but is in fact hobby, 90+ percent of the users are hobby and i had mostly poor experiance how people solved matters and such.
I abandoned PureBasic over a year ago, not my taste any longer.
My experiances are based on then, how it is now... ?

PureBasic? You buy a licence once and you have it forever.
Means that the users are always the same.

As the price is very competitive, the userbase is where people must look at the cent.
Students and such.

Opposite to that would be WinDev, Patrice recommends it.

Will have a higher part of commercial users because the price is "like a small car".
Too expensive for hobbyists.

Quote from: Edwin Knoppert on October 05, 2011, 06:10:26 AM
My experiances are based on then, how it is now... ?

More stable and a few more features.  It is what I am stuck with using now and I have not experienced any major issues even though there have been some changes in my multi-year absence.

Theo,

Look at the design interface and number of applications that have been done, then ask yourself with each specific programming tools they have been programmed, then it should not be too harsh to determin which are for hobbyist, and which are for the professional audience.

Visual Studio, WinDev and PowerBasic are making my days.
And the combination of WinDev + PowerBASIC is the most powerful bundle to use with the Windows 32-bit platform, now let's see how long it would take to PowerBASIC to produce a 64-bit version...

Patrice, do you use WinDev for x64, or VS?

Actually a PB x64 would make my day. I hope its not too far.

But no matter if its far or near.
Until i have it, I have to look around somewhere else.

About WinDev, I downloaded a DEMO,and did not understand a thing even how to make a "Hello world".
It would only make sense if i find somebody to teach me a crash course maybe.

Also what i have seen in their forums, the support can not compare to the PowerBasic support, which is fast and helpful.
However their marketing is great, no doubt.

Theo

WinDev is able to produce both 32-bit and 64-bit, however the problem occures when you use third party DLL(s) that are not 64-bit, then you have to write them with VS.

There are many video to learn how to use WinDev.
Creating an interface with WinDev is a piece of cake once you know how to do it (note: i could explain here in case you realy want to know). The strength of WinDev becomes obvious when you have to manage very large projects that could involve a pool of programmers, but it is also well suited to produce single developer application.

You can't compare PC-Soft with small workshops like those you are accustomed to. With WD17 they will release a brand new native unicode version, with everything converted to Mandarin for Chinese programmers, these peoples have a clear vision of the future and they aknowledge the new leadership of asian countries...

...

Patrice, thanks for that offer.
i have no doubt in that WinDev is on the right track. Once i have it and time to look for it, I'll contact you and take your advice about how to step into it.

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

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.

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.

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.

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 (http://www.windev.com/)

now try to find testimonials for PureBasic.

...

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.

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

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.

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

Quote
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 (http://www.progui.co.uk/)
Real Source  (http://edel.realsource.de/)
Pure-Area - lots of code snippets (http://purearea.net/pb/german/index.htm)

Quote from: Aslan Babakhanov on March 27, 2012, 09:57:45 PM
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.

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.

Quotesomehow "nearest to Powerbasic"

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

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.

The Blog from Fred shgows interesting aspecrs of developement:

PureBasic Blog (http://www.purebasic.fr/blog/)

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 (http://www.purebasic.fr/english/viewtopic.php?f=7&t=54606&hilit=Single+Pass+Compiler)" 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?

Theo (and others),

Just wanted to say thanks for posting your experiences with PureBasic here. Interesting read!  :)
The more I read about PureBasic, the more I become convinced that this will be my 2nd compiler, next to PowerBASIC.

If you have more PureBasic experiences that are worth mentioning here, please don't hesitate! ;)

Kind regards
Eddy

Eddy, currently use PureBasic x64 only and for 32 bit PowerBasic. Purebasic has some weaknesses about GOSUB and around that are for my programming style not so easy to overcome.
Also it lacks some variable types.
Anyway, aside from that many things can be done with PureBasic, and also the Editor and the surrounding are fine.

Quote from: Theo Gottwald on February 24, 2014, 06:24:07 PM
Purebasic has some weaknesses about GOSUB and around that are for my programming style not so easy to overcome.
Also it lacks some variable types.

Can't you use function calls instead of gosubs? Probably some more overhead, that's true ...
Which variable types are missing ....?

As i said above, because of a historically wrong decision in the past, PureBasic ist still  a "Stack Call based" Single-Pass Compiler.
About the variable types, it starts with a string engine that can never compare to the one from Powerbasic.
Next you will see that you have to make some strange moves when using some APIs.
Take a look here that will help you starting.

PureBasic Book  (http://www.purearea.net/pb/download/PureBasicBook.pdf)
Database Developement with PureBasic (http://pythonkit.com/download.php?id=3182)

PS: Some of these books may be in german.

Thanks, Theo. The first e-book I had already downloaded ..  :)

Quote from: Theo Gottwald on February 25, 2014, 07:51:07 AM
PS: Some of these books may be in german.

Dies ist normalerweise kein Problem ..  ;)