PCOPY! Issue #50 ~ November 16th 2007
Covering All BASICs


In This Issue:


Contributors:


 Regular Columns:
  From Our Editing Desk (E.K.Virtanen)
  Submitting to PCOPY! (Stephane Richard & E.K.Virtanen)
  Letters To The Editors (Mixed Contributors)
  Letters To The Hartnell (Mixed Contributors)
  In The News (Mixed Contributors)
  Exit Issue (E.K.Virtanen)

 Articles:
  About PCopy! (E.K.Virtanen)
  The mindset problem (Bill Williams)
  Interview with Eros Olmi (E.K.Virtanen)

 Reviews & Presentations:
  VIXEN: An XBLITE GUI Generator (Guy (gl) Lonné)
  Introducing Fatal Method Games (FMG)
  More about smallBasic (Chris Warren-Smith)
  3D graphics in thinBASIC: (Petr Schreiber)

 Tutorials & HowTo's:
  Coding Functions: (Guy (gl) Lonné)


 E.K. Virtanen
 Chris Warren-Smith
 Petr Schreiber
 Stephane Richard
 Guy (gl) Lonné
 Eros Olmi
 Fatal Method Games
 Spike_132000
 Bill Williams
 redcrab
 tunginobi
 Angelo
 tunginobi
 Dean Menezes
 
 Issue release 4.0


~ REGULAR COLUMNS ~

From the Editors: by E.K.Virtanen


Welcome to read fifth issue of PCopy! magazine.

I think many of you thought this magazine to be dead and buried. Guess what? To be honest, i thought so too at some point. But here we now are. PCopy! issue #50 is done and ready to get published.

Now, there is website under construction for PCopy!. Those ones who are interested, head your browser at pcopy.wikidot.com to follow how site soon get's it's final shapes. Also, email for all PCopy! contributions has been taken from gmail.com to avoid misunderstandings between asciiworld related contact email addresses. For now on, PCopy! email is pcopy.stuff@gmail.com

So what is the future of PCopy!?

Finally, the future is clear. After several moves (by PCopy! stuff) and weeks long off line situations, things gets settled. Though, MystikShadows is moving anyday now but hopefully, these irritating things now ends. For now on, PCopy! is published in periods of one to two months. No absolute deadlines for next issue, but it is planned to publish at mid-january.

I did write a short article about PCopy! history and future in this magazine, anyone interested, check it out.

I like to thank all contributors of this issue. Time table was not long but still, you folks gave me resources to do this great issue what we have here now. PCopy! would not live with out your efforts, thank you for keeping it alive.

E.K.Virtanen


Submitting to PCOPY!: by Stephane Richard & E.K.Virtanen


As you probably noticed, we have a list of contributors. Everyone that submits something gets his/her name added to this list for the particular issue the submission appears in. We can't claim to know every single BASIC dialect out there nor can we claim to know how to program in all of them. There are just too many of them. Hence, this is an official invitation to those of you that do know a specific BASIC dialect well enough to write about it. Help us make PCOPY! the most complete BASIC magazine there can possibly be by sending us submissions about them.

When we say submissions we mean anything that pertains to the specific BASIC dialect in question. Submissions can range from simple news item (a new version comes up, a new library is available and the likes), they can be personal reviews of a given BASIC interpreter/compiler, they can be tutorials, tips and tricks that shows readers how to accomplish a given task in the BASIC of your choice. The choice is yours. Submissions will help make PCOPY! even better than it is and the end result of that is that readers will have better BASIC related material to read in every issue that comes up.

So don't be shy, you know something others don't about a given BASIC, let us know about it, send us your submissions and we'll take it from there. If you're not sure how good a writer you are don't worry, if needed, we'll edit and format the submission accordingly. So please, submit whatever you have time to write.

All submissions can be sent to pcopy.stuff@gmail.com and will typically be added in the issue that is currently being worked on at the time the submission is sent to us.


Letters To The Editors: By Mixed Contributors

Letter from Spike_132000

Hey There AsciiWorld! Here is my news on YABasic!
ABasic, the open source Basic language from Marc-Oliver Ihm has stopped in development! The reasons for this are that Marc is currently going through the stages of learning the J2EE Stuff. The Community of the YABasic forums seems to have come to minimum posting since the bad news. The Latest version being 2.763 hasn't been updated in the past 2 years (From August 2005). Although it doesn't seem that long, it unfortunately is. Marc is sorry to admit "that probably I will not develop yabasic any further within the foreseeable future." This came as a blow to the YABasic Community when this information was found out. YABasic can still be downloaded from the homepage of YABasic. And there are still many people who use YABasic as there primary programming language because of it's ease of use. Please don't let the YABasic scene die! Download and program TODAY!!! yaBasic.de

Hi Spike.
I decided to start with your "bad news letter" here. I am very sorry what has happened at yabasic community. It was and still is a nice place to visit and peoples there are very friendly. But it is easy to understand that Marc just cant do everything, he has hes own life and work which naturally comes first. I use yabasic myself too so i only can wish that someone experienced enough gets interested for developing yabasic, or atleast fix the most harmfull bugs of it. Or maybe Marc can make time for that...i dont know, i only wish.

E.K.Virtanen



Letter from MystikShadows

Hi Everyone

First I'd like to say that I like the look, I know I know I made the look, but I think it works great the way it is, much more readable, easier on the eyes and after reading the whole issue #40 and not having a headache at the end, I think this is worth noting. From what I've seen with the different types of contents on the last article it seems to be a new look that works pretty good with all types of contents. I'll just take a minute right now to pat myself on the back ;-). hehe.

I wanted to make a good note here that it was very interesting to read about all the BASIC dialects that were featured in issue #40. yaBASIC I had just learned about before #40 came out, it turns out to be a very interesting dialect of BASIC that has some great unique features, namely the ability to feed it code at run time that it will execute as if it's part of it's original program. I find that genius.

What's to say about thinBASIC? I think it's a work of art. Some people complain when there's a whole lot of keywords to learn in a new language. To them I can say that the way thinBASIC's dialect evolved, the way keywords are usually grouped under categories such as CONSOLE and the likes, I believe it is, by far, the most ingenius way to organize a language syntax I have ever seen. Two thumbs up for thinBASIC and it's creators. I see a brigh future for thinBASIC in the direction it's going right now. Let's not forget to mention that the team is highly open to suggestions which I really like about the project.

I have to mention that I really liked the way Guy Lonné introduced XBLite to the world. His introductory article did a great job at highlighing what XBlite is all about as well as how easy to get GUI apps up and running especially with Vixen. I don't know for sure but I bet It was good enough to get a buch of people to take a 2nd or 3rd look at XBLite as their language for future GUI projects. It made me think about it ;-).

I think I've made it pretty clear so far that I'm a Trekkie. I love sartrek and not just in games, no I don't have the uniforms and the com badges lol but I do like Startrek a WHOLE lot. When you talked to me about doign an article on Startrek classic games and such, I was interested, but I gotta say I really liked the facts and information you included in that article. I think you started a trend, and I think more of those oldies but goodies should follow in the path of your Startrek time lime. Great work, I enjoyed it a whole lot.

I wanted to wait till OOP was fully implemented in FB before starting to learn it's version, I really thought I could accomplish that wait since I had plenty of other projects to keep me busy in the mean time. That is, until I read Richard's articles on the subject. I think Richard D. Clark (rdc) needs a swif kick in the butt for not starting to write programming related material atleast a decade or two earlier so that to day we would be able to read 100s of his books. He's a gifed writer, there's no two ways about it, and I can win a match where he denies it, and I set him on the right path again on that subject. The way he presented FB's OOP was brilliantly detailed and explained. And so now, want to or not, I know more about FB's OOP. That's how he is, you read what he writes and it sinks in like he Titanic ;-). Good work and I can't wait to read more of his writing.

All in all I enjoyed the rest of the articles in the magazine, I'd say it's the best release yet, but I haven't read Issue #50 yet but people would think i'm a little biased and well, I probably am in a way hehe. But yes, I think all the contents of issue #40 was well worth that time taken to read it. I'm very happy for all the contributions we had in that issue, and looking forward to many more contributions in the future issues to come.

