Mappy - 2600

[+johnnywc]

Hello all,

 

I've been checking on the JohnnyWC next game poll and if it ended today, most people want a port, and the port with the most votes is Mappy. This got me thinking about how a port of Mappy could be done:

 

Here's what we have:

 

- horizontal scrolling maze (yuck!)

- Mappy

- Goro (the red cat)

- up to NINE pink cats

- 10 prizes (5 sets of 2)

- trampolines

- bells

- removable floor pieces

- doors

- microwave doors (flash and move)

- 15 levels, each with a different floor layout

- 6 floors per level

 

There is also a bonus stage involving balloons, but this doesn't seem too difficult to recreate (balloons can be vertically separated).

 

Wow - lots for the ol' 2600 to do.

 

Thoughts:

 

- We can keep PF0 blank, only needed PF1 and PF2, asymetrical and reflective, for the house (roof and floors).

- We can keep the prizes vertically separated in the 6 floors, never allowing more than 1 to be on a floor (since the playfield actually takes up 2 screens)

- Scrolling can be done and would be coarse (4 pixel), but an alternative would be to have 3 screens: one that shows the right side, one that shows the middle and one that shows the left. The screens would change as Mappy reached certain positions.

- Doors can be represented by the ball sprite; the width can be changed as the door is open. Again - limit one door per floor that is visible on the screen.

- Trampolines could either be the ball sprite (8 pixels wide max), although they may have to be the PF and be 12 pixels wide.

- Limit the # of pink cats to a reasonable # (say, 4)

- Only one bell will ever be on the screen at once and is always on the roof level

- Removable floor pieces could be represented by a flashing PF; removed as Mappy passes over it

 

Looks like we'll need 32 cycles per line for the asymetrical reflective house layout, leaving 44 for the sprites. Two single-line sprites can be done in 36 cycles, leaving only 8 for loop maintenance, color changes etc. (not enough). Will probably have to go with double line sprites, but may be able to squeak in multi-colors instead.

 

