Mappy - 2600

[supercat]

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).

 

I don't know how best to handle the roof, but the floors in most places could be handled by sticking something like the following in RAM:

  stx COLUBK
  ldx #$xx
  stx COLUBK,y
  ldx #$xx
  stx COLUBK,y
  ldx #$xx
  stx COLUBK,y
  ldx #$xx
  stx COLUBK,y
  ldx #$xx
  stx COLUBK,y
  ldx #$xx
  stx COLUBK,y
  ldx #$xx
  stx COLUBK,y
  rts

A little pricey--31 bytes of RAM, but it would allow for arbitrary trampoline/floor color patterns. I'd suggest using "STX" for floor and "SAX" for trampoline. That way the code doesn't have to be changed between the "floor only" and the "floor and trampoline" scan lines. As a further possible speed up, before each group of trampoline scan lines (assume there are ten, and assume 2lk resolution for sprites), set up the stack to allow something like the following sequence:

code_go0a:
 pla
 sta COLUP0
 pla
 sta GRP0
 lda #$00
 ldx col1
 jmp zpcode; Assume stack is pre-configured for proper returns
code_go1a:
 pla
 sta COLUP1
 pla
 sta GRP1
 ldx col1
 lda #$00
 jmp zpcode; Assume stack is pre-configured for proper returns
code_go0b:
 pla
 sta COLUP0
 pla
 sta GRP0
 lda #$FF
 ldx col1
 jmp zpcode; Assume stack is pre-configured for proper returns
code_go1b:
 pla
 sta COLUP1
 pla
 sta GRP1
 ldx col1
 lda #$FF
 jmp zpcode; Assume stack is pre-configured for proper returns

I count 14 cycles of pla/sta plus 5 for ldx/lda, plus 3 for the jmp. 44 for the zero-page code itself. Total 76. RAM usage would be four bytes per scan line.

 

The code should be started at a different spot on the scan line to accommodate different scroll amounts. The P0 and P1 shape/color will be offset by a scan line, but that shouldn't be a problem since they'll be moving then anyway.

 

A little 'piggy' as code goes, but with a SuperChip it might be workable. Not sure how the roof should be done.

[supercat]

BTW, I haven't figured out yet how to handle the bonus levels, but if I remember right, they don't have anything except Mappy, trampolines, vertical walls, and musical notes. The normal Mappy kernel probably couldn't handle that (too many vertical walls) but a special kernel that hits RESBL repeatedly might work. The walls would be 'dashed' at every floor level, but I don't think that would be too bad--at least not by 2600 standards.

[r_type2600]

Great to see you expanding into platform territory, Johnny!

 

I must admit that I had passed on Mappy so far, but it looks to be a rather entertaining game concept and an original one on top.

In any case, I tried to educate myself on it, and a google search prompted a couple of rather nice fansites, which you may want to check up as a reference:

 

http://www.fourhman.com/mappy/

 

Especiall the "screens" page may be useful:

 

http://www.fourhman.com/mappy/screenshots.htm

 

This one is Japanese, but provides screenshots of conversions to even the most obscure systems:

 

http://tbs701.hp.infoseek.co.jp/mappy.html

 

I am sure that the 2600 version will outshadow quite a few of these

 

Good luck,

Eric

[Pac Munchkin]

Wow I can picture Mappy on the 2600 looking almost as good as Mappy on MSX! That looks like it could be really good!

 

Wade

[Thomas Jentzsch]

The code should be started at a different spot on the scan line to accommodate different scroll amounts.

I see the advantage of slightly smoother scrolling steps, but the very tight timing requirements might be just too much.

[supercat]

I see the advantage of slightly smoother scrolling steps, but the very tight timing requirements might be just too much.

 

Well, I'd been thinking also of the advantage to being able to colorize the trampolines although now that I think about it, I think the only trampoline that changes color is the one underneath Mappy, and unless it's popped its color will revert back to what it had been before.

 

Looking at the maps, except on the bonus levels, scrolling should be pretty straightforward since all the "holes" line up vertically. Even a full-width assymmetric playfield shouldn't be too much of a problem.

[+johnnywc]

Hello,

 

Thank you all for your insightful suggestions. Certainly sounds like Mappy will be quite a challenge, and I'm always up for that!

 

My goal is to try to do this without the Superchip in 16K, which may be possible. From the screen shots, it seems that:

 

1) there are 5 different floor patterns. therefore, pre-calculating the PF in a table for the 32 possible scroll positions for every 4-byte set would use 128 bytes; a total of 640 bytes needed. As Bob suggested, the 4 PF values can be precalculated for each floor, so only 4 bytes of RAM are needed (plus pointer info indicating the level you're on, which would indicate the pattern to use for each floor).

 

2) there are 3 diffierent trampoline patterns (including a blank one). using the same logic as (1), the PF can be precalculated and stored in a table for all 32 scroll positions needed 128 bytes per set for a total of 384 bytes. Of course, since trampolines can be broken on one side and not another, a mask would have to be applied depending on the value of that trampoline and what side is being displayed (left or right). Again, this will use 4 bytes of RAM (plus pointer info) and can be calculated in between floors.

 

