PureBasic Forums - English

I say PB+OGL is a fine combination.

Fred can just focus on building a strong core language, and I'll focus on doing the 3D part.

well, i'd like to have a 3d something that would simply allow me to concentrate on what i like

what a simple 3d engine should contain:

1. something to load objects
2. something to (re)apply skin to objects
3. something to load and play bones (object animations, sort of)
4. something to set light sources
5. something to do terrain, skybox
6. something to position, align, scale etc. all the stuff above
7. ah yes, a camera would do nicely, thank you
8. then some stuff to put objects in motion, don't wanna do that myself
9. and if anybody feels bored, i'd love to have shadows...

euh, and simple, obviously

LoadObject(7,"c:\whatever\object.xxx")
ScaleObject(7,2)
SetObjectPosition(7,10,10,10,0,0,180)
ShowObject(7)
SetCamera(10,10,100,0,0,180)
SetObjectSpeed(7,12,0)

something along those lines logic behind it? make things easy, build models in another program (although primitives would do nicely thank you) and let the 3d engine handle as much as possible without burdening the programmer (i don't want to know anything about possible collitions, i just want to know when they occur, etc.)

same thing for physics: set certain parameters (mass) per object, any eventual gravity hotspots, fire and forget

but this may be more in the line of 3d game creation tools, so for now i'd settle for quads, and a few other minor enhancements... <innocent look>

Psychophanta wrote:I mean; why to choose PB or BB, or whatever, if one of them could have (be) ALL-IN-ONE?

I agree, just imagine if Fred wrapped all the commands contained within the Ogre.dll (3DEngine.dll) supplied with PB and also had ODE plugged in to handle collision and physics! Man it would blow everything else away!!

Fred has said he would implement ODE in earlier posts see:
viewtopic.php?t=5305
Dated 22nd Apr 2003 (over a year ago)

And said he would further the 3D commands too:
viewtopic.php?t=7110
Dated 17th May 2002 (over 2 years ago)

I guess it will appear when he can be motivated to do it.

You write: "Also, unlike Pure, there is no restriction how you use the library functions that come with. You can make DLL's and use these functions as you wish.
Like every other compiler..."

If you read the small print on the other compilers, they do not allow this feature either. For example, Blitz3D lacks certain functionality like printing. What would stop the author from using Fred's assembly language print routines in a DLL and then just have Blitz3D call the DLL? Now he can advertise Blitz3D can print, and then run his product in competition against Purebasic.

Of course Mark Sibley of Blitz3D wouldn't do that, this is just a hypothetical scenario. But I did see users in the Blitz3D forum using Purebasic to create DLLs, and then selling the DLLs to other Blitz users in the name of 3rd party add ons that extend the power of Blitz which is a competitor of Purebasic. So why would anyone create a programming language, and then allow parts of their programming language to be used in products that compete against that language? If someone wanted to go out of business in a hurry maybe. I stand behind Fred on his request that you don't use DLLs as wrappers for other languages that compete against Purebasic. This is just common business sense.

StarHawk wrote:You write: "Also, unlike Pure, there is no restriction how you use the library functions that come with. You can make DLL's and use these functions as you wish.
Like every other compiler..."

If you read the small print on the other compilers, they do not allow this feature either.

Actually I was refering to IBasic PRO and if you look here, the creator (Paul Turley) says it:

http://www.pyxia.com/community/viewtopic.php?t=8162

no restriction

With other compilers (like c/c++ compilers) normally you have a restriction if you do commercial applications (if any restrictions at all...).

StarHawk wrote: But I did see users in the Blitz3D forum using Purebasic to create DLLs, and then selling the DLLs to other Blitz users in the name of 3rd party add ons that extend the power of Blitz which is a competitor of Purebasic.

I'm not a Blitz user...

StarHawk wrote:I stand behind Fred on his request that you don't use DLLs as wrappers for other languages that compete against Purebasic. This is just common business sense.

PureBasic was created by Fred, so he can request whatever he likes to.
It's his right to do so.

An essential difference between a "gaming" language and a general
application development language is the concept of a central timing loop.
Like a movie camera that has to frame each shot, a game has to
create a screen (some say page) complete in all details, then switch
that from a background (hidden) mode to the foreground (active screen)
so that it can provide smooth animation without screen flicker. The
next screen is then created in the background and switched to the
foreground at a rapid rate called the frame rate, or number of new
screens that can be created and displayed within one second. If you
are familiar with old movie standards, Super8 was 8 frames a second,
which caused discernable flicker. European alternating current is 50
Hz, or cycles per second, which for most people prevents discernable
flicker in electric light bulbs or on tv's or monitor screens. The American
standard is based on 60 Hz, which is a little bit faster, and therefore
less noticable. Monitor refresh rates have been improved to 72 to 85
Hz, which really gets you to the point of not noticing flicker.

The program has to anticipate the lapsed real time before the screen is
to be updated again, then switch the screens at a sustainable rate that
prevents jitter. Sometimes the computer cannot maintain that rate, and
you drop frames or find the update slightly delayed, both of which are
observable. Some people ignore this effect without effort, but others
insist on having the very best graphics cards and drivers, and a fast PC
to reduce this effect. Faster graphics and PCs also mean that the
program and graphics together have more time to detail the image to
be displayed, so the effects may be more realistic, or contain more
clues as to what is happening on screen.

Note these are primarily game considerations, although they also have
a strong bearing on how well a particular PC can do video. In a way,
you could thing of a program that plays DVD movies or other videos as
a type of game program but with the narrow purpose of just providing
good video and sound. The same can be said concerning a program
intent on playing music tracks.

This means that the most important element of a game development
system as opposed to a general application is the way it handles timing
for all extenal events - screen updates, music and sound coordination,
keyboard control, game controllers, networked messaging for online
game play, and so on.

PureBasic presents a challenge in this regard, because it is not optimized
for game play. On the other hand BlitzBasic has game play as its
central focus, and as a result, BlitzBasic is not designed for use in
creating DLLs. though it can use DLLs from other languages to add more
functionality to the games you write. Thus, if you are looking to work
with BlitzBasic and some other languages, the only way to employ
BlitzBasic is as the core (central, or main) part of your program.

Actually, I am referring to Blitz3D here. There is another product from
BlitzBasic that takes a step back towards a more general purpose
program while maintaining the same syntax, but it gives up the ability
to provide the timing core that is required for good game play.

In other words, it is unlikely that one product will serve both camps at
the same time. The primary goals are quite different.

I might also add that serious development in data, financial, and science
areas often demand extensive numeric and data handling capabilities that
can only be achieved at great effort with programming tools that have a
limited number or scope of data and numeric types. The resulting
compromises can have a serious impact on the development time, the
reliability, mantainability, and finally the overall speed of the applicaton
being developed.

Sometimes the best approach is to bite the bullet and pick the right tool
for the job. If you have a serious programming chore, or want to write
a commercially viable application (other than a game), then I would
recommend PowerBasic, which you will find at www.powerbasic.com.
It generally follows the more familiar syntax found in QB or QuickBASIC,
but is way and above more powerful and capable. It does cost more,
but see it's list of features before you decide. It can successfully be
used to create or call DLLs, and it's two main product offerings (PB/CC,
which is the PowerBasic Console Compiler, which is most similar to
the traditional BASICs, and PB/Win, formerly PB/DLL, which provides
the same looping capabilities as found with BlitzBasic, but it also can
be used to create DLLs). The have extensive example programs that
solve many problems or illistrate many techniques, and they also have
an older PB/DOS program, most similar to QB or QuickBASIC, but
which works well under all versions of Windows, giving you a DOS-like
programming capability, for you diehards out there. PB/DOS is free
to download and use, but is somewhat limited (I seem to remember
that the demo version will not let you create Exe files, but you can
compile and run in the IDE, which is the way I run many programs
anyway, since these compilers are superfast and the compile time
is hardly noticable).