MystikShadows
Stephane Richard


Hi Buddy.
Nice to get an email from you. I know how busy you are now since all the things needs to get packed there.

I could not agree more with you what comes for your letter. thinBasic is awesome tool with a awesome community and dev-team. In this issue we have pretty much thinBasic related articles, so i guess you get what you want ;)
Guy Lonné and Rick D. Clark are both excellent writers. Not only because they know so much, but because they do write articles and tutorials in a way that even i can understand everything quickly and easy. Guy Lonné contributed to this issue too and i can say that those contributions are good "GL" level staff. Hopefully we hear from rdc too after he gets hes things settled there somewhere.

I love startrek too, and specially that game which was point in my article you mentioned. Personally i am not 100% happy with that article since time table was once again too tight so i couldnt do what i wanted it to be. But im fine with that and now im planning similar article of another basic classic. If all goes as planned, you can read it in next issue.

What comes for yaBasic, i guess your feelings are pretty same than i have.

E.K.Virtanen

Letters To The Hartnell: By Mixed Contributors


From the past:

In previous issue of PCopy!, and in it's Useless corner Hartnell challenged readers. Quote: "Here's my challenge to you. Find a practical purpose for being able to LIST the code of the program that's running.".

Well, Hartnell got what he asked for and we did receive nice number of examples how to use LIST keyword in program that is running. Here are 4 letters from our readers to Hartnell.



Letter from redcrab

Hello !

You said in PCOPY #40, that LIST in a program is useless but I already used it in a program (very long time ago)(not with C64 but with BASICA /GWBASIC) here an example from many others... a way to use it : avoid PRINT


10 REM Hello this program is just an example of LIST statement in a program
20 REM Please choose
30 REM   1 -  to say "hello"
40 REM   2 -  to say "Good Bye"
50 REM   3 -  to quit
60 REM ------------ HELLO -----------------
70 REM ------------- GOOD BYE -----------
80 REM -- WRONG CHOICE ----
60 CLS
70 LIST 10-50
80 INPUT A
90 IF A=1 THEN LIST 60-60
100 IF A=2 THEN LIST 70-70
110 IF A=3 THEN END
110 IF A>2 or A < 1 THEN LIST 80-80
120 GOTO 70
			

Also it's very usefull when you detect logical error in the program then you show on console where the problem occured

Hope you will get fun with it !

redcrab



Letter from tunginobi

Showing instructions/docs?


			1 REM Press up to move up.
			2 REM Press down to move down.
			3 REM Press left to go in circles.
			4 REM Hold right to start skipping.
			LIST 1-4
			

Printing some silly message on screen forever:


			10 PRINT "HAHAHA"
			20 GOTO 10
			

Print silly stuff twice as fast! (Or double the output per loop.) Also forever:


			10 LIST
			20 GOTO 10
			

Damn I wish I had a C64 to test this on.

tunginobi



Letter from Angelo

to LIST the code of the program that's running

1) Self-modifying apps: I.E.


			10 LIST 100
			20 INPUT "DO YOU WANT TO CHANGE THE FORMULA";A$
			30 IF A$="Y" THEN LIST 100: PRINT "RUN": END
			....
			100 Y = X ^ 2
			

I used this trick on my Commodore 128 to draw a function

2) Interactive programming tutorials:


			10 PRINT "1) VIEW THE SOURCE OF THE PROGRAM"
			20 PRINT "2) SEE THE PROGRAM IN ACTION"
			30 INPUT A
			40 IF A = 1 THEN LIST 100-200
			50 IF A = 2 THEN GOTO 100
			.....
			100 [Here is your code]
			

Without this use of list, you should PRINT every line of code

Angelo



Letter from Dean Menezes


			0 GOTO 20
			1 LITTLE
			2 LITTLE
			3 LITTLE-INDIANS
			4 LITTLE
			5 LITTLE
			6 LITTLE-INDIANS
			7 LITTLE
			8 LITTLE
			9 LITTLE-INDIANS
			10 LITTLE-INDIAN-BRAVES
			20 LIST 1-10
			

Dean Menezes


In The News: (+ some olds)(Mixed Contributors)


ASCII-World.com is collecting classic Guess what number i am thinking sources in every programming language. For an example, see QBasic source here and if you think you can create similar game with your favorite basic, then feel free to post it here. Other than basic sources are also welcomed.

QB Express #25; Happy Halloween!
The October Issue of QB Express released October 31, 2007. Read it here.

QB Express #26 deadline
is at November 24th.

FBPackage Issue #1 Released October 07, 2007.
FBPackage Issue #1, containing QBE, FBC, Cool Stuff, Tips and Tricks, and Games. Totaling of 74mb+ of FreeBASIC Content! See more here.

As Spike told in hes letter
developement of yaBasic has been stopped and it's future is unsure.

Derek promises
to keep yaBasic forum and wiki online as long as there is even one interested person about yaBasic.

Work to improve and update smallBasic website
has been done lately. New website looks nice and more clear than old one.

PureBasic 4.10
(all OS) released at 11/09/2007.

PlayBasic
PlayBasic V1.70s Direct 3D Update Released, Play Basic V1.70N (Direct 3D) Beta Available and PlayBasic V1.63p Retail Update Available.

13 Nov 2007 - Gambas 2.0 First Release Candidate
The internal version number of this release is 1.9.91. The main changes are:

  • Gambas now can be used as a scripting language.
  • The IDE icon editor got support for image alpha channel.
  • The gb.pdf component was enhanced.
  • The interpreter can return error stack backtraces.
  • See more at gambas.sourceforge.net

CoolBasic - New generation in development
Aug 26, 2007 was a happy day for CoolBASIC users since Zero posted this at CoolBasic forums.

The home of BBC BASIC
R. T. Russell web site has been updated time to time. Latest update is "BBC BASIC for Windows library files and example programs". To see more, check this website; rtrussell.co.uk.

Newsbrief by MystikShadows (stephane Richard): QB64 Project
Back in September is when I first read about a project called QB32. It was started by Galleon Dragon and seemed to be a great idea at the time. After that I guess Galleon was busier programming the project than updating people as it seemed I lost track of it's development. In October I read about QB64 (that's right, so early in the project and updating itself to newer technologies already). QB64 is QB32 on newer CPUs.

QB64 as you can probably already guess from the name is a project to create a QB compiler that aims for 100% compatibility with existing. A compiler that aims to compile code wruitten in QBasic and QuickBASIC and allow them to run on more modern hardware and Operating System, currently it is developed under the Windows platform with special attention giving to the coding effort to make it as easy as possible to support the Linux operating system. There is also a hint in the air that QB64 will also be ported to the Mac OS/X platform in the future.

I personally don't know Galleon that well, but so far, I'd say he's exactly the right person for this undertaking. His programming knowledge (and his ability to acquire the right knowledge when a subject appears that he's not too familiar with) make him well prepared to take on this undertaking as we can see from the DEMO releases that have been made and his consistent development plan he has to reach QB64's goal. As he probably noticed, he has my support in this project (as well as the support of many other QB developers) and I plan on suggesting and helping in any way I can.

You can read all the details of his project in the The QB64 Project forum created on the QBasic Forum specifically for the QB64 Development Project.


~ ARTICLES ~

About PCopy! by E.K.Virtanen


This article is a short brief of PCopy! history, future and how you can help it to survive in future.

covering all the BASICs...

PCOPY!, a "magazine" created and offered to ALL BASIC developers all over the web. After some research amongst other BASIC forums and Websites we noticed that aside QB and family of compilers and FB, most other BASIC dialects didn't have anything close to a "magazine". Hence, PCOPY! saw the light of day. PCOPY! exists because we believe that alot of BASIC dialects out there deserve to be mentioned and talked about. Therefore, anything that pertains to any freely available BASIC can make it's way to PCOPY! being projects, new versions of compilers, new or updated libraries for these compilers, if it's about BASIC it can definitaly be in PCOPY!

Issue #10

    First PCopy issue ever did see the daylight at August 02, 2006 and it has eight articles and four tutorials beside of regular columns. Totally eight contributors did build up of this first PCopy issue ever.

    Columns:
    From The Editors
    Letters
    Neat BASIC Projects
    Exit Issue

    Articles & EditorialsBounce 3: On the Town - Lurah
    Space Sound Generator - Lurah
    Developer's Desktop Professional Project - MystikShadows
    Hey, this is gonna give some programmers a heart attack - Chandler
    KRef - A Kriegspiel Referee - Mac
    Don't feel obligated to use Vista - Kristopher Windsor
    Program Edition - Corey Yeates
    Lynn's Legacy: The Review - MystikShadows

    Tutorials3D Explanations & Simulations: Part 1 - Aroticoz
    Windows A.P.I. - Part One: A.P.I. Basics - MystikShadows
    mennonite's QB Intro - What Exactly is QBasic? - mennonite
    FBWin Console Apps In ReactOS - mennonite

Issue #20

    It took a months before second issue came out. Real life and some opinional differences affected badly. Anyway, issue #20 was released January 07, 2007 only with contributions of five writer. But it was released :)

    Columns
    From The Editors
    Letters
    Neat BASIC Projects and News
    Exit Issue

    Articles & EditorialsArticles & Editorials
    Interview with Jukka Lavonen
    Brutus2D 1.6 : Innovation
    The Evolution of Your Userbase
    About SmallBASIC
    Lesser-Known Basic Languages


    Tutorials
    Brutus2D Vs. BASIC
    Windows A.P.I. - A Complete Study Part II
    FreeBASIC syntax colors for GEdit

Issue #30

    Third issue came soon after second one. Only a bit over month after actually. Once again five contributors but issue was very good if we think time and efforts there was to use. PCopy! issue #30 was released at February 16, 2007

    Columns
    From The Editors
    Letters
    Quote of the Month
    News and Neat BASIC Projects
    Exit Issue

    Competitions and Challenges
    Game Competition: Asses of Fire


    Articles & EditorialsTravellin in a BASIC land
    Free Brutus2D
    mafSOFT - Mapixelator Preview
    Lesser-Known Basic Languages, Part 2.
    Hartnell's Lost Article
    Interview with Richard D. Clark
    20 Minutes into the Future...

    Tutorials
    Database Design - A Complete Study


Issue #40

    PCopy! #40 released at March 15th 2007 was milestone in two ways. For first, its new .css layout was accepted better than old dark. It was easier for eyes and not so "aggressive" Secondly, after issue #40, PCopy! nearly died away. Until Oct. 24'th 2007 there were no any talk about releasing anymore issues.

    Regular Columns
    From Our Editing Desk (MystikShadows)
    Submitting to PCOPY! (MystikShadows)
    Letters To The Editors (Mixed Contributors)
    Quote Of The Month (E.K. Virtanen)
    In The News (Mixed Contributors)
    Exit Issue (MystikShadows)


    Special Corners:
    The Useless Corner (Hartnell)
    Contest : The Dumbest Game (Hartnell)


    Reviews And Presentations:
    Introducing Yabasic (MystikShadows)
    Introductory Article On XBLite (Guy (gl) Lonné)
    About thinBasic (Eros Olmi)
    Epic Crusade (Jare)


    Articles:
    A piece of history: Star Trek Game (E.K.Virtanen)
    The Evolution Of BASIC (MystikShadows)

    Tutorials:Programming Simulation Games (MystikShadows)
    Basic4GL Tutorial: Tile Maps (Linkage)
    Introduction to the FreeBasic Extended Types (Rick D. Clark)
    Simulating Polymorphic Methods... (Rick D. Clark)
    FreeBASIC File/Folder Management (MystikShadows)


And the future?

Future of PCopy! depends of many factors. Me, you and many other person.

One man cant do this, not even two mans. It needs lot's of volunteers who contributes material, gives a hints about neat news which should be mentioned here. It is amazing how much time and efforts it takes only to go throught nearly hunder of basic related websites and try to see what's hot and what's not. It takes practically a whole day to do it. And even then, we cant be sure we got that all.

So tell me how? I dont know how to write articles...

Nearly everyone who reads this magazine has a basic dialect which he uses and specially, a basic related website what he follows closely. Not maybe a daily, but weekly. You visit at thinBasic forums often and know pretty good what there is goin on and what is hot? For regular member it is easy to catch the hotties from there. Visitor like me needs 10 times more time to see same things. And thats the problem.

Easiest way is just simply email to us when you see something that should be mentioned in PCopy!. Just send a simple email to us "hey guys, i think you should take a look of this http::www.urlhere.com" and we go and check it out.

Bit harder for you but way easier for us is to write few lines long news brief about what you just see there. Take a look of our   In The News section to see the picture.

Ok, i think i can help you with this.

If you think you can help us in some certain website, then just drop an email for us at pcopy.stuff@gmail.com and tell which is the site you follow. We then know that you do the spy work there and we can use our resources for rest of basic websites. It is a major help for us, even if we can get few basic websites covered this way. And you also can make sure that your favorite basic dialect/website is better covered in future releases of PCopy!.

PCopy! stuff appreciates all help it can get.

E.K.Virtanen

The mindset problem by Bill Williams


Run BASIC suffers from its greatest advantage: it is small and beautiful. Where PHP, ASP, Perl, and the like are big, can do darn near anything out of the box, and seem more in-line with "professional" techniques and practices; RB is small, does just what you need but nothing more, and is approachable to the hobbyist and small-timer.

Why is this a disadvantage? Mindset. People are used to the notion that it has to be complicated to be useful. Why else would anybody in their right mind be using these big languages like C++, C#, and Java for applications programming? For that matter, why would anybody in their right mind be using Java, anyway? Pre-emptive snarky comment: Yes, I know it runs on practically everything, even some newer toasters. The point is, we've lost, somewhere along the way, the notion that smaller is sometimes better. This isn't isolated to technical circles, but that's another story.

I, too, am guilty of this problem. My own personal "killer app", client-side, is a common sense editor for Liberty BASIC. I've gotten to the point where none of the projects I want to do can be done in a simple editor. I need include, resource packing, deployment, and all sorts of off-the-wall features nobody has ever dreamed of putting in an editor for this supposedly newbies-only language. I've tried time and time again to write it, whether in C, Visual Basic .NET, FreeBASIC, or more recently, AutoIt (no joke). Every single time, I've a very strange wall, something along the lines of: Wait, I need 800 lines of code to do THAT? And it looks like THAT?! With LB, I could do that with a 300-line function library and 25 lines of code that calls it and integrates it with the rest of the application.

Too many people are afraid to think outside the box, and creatively solve problems. The GNU GCC, a set of programs designed to be a more-or-less complete programming solution, was originated by hackers. You call the GNU GCC a hack? I think not! Hacks are supposed to be clever, beautiful, and small (for what it is). The GNU GCC is none of the above. I can't count the number of times I've tried to get the GNU GCC going on my system. I'm a pretty technically inclined person, but I haven't once been able to get that going, enough to even get a "Hello, World" program to compile. And then I have to write applications with that thing? Good grief!

Liberty BASIC and Run BASIC are classic hacks. They are small, espescially for what they are. They are very beautiful, and pleasant to work with (except when you do something horribly complex and wrong). And as for clever? Tell me how the OO syntax being used isn't clever! Best of all, the programmer has to think outside the box. The great hacks have always been made thinking outside the box. Take, for example, my forthcoming XML parsing library for LB4. Without objects or anything else to prop me up, I decided to approach it using a simple function called extractXML$(), which returns the XML inside a given element. It works quite well, and I'm expanding it to deal with attributes better and give it some basic escapement mechanisms. It's small, relatively light-weight (~100 lines at present, with plenty of whitespace), and it works. Now for most purposes, how is something like libxml2 better?

Going back to my killer app, everything I want to do for it can be done, but more importantly, done understandably, in Liberty BASIC 4. If I can ever convince myself to take the time to fully design my toolchain, it will practically write itself. It will take (dare I say) probably thousands less lines of code than it would to write in C, and it will be easier to read and maintain. It'll be easier to debug, easier to deploy... I could go on all day! And guess what: it's going to wind up being a pretty useful application.