Repositioning can be done on a line with no playfield (there's plenty of those).

 

Max # of objects on a line will be 7 (Mappy, 4 pink cats, Goro and a prize) that can be drawn with 2 players (15 and 20 hz flicker).

 

Lots to do, lots of RAM needed (maybe too much)?

 

Any thoughts are welcomed.

 

Thanks,

Edited April 28, 2021 by johnnywc
updated title

[djmips]

Use a SuperChip? Come on, be the first homebrew to do it!

[keilbaca]

Use a SuperChip? Come on, be the first homebrew to do it!

 

With CPUWIZ having the chips, its very possible...

 

I can't believe this is being made for the 2600, too cool.

[Cybergoth]

Hm... never played Mappy before I think. Is the version in the Ms. Pac-Man stick good enough or should I better try MAME?

[supercat]

- Trampolines could either be the ball sprite (8 pixels wide max), although they may have to be the PF and be 12 pixels wide.

 

My recollection of the game is that the trampoline is always between wall or floor sections. It could thus be accomplished the same was as the barriers in Lock & Chase: set the background color briefly.

[Pac Munchkin]

Could it be made without scrolling like just have the play field as wide as the screen, that might be more do-able?

 

Wade

[+johnnywc]

Hm... never played Mappy before I think. Is the version in the Ms. Pac-Man stick good enough or should I better try MAME?

 

Fun game - I would recommend MAME is at all possible, although I think the one on the Ms. Pac-man stick is close enough to give you an idea of how it plays...

[+johnnywc]

- Trampolines could either be the ball sprite (8 pixels wide max), although they may have to be the PF and be 12 pixels wide.

 

My recollection of the game is that the trampoline is always between wall or floor sections. It could thus be accomplished the same was as the barriers in Lock & Chase: set the background color briefly.

 

Great idea!

[+johnnywc]

Use a SuperChip? Come on, be the first homebrew to do it!

 

That may be the route to go - although I'll have to make sure that CPUWIZ has an ample supply of those things first.

[Thomas Jentzsch]

- Scrolling can be done and would be coarse (4 pixel), but an alternative would be to have 3 screens: one that shows the right side, one that shows the middle and one that shows the left. The screens would change as Mappy reached certain positions.

Delayed scrolling like in Thrust seems very doable and should look pretty smooth.

[+johnnywc]

- Scrolling can be done and would be coarse (4 pixel), but an alternative would be to have 3 screens: one that shows the right side, one that shows the middle and one that shows the left. The screens would change as Mappy reached certain positions.

Delayed scrolling like in Thrust seems very doable and should look pretty smooth.

 

Hi Thomas!

 

Can you explain your delayed scrolling technique?

 

Thanks,

[Thomas Jentzsch]

Can you explain your delayed scrolling technique?

It's pretty simple:

Once the object reaches a certain start point point, the screen starts scrolling into the opposite direction (~ every 2nd or 3rd frame) until it the object reaches the stop position.

 

You could e.g. use 80% of the screen as start position and 30% as the stop position in one direction and 20% start, 70% stop for the opposite direction. And you must make sure, that there is a certain gap between the start and other stop position. Else the screen will scroll too often.

 

I can post some code examples if you want to.

[Atariboy2600]

Hello all,

 

I've been checking on the JohnnyWC next game poll and if it ended today, most people want a port, and the port with the most votes is Mappy. This got me thinking about how a port of Mappy could be done:

 

Here's what we have:

 

- horizontal scrolling maze (yuck!)

- Mappy

- Goro (the red cat)

- up to NINE pink cats

- 10 prizes (5 sets of 2)

- trampolines

- bells

- removable floor pieces

- doors

- microwave doors (flash and move)

- 15 levels, each with a different floor layout

- 6 floors per level

 

There is also a bonus stage involving balloons, but this doesn't seem too difficult to recreate (balloons can be vertically separated).

 

Wow - lots for the ol' 2600 to do.

 

Thoughts:

 

- We can keep PF0 blank, only needed PF1 and PF2, asymetrical and reflective, for the house (roof and floors).

- We can keep the prizes vertically separated in the 6 floors, never allowing more than 1 to be on a floor (since the playfield actually takes up 2 screens)

- Scrolling can be done and would be coarse (4 pixel), but an alternative would be to have 3 screens: one that shows the right side, one that shows the middle and one that shows the left. The screens would change as Mappy reached certain positions.

- Doors can be represented by the ball sprite; the width can be changed as the door is open. Again - limit one door per floor that is visible on the screen.

- Trampolines could either be the ball sprite (8 pixels wide max), although they may have to be the PF and be 12 pixels wide.

- Limit the # of pink cats to a reasonable # (say, 4)

- Only one bell will ever be on the screen at once and is always on the roof level

- Removable floor pieces could be represented by a flashing PF; removed as Mappy passes over it

 

Looks like we'll need 32 cycles per line for the asymetrical reflective house layout, leaving 44 for the sprites. Two single-line sprites can be done in 36 cycles, leaving only 8 for loop maintenance, color changes etc. (not enough). Will probably have to go with double line sprites, but may be able to squeak in multi-colors instead.

 

Repositioning can be done on a line with no playfield (there's plenty of those).

 

Max # of objects on a line will be 7 (Mappy, 4 pink cats, Goro and a prize) that can be drawn with 2 players (15 and 20 hz flicker).

 

Lots to do, lots of RAM needed (maybe too much)?

 

Any thoughts are welcomed.

 

Thanks,

 

 

Cool! Of all the classic Namco games I really like to see Mappy soo much I did this label art last year but now it may come true after all.

[Thomas Jentzsch]

FULL quote

Cool! Of all the classic Namco games I really like to see Mappy soo much I did this label art last year but now it may come true after all.

Please limit your quoting a bit. Thanks!

[+johnnywc]

Can you explain your delayed scrolling technique?

It's pretty simple:

Once the object reaches a certain start point point, the screen starts scrolling into the opposite direction (~ every 2nd or 3rd frame) until it the object reaches the stop position.

 

You could e.g. use 80% of the screen as start position and 30% as the stop position in one direction and 20% start, 70% stop for the opposite direction. And you must make sure, that there is a certain gap between the start and other stop position. Else the screen will scroll too often.

 

I can post some code examples if you want to.

 

Thanks for the info Thomas. I've never done horizontal scrolling on the 2600. What is the general algorithm to do this? I assume it involves rotates and shifts? For example, it seems that Mappy can be done using just PF1 and PF2, asymetrical and reflective. Each line will use 4 bytes; looks like I need 6*4 bytes for the roof and 6*4 bytes for the floors = 48 bytes. The Mappy level is 2 screens wide, so each line can be represented by 8 bytes.

 

- the four bytes for each line are preloaded with the four right-most PF bytes (since Mappy starts from the right).

- as you scroll left, you use rotates to move pixels from PF1L -> PF2L -> PF2R -> PF1R, rotating a pixel in based on the current position.

- the reverse is done as you scroll right

 

In your delayed scroll, do the objects move (that is, does gameplay continue) during the scroll or does it just scroll until it hits the stop position?

 

Any help is greatly appreciated!

 

Thanks,

Edited August 7, 2006 by johnnywc

[Thomas Jentzsch]

Thanks for the info Thomas. I've never done horizontal scrolling on the 2600. What is the general algorithm to do this? I assume it involves rotates and shifts?

I don't know a general algorithm for that. Thrust uses are very special one, which works based on offsets and gradient values, which probably woudn't work here.

 

For example, it seems that Mappy can be done using just PF1 and PF2, asymetrical and reflective. Each line will use 4 bytes; looks like I need 6*4 bytes for the roof and 6*4 bytes for the floors = 48 bytes. The Mappy level is 2 screens wide, so each line can be represented by 8 bytes.

 

- the four bytes for each line are preloaded with the four right-most PF bytes (since Mappy starts from the right).

- as you scroll left, you use rotates to move pixels from PF1L -> PF2L -> PF2R -> PF1R, rotating a pixel in based on the current position.

- the reverse is done as you scroll right

Sounds good and like I did in Cave1K.

 

In your delayed scroll, do the objects move (that is, does gameplay continue) during the scroll or does it just scroll until it hits the stop position?

The gameplay continues. So the object that causes the scrolling can still move and therefore the absolute stop position may change.

[+johnnywc]

Thanks Thomas! I'll see what I can come up with. With 48 bytes needed to scroll, I may need that Superchip after all...

[Thomas Jentzsch]

Thanks Thomas! I'll see what I can come up with. With 48 bytes needed to scroll, I may need that Superchip after all...

Or a lot of ROM for precalculated shifts.

[+johnnywc]

Thanks Thomas! I'll see what I can come up with. With 48 bytes needed to scroll, I may need that Superchip after all...

Or a lot of ROM for precalculated shifts.

 

Is that feasible? (I'm not sure if you're kidding or not... ). Do you mean calculating the 4 PF values for each strip for each possible scroll position? If my math is correct - if you're dealing with a screen that is 4 PF fields long (32 bits), and the total length is 2 screens (64 bits), then you would have to precalculate 32 4-byte shifts for each row. With Mappy, there are only a couple configurations per row, so there is definitely some overlap. Also, since the levels are symmetrical (albeit across two screens), there is probably some way to save space there too. Well, with Lady Bug I pre-calculated the door configurations for the maze and this took up about 1000 bytes, so this would be very similar in the sense of storage.

 

32 * 4 = 128 bytes per row

 

max = 6 rows for the floors, 6 rows for the roof = 12 * 128 = 1536 bytes. Not too bad. I'll have to investigate this further.

 

EDIT: Of course, there are multiple roof configurations and floor configurations as well. This may not be feasible, or possibly a combination of the two methods (pre-calc the shifts for the floors but not for the roof, etc.)

 

Thanks!

Edited August 7, 2006 by johnnywc

[+johnnywc]

- Trampolines could either be the ball sprite (8 pixels wide max), although they may have to be the PF and be 12 pixels wide.

 

My recollection of the game is that the trampoline is always between wall or floor sections. It could thus be accomplished the same was as the barriers in Lock & Chase: set the background color briefly.

 

Hmmm... I've been thinking about this and it seems like you would have to either (a) have many variations of this part of the kernel to set the PF color at the right time (and set it back to black at the right time) or (b) have self-modifying code in RAM that sets the background color on the fly. Each would be based on the scroll position.

 

For example (screenshot taken from klov.com):

 

 

On the 2nd floor down, the background color has to be changed to green right away, and then to black for the remainder of the line.

On the 4th floor down, the background color is black, then green, and then back to black

On the 6th floor, it's green, black and then green. Also, since PF0 isn't used it's actually green, black, green and then back to black (assuming it's black to start with).

 

Of course, these settings change with the scroll as well. Could be tough to implement.

 

Any suggestions?

[vdub_bobby]

- We can keep PF0 blank, only needed PF1 and PF2, asymetrical and reflective, for the house (roof and floors).

- We can keep the prizes vertically separated in the 6 floors, never allowing more than 1 to be on a floor (since the playfield actually takes up 2 screens)

- Scrolling can be done and would be coarse (4 pixel), but an alternative would be to have 3 screens: one that shows the right side, one that shows the middle and one that shows the left. The screens would change as Mappy reached certain positions.

- Doors can be represented by the ball sprite; the width can be changed as the door is open. Again - limit one door per floor that is visible on the screen.

- Trampolines could either be the ball sprite (8 pixels wide max), although they may have to be the PF and be 12 pixels wide.

- Limit the # of pink cats to a reasonable # (say, 4)

- Only one bell will ever be on the screen at once and is always on the roof level

- Removable floor pieces could be represented by a flashing PF; removed as Mappy passes over it

 

Looks like we'll need 32 cycles per line for the asymetrical reflective house layout, leaving 44 for the sprites. Two single-line sprites can be done in 36 cycles, leaving only 8 for loop maintenance, color changes etc. (not enough). Will probably have to go with double line sprites, but may be able to squeak in multi-colors instead.

 

Repositioning can be done on a line with no playfield (there's plenty of those).

 

Max # of objects on a line will be 7 (Mappy, 4 pink cats, Goro and a prize) that can be drawn with 2 players (15 and 20 hz flicker).

If I was going to do this, I would:

 

Use PF1 and PF2 only, like you said, and use RAM to hold the scrolling platforms; I'd use delayed, Thrust-style scrolling like TJ suggested.

Use the PF for the trampolines - it doesn't seem very important to have the trampolines be a different color than the floor - just make them thinner. I'd make them 16-pixels wide, though; that seems to match the arcade width (2x sprite width) better.

Use the ball for the doors.

Use missiles for prizes? Or use P0/P1 and accept lots of flicker.

Use P0/P1 for Mappy and his enemies, and use a movement routine that limits flicker as much as possible (i.e., that avoids more than 2 or 3 enemies on the same level onscreen).

 

Basically the same as what you said already.

 

Counting cycles...I'd say that you could probably draw the asym playfield in 24 cycles since the asym playfield is only the platforms. (Use the time between the platforms to store the indexed data in temp vars and then read from those temp vars directly when you need to draw.) Also, you can get a single-line player in 17 cycles; two should only take 34. If you are willing to interlace your graphics you could use SwitchDraw and get color changes in too.

 

Of course, these settings change with the scroll as well. Could be tough to implement.

 

Any suggestions?

Make the platforms 5 scanlines thick - two solid lines, one blank line, two more solid lines. Then change the PF color for the blank lines and draw the trampolines on that line only.

Edited August 7, 2006 by vdub_bobby

[Thomas Jentzsch]

Use the PF for the trampolines - it doesn't seem very important to have the trampolines be a different color than the floor - just make them thinner.

But the color is important, else you don't know when they break.

 

Make the platforms 5 scanlines thick - two solid lines, one blank line, two more solid lines. Then change the PF color for the blank lines and draw the trampolines on that line only.

Yup, that's what I would do to. And the central, moving part of the trampolines could be done with a missile or two.

[yuppicide]

Mappy is one of my favorite games of all time. I would love to see it for the 2600. I don't remember how the Jakks version of the game is, but if it's the NES version then it stinks.

 

Although I am very good at the game, the arcade version is harder. The NES version I can score like 10,000 or 20,000 on the first level alone and get a free life. I have a special path I run that will enable me to get all the guys with the door a few times and also get Mappy underneath the items most of the time.

[cd-w]

Thanks for the info Thomas. I've never done horizontal scrolling on the 2600. What is the general algorithm to do this? I assume it involves rotates and shifts? For example, it seems that Mappy can be done using just PF1 and PF2, asymetrical and reflective. Each line will use 4 bytes; looks like I need 6*4 bytes for the roof and 6*4 bytes for the floors = 48 bytes. The Mappy level is 2 screens wide, so each line can be represented by 8 bytes.

 

- the four bytes for each line are preloaded with the four right-most PF bytes (since Mappy starts from the right).

- as you scroll left, you use rotates to move pixels from PF1L -> PF2L -> PF2R -> PF1R, rotating a pixel in based on the current position.

- the reverse is done as you scroll right

 

You can scroll the PF left using the following code (where X*4 is the screen line that you want to move), though this requires a lot of RAM to hold the screen data:

 

	asl				; Put Pattern into Carry
	ror SCREEN+3,X		; PF1
	rol SCREEN+2,X		; PF2
	ror SCREEN+1,X		; PF2
	rol SCREEN+0,X		  ; PF1

 

Chris

Edited August 7, 2006 by cd-w

[BrianC]

Mappy is one of my favorite games of all time. I would love to see it for the 2600. I don't remember how the Jakks version of the game is, but if it's the NES version then it stinks.

 

Although I am very good at the game, the arcade version is harder. The NES version I can score like 10,000 or 20,000 on the first level alone and get a free life. I have a special path I run that will enable me to get all the guys with the door a few times and also get Mappy underneath the items most of the time.

 

The Jakks version isn't the Famicom version. The Ms. Pac-Man stick doesn't use NES on a chip hardware.

Edited August 7, 2006 by BrianC