Rybags Posted April 30, 2006 Share Posted April 30, 2006 I've started programming Impossible Mission for the Atari 800. Actually, I started in mid 2002, but didn't put much effort in and lost interest. But, I picked up again a few months ago. Progress so far: - I've done a routine to generate the player sprite. I converted the C-64 player and converted each frame in Paint, then touched up the results a bit. It uses Player 0 & 1 for the body/legs and Player 2 for the head/arms. To save memory, the memory resident frames are right-facing (PLR0, PLR2) and left-facing (PLR1) and I use a table to generate the flipped images. I mixed the direction of the players to even out the processing requirements. Using the method described saves about 600 bytes or so but is a bit more expensive in CPU time. There are 28 frames for the player animation, using a total of just under 2K memory. The routine and it's associated data structures comes in under 1K. - Routine done to generate robot sprites. It's a nifty little program, and I've had it running with 8 moving objects. The robots are hires-multicolour characters and I'll be using Player 3 as an overlay for the body. That allows easy collision detection, plus adds some extra colour. The missiles will be used for the robot's death-rays. The routine dynamically generates character data from pre-shifted sprite definitions and masks, and maps the robots to either 6 or 9 characters depending on their screen X-position (since they're only 7 pixels wide, half the time they need only 6). The routine has full save/restore capability and seamlessly moves the sprites over background data. There are 7 frames for the robot sprite. To save memory, only the left and right facing sprites are defined for even X positions. Total memory usage for sprites/masks comes to a little over 2K. The routine and it's data structures comes to a bit over 1K. The project is far from complete - the next part will likely be the game engine (player movement). The trickiest part of that will be doing the collision avoidance routines - but the nitty-gritty will probably just involve generating tables and doing testing. The code I have so far written is pretty efficient - but I imagine the main remaining elements (move player and robots) will consume a fair slice of the CPU cycles per frame. I've been sparingly using zero-page, so that leaves a lot of scope to speed things up. It's been a balancing act between keeping the program reasonably short vs using unrolled loops and table lookups for things. I've only generated simple tests/demos for the work so far, and it is far from presentable. Hoping to have the game engine started and a demo/mockup for you sometime in the next week or so. Another barrier I noticed early on is the character limitations - only 128. My way around that will be to dynamically generate characters which are needed for each screen - no problem really. The Walls/floor/platforms will likely use about 6 characters, 9 characters are reserved for each robot (so, up to 36 in total). Which leaves the remainder to be assigned for the searchable objects. Utimately, the aim is to have the game playable on a 48K system, with no or minimal disk access once loaded. Most or all of the digitized speech will likely be for 64K only. A possible future development could be a 32 or 64K cartridge version. Short .AVI (Divx 5) of the player animation: im_player.zip Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.