In closing, programmers need to remember that small and beautiful can get the job done 90% of the time. Now is that too hard to take?

Bill Williams


Interview with Eros Olmi by E.K.Virtanen


In front page of thinbasic.com reads next lines;

"thinBasic is a script language interpreter. It means thinBasic is able to get a script text file as input and execute it on the fly. No compilation, no intermediate code, just plain text file and go, the script is analyzed and executed immediately."

And right under that sentence, we can see this: All started for passion...

This aint commercial break for thinBasic, but i just got to say that the whole thinbasic website and specially it's forum does radiate friendly and easy-to-approach feeling which does take you with it.

In short time, popularity of thinBasic has grown in amazing speed. Its not even so long ago when i heard about it first time and now, there is great number of users and co-developers hanging at the website and forum. And most impressing thing is, they all are very friendly and nice peoples.

In previous issue of PCopy!, there were allready article; About thinBasic by Eros Olmi so it's better for me to shut up and give Eros Olmi himself tell even more than last time.

  • E.K.V For a start, give us some details who and what you are?

    E.O We are two guy, Roberto Bianchi (43 years old) and Eros Olmi (41 years old), based in Italy (city of Milan) working since many years in IT field. We had the fortune (at least for me :D ) to meet each other some years ago in a company we worked on and also to share the same passion for "the art" of programming, even if programming is not our main working area. In fact we spend most of our working time managing companies IT, managing working groups and projects. But as soon as we have some spare time we dedicate it to programming, especially on thinBasic programming language project.

  • E.K.V What were motivations to start creating thinBASIC? World is full of languages, why one more?

    E.O Exactly, why once more. In fact thinBasic didn't start as a programming language. We had no idea at the beginning that a solution of an automation problem we were facing many years ago would have been a full programming language. But you know, sometimes the best things starts from nowhere. We had some process to automate. Especially data controlling over databases and data flow from one process to the other. How to do with automatic process? How to make something reusable and easy to maintain? How to have full control? At that time a good idea seemed to have some text rules to be parsed by a rudimentary parser engine and the engine been trigged by the kind of data passed in the flow. Anyhow, to keep the story short, after a while we had our text parser been able to interpret text scripts.

  • Original name of the interpreter was AutoProc. Parsed scripts were very simple compared to what thinBasic is able to interpret now but it was quite fast, simple in its logic and very easy to maintain and implement with new functions. After AutoProc we produced a DLL with the idea to embed AutoProc power into 3rd party applications. The name of the DLL was BINT32 (Basic INTerpreter 32 bit).

    OK, so BINT32 project was very interesting and it was a real challenge for us. We did it with great passion and I think for this reason we decided it could be a good start for something more complex, something to be used also from other people for developing general purpose script applications. So we started to release the project in public under the name of thinBasic (Roberto found this nice name), with a support web site and a forum. One of the first things we recognized was that we could not make a so big project alone. So we started to think about a possible way for sharing development time and resources and also how to open thinBasic development to other people in an easy and independent mode. The answer was: create a modular structured language made of many specialized modules developed and maintained independently even from different users. Every module is in change of different language aspects (for example file handling, console, user interface, OpenGl, and many others) and automatically loaded at script runtime by the Core engine only if script needs it. Thanks to the decision to share thinBasic development we were so lucky to meet the person we think was one of the reason why thinBasic is where it is now. This person is Petr Schreiber currently in change of TBGL development, the thinBasic module that bring the power of OpenGl (plus much more) to thinBasic language. Thanks to the immediate passion Petr showed for the project and to his constant support, we can consider this the real thinBasic starting.

  • E.K.V Hell, you got me too excited here. Your passion is infectious type. Though thinBasic is pretty new, it seems to be very all-round and popular language. What is the power of thinBasic, not in the eyes of thinBasic developer team but an average programmer who just uses it for he's/her programs? And where you see most irritating weaknes of it?

    E.O Passion: it is the magic word we always search. With no passion (in whatever field) the road will be short. This is something we believe in. Well, I think the first power item I list is thinBasic community. It is a little community made of passionated programmers that are always very happy to help each other and new users. It is strange the feeling we were able to create in thinBasic forum. Something to try for a while and see. Very difficult to explain but very tangible where you frequent for a while thinBasic forum. For a new user this is very important: good feeling.

    Going to more tech aspects I think 3 important items are: thinBasic coherent syntax, many native data types, thinBasic support.

    Coherent syntax.
    thinBasic is 90% developed using Power Basic compiler. We loved Power Basic clear syntax and we were inspired by it. thinBasic syntax is very easy to be learned especially for people having some Basic basis. Many commands are the same as other Basic dialect but we have always tried to keep them close to the original Basic language. So thinBasic is easy to be mastered from a language point of view.

    Many native data types.
    thinBasic has a full arsenal of native data types, from mainly all numeric data to fixed and dynamic strings to variants to user defined types: byte, word, dword, long, quad, single, double, extended, currency, fixed asciiz string, fized strings, dynamic strings, variant, and finally any data type defined by the user like, for example, any complex structure.

    Well, many recent languages (especially interpreted) have chosen to not implement specific data types but have just one general purpose variable type able to store any kind of data. While we think this can be a good things for many users, at the same time we think this approach is not good for all programmers enough curious to understand what its going on just one step after the curtains. As soon a programmer wants to deal with something a little bit more difficult than showing some data with a messagebox or deal with windows API or with external libraries, data types have a fundamental importance. Programmer has to know the difference between all numeric data types and between fixed strings and dynamic strings. In any case for those loving just one data type, variants are there able to store any data type.

    thinBasic support.
    So far we think we have been able to give a profession support to all thinBasic users even if thinBasic is free. We always listen to our user and most of the time users requests are developed in a very short time. Users are the best present a developer team can have. Users on thinBasic forum have helped us to give stability and reliability to thinBasic. Users have helped us to develop a good and quite professional help material. Users have helped us to fix so many bugs that we will never say enough thanks to them. From our side what we can do is to be open to users requests, I mean open mind that is listen, try to understand, develop together what is the best way or the best syntax for new features. We will try our best to go on on this strategy.

    Other good points can be: enormous number of commands (more than 1000), obfuscated scripts, bundled scripts (stand alone executables), integrated editor (thinAir) 100% developed by thinBasic (Roberto is in change of thinAir development), integrated help, full access to Windows API interface, access to any 3rd party dll library, modular structure automatically handled by thinBasic engine, and of course the many modules already developed by thinBasic or 3rd party users. A very partial list of interesting modules ready to be used for developing interesting script is: TBGL (OpenGl module by Petr Schreiber), TBDI (Direct input module by *Michael Hartlef*), TBASS module (a wrapper of the fantastic BASS music and sound library), AStar (a nice module developed by Randal and working on A* -A Star- path-finding algorithm), and many others you will find after installing thinBasic.

    Now on "most irritating weakness".
    The most frequent observation many users do is that thinBasic is not multi platform. I can understand this observation but I cannot do anything about that. The main reason is because thinBasic is developed using Power Basic compiler and Power Basic is not multi platform. We have already written more than 150000 lines of code and porting this massive sources into a new language is not something we can do at the moment. Other things I feel bad about thinBasic are: no multi threads, interpreted language (some consider interpreted languages not programming languages), access to the full range of COM servers is not supported, a more advanced IDE with integrated intelly sense features, some more execution speed (thinBasic is quite fast but we want it even faster in future).

  • E.K.V Youre also a natural atmosphere killer. You basicly just sayd "No linux/unix port coming in few years at least, if at all."?

    E.O Well, while I was replying at previous question I suspected this argument would have come out.
    First of all we must be honest. I think one thing our little community has appreciated during those years is our honesty and our way of telling what we could and could not do. We will never say something will be done if we are not sure we are going to do it. And I will keep this approach also on this question: we are not working on any port of thinBasic to systems other than Windows. Of course we think about it, we think on what are the possible roads to follow, we think what development environments can suit our needs to achive this porting. But those are just our brain storming discussions and discussions are not something concrete, something on which we can say to thinBasic community that some day in the near future we will port thinBasic under *nix.

    Just recently we have released a thinBasic SDK for FreeBasic. Using this SDK and FreeBasic it is now possible to build new thinBasic modules. Doing this job and during our learning of Freebasic I have to say I appreciate a lot the work done on FreeBasic. It is a great language full of possibilities and power.

    On the other side there is C. Roberto, thinBasic co-author, is a master in C. C can be the other possible choice as future development environment for thinBasic.

    But again, just thinking and looking around. We have still to finish our road in current environment (Windows). A lot of tuning and improvements are still to be finished and implemented. We are just at the beginning even if a lot of work has already been done. And we are here to stay.

  • E.K.V From a language, back to developers. Own language is something that every programmer dreams of at some part of their lifes. Now if you look back and consider what was something that it should not be like that? Was it harder to create own language than you thought or maybe easier? What were the major surprises that you, and your dev-team friends met in proces of creating thinBasic? General feeling of proces you have allready done there?

    E.O I do not consider myself a guru but just a person with a passion: programming. And, to be more specific, a passion in parsers, algorithms and optimizations. I think that passion in something can give enough force to face problems that at first seem impossible to be solved. Another important characteristic is: method. You need to have method when facing problems, nothing more than some rules to follow with any distractions. For me the method is always to break big aspects of the same problem into simpler one easy to be solved. It seems banal but it works. That said, every programmer can create its own programming language, maybe just for fun. Of course Im talking about interpreters and not compilers for which other competences are needed.

    Looking back there are many things I would change in thinBasic and to be honest this is an exercise that I very frequently do. It has already happen many times to recode complete important part of thinBasic core engine. And, believe me, this gives a lot of satisfactions because most of the time the new produced code is better, faster, more easy to maintain for future development. It is something I suggest to every programmer having the time to do it. Always go back and try to optimize again what was supposed to be the state of the art.

    The hardest part in developing thinBasic was the initial point. The main reasons was because at that point I had to make some important decisions that would have effected the whole project from that point on. What language to use, what parsing method to implement, which data structure to implement, start from the very base or search for some code already implemented. All problems that needed a decision to be made and some decisions were the base stones on which to build the full project.

    The easiest part was and is implementing new functionalities. We implemented a method to add new features that now let us develop a new keyword and new functions in a snap. Also other users using different compiled languages can implement new thinBasic keywords and features. The trick is thinBasic modular structure. I will not talk about this because only for this items a full session is needed. Maybe this is the right argument for a deeper excursion around thinBasic.

    For me (I can talk only for myself) the nicer and major surprise was to quickly find some other guy like me having programming passion and in particular passion in thinBasic project. This, for me, was really a very potent motivation to go on every time I had a problem. Talking with those guy in thinBasic forum gave me good sensations, good reasons to go on and face every single problem. It worked and it is still working.

  • E.K.V Do you co-operate with developers of some other languages or is it bloody war of users and attention?

    E.O No wars here :D of any kind. I sometimes chat with Gerome, on of the authors of FBSL language. We talk about how each of the team have solved common programming problems, we exchange ideas of possible solutions. Very nice talking. Anyhow, we are not competing with anyone, we follow our road but at the same time we are always open to positive "contaminations". In any case, so far there were no real occasion to have real connections with other development teams.

  • E.K.V Any greetings to readers you might want to say here?

    E.O If the reader has reached this point of the article I suppose there is some kind of interest in thinBasic. So the only two things I can say more are:

    • 1. try thinBasic by yourself looking at the many test scripts your will find in thinBasic installation. See if thinBasic can help you in your programming passion or in your job needs

    • 2. visit our community forum and see by yourself what is the thinBasic atmosphere we are talking about. I'm sure you will find a good place where to talk not only about thinBasic but about the many arguments that can be touched in developing applications.

    • We will listen to you and we will do our best to improve our thinBasic support.

    Ciao a tutti, Eros Olmi

    (hello to everyone)

    Thanks for Eros Olmi for giving us this interview and all the best for whole dev-team of thinBasic


