Traduit en anglais par The Electric Monk of TGS HOW ELMAR DID HIS Elmar Krieger is the author of several recent CPC games. Prehistorik 2 and Super Cauldron. He is also the author of Zap'T'Balls "Advanced Edition", which makes the most of every possible sprite technique. In this issue of Amstrad Cent Pour Cent, we bring you the exclusive routines of this great programmer, who has prepared a few RSX games for your enjoyment. After all, if you can't create cool little games, you're not worthy of the trust we've put in you. INSTRUCTIONS FOR USE Four programs are available. The first three must be encoded, then run to generate three files. Only the sprites and routines in machine language will be used (the 17 Kb screen image can be removed later). To fully understand the RSX principle, encode the fourth and final program and run it as is. You'll then understand what smooth animation means in Basic. That's what our readers are all about! For those of you who are keen to learn more, we'd like to hand over to our friend who, in the form of a mini-course, will explain the principle behind his routines. It's well worth your while. LET HIM HAVE HIS SAY In the nine years we've spent with our beloved CPC, countless articles have been written on the subject of sprites. So, in 1993, it's become rather difficult to find something that hasn't already been written about. If we look to our ancestors, at Ghosts'n'Goblins, for example, we find: "simulation with two bitplanes". An interesting technique, even a little ingenious, which is normally used on PCs and can give good results on our CPCs. To gain speed, we press the screen to a width of 64 bytes in X, as is done in 80% of CPC games. Why do we do this? In assembler, we can use the INC L instruction (which is faster than INC HL) to increase an address in the Ram-video. The second trick: we use arrays to perform complex calculations. As our routines will accept the coordinates of a sprite in X (0 - 63) and Y (0 - 255), we need to transfer them to a video address first. For example, with this formula: ADR = &C000 + (Y8)*64 + (Y MOD 8)*&800 + X In assembler, we use a 512-byte array at &A400, containing a video address for each Y line. If the HL register contains X and Y coordinates, the formula is reduced to: LD A,H LD H,&A4 ADD A,(HL) INC H LD H,(HL) LD L,A Let's move on to the "two-bitplane simulation" itself. In a 16-color mode (such as MODE 0), four bits are required to select one of the 16 colors. The word "bitplane" expresses that these four bits are not in the same byte (as on CPC), but are divided into four "bitplanes". The central idea of our technique: If we put the background in bitplanes 0 and 1 (two bits of information, so four colors like MODE 1) and the sprites in bitplanes 2 and 3 (four colors again), we've succeeded. You can do anything with the sprites in 2 and 3 without touching the background in 0 and 1. The only drawback: you have to sacrifice one of the four sprite colors to leave the background transparent. In MODE 0, this leaves only seven colors. But honestly, did you notice this in Ghouls'n'Ghosts, Wonderboy or Mission Genocide? On the other hand, there are enough highlights: - you don't have to worry about saving the background; - only 50% of memory is required; - changing colors also changes sprite priority. FORWARD, MARCH! Program 1 generates five demonstration sprites. If you want to draw sprites yourself, do so in MODE 0 with the first four colors of the palette (for sprites AND background I). Then store the sprites in memory in an appropriate form. This is done by program no. 2. Look here for all the information. The size of the sprites is put into a table, so you don't have to worry about it afterwards. In the DATA lines, you must enter, for each sprite on the ¡ the screen you've drawn, its number (0 -127), its position in the Ram-video (&COOO-&FFFF), its width (a multiple of four) and height (in bytes). For sprites, I reserved the memory space from from &6000 to &97FF, which is probably enough. The data is saved in the SPRITES.DAT file. Program No. 4 generates all assembler routines and calculation tables to decompress and display the data. THE RSX COMMANDS Here's an explanation of the RSX commands (note that for AZERTY keyboards, you must replace the "|" preceding an RSX command with "ù"). Load 'SPRMCODE. BIN' at address &9800, and initialize with CALL &9800. The commands are as follows: |INIT: initializes screen (32*32 characters). |PUTBKG,A,X,Y: prints sprite n° A at position X,Y in background colors (PUT BACKGROUND). |PUTSPR,A,R,X,Y: prints sprite no. A at position X,Y in direction R [0 = normal, 1 = transparent] (PUT SPRITE). |PUTSWF,A,R,X,Y: like the |PUTSPR command, but awaits a Frame Fly before (PUT SPRITE AND WAIT FOR FRAME FLY). |REMSPR,A,X,Y: remove sprite no. A (REMOVE SPRITE). Around each sprite, a frame of one byte in X and four bytes in Y is erased. To simulate movement, change the coordinates and print the sprite again. If the movement is larger than the surrounding frame, parts of the first sprite remain visible. Now for the colors. There are four colors in the background. We call them COLFON0 to C0LF0N3. As for the three sprite colors, they are called C0LSPR1 to C0LSPR3. Each variable contains a value from 0 to 26. We now look at the case where the sprites are in front (the second possibility must be by yourself - line 360 line in the demo may help...). So, if bits 2 and 3 are zero, there is no sprite and we can see the background color chosen by bits 1 and 0. In Basic, write : INK &X0000,COLFON0 INK &X0001,COLFON1 INK &X0010,COLFON2 INK &X0011,COLFON3 If bits 2 and 3 are not empty, the background color is removed: INK &X01YY,COLSPR1 (&X0100.&X0101,&X0110,&X0111) INK &X10YY,COLSPR2 (&X1000,&X1001,&X1010.&X1011) INK &X11YY,COLSPR3 (&X1000,&X1001,&X1010.&X1011) A demonstration of all the instructions can be found in program 4.