Ladybug - 2600

[+johnnywc]

Hello all,

 

I've been thinking about my next project and hope to write a 2600 port of Universal's Lady Bug. After playing the game a bit, it seems that there is a lot to do for the ol' 2600:

 

- asymetrical maze/changing maze (revolving doors)

- asymetrical dots (like Pacman of course)

- the ladybug

- up to 4 baddies

- the bonus vegetable in the middle

- hearts and letters

- skulls

 

I know Coleco had announced a port of this but I can't see how they would of been able to implement a passable version without major compromises.

 

My thoughts:

 

- keep the maze symemetrical - that is - when one door is changed on the left, change the same one on the right

- display the static portion of the maze every frame; display half the doors on alternating frames (like Mousetrap) for 30hz flicker (to distinguish them from the static maze).

- use the ball to draw the skulls (same color as dots). they would be blocks

- keep hearts, letters and vegetable vertically separated

- use intelligent flicker to display 4 baddies using P1; use intelligent flicker to display ladybug, hearts, letters and vegetables using P0 (never more than 2 on a line)

 

Any thoughts?

 

Thanks,

Edited June 12, 2006 by johnnywc

[+Random Terrain]

Can you use whatever technique they used for Lock 'N' Chase so that there is no flicker? I know nothing about Atari 2600 programming, so that might be what you were already talking about.

 

I'll be happy to see this game become a reality. There's more knowledge available now and lots of people to help, so this game should look better than it ever could back then.

[Cybergoth]

Hi there!

 

Any thoughts?

 

Probably no chance without a Sara board

 

1. For the door flicker like you planned it, you need to RAM buffer two different PF patterns.

 

2. You need to track/buffer all the dots.

 

3. 8 sprites is 8 * xpos, 8 * ypos, 8 * movement info, 8 * AI/State info, probably 8 pointers as well.

 

4. Repositioning both sprites while doing lots of other stuff like drawing a playfield as well, will most likely also require some more buffered info so that you quikly know when to repos which sprite where, without to much in-kernel overhead.

 

Greetings,

Manuel

[ZylonBane]

Any thoughts?

Do Turtles instead.

[Cybergoth]

Hi there!

 

Any thoughts?

Do Turtles instead.

 

Turtles should be a lot easier, yes. Alien's Return is almost there actually.

 

Greetings,

Manuel

[Feralstorm]

A few thoughts from an admittedly non-programmer:

 

The biggest stumble-block is apparently the assymetric/movable playfield combined with a bunch of moving objects.

 

I'm not sure how much playfield data has to be buffered in RAM, versus being built on the fly from variables when things are drawn. Since the turnstiles have only two possible positions, horizontal or vertical, only one bit is needed to register position, and one byte can potentially store data for eight of them. Perhaps the maze(s) can be rearranged to limit the areas which would use an assymetrical playfield.

 

Many ports of Universal games to the 2600 dispense with requiring you to grab specific letters for the bonuses, and instead just add a letter to the bonus word when the item is collected, which for Ladybug would be when the right image or color appears (might have to tweak timing to make that a little more challenging)

 

Maybe use the missiles for something? Possibly even flickery dots so that part doesn't have to be playfiled.

 

In any case, it's a helluva challenge. Good luck however it works out.

[supercat]

Maybe use the missiles for something? Possibly even flickery dots so that part doesn't have to be playfiled.

999450[/snapback]

 

