About IMPOSSIBLE MISSION playing

[José Pereira]

Is it in Impossible Mission game map rooms and corridors/lifts always the same everytime you play and in all versions?

And at the platforms screens the furniture and the objects they can or not have also the same at the samd places or are they randomly placed?

Same question goes for the enemys: Always the same number per screen and same x,y places with the same movement?

 

Just because I don't see a reason to get any of the versions code, or there is?

The idea/gameplay of the game doesn't seem hard to build from scratch:

Ramdomly or not, it's still a normal platforms run and jump game avoiding enemys that we have to pick-up objects.

 

I found some interesting things and it seems not hard to implement on A8 using ANTIC4 charmode:

PLATFORMS SCREENS: I got it in 1charset

LIFTS SCREENS: 1 other charset (1 other charset for the bottom status panel)

LARGE MONITOR: 1 other charset

And the Evil guy end screen can be a loading apart G2F screen.

These 4KBs and some more data of the PMGs and the software sprites (that aren't, indeed, soo many around).

I thought that I should try this one again but now I am really confident that this time I found a possible and easier way to get this one onto A8 .

But first it would be important you answer this post questions.

Thanks.

[Rybags]

Room placement is random as is the robot behaviour and object placement.

 

Of course there's certain rules for room placement, obviously those with 2 exits will not be on the edges.

Robot behaviour, often the robots in a given room will have similar traits.

 

There's a good document around somewhere which describes the various types of robot behaviour. Once you've played the game a while, you can often pick up what type of behaviour a robot will have before it even sees you.

 

When investigating "how to" on Atari, the biggest hurdle is the couple of rooms where more than 1 robot appear on a horizontal line.

 

My strategy was to use 3 Players for the human, missiles for the robot weapons, last Player as an overlay on the robots for extra colour and for benefit of collision detecting.

In the case of >1 robot per horizontal line, the overlayed Player would be placed on which robot the player is closer to and the colour would be same as the underlying Playfield for that robot to avoid flicker at the cost of slightly reduced colour in those rooms.

 

Robot weapons - probably missiles in expanded mode, alternate positioning as the colours are black/white. Flicker to an extent is OK here since the C64 version rotates colours thru the weapons.

[José Pereira]

@Rybags: And just because the maximum of enemys per line are two and they're only 7pixels wide then why not set PRIOR1 and Multicolour PMGs mode then eachone can have three colour and multiplex them (and different colours) on other lines/floors, one P0+P1 and the other P2+P3 ?

Screen in 40Bytes wide with black as the BAK colour register.

PF0 any (colour,luminance) for the 'backs' wall.

PF1 always white and PF2 for the platforms.

PF3 always light brown on the \\ lifts lines.

Clever in-between floors DLIs to have some more colours on the furniture (like the C64 colourmap).

 

The software sprites are the large ball (black and inside pixels in white), enemy's shooting in black+white interlaced (please see the BBC/Electron version) and our man better looking in three colours instead of two: BAK black (hair+trousers+shoes), PF1 white (shirt) and 4Missiles taking the PF3 register light brown (face+hands skin).

 

I am working on some screens to show you this but also why I think I can have the game each screen in just one charset...

Just give me some more time, O.K.?

[Rybags]

Not really any point using multicolour PMG mode - some animations of the human are such that the 3 distinct Players are needed there.

 

Nowhere near enough CPU time to do any scanline level tricks either. I suppose for just the robots it could be done but why? Running the game logic + doing softsprites + the PMG animation would take quite some CPU time.

PMG animation for the most part not very intensive. The robots are vertically static so just overwrite for animation, the human doesn't move too quickly so is suited to a wipe/overwrite type of technique.

 

Interleave tricks - no thanks. This game IMO requires a polished look, relying on colour blending or any flicker tricks would just look tacky.

[xxl]

you may take game engine from ORIC atmos. http://atari.pl/im.zip

[José Pereira]

@Rybags: I think you didn't understand my idea.

Our guy it's soft spritd and all robots are just PMGs (Multicolour mode). There is no flicker and more chars free for all the furniture, that is where we need them.

4robots or 3robots+1ball are the maximum you can have per screen, so lots of wasting chars. Instead of 3x4 chars (including shifting) per enemy that for all enemys you'll need 48chars then our guy only needs (again with shifting) around 16chars.

 

I have to go out now and didn't finished my idea but when I come back I'll end and post it here. Around 5 or 6hours from now...

[Rybags]

If the human is softsprite then those free characters are less than once thought.

 

Characters aren't a problem - DLIs are required for PMG reposition anyway so changing charsets comes almost for free if needed.

 

Additional to that, doing the human as a softsprite is ridiculous in that it means every single screen will require black and white as part of the colour set.

[José Pereira]

White it's in or can look good in almost all screens.

And black have to be because it will be needed for the borders that is the best screen looking way.

[Rybags]

Borders aren't an issue, it's fine for every screen to have a different border colour, in any case DLIs allow top/bottom to be black as per C64 version.

 

Additional to that, the operative point is that PMGs are essential for the human re collision detection that is pixel perfect. Bounding box method just doesn't cut it for this game at all.

[José Pereira]

You have guy PFs collisions with enemy PMGs.

Just don't have by now it's the hardware collision with their ray shots. But I may get it on later.

First I have to end my todays idea.

Afther that may I get also the hardware collision on the shots ...

[Creature XL]

@Rybags: I think you didn't understand my idea.

Our guy it's soft spritd and all robots are just PMGs (Multicolour mode). There is no flicker and more chars free for all the furniture, that is where we need them.

4robots or 3robots+1ball are the maximum you can have per screen, so lots of wasting chars. Instead of 3x4 chars (including shifting) per enemy that for all enemys you'll need 48chars then our guy only needs (again with shifting) around 16chars.

 

I have to go out now and didn't finished my idea but when I come back I'll end and post it here. Around 5 or 6hours from now...

 

If all robots have the same animation phase in a room, you only need the chars for ONE robot.

And one robot (8x16 pixels) needs only 2*3 chars AFAIK they aren't moving vertically. This is additionally faster to render.

In HitC I have essentially two soft-sprite routines, one for general movement and one for "ypos mod 8 == 0".

What happens to your idea with using alternating chars? Then you need only 3 chars for all robots And DLIs aren't a problem.

I think the background in HitC has more variety then MI. Although I haven't played MI a lot so I wouldn't know of later levels.

[José Pereira]

But 4robots can have 4 diferent animations at the same time.

And I want to proof that here just 1charset per screen is enough .

[Rybags]

Robots are rarely in phase. Additional to that, they travel over the background objects so softsprite with masking is required. However, optimisation would be possible in that sometimes entirely solid chars are generated such that no merging with background data is required for that char (I never really bothered investigating that).

 

Lack of vertical movement becomes a big helper in that the softsprite routine can be simplified. On the downside, it might be desirable to retain the bit 7 state of background data such that unwanted colour changes don't occur, which slows the render down a little.

 

I charset per screen won't be enough I would think.

A single robot requires about 9 chars from memory, so there's 45 chars for 5 robots.

 

Such characters are generated on the fly - given that a robot has 4 positions and the animation combinations means quite a few possibilities exist.

 

And as I stated before - more than one charset is no drama at all.

 

Memory fuzzy here too, but I'm pretty sure I guestimated the character possibilities just of BG objects to something near 160. But could be more, could be less.

Edited November 25, 2013 by Rybags

[Creature XL]

Robots are rarely in phase. Additional to that, they travel over the background objects so softsprite with masking is required. However, optimisation would be possible in that sometimes entirely solid chars are generated such that no merging with background data is required for that char (I never really bothered investigating that).

 

Lack of vertical movement becomes a big helper in that the softsprite routine can be simplified. On the downside, it might be desirable to retain the bit 7 state of background data such that unwanted colour changes don't occur, which slows the render down a little.

 

I charset per screen won't be enough I would think.

A single robot requires about 9 chars from memory, so there's 45 chars for 5 robots.

 

Such characters are generated on the fly - given that a robot has 4 positions and the animation combinations means quite a few possibilities exist.

 

And as I stated before - more than one charset is no drama at all.

 

Memory fuzzy here too, but I'm pretty sure I guestimated the character possibilities just of BG objects to something near 160. But could be more, could be less.

Didn't k ow about the phases.

However I am not quite sure if you know the alternating charset concept by Jose. It uses 4 sets. And daving bit 7 is no problem. See HitC. :rolleyes:

[Rybags]

No idea what alternating charset concept he's on about.

 

Regardless, the robots move over BG data so the characters have to be dynamically generated. The animation aside from rotation angle is the blinking lights, probably the best method there is to simply copy those few bytes of data over the definitions to obtain the animation.

[Heaven/TQA]

charset 0

charset 1

charset 2

charset 3

charset 0

charset 1

...

?

[Creature XL]

No idea what alternating charset concept he's on about.

 

In short, you have 4 charsets and these are used cyclic. Charline X uses set X&3.

Then you need only chars for one char-line of your soft-sprite. So instead of 3x3 you need 3x1.

For 6 soft-sprites only 6*3 chars are "wasted" instead of 6*9. That is - as you can imagine - a really big deal considering we have only 128 chars

Downside: one DLI per charline. However, this can be used to change colors or PMG positions colors. For a game like MI this might be very useful. Second disadvantage, you need 4Kb for chars instead of 1Kb. The code for the soft-sprites is a bit trickier, however, you gain a bit of speed as you always write to the same chars for each line. Hard to explain, but it works rather good when you wrapped your around it.

 

Anyway, as I haven't much experience with MI I'd rather let you guys figure out how to do it.

 

 

EDIT: See example by Heaven

Edited November 25, 2013 by Creature XL

[Rybags]

OK. By the calcs I did in the day, that's not necessary.

 

There's never more than 2 robots per scanline. As said before, dynamically generated definitions for each robot, so only 9 chars for a 3x3 object.

 

The background objects eat up a good number of characters in themselves but multiple charsets per screen will do the trick, fairly sure the DLI requirement should coincide with that needed for Player HPos movements.

[José Pereira]

@Rybags: And just because the maximum of enemys per line are two and they're only 7pixels wide then why not set PRIOR1 and Multicolour PMGs mode then eachone can have three colour and multiplex them (and different colours) on other lines/floors, one P0+P1 and the other P2+P3 ?

Screen in 40Bytes wide with black as the BAK colour register.

PF0 any (colour,luminance) for the 'backs' wall.

PF1 always white and PF2 for the platforms.

PF3 always light brown on the \\ lifts lines.

Clever in-between floors DLIs to have some more colours on the furniture (like the C64 colourmap).

 

The software sprites are the large ball (black and inside pixels in white), enemy's shooting in black+white interlaced (please see the BBC/Electron version) and our man better looking in three colours instead of two: BAK black (hair+trousers+shoes), PF1 white (shirt) and 4Missiles taking the PF3 register light brown (face+hands skin).

 

I am working on some screens to show you this but also why I think I can have the game each screen in just one charset...

Just give me some more time, O.K.?

 

There are basically three four type of screens and most of the gfxs are only on eachone of these types.

We can have:

CHAR000->CHAR006: Walls, Platforms and lifts

CHAR007->CHAR022: Our Guy sprite (including shifting)

CHAR023->CHAR038: The large black Ball (including shifting)

CHAR039->CHAR044: The Enemys Ray shooting

Then we have all free from CHAR045->CHAR127.

We can say that we have about 80chars for the furniture gfxs. There isn't any screen that has these gfxs using more than 80gfxs (all C64 all gfxs on all screens+lifts+pillars+wall are around 230chars).

On A8 we can 'pick-up them on the fly' and put them in chars045->127 at the needed (x,y)Pos.

 

Other thing is that, also, there are a sort of four type of screens and we can have one charset with each one (only two or three gfxs appear in all these four type screens like the front view computer).

As a generic we can say that these foour types of screens are:

-> COMPUTERS screens

-> BEDROOM AND SEATING screens

-> TOILET screens

-> KITCHEN screens

 

I can create any possible combinations on these one using on each just one charset (using those previous chars organization).

 

My idea about PMGs is the described on the quoting box:

-> ANTIC4

-> PRIOR1

-> 40Bytes wide screen

-> Multicolour PMGs Mode with 5th Player enabled

-> We can have 4maximum enemys on screen (5?) but there are only a maximum of two per line so:

(P0+P1) 3colours_Enemy1

(P2+P3) 3colours_Enemy2

-> For the PFs we can have:

BAK: always Black

PF0: (any colour,any luminance) that is the 'backs' Walls colours

PF1: always White

PF2: The front/DLI/the floor of the Platforms

PF3: always light Brown (1C)

Using that method of the 4type of screens we can have between the Platforms cleverly and universal DLIs to change the PF2 colour.

-> By now we have possibility to set Our Guy doing hardware collision with the Enemy's robots that are just Players hardware sprites (any enemy can have (any colour,any luminance) and all on screen can be different from the others.

-> Our guy uses BAK_Black and PF1_White but also the face and hands skin using the 4Missiles in 5th Player Mode taking the PF3 colour register.

 

 

Here are the 4types and the looking (probably less colour DLIs between the Platforms but you get the idea. O.K. And I know that are Platforms that can be placed in stairs between these 'lining Platformsm but it also works...)_

-> COMPUTERS SCREEN:

Normal looking:

PAL Blending:

-> BEDROOM SCREENS:

Normal:

PAL Blending:

-> TOILETS SCREENS:

Normal:

PAL Blending:

-> KITCHEN:

Normal:

PAL Blending:

 

 

 

And the Enemys sprites if using the Players Multicolour and a great good looking they could have:

 

 

 

 

Edited November 25, 2013 by José Pereira

[José Pereira]

Forgot to say that I started the gfxs conversion using the BBC/Electron for the pillars, platforms and lifts and later the C64 ones for the furniture gfxs but most are re-done to suit my personal taste and fit better on A8 DLIs and less available chars per charset.

[Creature XL]

 

There are basically three four type of screens and most of the gfxs are only on eachone of these types.

We can have:

CHAR000->CHAR006: Walls, Platforms and lifts

CHAR007->CHAR022: Our Guy sprite (including shifting)

CHAR023->CHAR038: The large black Ball (including shifting)

CHAR039->CHAR044: The Enemys Ray shooting

Then we have all free from CHAR045->CHAR127.

We can say that we have about 80chars for the furniture gfxs. There isn't any screen that has these gfxs using more than 80gfxs (all C64 all gfxs on all screens+lifts+pillars+wall are around 230chars).

On A8 we can 'pick-up them on the fly' and put them in chars045->127 at the needed (x,y)Pos.

 

Other thing is that, also, there are a sort of four type of screens and we can have one charset with each one (only two or three gfxs appear in all these four type screens like the front view computer).

As a generic we can say that these foour types of screens are:

-> COMPUTERS screens

-> BEDROOM AND SEATING screens

-> TOILET screens

-> KITCHEN screens

 

I can create any possible combinations on these one using on each just one charset (using those previous chars organization).

 

My idea about PMGs is the described on the quoting box:

-> ANTIC4

-> PRIOR1

-> 40Bytes wide screen

-> Multicolour PMGs Mode with 5th Player enabled

-> We can have 4maximum enemys on screen (5?) but there are only a maximum of two per line so:

(P0+P1) 3colours_Enemy1

(P2+P3) 3colours_Enemy2

-> For the PFs we can have:

BAK: always Black

PF0: (any colour,any luminance) that is the 'backs' Walls colours

PF1: always White

PF2: The front/DLI/the floor of the Platforms

PF3: always light Brown (1C)

Using that method of the 4type of screens we can have between the Platforms cleverly and universal DLIs to change the PF2 colour.

-> By now we have possibility to set Our Guy doing hardware collision with the Enemy's robots that are just Players hardware sprites (any enemy can have (any colour,any luminance) and all on screen can be different from the others.

-> Our guy uses BAK_Black and PF1_White but also the face and hands skin using the 4Missiles in 5th Player Mode taking the PF3 colour register.

 

 

Here are the 4types and the looking (probably less colour DLIs between the Platforms but you get the idea. O.K. And I know that are Platforms that can be placed in stairs between these 'lining Platformsm but it also works...)_

[..PICS..]

 

 

Looks nice and sounds OK at a first glance - haven't read it in full detail.

 

However, I want to mention some thinks you should consider:

For one, if there is a maximum of 6 enemies ( I think you even said there are only 4) I would propose using the soft-sprites for them.

Do not forget the soft-sprites need to be pre-shifted. The player's sprite has lots of shapes AFAIK. To give you an idea, one pre-shifted shape (9x16 pixel) WITH PMG-overlay needs 256 bytes.

Considering 24 different shapes (number taken from HitC not from IM) this amounts to 6Kb PLUS 6Kb for the pre-shifted AND-Tables.

Sure, a few bytes aren't used, however, in this format it is relatively easy to use (from a coder's point of view).

Additionally, you can have fixed colors for the player's sprite. Of course you can use arrange the PF-colors, but IMO its cooler to give the player its own colors if possible.

Stuff like flashing when hit or other "efx" are much easier to achieve. Don't know if that is needed in IM.

 

I guess the "basic stuff" that is the (static) rooms would be implemented rather quickly with my engine developed for HitC.

Not that i would code it, but I am a bit proud of my engine

[José Pereira]

Mine and here you have:

Ones that are only Players hardware sprites like enemys and others only soft sprites like the enemys shots or the large black ball.

Here I have it like 'one is one and the other is the other'!...

There is no over/underlays like the proposal I sent to you about Creatures2.

The only one that we can say we havd a mix between between soft sprites and PMGs is the our guy because I added to him the light brown PF3 colour using the 5th Player 4Missiles mode.

But it can still be black&white, BAK&PF1 two colours only like on C64 but ugglier because we, on A8, don't have hi-res hardware sprites (that's why I decided that to turn this and look better a 3rd, the skin colour on the face and on the hands would look great!).

[Rybags]

PMGs need to be used for the collision detect aspect. The detection has to be pixel-perfect (although one idea I had was to have an option that allowed some leeway)

 

However nice it is to use them to give more overall colouring, the extra CPU time of rendering a large softsprite for the human and doing the tedious collision detection would make it impractical.

 

Possibly some compromise method could be employed where a Player and couple of missiles are reserved to serve as overlay for collision detect purposes but in reality I doubt it would work well.

 

For me a game that preserves the C64 gameplay element would be more important than one that looks nice but has inferior dynamics.

[Heaven/TQA]

Jose... I guess you need to take the Summer Games sprite

[José Pereira]

Hi.

I already had this same idea some time ago and was more or less using the same idea MPG Productions did on RGB regarding IM but wasn't very sure how to have the colours for the sprites.

For a long time I decided that the best and almost sure quick way is to get the BBC/Electron version as our recent Ransack may prove.

Problem on the Beebs version is that they use they're overscan tall size of 256scanlines (32charlines). Puting they're version and the C64/ZX and CPC ones together (these ones have the platforms screens in 192scanlines=24charlines tall) I realized the way and why all are at 192 and they had to re-sized soo much more on Beebs:

-> On the Beebs version a screen with all the floors alligned you have 4steps but if there's a floor between them it's placed at the middle, because a floor it's 1charline tall you then see that to put it at middle the space between must be an odd number.

Here's screen(s) that shows this but on C64 version because I can't find a Beebs one now:

 

 

Although they seem to have floors at different charlines in C64 version:

I'll have to see if Beebs also have but the more common and/or normal are these...

And to have the 'common ones' possible we must have odd number of charlines between the 4steps floors.

-> All versions have, like this:

5charlines

1charline_Floor

5charlines

1charline_Floor

5charlines

1charline_Floor

5charlines

1charline_Floor

->BBC&Electron to have the same they decided, because they could, to have 5 turned to 7charlines and that does the 32charlines screen tall.

 

 

Now talking about A8 conversion...

Beebs doesn't have a charmode mode if I remember it right and it is using their 2bpp 4colours modes to save memory and a screen is 8KBs of Memory.

Me and Xuel already realized that on Ransack and we could sucessfully turned that into charmode. Now the point is: "Can we also and easy turn Beebs IM into charmode?"

I think we can and even one charset for all screen or if not we must have some multiple charsets across the screen...

From my study we'll have just a couple of chars needed for the floors and walls+lifts and maximum 4robots+large black ball (including shifting)+robots shots takes around 70chars (000->069) so there's 58chars left for the furniture gfxs.

If we set char 070->char 127 for this and 'fill' these chars with the current screen gfxs would be enough? Something that only seeing the code will say...

 

Other thing is how easy would be, like in Ransack, taking the Beebs code and port it to A8 just taking off two chars per step and that would be the Beebs code but 32charlines turn into 24chars and will have exactly same screen tall size of 32charlines=192scanlines like the other versions?

 

Here's a screen of Beebs versions and next to it the A8 version with the change:

Difference between the C64 version and Beebs is that the gfxs are 1scanline overlapping the Floor and this make sense because this version using bitmap mode doesn't have the chars per charset problem. But this can be also present at A8 version with just some small re-done and just 3or4 chars more needed but we can still have it all char/floors alligned like on C64 version and all the other versions and this way save some chars.

Other thing is that if all the gfxs/furniture is at the top and not overlapping the floor the Robots will be less chars (3x3chars instead of 4x3chars (shifting including)).

 

 

What I have on my screen it's the easy way and possible. Like in RGB and some other situations we have our guy as PMGs only and each Robot is PFs and one Player gives him the majour colour.

Seeing all our guy frames two players (16pixels are more than enough to cover all the clothe and hair and all frames of the Beebs guy face and hands can use 8pixels wide (there's only one that has 9 but we can erase one and it's still good looking), soo for our guy we'll use (PMGs prior1):

-> P2&P3: dark gray (more BAK_black and PF1)

-> 4Missiles in 5th Player mode and set white as PF3.

And the Robots:

-> One use P0 and the other P1 (maximum per line possible are two soo this is O.K. and that large ball can use PFs only and black majour colour it's BAK colour register)

 

Then it's easy. The screen PFs have common for all:

BAK: black

PF3: white

And then others can be different per eachone:

PF0: wall colour

PF1: wall and floor colour

PF2: furniture/gfxs colour (that can be mixed with PF3_white like I showed on my screen)

 

 

 

 

Humm....... The usual question:

"Anyone interested?"

Edited January 20, 2015 by José Pereira