Aardvark for Atari VCS/2600

[Thomas Jentzsch]

Most likely in his blog.

[iesposta]

Good idea! made me to think in reusing the 48-pixel score routine for displaying the aardvark Added to TODO list.

 

It doesn't have to be that complicated.

There's a Tool to design HMOVE double wide shifted sprites! (Thomas was correct.)

http://atariage.com/forums/blog/148/entry-9089-2x-vector-sprite-tool/

[+SpiceWare]

The above links to the single player version of the tool.

This version is the one I used for the dragon in Medieval Mayhem, it uses both players for a two-color image.

Do note that's still using my old graphics.h file where the binary notation is done using _ for 0 and X for 1. To convert to standard binary do a find/replace of:

• zz/%
• _/0
• X/1

Let me know if you plan to use the two-color converter and I'll update it to use standard binary notation.

[+SpiceWare]

I have a few other converters here in the Utility listing.

 

I do have more, such as a 128 pixel converter on my local machine that I'm using for the bus stuffing demos. So if you don't see a converter you need just ask, it's probable that I have it on my local drive and just need to upload it to my site.

 

 

The images need to be somewhere online. You can post an image on AtariAge and use it, such as this one:

 

which has a URL of http://atariage.com/forums/uploads/monthly_12_2016/post-3056-0-27372600-1481647049.gif

 

 

[+nanochess]

Wow! Thanks I'm sure these will be useful

[iesposta]

Wow! Thanks I'm sure these will be useful

 

If you want to try, here's my results from using SpiceWare's Graphic Tools.

It seems to have turned out longer than I was planning? Maybe not.

It is colored so the tool makes Player0 and Player1.

You don't have to use different colors.

It is still 2 double-wide size sprites, just HMOVED around to appear more high resolution.

You already are using P0 & P1 for the aardvark.

 

I don't have a clue about ShiftLtoR and ShiftRtoL code !

 

 

Used (very small):

 

Output:

Adjusting data for Sprite 0
B4 y =0
Image = XXXXX___
xpos = 8
shift = -1
y =0
Image = _XXXXX__
xpos = 6
shift = 1

Adjusting data for Sprite 1
B4 y =2
Image = XXX_____
xpos = 8
shift = -1
y =2
Image = _XXX____
xpos = 6
shift = 1

Note: these graphics use graphics.h
ImageA1


