PCOPY! Issue #50 ~ November 16th 2007
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)
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é)
Guy (gl) Lonné
Fatal Method Games
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 email@example.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.
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 firstname.lastname@example.org 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!
Letter from MystikShadows
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
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.
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
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 !
Letter from tunginobi
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.
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
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
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!
QB Express #26 deadline
FBPackage Issue #1 Released October 07, 2007.
Work to improve and update smallBasic website
13 Nov 2007 - Gambas 2.0 First Release Candidate
The home of BBC BASIC
Newsbrief by MystikShadows (stephane Richard): QB64 Project
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!
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.
Articles & EditorialsBounce 3: On the Town - Lurah
Tutorials3D Explanations & Simulations: Part 1 - Aroticoz
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 :)
Articles & EditorialsArticles & Editorials
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
Competitions and Challenges
Articles & EditorialsTravellin in a BASIC land
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.
Reviews And Presentations:
Tutorials:Programming Simulation Games (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 email@example.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.
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?
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.
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.
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:
(*) 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
Picture 1: VIXEN's startup screen.
Picture 2: how VIXEN looks in my computer after step 12.
Picture 3: setting VIXEN's generation switches (menu option "Options/Generation").
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!"
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
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.
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.
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.
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
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.
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.
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.
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.
Here is complete code to show planet and its Moon, to give you idea how do you code using entity system.
'============================================================================= '= 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!
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.
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.
~ TUTORIALS & HOWTO's~
Coding Functions: by Guy "gl" Lonne
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.
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
Here is my proposed set of conventions to code a function.
Function naming convention
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
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:
Don't name the error number r_errNum since its usage as an output parameter is obvious to anybody.
I must admit that this error reporting might be far too sophisticated to be practical.
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:
Here is what answered Alan Gent (who designed the function):
DIM new new = 555
By design, XstLoadData (arg1, data$, arg3) takes data$ (the 2nd argument):
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!
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!
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.
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.