foxx, you have to be the most long winded person I've ever come across!

Informative and VERY accurate, I might add.

--blueb

Not very, Super8 was never 8 frames per second

MadMax wrote:Not very, Super8 was never 8 frames per second

I thought it was a class of racing car, 0-100 in <8 seconds.

MadMax wrote:Not very, Super8 was never 8 frames per second

As far as I remember the '8' in 'Super8 stays for the width of the film material - 8mm.
The frame rate was 25 frames per second.

Hope I'm not too wrong

Really? I'm not sure either. Yes, I am very long winded, but my mind
fine-chews random facts and tries to create a mulch that fills in the gaps.
Best I can remember is that some sales guy explained Super8 to me,
and I never challenged it. When someone points up an error, the best
I can do is apologize and try to get the right information.

So I do apologize. If one were limited to just what they knew firsthand,
rejecting all other resources (and sources), one would have a very
narrow and limited view of the world at large.

A quick search on Google turns up lots of hits for a certain Motel chain,
but here is a bit of revelant fact (or apparent fact):

"The Super 8MM film format was developed by Kodak in 1965 to replace regular 8mm. Regular 8 had the reputation for being very unstable. It didn't get exposed properly through the film gate. Super 8 solved this problem by putting a pressure plate in the film cartridge."

(Now if I could just find that salesman, I would kick his butt.)

"People in the 60's and 70's used super 8 to record jerky home movies. This format is the second most popular format next to 35mm. The reason for this is because loading a film cartridge for your super 8 camera involves no threading of the camera. This makes it easy for anyone to use. Besides being easy, it's also very cheap. Today it costs about $20 US or $28 cdn to buy and process a full 3.5 minute 50 foot roll of colour Super 8 film."

Okay, okay. An unfortunate bit of misinformation slipped in there. I
apologize again. But not for being long-winded. Just don't read it if
you already know it or just don't care, but I've been told may many
that I've made things clear that were confusing before, and I'm always
glad to help.