IMHO, Pesco demonstrates the right approach for dot-muncher games. If the playfield and turnstiles could be worked to be symmetrical, I would think things quite feasible (and even if they can't, there might still be ways...)

[Cybergoth]

Hi there!

 

1. For the door flicker like you planned it, you need to RAM buffer two different PF patterns.

 

Ah... I was wrong here of course, you need to buffer it only once, assuming the dots would flicker just like the doors. Still, that is 2 times the number of rows you do, (considering flipdors and dots can only be on PF1/PF2), so it'd still require some 50 bytes screen buffer, assuming 25 rows, 6 pixels high. (Hm... of course, that means the dots being the size of a wall pixel... )

 

Greetings,

Manuel

[+johnnywc]

Hello all,

 

Hi there!

 

Any thoughts?

Do Turtles instead.

 

Turtles should be a lot easier, yes. Alien's Return is almost there actually.

 

Greetings,

Manuel

999200[/snapback]

 

Hmm... I never played Turtles so that isn't an option. One requirement for me to port something is "the love of the game".

 

Maybe use the missiles for something? Possibly even flickery dots so that part doesn't have to be playfiled.

999450[/snapback]

 

IMHO, Pesco demonstrates the right approach for dot-muncher games. If the playfield and turnstiles could be worked to be symmetrical, I would think things quite feasible (and even if they can't, there might still be ways...)

999452[/snapback]

 

I agree on the Pesco part. One concession I was willing to make was to have the playfield symmetrical at all times; that is, when one door is flipped, the other side flips too. I don't think it would adversely affect gameplay, it may even make it more challenging.

 

 

Hi there!

 

1. For the door flicker like you planned it, you need to RAM buffer two different PF patterns.

 

Ah... I was wrong here of course, you need to buffer it only once, assuming the dots would flicker just like the doors. Still, that is 2 times the number of rows you do, (considering flipdors and dots can only be on PF1/PF2), so it'd still require some 50 bytes screen buffer, assuming 25 rows, 6 pixels high. (Hm... of course, that means the dots being the size of a wall pixel... )

 

One idea is to store a different static maze for each combination of doors (up or down). One even frames you would display the part of the maze without any doors and on odd frames you would display the maze with doors. This maze would be one of N combination of mazes (depending on the position of the doors). For example, there are 11 rows and 20 doors in the arcade version; this would trim down to 8 rows and possibly 6 doors (assuming a symmetrical maze). Each maze can be stored in rows+(rows-1)*2 = 30 bytes. The maze combinations are now 6^2=36 possible combinations, stored in 36*30=1080 bytes of ROM. If you went up to 7 doors this increases to 1470 bytes, etc. You would need 2 pointers in RAM that would be set depending on the state of the doors for the odd number of frames. I mapped out a screen that would be 11 columns x 8 rows for 88 dots, stored in 4 * 8 = 32 bytes. This assumes an 8K cart, one bank reserved to just draw the maze and the other bank for the status and game logic.

 

EDIT: I just thought about my math and it's a little off. If I have 6 doors that can be either up or down, this is 2^6 = 64 combinations. But, since PF1 and PF2 are independant, it's really 2^3 = 8 combinations for each PFx, each one pointing to 15 bytes of data. With this, you could have 8 doors instead of 6 for 2^4 = 16 combinations for each PFx. Total ROM usage would be 16 * 15 * 2 = 480 bytes. Hmm.. I'll have to think more about this.

 

I'm going to proceed on my WIP and see what I come up with. Thanks for all the suggestions.

Edited January 13, 2006 by johnnywc

[Atariboy2600]

I found a page that Digital Press own Ladybug mockup game page thats at first looks real but in the end said its was only a fake

 

Ladybug 2600 Page.

 

[+johnnywc]

Well, here is a rough maze layout.

 

The good:

 

- uses PF1 and PF2 for the maze layout. PF0 is a constant %10000000 (except when drawing dots)

- maze is 11x9, with 90 dots; arcade version is 11x11 with 121 dots (minus other objects)

- there are 16 doors, 8 independent (20 in the arcade). doors are drawn every other frame to identify them

- 8 bytes of RAM being used for the maze (4 pointers), 36 for the dots

- dots are white

- should be able to have all door layouts in ROM

 

The bad:

 

- 11 columns means only 12 pixels per column (4 for the vertical barriers), meaning dots aren't centered. I stagger them to make it look a bit more appealing

- to get 9 rows, I reserve 16 pixels for the sprites and 2 for the vertical barriers instead of the standard 4. looks a bit squished. Increasing to 3 or 4 reduces the # of available scanlines for status (score, SPECIAL, EXTRA, lives, etc) and would result in (1) less rows or (2) shorter sprites (possibly 14 pixels high?)

- white dots causes lines in the background

 

Thanks,

ladybug.bin

[ZylonBane]

I found a page that Digital Press own Ladybug mockup game page thats at first looks real but in the end said its was only a fake

It only looks real if you know very little about the 2600's technical limitations. That playfield is ten kinds of impossible.

[Cybergoth]

Hi there!

 

Turtles should be a lot easier, yes. Alien's Return is almost there actually.

Hmm... I never played Turtles so that isn't an option. One requirement for me to port something is "the love of the game".

 

Well, it's never too late to fall in love

 

One idea is to store a different static maze for each combination of doors (up or down).

 

Oh, wow! I hadn't imagined that you could possibly manage to store all door combinations in managable space. The extra dot display lines are also pretty clever.

 

Greetings,

Manuel

[+johnnywc]

Hi there!

 

Turtles should be a lot easier, yes. Alien's Return is almost there actually.

Hmm... I never played Turtles so that isn't an option. One requirement for me to port something is "the love of the game".

 

Well, it's never too late to fall in love

 

Hmm.. maybe I'll give it a shot. I still have Mappy on the list after Ladybug though...

 

One idea is to store a different static maze for each combination of doors (up or down).

 

Oh, wow! I hadn't imagined that you could possibly manage to store all door combinations in managable space. The extra dot display lines are also pretty clever.

Thanks - it looks like it's going to work pretty well. The way I have the doors arranged, there is going to be 2^5 = 32 combinations for PF1 and 2^4 = 16 combinations for PF2. I also increased the rows from 8 to 9 (8 just didn't look right). This will now take (32+16=48)*18 = 864 bytes to store all door combinations. Not too bad. I can always remove the one door that's overlapping PF1 and PF2 to reduce a few combinations and get this down to 576 bytes if necessary.

 

Of course, this is only one hurdle. The plus is that it leaves me with 80+ bytes to work with after storing all the dots and the maze pointers.

 

Here's another WIP, this one only flickers the pivot/turnstile on the doors and rounds out the maze a bit. Not sure if it's better than the previous one, but it does reduce flicker (in anticipation of the flicker that is sure to come! )

 

Thanks again for the input.

ladybug.bin

[Cybergoth]

Hi there!

 

Hm... what I'd like to see would be a variant of the first demo, with different PF colors on both frames. Could you possibly try alternating colors between $54 and $94 for me, please?

 

Greetings,

Manuel

[supercat]

Rather than flickering the turnstiles, I think it might work better if you alternate scan lines between turnstiles and walls (the dots would be on scan lines that would otherwise correspond to either the centers of turnstiles or the gaps between them).

 

This would have the definite advantage that every other scan line would have a symmetrical playfield. Even if you want single-line resolutions on your sprites this can be useful (using VDEL, you can do 3 sprite updates on symmetrical scan lines and one on the assymetrical ones).

 

This would make the turnstiles be dot-colored which may or may not be a good thing. If that's objectionable, there are other things that could be done but those would have their own issues.

[+johnnywc]

Hi there!

 

Hm... what I'd like to see would be a variant of the first demo, with different PF colors on both frames. Could you possibly try alternating colors between $54 and $94 for me, please?

 

Greetings,

Manuel

999844[/snapback]

 

Here ya go!

ladybug_altpf.bin

[Cybergoth]

Hi there!

 

Here ya go!

 

Now that looks excellent, no? Almost no noticable flicker

Thanks!

 

Greetings,

Manuel

[+johnnywc]

Hi there!

 

Here ya go!

 

Now that looks excellent, no? Almost no noticable flicker

Thanks!

Thanks for the tip - it does look much better.

 

How about this one? This shows the purple color on the frame that shows the door. The color difference is more noticeable, but still very little flicker. Do you think it's better?

ladybug_altpf2.bin

[Feralstorm]

The impossible screen mockup made me consider another speculative possibility. The non-moving parts of the maze are symmetrical, so maybe use the missiles to depict the doors. This would greatly lessen the amount of RAM-buffered asymmetrical playfield used (down to just the dots), would allow the doors to be different colors from the maze (but not from the sprites). Could be done not too badly with clever use of flicker and/or repetition. Might even be possible to make the doors transition from one state to another.

 

just a thought from someone who doesn't know enough.

[Cybergoth]

Hi there!

 

How about this one?  This shows the purple color on the frame that shows the door.  The color difference is more noticeable, but still very little flicker.  Do you think it's better?

 

Hm... it's less contrasting. I think I prefer it the other way round.

 

According to my Jumpman notes, $94 and $C4 should also be a very good combination, for turquoise background with green doors.

 

I think one has to experiment some to find the best combinations. One should also try them on a real TV, as the emulator output may differ a lot here

 

Greetings,

Manuel

[+johnnywc]

The impossible screen mockup made me consider another speculative possibility. The non-moving parts of the maze are symmetrical, so maybe use the missiles to depict the doors. This would greatly lessen the amount of RAM-buffered asymmetrical playfield used (down to just the dots), would allow the doors to be different colors from the maze (but not from the sprites). Could be done not too badly with clever use of flicker and/or repetition. Might even be possible to make the doors transition from one state to another.

 

Those are interesting ideas. I had considered the same thing a few years ago but unfortunately there isn't enough time in the kernel to use the missile (or missiles) more than once on a line, plus the maximum horizontal length is 8 (you would need at least 16 to make it useful). The last part is that even though they can be a different color than the background, the catch is that they have to be the same color as P0 (or P1) when on the same scan line, which would be very often during the game.

 

I'm moving forward with this game but I'm only going to have symmetrical doors as I see no way to do it with asymmetrical doors without either massive flicker or the Superchip (both which are unacceptable IMO).

 

Thanks for the ideas!

[+johnnywc]

Hi there!

 

How about this one?  This shows the purple color on the frame that shows the door.  The color difference is more noticeable, but still very little flicker.  Do you think it's better?

 

Hm... it's less contrasting. I think I prefer it the other way round.

 

According to my Jumpman notes, $94 and $C4 should also be a very good combination, for turquoise background with green doors.

Thanks for the tips. I tried $94 and $C4 - it looks good but I'm trying to get the maze pink or purple (like the arcade).

 

I think one has to experiment some to find the best combinations. One should also try them on a real TV, as the emulator output may differ a lot here

One combination that looks great on the TV (I tried it on my CC2) is $44 for the maze and $64 for the doors. I also toned down the white on the dots (to $04) since the contrast between them and the dark walls was too much! I'm right in the middle of working on the kernel so things look a bit ugly right now but as soon as things are stable I'll post a demo that allows you to change the foreground and the background with the select/reset switches.

 

Thanks for the tips!

[Cybergoth]

Hi there!

 

IMHO, Pesco demonstrates the right approach for dot-muncher games.

 

What about Alien?

 

Greetings,

Manuel

[ZylonBane]

I am Mahir! I kiss you!

 

What about Alien?

What about it? The Alien approach may have worked for an original title, but the whole staggered-missile setup wouldn't be ideal for a port of an existing title. It just looks too... weird.

 

Buy War Bonds,

ZylonBane