ImageA1
 .byte zz_XXXXX__ ; 0
 .byte zzXXXXXX__ ; 1
 .byte zzX___XXX_ ; 2
 .byte zzX____XXX ; 3
 .byte zzXXX____X ; 4
 .byte zzXX___XXX ; 5
 .byte zzXXX__X__ ; 6
 .byte zzXXXX_X__ ; 7
 .byte zzXXXXXXX_ ; 8
 .byte zzXXXXXXX_ ; 9
 .byte zzXXXXX_X_ ; 10
 .byte zzXXXXXX_X ; 11
 .byte zzXXXXXXXX ; 12
 .byte zzXXXXXXXX ; 13
 .byte zzXX__XXXX ; 14
 .byte zzX___XXXX ; 15
 .byte zzX____XXX ; 16
 .byte zzX____XXX ; 17
 .byte zzXX____XX ; 18
 .byte zzXX____XX ; 19 ImageB1
 .byte zz________ ; 0
 .byte zz________ ; 1
 .byte zz_XXX____ ; 2
 .byte zzXXXX____ ; 3
 .byte zzXXXXXX__ ; 4
 .byte zzXXXXXXX_ ; 5
 .byte zzXXXXX_X_ ; 6
 .byte zzXXXXX___ ; 7
 .byte zzXXXXXXX_ ; 8
 .byte zzXXXXXXX_ ; 9
 .byte zzX_XXXXXX ; 10
 .byte zzX___XXXX ; 11
 .byte zzX___XXXX ; 12
 .byte zzX__XXXX_ ; 13
 .byte zzX_XXXX__ ; 14
 .byte zzXXXX__X_ ; 15
 .byte zzXX____X_ ; 16
 .byte zzXX____X_ ; 17
 .byte zzXX____X_ ; 18
 .byte zzXX____X_ ; 19 Shift1LtoR
 .byte HMOVE_R6 | HMOVE_0 >> 4 ; 0 x0= 6 x1= 0
 .byte HMOVE_R1 | HMOVE_0 >> 4 ; 1 x0= 7 x1= 0
 .byte HMOVE_L1 | HMOVE_R6 >> 4 ; 2 x0= 6 x1= 6
 .byte HMOVE_R5 | HMOVE_R1 >> 4 ; 3 x0= 9 x1= 7
 .byte HMOVE_R7 | HMOVE_L3 >> 4 ; 4 x0=16 x1= 4
 .byte HMOVE_R2 | HMOVE_0 >> 4 ; 5 x0=18 x1= 4
 .byte HMOVE_L1 | HMOVE_L1 >> 4 ; 6 x0=17 x1= 3
 .byte HMOVE_L1 | HMOVE_L1 >> 4 ; 7 x0=16 x1= 2
 .byte HMOVE_0 | HMOVE_L1 >> 4 ; 8 x0=16 x1= 1
 .byte HMOVE_R1 | HMOVE_0 >> 4 ; 9 x0=17 x1= 1
 .byte HMOVE_R1 | HMOVE_0 >> 4 ; 10 x0=18 x1= 1
 .byte HMOVE_L2 | HMOVE_L1 >> 4 ; 11 x0=16 x1= 0
 .byte HMOVE_R1 | HMOVE_0 >> 4 ; 12 x0=17 x1= 0
 .byte HMOVE_R1 | HMOVE_R1 >> 4 ; 13 x0=18 x1= 1
 .byte HMOVE_R1 | HMOVE_R1 >> 4 ; 14 x0=19 x1= 2
 .byte HMOVE_R1 | HMOVE_R4 >> 4 ; 15 x0=20 x1= 6
 .byte HMOVE_0 | HMOVE_0 >> 4 ; 16 x0=20 x1= 6
 .byte HMOVE_R1 | HMOVE_R1 >> 4 ; 17 x0=21 x1= 7
 .byte HMOVE_R1 | HMOVE_R1 >> 4 ; 18 x0=22 x1= 8
 .byte HMOVE_R1 | HMOVE_R1 >> 4 ; 19 x0=23 x1= 9 Shift1RtoL
 .byte HMOVE_L6 | HMOVE_0 >> 4 ; 0
 .byte HMOVE_L1 | HMOVE_0 >> 4 ; 1
 .byte HMOVE_R1 | HMOVE_L6 >> 4 ; 2
 .byte HMOVE_L5 | HMOVE_L1 >> 4 ; 3
 .byte HMOVE_L7 | HMOVE_R3 >> 4 ; 4
 .byte HMOVE_L2 | HMOVE_0 >> 4 ; 5
 .byte HMOVE_R1 | HMOVE_R1 >> 4 ; 6
 .byte HMOVE_R1 | HMOVE_R1 >> 4 ; 7
 .byte HMOVE_0 | HMOVE_R1 >> 4 ; 8
 .byte HMOVE_L1 | HMOVE_0 >> 4 ; 9
 .byte HMOVE_L1 | HMOVE_0 >> 4 ; 10
 .byte HMOVE_R2 | HMOVE_R1 >> 4 ; 11
 .byte HMOVE_L1 | HMOVE_0 >> 4 ; 12
 .byte HMOVE_L1 | HMOVE_L1 >> 4 ; 13
 .byte HMOVE_L1 | HMOVE_L1 >> 4 ; 14
 .byte HMOVE_L1 | HMOVE_L4 >> 4 ; 15
 .byte HMOVE_0 | HMOVE_0 >> 4 ; 16
 .byte HMOVE_L1 | HMOVE_L1 >> 4 ; 17
 .byte HMOVE_L1 | HMOVE_L1 >> 4 ; 18
 .byte HMOVE_L1 | HMOVE_L1 >> 4 ; 19 ;
End

Edited. What I posted before did not make sense

Edited December 14, 2016 by iesposta

[Andromeda Stardust]

I have a few other converters here in the Utility listing.

 

I do have more, such as a 128 pixel converter on my local machine that I'm using for the bus stuffing demos. So if you don't see a converter you need just ask, it's probable that I have it on my local drive and just need to upload it to my site.

 

 

The images need to be somewhere online. You can post an image on AtariAge and use it, such as this one:

demo_version.gif

 

which has a URL of http://atariage.com/forums/uploads/monthly_12_2016/post-3056-0-27372600-1481647049.gif

 

Screen Shot 2016-12-13 at 10.39.37 AM.png

 

Screen Shot 2016-12-13 at 10.39.41 AM.png

Neato. Do the "bus stuffing demo" work on Harmony?

[+SpiceWare]

If you want to try, here's my results from using SpiceWare's Graphic Tools.

Nicely done!

 

I don't have a clue about ShiftLtoR and ShiftRtoL code !

When the dragon enters the screen she starts out moving Left-to-Right, then turns around and moves Right-to-Left. REFPx is used, so the graphic data is the same for both directions, but the HMOVE values to shift the players are different.

[+SpiceWare]

Neato. Do the "bus stuffing demo" work on Harmony?

Yes, that link has 5 demos so far and they all work on the Harmony. While we are working on support in Stella, the features of the Bus Stuffing Driver are undergoing major changes which require Stella to be updated as well. As such we won't release Stella support until we've finalize the Bus Stuffing Driver, which will hopefully be in the first half of 2017.

[Andromeda Stardust]

Yes, that link has 5 demos so far and they all work on the Harmony. While we are working on support in Stella, the features of the Bus Stuffing Driver are undergoing major changes which require Stella to be updated as well. As such we won't release Stella support until we've finalize the Bus Stuffing Driver, which will hopefully be in the first half of 2017.

Sounds awesome. My Harmony is the older model purchased in 2012, v1.05 firmware. Do I need to upgrade to v1.06, or is that only for the compatibility fix affecting Encore models?

 

I'd love to be able to test out some of these.

[davidbrit2]

I am 110% in favor of devaluing ROM hoarders' sacred prototypes. Awesome stuff; I'll have to try this on the Harmony.

[+SpiceWare]

v1.05 firmware

 

 

that's what mine's running.

[Thomas Jentzsch]

Any updates?

[+nanochess]

Any updates?

 

As soon as I have more time next time the aardvark should exit the screen when all points are eaten.

[+nanochess]

Aardvark now exits the level, and also has music and sound effects

 

Check post #1

 

Edit: just realized I forgot the tongue sound effects, well, for next version!

 

Edit 2: now I need to re-write the TODO list, less things missing!

[The Maxx]

This is excellent. I always thought this was a cool arcade game! It has been awhile since I played the arcade, but you seem to be replicating the experience very well.

 

Three things (admittedly, I did not read the rest of the thread, so maybe some of this has been mentioned)

 

1. Sometimes a worm will walk on top of (and in the same direction as) an ant. This is deadly since you have to eat the ant or you will die, but if you eat the worm you will die.

 

2. In my opinion, the controls are a little too precise... It seems like if you are pushing down and left... and your tongue is over a hole, it should go down. However, you'll miss it. So I seem to spend more time just finding the hole than should be necessary. I wouldn't be able to read your code, but I'm imagining from some of my own games that it might be remedied by changing the sequence of events - meaning, check if the joy0down/up and reposition the y coordinate before checking joy0right/left. Just a guess.

 

3. I think I found a bug. I had reached down into the bottom of the anthill when an ant spawned on top of my aardvark's tongue. The death music kind of went into an infinite loop. I know how vague this description is, so I took a small video to show the location of the ant (my aardvark's tongue had nearly, if not fully, reached the end of the tunnel) and for you to witness the music loop yourself.

 

Nice work! This one is becoming so great! (My apologies if any of this has been mentioned before)

 

https://youtu.be/8lnW5LKEhYo

[Arenafoot]

 

2. In my opinion, the controls are a little too precise... It seems like if you are pushing down and left... and your tongue is over a hole, it should go down. However, you'll miss it. So I seem to spend more time just finding the hole than should be necessary.

I agree. The game is fun, but lining up the tongue right over the hole doesn't seem to work later on in the game - especially after the first bottom ant has been eaten.

[+nanochess]

Thanks for the bug report, I'll address it in the next release. The interface handling also surely will be addressed but not so soon.

[Thomas Jentzsch]

That and/or joystick direction priority should help. E.g. if you press left and down, down is always checked first.

[Thomas Jentzsch]

How about a death (or stunned) animation for the Aardvark? E.g. it could collapse or tilt to one side.

[+nanochess]

How about a death (or stunned) animation for the Aardvark? E.g. it could collapse or tilt to one side.

It's in my TODO list

[JohnH]

Responding to something from earlier:

 

 

I only found that the days become shorter, so the spider appears sooner and sooner. Eventually the spider will appear so soon, that the player has no chance to clear the screen before. That's pretty lame and IMO should be changed.

 

Spider management is an important part of late game strategy. The spider doesn't kill you until it reaches the tip of your tongue (traveling from the base), and is cleared from the screen when you eat a Queen Ant like all the other bugs (it immediately respawns from its starting point). The appearance of the spider is by no means the end of your game.

Edited January 24, 2017 by JohnH

[Thomas Jentzsch]

Responding to something from earlier:

 

...

 

Spider management is an important part of late game strategy. The spider doesn't kill you until it reaches the tip of your tongue (traveling from the base), and is cleared from the screen when you eat a Queen Ant like all the other bugs (it immediately respawns from its starting point). The appearance of the spider is by no means the end of your game.

That was me. I know about the Queen Ants and how to use them as part of the strategy.

 

But have a look at this video. Here you can see:

• around hill #15, the spider arrives very soon and the player hardly makes any significant score progress anymore
• around hill #20, the sun starts at the very left, so there is zero chance to clear the screen

This may have been acceptable for an Arcade, where long plays were not wanted. But for a homebrew, the game shouldn't become unfair.

[JohnH]

Hill 15 is a very advanced level in the arcade, let alone 20.

 

I make no judgement on the difficulty of a homebrew game over an arcade game. I think the game should probably have the same difficulty advancement in both versions. Anyway, it's hard enough to write homebrew without imposing additional game design standards besides.

[+Tarzilla]

That's why the 2600 has a Difficuty switch...so games could be enjoyed by different ages and skill levels.

 

Hill 15 is a very advanced level in the arcade, let alone 20.

 

I make no judgement on the difficulty of a homebrew game over an arcade game. I think the game should probably have the same difficulty advancement in both versions. Anyway, it's hard enough to write homebrew without imposing additional game design standards besides.