~ REVIEWS, PRESENTATIONS AND EDITORIALS ~

VIXEN: An XBLITE GUI Generator by Guy "gl" Lonne


What is VIXEN:

VIXEN is a WYSIWYG screen designer and a GUI application generator for the XBLITE programming language. It is a programming tool made for Xbliters by Xbliters.

VIXEN is not part of the official distribution and is still a work in progress. That is to say that VIXEN is still in its infancy.

What is XBLITE? Glad you asked! XBLITE is an Open-Source BASIC-like programming language, initiated by David SZAFRANSKI. David distributes a complete development suite for Windows applications. For more information, read an "Introductory Article On XBLITE" at PCopy! #40 and visit David's website perso.orange.fr/XBLITE/.

A complete development suite? Well, IMHO not without VIXEN...

If writing console applications is quite easy in XBLITE, developing Windows GUI applications is much more difficult. Some XBLITE Newbies thought of "canning" their growing knowledge in a tool: a visual XBLITE environment, a.k.a. VIXEN. VIXEN allows to create preview windows, add controls to them, tweak some parameters and generate a Windows GUI application in XBLITE with the same look as the preview windows'. Not new under the sun but such an interesting programming challenge!

What is not VIXEN

VIXEN is not an IDE. View VIXEN rather as an addin to XSED, XBLITE's source editor.

See VIXEN as an improved template tool for XBLITE GUI applications, coupled with a GUI prototyper. VIXEN is intended to produce a program "XSED-ready". XSED remains the central tool for XBLITE programming and VIXEN merely generates a "fill-in-the-blanks" XBLITE GUI skeleton.

The VIXEN Project

While exploring XBLITE possibilities in Windows GUI programming, John "prujohn" Evans felt that a WYSIWYG application designer for XBLITE would be a good addition. He started the XBLITE project "XBLITE GUI designer" at SourceForge mid-2006 and proposed a beta version for download as early as 22 July 2006 (version 0.50a). I applied to the VIXEN project as a developer and I contributed at the time with a few niceties.

At this point, prujohn decided rightfully that VIXEN was useful enough. However, as a plain User, I felt that VIXEN was useful but rough. True to the OpenSource concept and building on prujohn's foundations, I expanded VIXEN to be more flexible and feature-rich, generating quality XBLITE source. The very process of developing VIXEN feeding back VIXEN itself, the current version of VIXEN allows several kinds of generation: GUI application using the Win32 API or WinX, a windowing library finely crafted in XBLITE by Callum Lowcay, with a concise or verbose source, with debugging wrappers, ASCII or Unicode...

For added comfort at preview time, a drag and resize control was implemented, derived from a Visual Basic custom control. David ported to XBLITE the custom control "VBThunder Forms Designer" at vbthunder.com, with Ben Baird's permission (the Author), thanks to his generosity. Burning some midnight oil, Rhett "lzdude69" Thomson contributed with icon and XP style handling.

Feeling that VIXEN deserved a better icon, I organized a beauty context at XBLITE Google Group. VIXEN received its current icon, a submission of Callum Lowcay, WinX's author.

Then, VIXEN needed a tester. Don B. was unlucky enough to have VIXEN crash on him regularly when attempting to change the look of his preview controls and windows. Nominated VIXEN's tester, he got special attention from the VIXEN team to go through this difficult time.

How to download VIXEN

The latest version of VIXEN is available for download at URL: http://groups.google.com/group/XBLITE/

Since GOOGLE does not allow posting executable files, your download makes believe GOOGLE that it does not contain any, not even an installation application such as VIXEN_setup.exe. This is the reason why VIXEN_v*.zip contains VIXEN_setup.zip and google_install.txt.

How to install VIXEN

You downloaded VIXEN_v1_??.zip from XBLITE Google group; to install VIXEN on your computer:

  • 1. Copy the file \My documents\My downloads\VIXEN_v*.zip in C:\temp (for instance)
  • 2. Unzip it in C:\temp
  • 3. Rename C:\temp\VIXEN_v*\ google_install.txt to google_install.bat
  • 4. double-click on google_install.bat (an XBLITE project is created in folder C:\XBLITE\src\vxbl)
  • 5. Answer to VIXEN_setup.exe (the installation program), launched by google_install.bat
  • 6. Copy the shortcut created on your desktop and pointing to ...\vxbl.exe into C:\XBLITE\bin\tools, so that you can launch VIXEN within XSED
  • 7. Clean up by deleting your folder C:\temp\VIXEN_v(*)

(*) is VIXEN's version, i. e. "1_36" for version 1.36.

GUI in Win32 API

A GUI application in XBLITE uses the Windows Application Programming Interface a.k.a. Win32 API or WinAPI.

With VIXEN, you can create either a "bare-bone" GUI skeleton or a GUI skeleton with debugging error checking (check menu option Options/Generation/Use Debugging Functions to activate this "fully fleshed" generation).

When to use the generation with debugging functions?

A simple application can be kept simple by priming its development with a GUI skeleton without debug messages. But, the "fully fleshed" skeleton is appropriate for applications promising to become complex.

GUI in WinX DLL

The development of a GUI application in XBLITE using Win32 API requires a lot of hard-earned know-hows. Callum Lowcay designed WinX, a windowing library in XBLITE, to "encapsulate" his experience in writing GUI applications in XBLITE. WinX sits on top of Win32 API and offers a GUI framework.

With VIXEN, you can create either a "bare-bone" WinX skeleton or a WinX skeleton with debugging error checking (menu option Options/Generation/Use Debugging Functions must be checked). Since WinX hides a lot of complexity to the XBLITEr, the "fully fleshed" generation is recommended to track possible execution errors.

A note from Don B. : To use WinX, the LINKer that is distributed with Xblite must either be replaced with a more recent version of the MICROSOFT LINKer or else the WinX source files must be compiled and re-linked with the older LINKer distributed with Xblite.

A primer for VIXEN

  • 1. Start VIXEN; an empty property window appears with the title: "VIXEN v1.36 - Visual GUI Designer for XBLITE"


  • Picture 1: VIXEN's startup screen.

  • 2. Type Ctrl+N "New Project...":
    - VIXEN displays a dialog with the title "Message From VIXEN": Create a new project?

  • 3. Press Enter to answer Yes:
    - VIXEN creates a preview widow called winMain, with the title "(change me)", begging to be replaced

  • 4. Change whatever you like: for example the title "(change me)" for "My First GUI Application For XBLITE"
    - Observe that VIXEN accounts for your changes after you tab the property entry box off or click it off

  • 5. Click on the Navigation tree node winMain to make it current and add a text label with Ctrl+L (or with the menu option "Controls/Text Label");
    - VIXEN creates a label preview control, wrapped with a red sizer control since VIXEN offers no other way to move/resize a text label, in your preview window

  • 6. Position the new label preview control with your mouse since VIXEN placed the mouse cursor on the "move gripper"

  • 7. Change"(change me)" to, say, "My Text Label"

  • 8. Grab the right edge to adjust its length to the text

  • 9. Create an "OK" button by clicking on the window's node, CtrL+B (or select the menu option "Buttons/Push Button") replacing "btn2" by "btnOK" in the "New Control" dialog

  • 10. Select the entire text "(change me)" and overtype "OK"

  • 11. Drag the new preview button to the proper position

  • 12. Click on node "lbl1" to make it current:
    - VIXEN places the mouse cursor over the move gripper to allow to move around the preview label; I realize that it is an oddity but I did not find any other way to prepare a text label (or a combo box for instance) for a "mouse move/resize" operation


  • Picture 2: how VIXEN looks in my computer after step 12.


  • 13. Save this outstanding VIXEN project by Ctrl+Shift+S (or by the menu option "File/Save As...") in project file "GUI101" for illustration sake;
    - Notice that the menu option "File/Save" is disabled

  • 14. Generate your GUI application with Ctrl+G (or with the menu option "Generate/Generate XBLITE Source")
    - VIXEN displays the message "Generation switches that are on:", followed by a list of switches that are turned on/off with menu options "Options/Generation/Use Windows API, ..., Source Verbose Mode"

  • 15. I suggest that you cancel the generation in order to set on the generation switch "Options/Generation/Source Verbose Mode", which sets VIXEN in a pedagogic mode (pedantic for seasoned VIXENers)


  • Picture 3: setting VIXEN's generation switches (menu option "Options/Generation").


  • 16. Re-Ctrl+G, Enter to validate the switches setting, Enter again on the XBLITE source file name and hopefully VIXEN sends you the victory message:
    "Now you can paste with Ctrl+V the generated XBLITE source path c:\dev\XBLITE\XBLITE bok\articles\gui101.x" (which I did in this very article since I am writing it along with a VIXEN session)

  • 17. Start your favorite programmer editor (mine is XSED), start the open file dialog with Ctrl+O and paste with Ctr+V the path in the file name entry box:
    it is now programming time!


Picture 4: running VIXEN as an XSED addin (XSED menu option "Tools/vixen.lnk").


VIXEN is designed to be seamlessly integrated into the XBLITE installation. Its About window gives some useful information on the setup and the HELP file is short but to the point.


Picture 5: showing VIXEN's About (menu option "Help/About...").


Picture 6: using VIXEN's help (menu option "Help/Help...").

A time to preview, a time to code

Since I held your hand from prototyping your first GUI application with VIXEN to generating it, ready for fleshing out its skeleton with XSED, let me just add that, at this point, I forget VIXEN to switch to XSED.

Usually, I run XSED, open the generated source with Ctrl+O and Ctrl+V, I quickly compile the program with F9, link the compiler-generated object with F10 and run the resulting executable with F11.

Until now, all the running applications I obtained were identical to their VIXEN project; only now, I could say with elation "It's alive!"

Conclusion

If VIXEN did not exist, I would have to invent it! Seriously, prujohn provided with a useful tool. Any Newbie to XBLITE will save time by prototyping a Windows GUI application on a WYSIWYG mode and by generating a working skeleton with some tried and true coding techniques.

Thanks prujohn for VIXEN! And thanks D. for XBLITE!

Guy "gl" Lonne, 2 November 2007


Introducing Fatal Method Games by FMG Team


Hi peoples.

We would like to introduce to you our small Fatal Method Games (often shortened as FMG) game programming team.

Fun is our primary issue when we create these games, mostly with generally considered as "interesting" ideas such as killing a monsters and space fight's. We like PCopy! ezine so we thought to boost-up our games here a bit, by sending a letter to editor. Our primary programming language is Finnish made CoolBASIC, but .dll's are created with C++. Soon we are goin to move on at Blitz 3D, which will give us better and more powerful dimensions in our game developement. But most of all, BASIC languages are best in our purposes, which are to create games and fast as possible.

        
Angels Of Fury II & NetMatch - The End by Fatal Method Games.

We wish you peoples to check out our games, and give us constructive feed-back so we can create better games all the time while we advance as programmers ourself too.

Email: fatalmethod@gmail.com Url: www.fatalmethodgames.com

Fatal Method Games developement team

More about smallBasic by Chris Warren-Smith


User Defined Structures

A new feature recently added to SmallBASIC is user defined structures (UDS). This feature follows the "declare by usage" model of regular basic variables. A UDS works more like an ad-hoc compound variable rather than a fixed size predeclared struct found in say the "C" language.

Here's an example:


		dog.legs = 4
		dog.name = "sheba"
		animals << dog
		? animals(0).name ' prints sheba
		? animals(0).legs ' prints 4
		

The "<<" symbol above tells SmallBASIC to add dog as an element to the animals array. Being the first animal added the dog lives in the zeroth element, ie animals(0).

Here's how this code would have been written without use of user defined structures:


		dog << "4"
		dog << "sheba"
		animals << dog
		? animals(0)(0) ' prints sheba
		? animals(0)(1) ' prints 4
		

As you can see the UDS feature helps you to better organize your code and make it more readable.

Short circuit evaluation

SmallBASIC can now perform short circuit evaluation around logical OR and AND expressions. Let's go straight to an example:


		func foo(id)
		  ? "foo entered:"; id
		  foo = 1
		end

		func false_foo
		  false_foo = 0
		end

		func true_foo
		  true_foo = 1
		end

		if false_foo AND foo(1) then
		  ? "1. false_foo AND foo
		fi

		if true_foo AND foo(2) then
		  ? "2. true_foo AND foo
		fi

		if true_foo OR foo(3) then
		  ? "3. true_foo OR foo
		fi

		if false_foo OR foo(4) then
		  ? "4. false_foo OR foo
		fi
		

