Impossible Mission 800 - some progress

[Rybags]

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

[danwinslow]

Sounds good. One note : I couldnt get the clip to play in Windows Media. Says it cant find the codec.

[Rybags]

The video uses the Divx codec.

 

OK, I've whipped together the robot movement demo.

 

It's primative, with only movement and no animation - plus it doesn't clear the screen first.

 

Just binary load it from DOS - no need to disable BASIC.

 

imrobots.zip

 

You'll notice bands of different background colour - that's timing indicators - the dark brown is the "restore" operations (putting back data that was under the sprites). The lighter brown is the sprite draw operations.

Edited April 30, 2006 by Rybags

[danwinslow]

Yup. worked...so I take it you have a lot of DLI going on? You know, if you felt like going into a lengthy lecture about what your techniques are here, I think I could stand it.

[Rybags]

No DLIs at all in that one - they're software sprites only.

 

It just waits on $D40B to sync the movement but the real deal will have DLIs as I'll be overlaying a player onto the robots + using the missiles for the enemy fire + doing some colour changes.

 

Final version will use a DLI to start the frame generation process near the bottom of the visible display - doing so means most of the display changes will take place when no screen updates are occuring.

 

Although the final code should fit within a single screen period, I still have to keep it tight due to less available cycles for NTSC frames.

 

Since the robots don't move vertically, fixed position DLIs can be used - I'll probably even go so far as disabling PMGs in certain screen regions as it saves 5 cycles per scanline.

[miker]

and? some news regarding the project?

[miker]

(bump)

[FastRobPlus]

I'd like to hear more about this too.

[Rybags]

I've not done anything since the middle of last year.

 

I had Partition Magic nicely trash one of my RAID drives - lost a fair bit of work although I was able to recover some.

Also lost my hero sprites, although it's only a couple of hours work to get some new ones defined.

 

 

Hoping to pick it up again at some stage and get a "Proof of Concept" demo going with a semi-playable room level.

[Artlover]

I had Partition Magic nicely trash one of my RAID drives - lost a fair bit of work although I was able to recover some.

How did it do that? My experience has been it's pretty safe unless you're trying to do something extreme like repartition a full drive or something.

 

To that end, R-Studio is a terrific data recovery tool. Utter pain in the butt to use, but it's functionality and data recovery abilities are nothing short of amazing.