Feature: FF8 Flashback Tutorial
Posted by Nick on 22 March 2000, 04:05 GMT

Jason Hsu is the third one to have a feature here. This BASIC tutorial covers clearing the draw buffer and some other graphics-related applications.

FF8 Flashback

by Jason Hsu

Intro

My current project, for all you FF8 players out there, is called TT. Can you guess what it is? That's right! It is a fully working port of Triple Triad for the 89. For leisure programmers, good project ideas can often times come from mini-games in larger games commercially available. If you have not played FF8 before, Triple Triad is a simple card game which uses a higher number beats lowers wins. Check out www.tripletriadonline.com to play a online version of the game. Small projects like these are such that they can conveniently fit within a couple of k for the main executable and maybe 10k for the data files. Try to plan ahead a project that is of a magnitude that is completable by yourself within a month. From past experience, it is difficult to complete anything that spans more than a month. For now, we'll assume that you have some minor experience in the 89 BASIC set. We are going to be exploring some of the more interesting optimization routines i made for TT.

The first optimization: clean draw buffer

I used to actually download basic programs for my 86 and run them. USED to. The problem with most beginner programmers is that they are, pardon the metaphor, like little children in their use of the draw buffer. I have had programs which didn't erase the draw buffer, or left the axes there when loading a picture, or left the draw buffer as it was when it exited. Let me stress that cleaning up is VERY IMPORTANT in elegant coding. Does Microsoft Word leave the document on the screen when it exits? Of course not! All programs must remove any trace of presence so that the next one may run from a clean slate. Of course, just saying this is one thing, and implementing this is another. Lets take a sneak peek at some simple-to-implement TT code which handles this problem. Before we look at the code, we need to make clear the convention used in TT. TT runs in its own folder (tt), so in case a fatal crash occurs mid-run, there wont be temporary variables strewn across (main). All of TT's runtime files are prefixed as tt_ for posterity. Any temporary files that are needed to restore the draw buffer are prefixed as tm_. Our objective is to 1) maintain anything the user has in the draw buffer when the program terminates. 2) maintain all graphs and graphing settings the user has when the program terminates. 3) turn off axes, and set the window to single point increments in case any pt__ commands have to be used (try to avoid pt__ commands in favor of px__ commands whenever possible, ill explain later). 4) clear the screen in preparation of main runtime. 5) change the working folder to tt, but maintain the original folder upon termination. Here are the first few lines of code, explanation follows in the next paragraph.

The three distinct parts of code here are define local, entry, and exit. In between entry and exit there is also a main, which is body of the code, but we will be focusing on only these three parts today. First of all, note how the different parts of code are blocked off with spacing and comments (c) to help aid in debugging and rewriting code. The first section is define local. Only one command is stated under here and that is the Local command, with an arbitarary number of arguments. Here, Local has 4 arguments, which are tm_fold, tm_pic... etc. A look at Appendix A (the 89 command Bible) in the instruction manual reveals that Local establishes that the following variables are to be deleted upon termination of program. Simply put, if any variable declared in the Local command is defined later in the program (say, from a storage), it will AUTOMATICALLY be deleted when the program is done. This is very useful as it relieves stress in the last few lines of code from excessive DelVar activity.

The next part of the code is entry. The entry region is not well defined in all programs, but it can roughly be described as everything including declaring variables to loading data. Basically, anything that is before the main menu if a menu is used or before the beginning of the principal routine is part of entry. Again, make sure ENTRY is preceeded with a comment (c) so that the BASIC interpreter will not try to interpret it as a command. The (c) character can be quickly accessed with the keystroke <>-C (diamond-C). Back to the code. The first consideration we must address is getting out of the (main) folder. Among the worst things a BASIC programmer can do is to run all the variables in the main folder and even worse to lay them around without deleting them. This is what I refer to as unaddressed trash. If you are constantly seeing things like 'xxy' or 'x1c' or 'y2' or 'quadratic' or things like that in the main folder, it is most likely the result of some crappy coding.