The output from the test is:


		foo entered:2
		2. true_foo AND foo
		3. true_foo OR foo
		foo entered:4
		4. false_foo OR foo
		

In the first IF test, since the false_foo function returns FALSE there is no point evaluating foo(1) since we already know that the overall result will be FALSE. In the second IF test the true_foo function returns TRUE. foo(2) is then entered to see if it will also return TRUE and since it does the second line of output is printed. See if you can work out what's happening with the other lines.

Wrap up

That's all I have time to talk about in this edition. In the next edition I would like to tell you about some improvements to SmallBASIC units and also how to setup the gedit text editor as an IDE for SmallBASIC on Ubuntu.

Chris Warren-Smith

3D graphics in thinBASIC: by Petr Schreiber


If you read last issue of PCOPY carefully, you probably didn't missed mention about thinBASIC, interpreted language from Italy. ThinBASIC was designed as modular language from the beginning, so quite soon after I realized how friendly authors and community around this language was, I started to think about creating my own module to enhance thinBASIC graphic capabilities. And about this module you can get the latest information right now!

Brief trip to the history

  Tree created completely using script, TBGL Cylinder primitive and alpha mapped leafs provide the illusion

TBGL was born as nothing more than just simple OpenGL wrapper. In those early and mysterious times, when I met thinBASIC during late summer 2005, it was not possible to write headers for DLLs as it is possible (and very comfortably) now.

When working in other languages I always hated the part of creating OpenGL window, choosing proper pixel formats and managing windows loop, so this was first thing added to the module. Then I added my favorite set of functionalities I frequently used in classic OpenGL, like functions for translations, rotations, scaling and changing rendering states.

That was how TBGL looked at the beginning, but years have passed :)

Great encouragement for me was when TBGL was added to thinBASIC on December 2005, that was month with double Xmas for me.

ThinBASIC was enhanced by ability to create header files to access classic DLLs later, so I did translation of classic OpenGL headers to thinBASIC, to not wrap function one by one like mad to TBGL module. It was interesting period as I was thinking what to do with TBGL now.

The situation was the same as in most general purpose languages. You got the OpenGL 1.1 headers, you had way to create OpenGL window. But then it would not be of much advantage comparing to other languages, wouldn't it?

What can you do with graphics NOW

TBGL and tools around now have much larger possibilities than in those early times. First thing everybody solves is how to create and handle 3D models. There are thousands of formats and modelers currently. The most awarded, 3D Studio Max and Maya are powerful but also very expensive, especially for us, poor mortals. And their file formats are quite complicated.

So I created new file format which allows defining geometry, color and texture for vertices, as well as organizing part of model to layers. Format is called M15, it is very simple and with open specification available to everybody.

Ok, we got the format, but we need to get some generator for it. For this I created thinEdge, 3D modeler with basic functionality which allows creating M15 models. If you do not like this program, you can use any 3D editor able of producing OBJ files and use thinEdge to just import it and export data in M15 format. thinEdge was used for media creation in RobotDuel game.

Situation gets even better, as Michael Hartlef created direct M15 exporter for now very well known and powerful Blender modeler. This way models for thinBASIC game called "TopDown 3D" were created as well as very interesting demo showing how to do 2.5D graphics found in adventure games like Syberia or Paradise. Draw 2D background and place over 3D object can do anybody, but to make 3D object clipped by prerendered geometry we can thanks to little trick TBGL allows.

Michael Hartlef's adventure like 2.5D graphics. Rendered background and real time sphere which respects scene depth

TBGL can directly not just load the models, but even create and modify them in realtime. Animation of models can be done in two ways. The first is more general approach using which you control directly each vertex using functions such a TBGL_m15SetVertexXYZ, TBGL_m15SetVertexRGB... There are tens of functions just to manipulate the models. Using these functions it is possible to do more general animations of models, such as making grass turfs wave in the wind, simulating water drops in the lake or simply animate texture on the model using UV coordinates manipulation.

Fact is for some kind of animations this approach would mean too much work. Take for example facial animation or posing generally.

Few lines of code and you can create very different animations

For this reason, TBGL provides basic mechanism of virtual bones, which you can attach to models and then easily rotate to produce wide range of animations.

These functions were demonstrated in few basic projects like animation of human and zombie character or chimpanzee facial animation.

You should see picture with 3 heads somewhere nearby. The face on the right side is original model, where I color-keyed unique bones. Then in TBGL you could just filter vertices according color and pass them to appropriate bones. Of course you can define this way, but for other cases you might find it more practical to specify them using bounding box or named layer.

To create expression you can see on the left face you need just few lines of code:

         
		tbgl_m15ResetBones %MODEL_HEAD
		tbgl_m15RotBoneX %MODEL_HEAD, %BONE_JAW_BOTTOM, 10
		tbgl_m15RotBoneX %MODEL_HEAD, %BONE_JAW_UP, -1
		tbgl_m15RotBoneZ %MODEL_HEAD, %BONE_EYEBROW_LEFT,-7
		tbgl_m15RotBoneZ %MODEL_HEAD, %BONE_EYEBROW_RIGHT,7
		tbgl_m15ApplyBones %MODEL_HEAD
		tbgl_m15DrawModel %MODEL_HEAD
      

Latest big addition

TBGL module would never be so widely usable without user suggestions. As thinBASIC popularity grows from day to day, more and more users come with interesting ideas for practical features. This way also idea for most of latest TBGL version command set was born.

The latest TBGL allows unified control over entities, grouped in scenes. Entities are of many kinds - cameras, lights, pivots, geometric primitives. You can create more scenes, and group entities in them as you need.

Entity system scheme

Advantage of entity system is that you can predefine multiple cameras, multiple lights (more than hardware supports) and then just enable / disable them as you need.

Resulting animation of Planet And Moon

Here is complete code to show planet and its Moon, to give you idea how do you code using entity system.

You need to create TBGL window as usual, then create scene to have some place to put entities in. For Planet and Moon scene we will need 4 entities - camera, light ( to eliminate flat look ), plus the mentioned Space objects, expressed using spheres. I marked objects with equates, which are expressed in TBGL using %name, you could use just numbers or classic variables too of course:


'=============================================================================
'=                             Simple scene with                             =
'=                             planet-moon model                             =
'=============================================================================

Uses "TBGL" 
Dim hWnd As Dword 

hWnd = TBGL_CreateWindowEx("Planet And Its Moon - press ESC to quit", 640, 480, 32, 0) 
		TBGL_ShowWindow 

%MY_SPACE = 1
tbgl_SceneCreate(%MY_SPACE)
  
%eCamera = 1
tbgl_EntityCreatecamera(%MY_SPACE, %eCamera)  
tbgl_EntitySetPos(%MY_SPACE, %eCamera, 10, 10, 10)  
tbgl_EntitySetTargetPos(%MY_SPACE, %eCamera, 0, 0, 0)  
	%eLight = 2
	tbgl_EntityCreateLight(%MY_SPACE, %eLight, 0, %TBGL_LIGHTTYPE_POINT)  
	tbgl_EntitySetPos(%MY_SPACE, %eLight, 10, 10, 10)          
    
	%ePlanet = 10
	tbgl_EntityCreateSphere(%MY_SPACE, %ePlanet, 0, 1)
	tbgl_EntitySetColor(%MY_SPACE, %ePlanet, 0, 0, 255)
    
	%eMoon = 20
	tbgl_EntityCreateSphere(%MY_SPACE, %eMoon, %ePlanet, 0.5)
	tbgl_EntitySetColor(%MY_SPACE, %eMoon, 128, 128, 128)  
	tbgl_EntitySetPos(%MY_SPACE, %eMoon, 5, 0, 0)
  
	TBGL_GetAsyncKeyState(-1) ' -- Resets status of all keys 

	While TBGL_IsWindow(hWnd) 

	' -- After this you start drawing
		TBGL_ClearFrame 
    
	' -- Rotate Planet
      tbgl_EntityTurn(%MY_SPACE, %ePlanet, 0, 1, 0)
	' -- Rotate Moon      
	tbgl_EntityTurn(%MY_SPACE, %eMoon, 0, 2, 0)
      
	' -- Render whole scene using one line of code
	tbgl_SceneRender(%MY_SPACE)

	' -- DrawFrame makes all geometry visible on the screen
	TBGL_DrawFrame 

	' -- ESC key to exit our program
	If TBGL_GetWindowKeyState(hWnd, %VK_ESCAPE) Then Exit While 

	Wend 

	TBGL_DestroyWindow              
		

