SPACE 2

home *** CD-ROM | disk | FTP | other *** search

/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / magazi~1 / 454 / articles / assembly.asc < prev next >

Wrap

Text File | 1989-11-11 | 12.3 KB | 242 lines

******************************************************************************* * STatus Disk Magazine * * Issue 1, Volume 1 * * * * NOTE: This issue is to be copied freely by Atari ST users. We at STatus * * strictly prohibit anyone selling this issue as part of a Shareware or PD * * collection. * * * * STatus Disk Magazine * * Suite 299 * * 4431 Lehigh Road * * College Park, MD 20740 * * * * STatus Disk Magazine (c) 1989, is a COMMERCIAL effort. * ******************************************************************************* Assembly Language Tutorial Graphics, Part One: Higher Level/GEM usage One of my aspirations is the make a video game. Whether or not people percieve the Atari ST/Mega line as game machines to me is irrelevant, because to me, entertainment is one of the top uses of any computer I buy. Now keeping this in mind, remember, I'm probably as much a beginner in assembly programming as anyone who is reading this. So what makes me able to teach anyone? Well, nothing actually, except that I'm learning it WITH you! The code in this article may not be the most efficient, and if you have any helpful hints or tips, forward them to me. The reason I think this will all be more fun and interesting is because I will take the time to help the beginners while trying to push the vanguard with some of the more dedicated hackers. Okay, enough prattling, let's get down to business. The first thing I am going to say is this: Until I can find some good documentation on the use of VRT_CPYFM ( the transparent raster copy ), I cannot say that multi-color sprite-like graphics is impossible, but it sure is NOT easy! Many options can be tried: You can try using the Line-A sprites and "layering" them, you can try the Line-A BitBlk routine, or, if it is indeed possible, layer rasters using the vrt_cpyfm function (VDI opcode is 121) but the obvious problem is defining a single color source, which is something I decided to forego. Judging from the demands players today place on the computer game, it is most likely that in the ST world, programmers have been using their own customized routines which handle the graphics in a sprite-like manner. But what about getting our feet wet and mucking around with some of the higher level raster functions first? Let's do it! I chose to use vro_cpyfm for this program ( which is contained in RUN_MAN.ARC ), since I wanted to keep it simple and allow for learning the necessary criteria for making a "blit". The reason it is so simple for what we're doing is that we're literally booting up a DEGAS picture into an area of memory, and getting the images we want from a series of drawings in it, and vro_cpyfm will handle all four bit-planes with a single call. The first thing I always do within a program like this is use the GEM m_alloc call to set aside memory for my graphic screens. In this case we need at least 96000 bytes, since we have two screens which are going to be "flipped" so as not to have flickering animation, and a third screen which contains the raster data we're using. The next thing is to set the resolution. When you use GEM and set the resolution to a new value within the program, dialog boxes, alert boxes, drop downs, etc... all still work in the original resolution. But for this program, with none of that in use, it really doesn't matter! Booting up a DEGAS picture is quite easy. The format of a DEGAS pic is: 2 bytes - resolution 32 bytes - palette (the RGB values of the 16 colors) 32000 bytes - screen data 32 bytes - animation information, used by DEGAS Elite only. The total length of the file is 32034 bytes in original DEGAS format, and 32066 bytes in DEGAS Elite, Uncompressed format. Looking at the source code, you can see how I go about booting the picture in and setting the palette properly. I have written macros that open the file ( f_open), move the file pointer ( f_seek ), read from the file ( f_read ), and close the file ( f_close ). All of these correspond to the proper GEMDOS calls. If you wish to delve into files and how to handle them, examine the macros as they are well commented. Now here is the good part. According to every book on how to do a raster copy, you have to set up MFDBs. Some people look at the abbreviation and immediately enter catatonic shock and one friend of mine actually stopped using his ST and began chanting meaningless things about how his C128 was never like this.... MFDBs are simply Memory Form Definition Blocks. The name is still complicated enough that most people think they will need a bullwhip and a fedora to deal with the programming aspect of it in assembly. This is where the C user starts to giggle and whips out his TYPE DEF STRUCT command... Well, here's all you need to do to define an MFDB, and its there in my code: MFDB: name of the MFDB for our purposes address ds.l 1 address of the screen data for to associate with this MFDB widthnpix ds.w 1 width of the raster image in pixels. ALWAYS 320 in low rez, or 640 in medium and high rez. heightnpix ds.w 1 height of the raster in pixels, which is 200 in low or medium rez, and 400 in high rez. widthnwords ds.w 1 the widthnpix divided by 16. formflag ds.w 1 the form flag, usually 1, according to the DevPac ST manual. numofplanes ds.w 1 number of bit planes in raster. 4 = low rez 2 = medium rez 1 = monochrome reserved ds.w 3 three reserved words, set to 0. Essentially, its ideal to set up all your MFDBs to be identical except for the address of the screen. All of these parameters are easily either calculated or returned from GEM inquiry functions if your program must be adaptable. However, none of that really will matter with trying to move a little guy across your SC1224... Now, when messing with with the MFDB, you'll set the values to whatever is appropriate. In my code, you'll see I set that up before I begin messing with the actual raster copying. Also, in case you're wondering, all the MFDB really holds are parameters for the screens you're copying either from or to. Easily enough done. But wait...don't you want to tell it WHERE to get and send all this graphic data? That's where the PTSIN arrays come in. This is actually quite easy, and the format is as follows: PTSIN - x coordinate of upper left corner, source PTSIN+2 - y coordinate of " " " " " " " PTSIN+4 - x coordinate of lower right corner, source PTSIN+6 - y coordinate of lower right corner, source PTSIN+8 to PTSIN+14 are the same parameters, but apply to the destination raster. Essentially, to copy from a raster whose coordinates are (200,100,231,131) to another location, such as (26,92,57,123), you'd set it up like: move.w #200,ptsin move.w #100,ptsin+2 move.w #231,ptsin+4 move.w #131,ptsin+6 move.w #26,ptsin+8 move.w #92,ptsin+10 move.w #57,ptsin+12 move.w #123,ptsin+14 There is another parameter to worry about also. That is, the raster mode. To make it short and sweet, none of this really helps you if you're trying to make them handle like sprites. Mode #6 is good for a single raster that you want to erase by ANDing it with itself, but on a screen full of objects, some of which will overlap, you may want to confine yourself to mode #3 for displaying it, and mode #0 for erasing it. Or, you can even perform a v_clrwk as long as you know that what you want to erase is on the logical screen. Now for the juicy part... If you look at the DEGAS picture, you'll see the man is in different parts of the screen. We want to cycle back and forth between the rasters used, and the way to do that is to associate each step in the "cycle" with one of the possible rasters and its coordinates. That could get complicated, so I split it into two sections. One loop goes through all the rasters from left to right, and the second one goes back ( right to left ) through all but the raster farthest left and the raster farthest right in the image. The reason is simple: The first loop shows those two images already, so if we did it twice, those images would appear TWICE, not once, like all the others. As all of this is happening, we have adding to the x coordinates of where to put the image on screen. If we don't, he'll appear to be running in place. As we add to that, each loop either will add or subtract the x coordinates of where to look for the proper raster to display as well! This effectively cycles the necessary rasters while moving the destination across the screen, from left to right. Now, how do we make all of this flicker-free? We all know that the supposed graphic wunderkind, the Amiga, flickers! And the last thing you need is to have your ST flicker like an Amiga! So.... looking in my loops, you'll note that after I set up the proper x coordinates into the ptsin arrays for the source and destination rasters, I copy the raster to the LOGICAL screen, which is NOT being shown. Once it is shown, I can erase the previous screen, which is now the logical screen with a v_clrwk. To make sure none of this occurs before the screen I want is displayed, I do a XBCALL #37,2, which, to my macros, is just saying to perform XBIOS 37 and fix the stack by 2 bytes. XBIOS 37 is the V_sync call and its purpose is to stall things until the VBL ( vertical blank ). This assures you that you'll have flicker-free animation. Some obvious improvements can be made in this code. I could, for example, do comparisons and determine the proper source raster from that, so as not to use two seperate, distinct loops within a larger loop ( which essentially keeps the whole thing going coherently! ). If you want to, you can make him run faster or slower by usign more XBCALL #37,2 's in that section. Right now, he runs pretty fast...