Significant tricks & techniques in MW4 by Cadaver ------------------------------------------------- This rant details some of the more out of the ordinary techniques used in the finished version of MW4 that make it possible to be what it is. None of them is anything special, but they're still not usually used in C64 action games, so I thought to write something of them. Please refer to the MW4 source code to see what I'm talking about, ../games/mw4src.zip. 0. Free/anydirectional scrolling (Also discussed in Rant #4) This is like the block scrolling in any of my games, in that all action still happens in 2 routines: - SCROLLLOGIC, determine where to scroll the screen, update "subtract-value" to position sprites correctly, determine if shifting the screen is required - SCROLLWORK, hard work of scrolling (screen memory/color memory shifting and drawing new data to the edges) SCROLLLOGIC is still called at the beginning of the frame, so that the sprite subtract is correctly updated and we know what the scrolling values are going to be for the rest of frame. SCROLLWORK is called in the end of the frame, respectively. The difference to "usual" 8-way scrollers comes in the SCROLLLOGIC routine. Usually scrollers pick one of the 8 directions, and advance the scrolling for a certain amount of frames until a distance of 1 char has been scrolled (Turrican for example). But here the algorithm doesn't think that much forward. What it starts with are the current finescroll values (scrollx, scrolly) and the current scrolling speed (scrollsx, scrollsy). Btw. those values have 3 bits of subpixel accuracy, so they go from 0-63 instead of 0-7. The scrolling speed is a signed number, so it goes from +32 to -32 (speeds higher than 4 pixels/frame are unsupported, as screen shifting can happen on each second frame at most). The first step is to subtract the speed from the finescroll values, separately for X and Y axes. If the finescroll values overflow, we don't care of it yet, instead we just clamp them at the ends of the finescroll range (0 or 63). This is because we are not yet ready to perform a complete screen shifting in the space of one frame! Now we have the finescroll values for the next frame! The next step is to subtract the speed from finescroll yet again. This time we check overflow in either positive or negative direction, and by doing this for both axes we know where the screen needs to be shifted. If the finescroll *does not* overflow, we can discard the values from this second subtraction, no shifting is necessary, and the process starts over on the next frame. But if we get an overflow, this tells that the screen has to be shifted. Now the rest of the process goes like this: - A flag is set so that next time SCROLLLOGIC is executed, it just takes into use the precalculated finescrollvalues that we got from the second subtraction, and updates the sprite-subtract, but doesn't do anything else. - At the end of the frame, SCROLLWORK will shift the screen memory. As double buffering is used, it's always a copy from the currently visible screen to the currently hidden screen, with an offset that is determined by the shifting direction. After the shift, new data is drawn to the screen edges. - At the end of the next frame, SCROLLWORK will shift the color memory. This requires checking that the rasterbeam ($d012) is at a suitable position (at the scorescreen, or at the vertical blank) as to not cause tearing effects on the screen. The file "screen.s" contains the SCROLLLOGIC & SCROLLWORK routines. 1. Realtime depacked sprites This is also something I've written about before, but how it's used in the "new" MW4 engine is a bit different. All main characters and enemies (about 160 frames loaded at once) still reside in the videobank memory: these are not unpacked in real time, as it would be quite impossible to achieve 50Hz frame rate while doing that. (UPDATE: for a way to reduce the CPU hit enough to make 50Hz possible, see the sprite caching rant.) But the weapon carried by each character/enemy, all bullets/other projectiles, items lying on the ground, and "particle" effects like small smoke clouds use packed sprites. There's room for 20 packed sprites in the video bank, which is also the max. number of actors active at once, so each actor can utilize 1 packed sprite. Packed sprites are divided into 6 "slices", consisting of 7 bytes, like this: (each string of four numbers represents four multicolor pixels - one byte) 1111 2222 3333 1111 2222 3333 1111 2222 3333 1111 2222 3333 1111 2222 3333 1111 2222 3333 1111 2222 3333 4444 5555 6666 4444 5555 6666 4444 5555 6666 4444 5555 6666 4444 5555 6666 4444 5555 6666 4444 5555 6666 As you see, the lowest 7 rows of a packed sprite aren't used at all, to make the depacking process quicker (the lowest 7 rows have been cleared beforehand, when the program starts - this needs to be done only once). All packed sprites are so small that they fit into the 6 slices. For each slice, one bit determines whether it's empty (0) or whether it contains 7 bytes of data (1). Furthermore, packed sprites are stored only facing right. If they need to be displayed flipped, the flipping is also performed realtime in the program. One more thing, before I present the actual depack routines from "sprite.s". The depacked sprites are not doublebuffered, so they need to be depacked when the raster beam is at the scorescreen, or at the vertical blank. Since the color-RAM scrolling "competes" of this time too, I thought I was going to run into trouble, but experience indicates that during a single frame, not so many packed sprite frames change (naturally, we don't want to waste time depacking the same sprite again), and therefore not so many have to be depacked, so there's enough time even on NTSC machines. The unflipped sprite depacking is quite straightforward. This code depacks one slice. The destination address uses X as index; the highbyte of the address has to be modified into the code. For the source address, variables temp3-temp4 + Y register are used for zeropage indirect addressing. dspr_slice: lsr temp2 ;Check slice type (empty/data) bcc dspr_emptyslice dspr_fullslice: lda (temp3),y dspr_fullsta1: sta $c000,x iny lda (temp3),y dspr_fullsta2: sta $c000+3,x iny lda (temp3),y dspr_fullsta3: sta $c000+6,x iny lda (temp3),y dspr_fullsta4: sta $c000+9,x iny lda (temp3),y dspr_fullsta5: sta $c000+12,x iny lda (temp3),y dspr_fullsta6: sta $c000+15,x iny lda (temp3),y dspr_fullsta7: sta $c000+18,x iny rts dspr_emptyslice:lda #$00 dspr_emptysta1: sta $c000,x dspr_emptysta2: sta $c000+3,x dspr_emptysta3: sta $c000+6,x dspr_emptysta4: sta $c000+9,x dspr_emptysta5: sta $c000+12,x dspr_emptysta6: sta $c000+15,x dspr_emptysta7: sta $c000+18,x rts When also flipping the sprite, things become harder. I use a 256-byte lookup- table to flip the bit-pairs in each byte, but the problem is that there's no free index register to access that, so we have to modify the code to access the fliptable instead (a bit slow). Fortunately depacking an empty slice is still easy & fast. dsprl_slice: lsr temp2 ;Check slice type (empty/data) bcc dsprl_emptyslice dsprl_fullslice:lda (temp3),y sta dsprl_fulllda1+1 dsprl_fulllda1: lda fliptable dsprl_fullsta1: sta $c000,x iny lda (temp3),y sta dsprl_fulllda2+1 dsprl_fulllda2: lda fliptable dsprl_fullsta2: sta $c000+3,x iny lda (temp3),y sta dsprl_fulllda3+1 dsprl_fulllda3: lda fliptable dsprl_fullsta3: sta $c000+6,x iny lda (temp3),y sta dsprl_fulllda4+1 dsprl_fulllda4: lda fliptable dsprl_fullsta4: sta $c000+9,x iny lda (temp3),y sta dsprl_fulllda5+1 dsprl_fulllda5: lda fliptable dsprl_fullsta5: sta $c000+12,x iny lda (temp3),y sta dsprl_fulllda6+1 dsprl_fulllda6: lda fliptable dsprl_fullsta6: sta $c000+15,x iny lda (temp3),y sta dsprl_fulllda7+1 dsprl_fulllda7: lda fliptable dsprl_fullsta7: sta $c000+18,x iny rts dsprl_emptyslice:lda #$00 dsprl_emptysta1: sta $c000,x dsprl_emptysta2: sta $c000+3,x dsprl_emptysta3: sta $c000+6,x dsprl_emptysta4: sta $c000+9,x dsprl_emptysta5: sta $c000+12,x dsprl_emptysta6: sta $c000+15,x dsprl_emptysta7: sta $c000+18,x rts MW4 uses a total of 114 packed spriteframes, and when it's taken into account that many of them are also shown flipped, the number rises to about 170. So, the game would clearly have been impossible to implement without packed sprites! 2. Flipping of sprites while loading them Near the end of MW4 development, I began to run out of diskspace. It would be nice to have at least 3 save game slots, but they'd take 48 blocks off the disk. To somewhat help this, "flip duplicates" of sprites aren't saved on disk, instead there's just emptiness at their place (Exomizer packs that quite well) and a "command code" to instruct the sprite loading routine to rebuild these flip duplicates at load time. This routine is also in "sprite.s". The trouble with it is that sprites can also reside under the I/O area, so it needs to be switched off/interrupts be disabled. Of course, this can't happen for a prolonged time, or the raster interrupts would freak out. The "fliptable" is also used by this routine, and the process goes like this for one sprite: temp2 is the row counter, alo-ahi are the zeropage source pointer, and tempadrlo-tempadrhi are the destination pointer. The routine first takes the rightmost source byte of a sprite row, flips the bitpairs, and puts it to the leftmost byte of destination sprite, then flips the middle byte, and then, at last, leftmost source byte is flipped and put into the rightmost destination byte. This process is repeated for all 21 rows of the sprite. lda #21 ;Row counter sta temp2 clc loadspr_rowloop:ldy #2 sei dec $01 lda (alo),y ldy #0 tax lda fliptable,x sta (tempadrlo),y iny lda (alo),y tax lda fliptable,x sta (tempadrlo),y dey lda (alo),y ldy #2 tax lda fliptable,x sta (tempadrlo),y inc $01 cli lda tempadrlo ;Sprites never cross page boundaries adc #$03 sta tempadrlo lda alo adc #$03 sta alo dec temp2 bne loadspr_rowloop 3. Scripting system The scripting system as implemented in the "new" MW4 engine is truly raw. No interpreters, no virtual machines, no paged bytecode, just loading of ASM code in 2KB chunks and executing it. All code corresponding to this is in the file "script.s". Scripting performs various activities of the game such as the title screen, parts of the game menu system, starting a new game, conversations and such. There are 2 ways to call a script: - "One-shot": the X register is loaded with scriptfile number, A is loaded with entrypoint number, and the routine EXECSCRIPT is called. If the scriptfile number is not what is currently loaded, EXECSCRIPT loads the new scriptfile first. In the beginning of each 2KB script chunk, there is a jump table for the entrypoints, and so it knows where to jump. - "Continuous" or "latent" execution. The game mainloop (in "main.s") will call a certain script routine, using the EXECSCRIPT call, each frame until told to stop or execute a different script routine. A script routine has no "state information", so it must use the game's variables (defined in "var.s") to know where it's going. For example, in the beginning, when Ian gets hit by the alien craft, the appearances/actions of the other characters are timed by a simple delay counter. To ease the pain of scripting, I defined some macros, these are in the file "scriptm.s". Most of them pertain to conversations. An important concept of the scripting system is to have access to all subroutines and variables of the game main program. Therefore, all its symbols are dumped in the makefile for use by the script routines. A script routine can naturally crash the game if it wants to, so care had to be exercised when writing them, just like writing the main engine code. Care must also be taken of what routines are called in the script routine: if it JSRs off to a subroutine that also calls EXECSCRIPT, a different script file might be in memory upon return and a crash would be inevitable. Therefore, whenever this is suspected, the script routine uses a JMP instead, or sets a latent script to be executed on the next frame. Because each script routine is identified by a 16bit number (highbyte = file number, lowbyte = entrypoint), assigning script routines to the objects (switches, computers and such) in the levels was easy using the level editor (AOMEDIT2). The bytecode-based scripting system of the preview wouldn't have allowed that as easily.