Entity system saves you also lot of calculations, imagine you would have to track point in which gun on airplane is placed. Madness. But with TBGL it is now very easy. If you know, that gun was located on original model at position ( 2, 0, 0 ), then just call:

TBGL_EntityTrackPos( %MY_SCENE, %MY_AIRPLANE, 2, 0, 0, globalX, globalY, globalZ )

To passed variables, in this case globalX, globalY and globalZ, you will retrieve the current location, does not depend if model is standing on the head on other side of the planet. And TBGL is full of such a tiny utility functions, you can also retrieve local axes of the entities, make them look at some location or even other entity. That all often using single line of code...

If you want to move camera in 3D space you do not need to struggle with SIN/COS or multiply matrices, just use TBGL_EntityPush, TBGL_EntityTurn and you are done!

Typical entity usage: Lamp is composed from multiple parts, it has spotlight attached. You can use keys to enlight that thousand of rotating entities

Thanks to parent-child system you can do things which were before too bothering to do, like simply attach two spotlight sources to model of car. Then when you move car, lights go with it and preserve car direction.

Also good to know rendering entity systems is very fast, on modern PCs you can get even thousands entities at very convenient framerates.

I could speak about new system for hours, but it will be better if you will get thinBASIC preview and try it yourself. Help file provides information for all keywords, and usually contains tiny code snippets to make more clear how function works.

Screenshot from older script. Ship navigates using space, and can shoot both AI powered enemy or calm asteroids.Models by Michael Hartlef and Kent Sarikaya

Hope I did not bored you too much, and if you even feel you are ... yes, even curious and hungry for more information :), then please do not forget to visit thinBASIC forums and also special TBGL module website.

References

Website: http://www.thinbasic.com
Support forum: http://community.thinbasic.com
TBGL website: http://psch.thinbasic.com/



~ TUTORIALS & HOWTO's~

Coding Functions: by Guy "gl" Lonne


Coding functions.

I am amazed when I meet functions Craftsmen. These talented Coders not only solve the problem at hand, but also share their solving tools. However, they display a special skill: function coding. I tried to draw some pointers from them to become myself a function contributor. So should you too.

Introduction

Writing functions is a good way to break down your program into manageable actions. Here are some pointers that I drew from my past experience in XBLITE programming.

My rule book

  • Good programming habits crop up to good programming practices.
  • A function saved is a function earned!
  • No conventions is worse than bad conventions.
  • Don't get too smart with XBLITE standard functions.

Here is my proposed set of conventions to code a function.

Function naming convention

  • Choose a prefix to follow an object-like convention
    Ex.: Gui for GUI-related functions, GuiTellApiError ()' display the API error message

  • Build a sentence, starting with an action verb, used as an order to the computer (imperative form)
    Ex.: ShowBiz ()

  • Your function names should use consistent set of action verbs

Examples:

		cell_GetVal () ' get a cell's value
		cell_SetVal () ' change a cell's value
		cell_ResetVal ()' initialize a cell's value
		cell_GetString$ () ' get a cell's text
		
  • "Get" meaning that you retrieve a value
  • "$" indicating that the value is a string

Function behavior

  • Input parameters of a function have a regular variable name
    Ex.: MyFun (inputParam)

  • Output parameters of a function are prefixed by "r_" (for returned)
    Ex.: MyFun (@r_outputParam)

  • Input /Output parameters are also prefixed by "r_"
    Ex.: MyFun (@r_inputOutputParam)

Tip: try to avoid Input/Output parameters. Use instead a couple Input parameter/Output parameter.

Guidelines to handle the returned error code

When error checking is important:

  • Old XBasic convention: A function always returns an error flag
    Ex.: bErr = XbasicFun () ' returns an error indicator: $$TRUE = error, $$FALSE = OK!

  • A function can indicate an error by using an error number as the last parameter
    Ex.: cell_Validate (CellX, CellY, @errNum)

Don't name the error number r_errNum since its usage as an output parameter is obvious to anybody.

  • A function can indicate an error by returning an error number
    Ex.: errNum = Dog_FetchStickErr("Fido"), which, to the educated XBLITEr, translates into:
    You: "Fido, go fetch the stick!"
    (After a while, Fido returns to his Master)
    Fido: "Can't fetch the stick. Erreur # 1: I couldn't find that damned waff (bark)!"

  • A function could report an error by returning an error message or an empty string
    Ex.: errMsg$ = man_DoSomethingErr("Guy"), which you should read:
    "Men do make mistakes and Guy tried and failed to do something.
    Come on, Guy! Tell us what went wrong!"

I must admit that this error reporting might be far too sophisticated to be practical.

XBLITE functions

Don't get too smart with XBLITE standard functions.

These functions are designed for covering a lot of ground as they address the needs of a wide user community. You will recognize an XBLITE standard function because it starts with the "Xst" prefix.

For example, Liviu from the XBLITE Google group reported the following glitch:

  • XstLoadData(@new[], "555", $$XLONG) doesn't not work,
  • but
  • XstLoadData(@new[], "555,", $$XLONG) will do the job (note the extraneous comma after the figure).

Here is what answered Alan Gent (who designed the function):
"XstLoadData was designed to load a comma separated list of items into an array. If you have just one item, then the function isn't really necessary.


		DIM new[0]
		new[0] = 555
		

By design, XstLoadData (arg1, data$, arg3) takes data$ (the 2nd argument):

  • either 1. As a comma separated figures list,
    or 2. As a file path, if there are no commas in data$."

I would further comment that, since it does not make sense to pass a single figure in a supposed CSV list, I appreciate the added flexibility (the added twist?) to pass a file name instead: clicks logically to think of data$ being either 1 or 2. Yes, I feel comfortable to make it a mental habit when using XstLoadData (). However, this is a very personal comment.

So, instead of adding an additional comma to make believe that it is a CSV list of figures, I would account for singletons and not call XstLoadData (). At the very least, it avoids the call XstLoadData () overhead.

As my rule book says: If it ain't helping, chances are it is hurting!

Meaning: Be to the point! Avoid the fat! Produce lean and mean code!

Conclusion

When coding a function, always keep in the back of your mind that this very function could be your legacy to the XBLITE posterity.

What I mean is that it is a potential good candidate to end up in a library. So, get into the habit to code every function as a future building block.

Remember: Good programming habits crop up to good programming practices.

And: A function saved is a function earned!

Credit

Among all the books on programming I read, there is one that changed a lot my view on the programming activity: "C Programming Proverbs and Quick Reference" from Ron WODASKI. This book still sits on my shelf, after 20 years of loyal service. Let the record show that I still read it from time to time, just for pleasure. It is because of this book that I wrote, with much less talent, this short article.

Guy "gl" Lonne, 22 September 2007


Exit Issue: by E.K.Virtanen


...and thats all folks for this time.
I hope you did like and find something interesting from this release of PCOPY! and this way, keep reading of future releases. If not, tell us what we did wrong so we can make this magazine better and better all the time. We ain't professionals but we learn all the time and this way, we get better.

We're completely opened to suggestions. If there's something you would like to see appear in PCOPY! if it's basic related chances are it can and will be included. So don't be affraid to tell us all about it and if it's worth being in PCOPY! you can bet that it will be included as soon as possible.

Don't forget to be on the lookout for the next release of PCOPY! where we'll do our very best to bring you news and other related contents about any and all BASIC dialects out there. There's a big list, going through each of these languages to get the news is a great task but I believe we're taking up this challenge head on to get you the good stuff. We hope you liked it and will continue to like in the future.

Until our next edition, this is PCOPY! signing off.