3) Doors will be represented by the ball. The width will have to be changed from 2 to 4 temporarily with a HMBL value in the middle to draw the door knob and indicate the swing direction of the door. Microwave doors are the same except the color cycles. Door will move to simulate the microwave effect when it's opened. Open doors will be the ball with a larger width ( 8 ).

 

4) The roof can have 3 configurations - one without an attic, one where there is an attic and one with the bells. Most likely this may need to be scrolled with the traditional rotate method on the fly since it would take much ROM to store pre-calc values (6 * 128 * 3 = 2.25K). Also, since there is no break between each section of the roof there is no time to pre-calc the PF values anyway. Best approach is probably to store the PF values for the 6 sections in RAM (24 bytes - ouch!!). The gain here is that it only takes 24 cycles to draw the roof, leaving plenty of cycles for the players. ROM usage for the data (assuming 3 roof configurations) would be 6*8*3 = 144 bytes.

 

5) Prizes are always in the same spots. They should be arranged so that no more than 1 can appear on a floor at a time (this would require moving a few around in the original configuration). The should probably be drawn with the players (although this will increase flicker). Locations and type can be stored in ROM since they're static; active yes/no can be stored in a few bytes of RAM. I don't think missiles would work here as the color would be dependent on the player, which would be either the mouse or the cats.

 

6) With all PF reads loaded from zp RAM, 24 cycles is needed to update the PF. This should leave enough time for single line resolution sprites (maybe even multicolor). To reduce flicker, there will most likely need to be less cats than the maximum 10 on Mappy Even with 4 max, that means 20hz flicker worse case scenario (with Mappy and a prize). This may have to upped to 6 cats (15 hz flicker worse case scenario) to increase difficulty adequately although this increases the RAM needed of course. Forced vertical separation for the cats doesn't work since it takes away the ability to zap them all with the microwave door.

 

7) Trap doors will be tough; although conceptually they can be represented with a flickering PF by applying a mask against the PF values every other frame. Similar to the trampolines, there are 4 configurations. Could be a slick way to do this - will have to think about it.

 

8 ) Bonus level will have to be a different kernel (as supercat suggested). Looks like there are 12 sections of PF that need to be defined; these can be preloaded with overlay RAM in 48 bytes. Balloons will need to be vertically seperated per visible screen. Blank lines will be necessary in the PF for the repos. The 4 trampolines can be hardcoded based on location of the scroll. Bottom trampolines can be drawn with COLUBK, similar to the game kernel.

 

This look feasible? Any other ideas are welcomed and thanks for the suggestions!

Edited August 8, 2006 by johnnywc

[Shawn]

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.

 

 

I know he has hundreds of them so there is no worries. I just got 50 myself.

[Cybergoth]

6) With all PF reads loaded from zp RAM, 24 cycles is needed to update the PF. This should leave enough time for single line resolution sprites (maybe even multicolor). To reduce flicker, there will most likely need to be less cats than the maximum 10 on Mappy Even with 4 max, that means 20hz flicker worse case scenario (with Mappy and a prize). This may have to upped to 6 cats (15 hz flicker worse case scenario) to increase difficulty adequately although this increases the RAM needed of course. Forced vertical separation for the cats doesn't work since it takes away the ability to zap them all with the microwave door.

 

This look feasible? Any other ideas are welcomed and thanks for the suggestions!

 

Phew... that sounds like pretty severe flicker. Almost of Wizard of War / Pac-Man quality, no?

 

Couldn't a better solution possibly work like this?

 

It seems it would allow a detailed Mappy + Prize + Master Cat, plus another 5 limited shape minor cats - all at 30Hz.

[+johnnywc]

6) With all PF reads loaded from zp RAM, 24 cycles is needed to update the PF. This should leave enough time for single line resolution sprites (maybe even multicolor). To reduce flicker, there will most likely need to be less cats than the maximum 10 on Mappy Even with 4 max, that means 20hz flicker worse case scenario (with Mappy and a prize). This may have to upped to 6 cats (15 hz flicker worse case scenario) to increase difficulty adequately although this increases the RAM needed of course. Forced vertical separation for the cats doesn't work since it takes away the ability to zap them all with the microwave door.

 

This look feasible? Any other ideas are welcomed and thanks for the suggestions!

 

Phew... that sounds like pretty severe flicker. Almost of Wizard of War / Pac-Man quality, no?

 

Couldn't a better solution possibly work like this?

 

It seems it would allow a detailed Mappy + Prize + Master Cat, plus another 5 limited shape minor cats - all at 30Hz.

 

Yes - flicker would be pretty bad. Not as bad as WoW, but pretty bad. Limited shape cats might be fine (using the missiles of course), but the color could be a problem. Mappy should be gray, Goro should be red and the cats should be pink. Not sure how all that would work out. Not sure what kind of cat you can make out of missiles either. Hmmm....

 

EDIT: Cool demo by the way - what is that?

Edited August 8, 2006 by johnnywc

[+SpiceWare]

Hmm - gray sprite for Mappy, red sprite for Goro, draw 2 cats using the missiles and swap missiles for every frame for a blended pink.

 

Of course that doesn't consider the prizes.

[Cybergoth]

Yes - flicker would be pretty bad. Not as bad as WoW, but pretty bad. Limited shape cats might be fine (using the missiles of course), but the color could be a problem. Mappy should be gray, Goro should be red and the cats should be pink. Not sure how all that would work out. Not sure what kind of cat you can make out of missiles either. Hmmm....

 

Personally I'd prefer some color changes/dependencies over too severe flicker.

 

EDIT: Cool demo by the way - what is that?

 

That's "Look Mom, No Flicker" from Piero Cavina

[vdub_bobby]

How about this:

 

P0=Mappy, Goro (flickered)

P1=two cats (flickered)

M0=prizes

M1=one cat (flicker two missile shapes to get a recognizable cat)

 

That gets you Mappy, Goro, three cats, and two prizes on the same horiz line all at 30 Hz flicker. Plus, except for the prizes, all the colors can be the same as the arcade.

 

To get more cats...well, I dunno. For more cats I'd use forced vertical separation, even though it would prevent you from hitting all the cats with one door. If it was done well enough most players would never even notice.

[Cybergoth]

To get more cats...well, I dunno.

 

What if every other cat walked along the ceiling?

[+johnnywc]

How about this:

 

P0=Mappy, Goro (flickered)

P1=two cats (flickered)

M0=prizes

M1=one cat (flicker two missile shapes to get a recognizable cat)

 

That gets you Mappy, Goro, three cats, and two prizes on the same horiz line all at 30 Hz flicker. Plus, except for the prizes, all the colors can be the same as the arcade.

 

To get more cats...well, I dunno. For more cats I'd use forced vertical separation, even though it would prevent you from hitting all the cats with one door. If it was done well enough most players would never even notice.

 

Interesting idea. A few issues:

 

- you'll be hard pressed to make 5 distinguishable prize shapes with a missile. plus, the color will flicker between the Mappy and Goro color (unless they are the same)

- I may be wrong, but i don't think you'd be able to have asym PF, 2 single line resolution sprites, and a missile drawn on the same line (worse case scenario). Other lines could have both missiles, the ball (for the doors), both players, NUSIZ change for the ball (for the doorknob), NUSIZ and a HM change for missile 1 to draw the cat. I was supposed to be using those extra cycles to pre-load my PF temp vars for the next floor!

 

One concession would be to have a limit of Mappy, Goro, 3 cats and the prize. 20hz flicker, worse case scenario. Goes up to 30hz when the prize is taken (improving flicker over the course of the level, like Lady Bug) and Goro does not follow you like the other cats. The difficulty could be ramped up to accommodate for the lesser # of cats.

[vdub_bobby]

- you'll be hard pressed to make 5 distinguishable prize shapes with a missile. plus, the color will flicker between the Mappy and Goro color (unless they are the same)

Well, you get four for free: a "box" 1 pixel wide, a box 2 pixels wide, a box 4 pixels wide, and a box 8 pixels wide.

 

And yeah, you sacrifice some color independence for the prizes (not a big issue IMO) in this scenario.

 

And actually - if you make the prizes always flickering at 30 Hz then you can distinguish them by color as well - each prize could be either the same color as Mappy or the same color as Goro.

 

- I may be wrong, but i don't think you'd be able to have asym PF, 2 single line resolution sprites, and a missile drawn on the same line (worse case scenario). Other lines could have both missiles, the ball (for the doors), both players, NUSIZ change for the ball (for the doorknob), NUSIZ and a HM change for missile 1 to draw the cat. I was supposed to be using those extra cycles to pre-load my PF temp vars for the next floor!

Well...

While drawing the platforms you would use a 2-line kernel (so you could use SwitchDraw) and you would:

asym PF (platform): 24 cycles

P0, P1 (Mappy, Goro, two cats): 30 cycles (use SwitchDraw, no color changes)

M1 (prizes): not drawn

M0 (other cat): 24 cycles

hit HMOVE: 3 cycles

decrement Y: 2 cycles every other line.

 

Okay, that's too many - though not by a lot. Take the minor cats to 2-line resolution and you are there, though:

line 1:

asym PF: 24 cycles

P0: 15 cycles

P1: 15 cycles

M1: 0 cycles

M0: 0 cycles

hit HMOVE: 3 cycles

decrement Y: 2 cycles

--Total: 59 cycles

 

line 2:

asym PF: 24 cycles

P0: 15 cycles

P1: 0 cycles

M1: 0 cycles

M0: 24 cycles

--Total: 63 cycles

 

During the non-platform areas, you'll have plenty of time to draw the prizes and preload the PF values since you'll automatically have an extra 24 cycles every line.

[Cybergoth]

To get more cats...well, I dunno.

What if every other cat walked along the ceiling?

 

*bump*

 

Hey, I thought that was quite a good idea actually! Twice as many cats for no extra flicker!

[Thomas Jentzsch]

Couldn't the PF be used for the prizes somehow?

[Cybergoth]

Couldn't the PF be used for the prizes somehow?

 

I fear not even with a superchip could you buffer prizes AND scrolling.

[+Nathan Strum]

Not sure what kind of cat you can make out of missiles either. Hmmm....

 

What are the limitations for working with missiles?

[vdub_bobby]

Not sure what kind of cat you can make out of missiles either. Hmmm....

 

What are the limitations for working with missiles?

Must be 1, 2, 4, or 8 pixels wide.

 

So by changing size and position line-by-line you can sort-of make sprites. See Lock 'n' Chase and, especially, Dark Cavern for good use of missiles as sprites.

 

EDIT: In Dark Cavern everything except the user-controlled sprite can be either a player or a missile.

Edited August 8, 2006 by vdub_bobby

[supercat]

During the non-platform areas, you'll have plenty of time to draw the prizes and preload the PF values since you'll automatically have an extra 24 cycles every line.

 

In the platform areas, there won't be any prizes. Further, I don't think it's necessary to support more than two flickerless objects on the platform scan lines.

 

Otherwise, I was wondering whether it might be practical to restrict the timing of the cats' movements so that many of them would end up being multiples of 16 pixels apart? That would be an obvious win.

 

Likewise, in the bonus round, adjusting balloons to either be separate vertically OR be a multiple of 16/32 pixels apart would be helpful.

 

My personal taste would probably be to have Mappy and the prizes be stripe-color players, and have the cats and Goro be single-color. A "hiding" cat could perhaps be drawn using a missile and/or an alternate version of the prize.

[vdub_bobby]

Further, I don't think it's necessary to support more than two flickerless objects on the platform scan lines.

Probably right, but if you can why not?

 

The real key is if you can get a decent looking cat with a single, non-flickered missile. If you can then you can have Mappy (P0), two enemies (P1 and M1), and a prize (M0) all on the same horizontal line with no flicker. With flicker you can add more sprites, up to double.

 

But I don't think a single, non-flickered missile can be contorted into a cat shape. Nathan, prove me wrong?

Edited August 8, 2006 by vdub_bobby

[supercat]

Probably right, but if you can why not?

 

If it can be done without compromises elsewhere, sure. But don't go to excessive lengths.

 

As using a cat-missile, if the player cats are 2-line resolution, it may be possible to use a missile with flicker-blinds to add an extra cat. I'd suggest the following recipe:

Two objects or fewer: use both player sprites
Three cats: draw two cats with players; use missile for third
Mappy plus prize plus cat: flicker prize and cat (player sprites for everything)
Mappy or prize plus two cats: draw one cat using a player, and use missile for second cat.
Mappy or prize plus three cats: flicker two cats using a player, and use missile for third cat.
Mappy plus prize plus two cats: Flicker mappy and prize with one player; draw one cat with other player; use missile for third cat.
Mappy plus prize plus three cats: Flicker mappy and prize with one player; flicker two cats with other player; use missile for third cat.
Mappy or prize plus four cats: Flicker mappy with one cat; flicker other two cats; use missile for fourth cat.
Mappy plus prize plus four cats: Flicker mappy with prize; flicker two cats; use missiles to flicker third and fourth cats (they'll appear 'dotty' but eh)
Other possibilities might require dropping to 20Hz flicker or other such nastiness.

If Mappy and the prizes are stripe-colored and the cats aren't, each line will have either two stripe-colored players, or a stripe-colored player, a solid player, and a missile.

Edited August 9, 2006 by supercat

[Thomas Jentzsch]

As using a cat-missile, if the player cats are 2-line resolution, it may be possible to use a missile with flicker-blinds to add an extra cat. I'd suggest the following recipe:

That's a pretty complete access to avoid flicker at all costs. But IMO changing flicker is also pretty bad or even worse. When objects flicker at a constant, high(!) rate this is often less noticable than when the flicker goes on and off.

 

So when you have to flicker anyway, I would suggest using a "basic flicker" of 30Hz for all objects that may eventually flicker.