![]() ![]() #Goattracker instrument tables codeThe game is pretty much 100% written in assembler, unlike Fort Django, which still had a fair amount of C code in it. This not only influenced the character design but the backgrounds too, so there's more black empty space than would look good in a static picture.Ģ017? Well, um. I initially gave the main character a more rounded look as I would do in a picture, but this did not work with the background. I noticed that PETSCII game visuals need a somewhat different approach than static screens: The overlaid "sprites" have to go well with the background without too large black outlines. With the visuals, I took the easiest, black-background PETSCII approach. But once I had my routines in place, I kind of prefer the 1/3 because it gives automatically a nice gameplay speed without having to slow things artificially. Also, I probably could use the X/Y registers without having to resort to the INC gimmick. I already think I might have the graphic shapes erased with routines similar to drawing them, resulting in a faster screen clean-up. When transfering the 8x8 character elements to the buffer, the writing address hi byte is INCed with self-modifying code to reach the next vertical line whereas X register handles the horizontal coordinate. With this approach I balanced speed, memory and convenience. Again, this is 2K and takes nearly the entire frame.ĭuring each frame the interrupt plays a GoatTracker SID tune and polls the joystick. The 256-byte aligned background buffer is copied to the visible screen using speedcode. This uses something like third of a frame, depending on how many movable objects there are on screen. Some smaller graphic elements, like bullets, are drawn using hardcoded routines. Each large "sprite" graphic is stored in 143 reverse-ordered data bytes including color and line-padding zeroes. The 8 x 8 character "sprites" are drawn over the 256-byte aligned buffers. Copying 2K of characters and colors takes nearly the entire frame. The background screen & colors, which were built on entering the "room", are copied to the respective 256-byte aligned buffers using speedcode. The visuals and game logic are orchestrated like this: I discarded the idea of double-buffered page swapping routines as the color memory in this mode is fixed at $D800 anyway. I use 256-byte aligned buffers for holding the current screen background and building the screen for displaying. I went for 1/3, which is something like 16.67 frames per second on a PAL machine. ![]() I wondered if I could stick to 1/2 or 1/4 framerate, knowing that each frame would add greatly to the amount of code that can be executed. I could not achieve 50 frames per second for these big dudes. What I've done is a bit of a compromise between these, an arcade game following Priestley's non-scrolling style but ignoring the more complex aspects of his routines. Later, others made fast arcade type games with a more streamlined approach, for example Dan Dare III, Savage!, and Extreme. Don Priestley used his unique techniques in Benny Hill, Popeye, Trap Door, Flunky etc. Many ZX games had movement restricted to the color grid, with big player "sprites" to compensate. This visual style is closer to ZX Spectrum game programming techniques, even if the Speccy does not have a character display. #Goattracker instrument tables fullHowever, not many full screen action games were done using the technique, probably because sprites are far more useful and the clunky char-by-char movement was not that attractive. There's nothing special about using PETSCII for games, it was done a lot back in the day. Fort Django used PETSCII for the backgrounds, but all the gameplay worked with sprites. ![]() For some time I've wanted to use this approach. Digiloi is a game I made for Commodore 64, using only the default character graphics (PETSCII) for visuals. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |