PureBasic Forums - English

The thing that drew me to PureBasic was its flexibility - its also the reason why I havent touched DarkBasic pro for about 4 months. But I think PB is suited to games and graphical apps as much as anything else - I like to think that PB can be used for anything, which in effect makes it a stronger language than Blitz\Dark.

The PureBasic resources, such as coding examples and details covered in
its various help files, go a long way towards showing its maturity and
flexability. But the all-important concept of an embedded looped sequence to respond to external needs is not inherant to it. A gaming
language would make that central and transparent. For a PureBasic
game developer, you need to resolve that problem going forward.

The challenge is to integrate into the Windows environment and become
one with its method of passing messages of external events around the
loop until some process recognizes something that involves it and then
reacts to it. If the message is not for it, it has to be handed off to the
next process. You can think of it as sort of a daisy chain into which
your program must insert itself when it starts running, and from which
it must uncouple itself when it ends. If it fails to uncouple correctly,
it will hang your system because it will break the chain. (Since Windows
Nt/2K/XP work hard to uncouple one virtual machine from another, the
recovery may not require a full system reboot).

Similar things are required in Linux and Mac OX, but of course they are
not going to be done the same way as done with Windows. In fact
things are not done the same way under Windows 3.x as done under
Windows 95/98/Me as done under Windows NT/2K/XP. If you go with
a gaming language, it needs to have sorted all that out for you. If
you attempt the same with PureBasic, you have a struggle and sharp
learning curve ahead.

oldefoxx wrote:If you attempt the same with PureBasic, you have a struggle and sharp learning curve ahead.

But in the end you come out a wiser programmer.

I won't disagree with that argument. It also applies to people who write
in Assembler, create their own gunpowder and cast their own bullets when
they go hunting, and forge their own steel when they make knives and
swords. It has meit, but we don't all want to end up reinventing the wheel.

Fair point.

I belive it is the bad 3D support with PB.

All(?) 3D programmers are working with BB because the 3D support is better there.
When PB have a usefull 3D interface to OGRE, then let us see again.

I belive it is the bad 3D support with PB.
All(?) 3D programmers are working with BB because the 3D support is better there. When PB have a usefull 3D interface to OGRE, then let us see again.

Agreed! If PB had a killer 3D engine it would really round off the language and make it a serious contender against BB and DBPro. I think more would people would move here because of PB's kick ass speed and flexiblity! At the minute there is just too much messing about to even get a model loaded into PB using the cluncky milkshape exporters. Then theres no collision! Doh!

I think PB is just fine for making games, 2D of course, But just wait and see, when we get the 3D bit!!. PB is the ideal all purpose language, because of the way the compiler works( only the necesary is compiled into the exe) This is a huge advantage.

I have used other languages, that are specific for games, among them B3d and DBP, and they do what they do very well, but I still prefer PB; maybe because if I program a game it tends to be 2D. I like coding other things apart from games and once you start programing something that is not a game with "game oriented languages", things get troublesome or plain imposible. This is why I find PB a far superior language.

I can live without the 3D part, but of course it will be very nice to have it. My main concern is the Linux side of PB, I realy wish it was less buggy. If it worked as well as the Windows side of PB I'd be ever so happy (not that I'm sad now) just that I'd rather not have to use windows anymore.

Only reason I can see why others are more popular, is because they have or have had companies behind them, that invest in publicity. But PB should be getting more and more popular. Not only PB is a fantastic language (at least I have a great time using it) the forums and the comunity is very helpful and we don't get all the bitching that goes on on other places.

To be honest I wouldnt be bothered if the 3d side of PB is ever updated (although it would be nice to play with). I decided to go directly into OpenGL because I prefer to have control over everything.

As an examle, say I developed a game with Blitz. And then up pops a nasty bug with the 3d engine. I have no way of fixing that bug, customers are unhappy, business slows.

But if Ive done the 3d myself, not only do I have knowledge of a 3d API/3d math etc that could be beneficial in the future and is an extra skill for the CV, but i then have the facility to fix things straight away and i dont have to wait for the language author to update.

I really don't employ 3D in my own code, though I have played wiith
OpenGL just a little bit. But everybody that is arguing that the strength
of PureBasic is in its ability to write financial, commercial, or scientific applications is off their mark. Note that you can write such things, but
PureBasic does not have the range, precision, or accuracy in its
numeric types and math routines to truely serve in those areas.

Take floats for instance: If you used PureBasic to try and calculate you
flight to Pluto, you are not going to even get within viewing distance of
that planet. The size of a float is not sufficient to retain the necessary
precision to reflect your exact position, nor the position of Pluto, because
a lack of precision also means a lack of accuracy.

Take longs for another example: Try to express the national debt with
a long. Again, insufficient digits.

Strings could be another limiter. Fit the whole of the human DNA
sequence into a single string for process. That could be a problem

Efforts to circumvent these limitations, such as using structured types, memory mapping, and arrays, become cumbersome once you start into
the problem of manipulating them or applying mathematical or logical
operators to them. Even resolved, because the code is unweldy, it
is hard to troubleshoot or maintain, and the lack of optimization
could mean poor performance overall.

Comparing PureBasic to programs that are intended primarily for the
purpose of producing animated 3D sequences makes it look good by
comparison. But once you turn to serious applications, it has to
travel in a different company. And there it doesn't fare as well.

I like PureBasic, and it offers me a lot. But it really needs to focus on
what part of the community it intends to support first. Saying that a
better 3D engine will blow the competition away is ignoring the fact
that PureBasic is far behind in that area, so the "blowing away" is
unlikely. PureBasic might attract some more gamers that like the
broader range of functionality, but they will always complain
bitterly that the 3D engine falls short in one feature or another that
a different program provides. There search for the "perfect" 3D
experience will drive them on and on, and they will move on.

Where PureBasic excells is that it does range far beyond the mere
aspect of visual sensations. And building on that aspect is more
likely to cause it to gain in popularity. That, and stronger cross-
platform capabilities, which would support a fundamental shift from
Windows to Mac OS and/or Linux in the programming community.

You're exactly right. By far the most important thing that should be implemented next are double floats/longs etc. that lack of precision is holding PB back from its potential.

You're exactly right. By far the most important thing that should be implemented next are double floats/longs etc. that lack of precision is holding PB back from its potential.

I Agree, these things really should be done first. Even calculating HDD space is a problem with PB the way it is atm.