If a variable must be retained for the next use, then atleast name it descriptively and place it in a folder, so the user has a sense that it used for something. We cannot simply change to the (tt) folder, because if we did, how would we know what folder the user is coming from? For this task, I would have used getFold(). However, it seems that TI has changed the parameters for the getFold() so that whatever file you store it to, it will constantly change the data to whenever the current folder is changed. This renders the getFold() command useless, but luckily the setFold() command was modified to suit. Now, whenever a setFold() is invoked, it will return a string which contains the name of the folder it is CHANGING FROM. Bingo! The line setFold(tt)->tm_fold means this: Set the current folder to (tt) and store the string name of the folder we changed from to tm_fold. The prefix tm_ is to help me remember that this is a temporary file, and fold is to tell me that it contains the name of the folder to change back to. Note that tm_fold was defined as local in the local definitions. Now that we are safely in our predesignated folder (tt), we have more freedom to code.

The next step is to save the state of the current draw buffer, graph equations, and graph settings. Of the two lines there, always do StoPic tm_pic FIRST. The draw buffer is highly volatile and sensitive to any type of regraphing, clearing, etc. There! We just stored the draw buffer to the file tm_pic. Again, tm_ denotes that it is a temporary file, and it is also defined as local. Next, do StoGDB tm_GDB. What exactly is a GDB? A GDB is a GRAPH DATABASE. Graph databases store not only the current graph settings, but also the current graph equations. Perfect! That kills two birds with one stone. (sorry for the metaphor to any humane society people) Finally, we need to turn of the axes and set viable window settings for possible pt__ commands. A careful examination of both needs reveals that they are both covered under the graph database. So here is what I have done: I made the settings in advance, then stored the file as tt_GDB. Here, the prefix tt_ helps me to remember that this is a critical Triple Triad file. In order for the program to run correctly, this file will have to be included in a batch file distribution of the final version. I recommend you to lock this file either before transferring to the computer or to make an install program that locks it on the users calc. Finally, the screen is cleared in anticipation of accesses to the draw buffer.

The last section is EXIT. This is to be run right before program termination. Exit encompasses the restoration of user's draw buffer and deletion of non-storage variables. The first line to run is RclGDB tm_gdb. YOU MUST RUN THIS ONE BEFORE RCL_PIC, because if you recall a graph database before recalling picture, the screen will be regraphed and the pic will be lost. Next, instead of using a ClrDraw and a RclPic, I used a RplcPic, which is a replace recall. There are many picture loading commands, but only replace acts as a ClrDraw and a RclPic. Small optimizations such as this not only make the code shorter (faster) but easier to read. Finally, the current folder is changed back to the saved string. The pound sign in front of the string is absolutely crucial and here is why. The setFold() command doesn't take a string, but a folder name. That means that main is legal, but "main" is not. However, remember that our setFold() command in the ENTRY returned a string, not a folder name. In order to change the string to a name, we must use the pound sign, which is called an indirector. There are two commands that can change a string into a non-string, indirect and expr(). However, expr() only changes strings into variables and equations, and not names. YOU MUST USE THE INDIRECTOR FOR SETFOLD(). Thats it. The EndPrgm signifies the program terminates. At this point, the locals will automatically delete, and control will be returned to the OS. A thorough investigation of the (main) folder, (tt) folder, and the draw screen will reveal that there were no overt changes. Success!

Contact

I have no idea if there is an audience for this stuff. Email me back about whether or not you liked this, found it useful, or if you have some questions. Or perhaps you would just like to discourse on 89 programming tips and such. My address is infernalraccoon@hotmail.com and my AIM S/N is infernalraccoon. Thanks!

Just a little more!

I did not release any of my works for a long time. I think the only one I uploaded to ticalc.org is Imput List Reader. I released that sometime in 98 I think. I'm not sure on that. Anyways, I did research on the available 86 text editors (always research the current need and scale your program around that). Basically all the rest of them used strings (ha!). I decided to store data in lists, which allowed for FORMATTING, ENCRYPTION, and the like. However, I did not get around to optimizations and such. Still, download it to check out its code (you might learn something) and run it to see how cool it is ;P. Get it here. I think I might ask my friend David to continue it, as he still has a 86. He is also planning on a Triple Triad port for the 86, so you 86ers might expect some good stuff from him.

The comments below are written by ticalc.org visitors. Their views are not necessarily those of ticalc.org, and ticalc.org takes no responsibility for their content.