Analysis of certain Atari 5200 games

[+Cafeman]

I hooked up my 5200 and played a lot of games over this weekend. Lets talk 'how did they do that?', mmmkay?

 

1. Popeye. I assume this is in Antic 4 like 95% of the 5200 games. How in the world did they get all those notes/hearts to display? Popeye and Brutus each seem to be 2-color sprites so they must be using up 4 players. I've seen 5 hearts at one time. I've seen 3 side by side at the bottom at one time -- no flickering. Does the engine use BG graphics for the notes? If so, how does it scroll them past the bg without trashing it?

 

BTW, I think Popeye is an underrated game. This 5200 version has very good music and nice sounds, in addition to being a fun little platformer.

 

2. Miner 2049'er -- Bounty Bob is a 5 color sprite! I wonder if Bob uses 2 Players and 2 missiles for his character, or several players? Then the enemies would need to be bg graphics again. The enemies in Miner seem to be separated vertically -- they don't cross the same scanline, so they could be reused sprites. If this is true, in an antic 4 game with a mode line of 8 scanlines, does this mean that the coders had to implement a DLI on every scanline?

 

A further question along these lines -- if you want to reuse sprites, is it 100% necessary to have a DLI on every scanline? I mean, without flickering, how else would you change the HPOSPx register? If so, does all the code need to fit in Vertical blank then?

 

I'll ask that question again -- if I want to implement sprite reuse, and only have flickering when the 2 game characters are on the same horizontal scanline, is it true that I MUST have DLI's on every modeline?

 

Also, if I have DLI's on every scanline, does this eat into game processing time in some negative way? Or not?

 

I've asked lots of questions -- I hope you all have lots of answers, and thanks!

[Tempest]

Bob uses 3 players, and the overlap makes new colors. Bill Houges page explains all of this, it's an interestng read.

 

Tempest

[Jetboot Jack]

You're right Popeye is in char mode - the Sea Hag's thrown bottles move in character increments.

 

The hearts/notes/letter in Popeye are Missiles - each is 4 pixels wide - 2 missiles per object - watch and you'll never see more than 2 falling objects on a line, when they hit the water theu become antic 4 characters...

 

Miner's enemies are on seperate mode lines - no need for DLI's every scanline - just on those modelines that need seperate horizontal positions for the players.

 

Can you expand more on your multiple sprite per line query - I've written a horizontal multiplexer in the past...

 

sTeVE

 

[ 01-13-2002: Message edited by: Jet Boot Jack ]

[+Cafeman]

Jet Boot,

 

I don't know what a horizontal multiplexer is. Huh?

 

Okay, I will attempt to ask my question again in terms of 5200 Joust. This question has been nagging me since I started this 5200 hobby, I can't wait till I understand it all.

 

In Joust -- the buzzard sprites are evidently re-used Players. Joust is in Antic mode E. I.E., there could be up to 192 modelines! There are no doubt less modelines in the display list in the gameplay area though.

 

Say they use one player to show 2 birds. You just draw each on the player 'strip' and in a display list interrupt, you change HPOSPx. I assume you need a DLI on EVERY mode line then. Or else you could run into problems.

 

Outside the DLI's, in normal code, there must be a check to see if the vertical position of PlayerX-bird1 is getting close to the vertical position of PlayerX-bird2.

 

Again -- do you think that in 5200 Joust, that there is a DLI on every Antic E modeline in the playfield area? Or is there some easier solution?

 

--------------

 

Popeye again -- thanks for the explanation on the hearts. How do you know that the hearts and notes are each 2 missiles?

 

Also, again -- Antic 4 Character mode has an 8 scanline mode line. Do you think that the coders put a DLI on every game-screen Antic 4 mode line? And, since the is Antic 4 (and thus there are 8 scanlines per modeline, and the DLI only takes effect on the last scanline of the prior modeline) ... is there further logic to stay in the DLI for all 8 scanlines of the modeline?

 

--------------

 

Last question -- if this is indeed how the 5200 / Atari 8bit programmer uses the sprite re-use feature via DLI's ... does this in any way negatively effect the total amount of time you have to compute the game code & draw stuff, as opposed to a situation with NO DLI's?

[DanBoris]

If you look at the display list of Joust you will find one DLI at the start, then 2 towards the end. I assume from this that after that first DLI the game simply stays in the DLI for the entire height of the screen, making the sprite position moves as needed. Doing this will each up a lot of processing time, but this wouldn't be a problem with a game like Joust since it has fairly simple game logic and doesn't need the time to do other stuff.

 

If you didn't want to do it this way, you could dynamically alter the display list for each frame and insert DLI's only in the places where you needed them.

 

You can easily determine where different players and missiles are used by using my VSS emulator (www.atarihq.com/danb). The debug version has the ability to turn each player and missile off by pressing keys on the keyboard.

 

Dan

[Bill Lange]

Thanks for explaining how popeye worked. That was very interesting.

 

How many times can you multiplex a player? If your player is 8 bits across and eight byes high, seems as though you can have 192 scan lines / 8 in single resolution. That would be about 24 objects in each player "ribbon" but they can not be on the same horizontal scanline.

 

How does Shamus work? There seems to be 5,6,7 or more objects all bunched together. Doesn't seem to be character graphics.

[+Cafeman]

Dan, I am using VSS .80. Do I need to download a different 'version' of VSS for the debug feature? I will check it out.

 

Also, Popeye doesn't run in VSs .80 for me - the screen is black but I hear the music. Popeye doesn't run in Atari800win for me either -- it crashes.

 

Thanks guys for the talk! I need to keep talking about this, and try it out a few times, to understand it better.

[+Cafeman]

Huh! Check out this quote from the Big Five Software site --

 

"At the top of the screen is a mode "2" text line for the scores, and the remaining lines are mode "e" graphics lines. Mode "e" allows for three playfield colors plus the background color. "

 

Miner is also in Mode e; just like my game Koffi. I had assumed it was Antic 4 but NOPE.

[calamari]

I've also been thinking about this multiple sprites on one line situation..

 

I think Wizard of WOR does this by not drawing the sprite on some frames. I can think of a few ways to accomplish that, but I am not sure which way would be fastest. Any ideas on a good method for this? Also, I'd like to include 2 sprites and the 4 missiles (for a total of 6), that would hopefully minimize flicker.

 

Also, I'm guessing if I do multiple sprites/scanline, I lose collision detection. Is there any way around that? The program I'm messing with could potentially have 10 or more sprites on the same line.

 

I think character graphics could also work, but I am not sure how much of a speed impact they would have (erasing and redrawing each "block").

 

calamari

[Jetboot Jack]

Cafeman,

 

Nasty Tip - If you rip the a cart from an 800XL while on and running you will corrupt the background graphics, but the sprites will stay in place - hehehe - I learned that as a very young hacker...

 

Also a friend disassembled the ROM data from a disc dump of Popeye, many, many years ago and we looked at some graphic data -- we saw the sprites :-)

 

You don't have to put a DLI on every mode line - Miner 2049'er does 3 -- see their page.

 

Like Dan has pointed out -- I would dynamically poistion the DLI as vertical re-use and horizontal positioning is required.

 

Almost every Atari 8bit game uses vertical sprite re-use in some form or other. Vertical re-use is not multiplexing - since no two instannces of the same player occupy the same horizontal line.

 

In Joust they simply flicker the birds, placing sprites every other frame, when more than 4 occupy a horizontal line. I would imagine that Joust uses a very dynamic sprite kernal - as it only has a DLI at the start of the display and stuffs horizontal position data changes in to HPOS via a vertical counter.

 

Horizontal multiplexing to get more than 5 PMG per line is possible in many ways - I have written code that does that by drawing all sprites to be multiplexed every other frame - so all sprites except the main character shimmer. I've also written a routine (DLI's at fixed vertical positions) that only shimmers PMG that occupy the same horizontal line, checking transitions from one vertical screen zone to another.

 

One other technique exists and I have made it work - albeit in a non commercial game application - just a test bed. Using a horizontal timing kernal I have got 8 animated and moving sprites on a horizontal line with no flicker! The code was SUPER tight, precise instruction timing like a 2600 screen kernal.

 

sTeVE

 

P.S. I get Popeye to run in Atari800win under 2K and XP just fine BTW

[Jetboot Jack]

Bill - Shamus uses software sprites -- its either a bit mapped, or more likely a character based game since it has a black background, the enemy never overlap and always move in block wide horizontal and vertical steps (and with those VERY animated deadly walls too much data to shunt around a bitmap IMHO!).

 

Calamari - WOW uses software sprites too -- Mode 7 I reckon -- there is an antic E resolution line where the name of the level is -- looks like mode 1 text, and I wonder if the warriors are PMG...

 

sTeVE

 

[ 01-14-2002: Message edited by: Jet Boot Jack ]

[DanBoris]

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Cafeman:

<STRONG>Dan, I am using VSS .80. Do I need to download a different 'version' of VSS for the debug feature? I will check it out.

</STRONG><HR></BLOCKQUOTE>

 

Moderator Edit: The 'debug' version of VSS .80 is located here: http://atarihq.com/danb/

 

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>[QB]

Also, Popeye doesn't run in VSs .80 for me - the screen is black but I hear the music. Popeye doesn't run in Atari800win for me either -- it crashes.

 

QB]<HR></BLOCKQUOTE>

 

Maybe you have a bad ROM image for Popeye. I do recal at one time there were some bad images floating around.

 

Dan

[Bill Lange]

I download Popeye from XL Search and ran it on Atari800win Plus. Make sure if your in 800XL mode that you disable BASIC as it will crash.

 

I took a screenshot of the first level and blow it up 800% in Paint and sure enough the hearts are 4 bytes high and 4 bits across. I didn't see more than 4 floating hearts at once.

[DanBoris]

I took a look at the Shamus display list, it uses ANTIC mode 4. The enemies do move nice and smooth, but they never overlap. I have to say this is a very impressive use of a character mode.

 

Dan

[Bill Lange]

quote

I took a look at the Shamus display list, it uses ANTIC mode 4.  

 

I guess since Antic mode 4 uses 4-bit wide characters instead of the usually 8-bit wide by 8 byte high, they characters move more smoothly since they only move across the screen 4 bits at a time. HMMMMM

[Bill Lange]

Shamus - I could have sworn that a whole wall of bad guys would bear down on me. It seemed like they moved more smoothly then char gr and that they were on top of each other. I'll have to boot that up tonight to refresh my memory!

 

Popeye - I am running Atari800win Plus 2.8 on a 2 GH P4. I'll see if I can find the image for Popeye and see if it works. I also want to take a look at those musical notes that you guys were talking about.

 

Nice thing about emulators, I can assemble a 1000 line program using the Atari Assembler Editor Cartridge in about 10 seconds as my computer runs the emulator at 1400% speed. It used to take 15 to 20 minutes to do it on an actual Atari. That is almost as bad as punch cards ... well, maybe not!

[Jetboot Jack]

Bill,

 

In Shamus the enemies do move smoothly - looks like multiple redefined images to give pixel increment movements.

 

If you look at the colors the enemies and the backgrounds are all the same ones.

 

It may be Mode E, but I can't see how you can animate the walls in that mode, it looks like character set rotation for animation for all objects.

 

Pickups and Shamus are PMG...

 

sTeVE

[Bill Lange]

quote

In Shamus the enemies do move smoothly

 

I'll take another look at it.

 

I am working on an 8-bit converstion of the 2600 Haunted House game. I use PMG for the player, ghost, bat, and spiders. Only one spider per floor so no more than 4 PMG players. I use redefined characters for stairs, lock/unlocked doors, scepter, key, urn and urn pieces as well as the funky numbers that HH used. I have all the PMG and characters drawn. I can move/animate the eyes. Right now its in mode 2, but I want to get it working in Antic mode 4. I'd like to get it to the point where I can use a map like in GETAWAY! One map for each floor. Maybe base the house on the mansion from Infocom's DEADLINE or something.

 

Then hopefully someone can help me get the 8-bit source working on the 5200.

[Jetboot Jack]

Dan - you should see the Menace (take a look ath the AMIGA version) code we wrote! A scrolling Antic 4 screen, with a parallax backdrop - rotated character data - so two overlapping scrolling screens in effect.

 

PLUS 10 16*16 pixel character mode sprites moving in 1 pixel increments for the enemies!

 

We used the same basic backdrop code from an earlier game - CONTAGION - albeit in a very simple version to get the 2 layer parallax on that game. Or take a look the BIG tank at the end of the levels in PLASTRON - the team scrolled the tank on, but rotated the character data to look as if the background was still while the tank rolled on.

 

Bill - the Shamus sprites move at 1 pixel increments not 4! The data is rotated thru the characters - that's the way I've done it in the past - with either 10 characters each at different data offsets or copying the data into a block of 6 characters or so you can get 100% smooth motion!!

 

sTeVE

[Heaven/TQA]

very interesting conversations... and it shows me that i was not wrong when thinking about the same questions 14 years ago...

 

just few adds:

 

dropzone is also a nice charmode + smooth movement of sprites engine. i learned this way of using sprites (chars) from VIC-20 or every other machine which was not cabable of using sprites...

 

jet boot: i still can not wait to get your conversions... ninja 2+shadows of the beast...

is meneace released??? can i download it from somewhere?

 

i am interested in your multiplexer as well...

 

i made another nice "real overscan" routine which was an accident... if you display more scanlines with antic than your tv set can show... you get the nice "rolling" effect... and if you are counting cycles you can stable the whole picture by switching back to a normal dlist. and voila a "real" overscan scroller was born... above the 1st scanline antic can produce...but i realised that it just runs perfect on my special tv set...

 

or other secrets: HIP - Hard Interlacing Picture

http://www.s-direktnet.de/homepages/k_nadj/hip.html

 

ps. on the c64 mailing list there is a discussion that you can never multiplex more than 8 sprites on 1 scanline on c64...the VIC ignores repositioning of sprites...so the techniques are always the same and should be carried on like a secret and magic so it will not be lost in time...

[Bill Lange]

quote

i made another nice "real overscan" routine which was an accident

 

Can you do anything usefull with the "Real Overscan Scroller"?

 

quote

if you display more scanlines with antic than your tv set can show

 

I can't remember off the top of my head how many scanlines there are, but the number 192 comes to mind. So if you draw a 193 scanline in your DL, then the picture starts to scroll? I am assuming this isn't in the overscan area, but actually off the bottom of the TV's internal workings.

[DanBoris]

quote:

---

Originally posted by Jet Boot Jack:

Bill - the Shamus sprites move at 1 pixel increments not 4! The data is rotated thru the characters - that's the way I've done it in the past - with either 10 characters each at different data offsets or copying the data into a block of 6 characters or so you can get 100% smooth motion!!

 

sTeVE

---

 

It appears that in Shamus a sprite has to be fully within a character cell before it can change direction. With this restriction in place it will only take a max of 2 character cells to hold a 4x8 sprite. Without this restriction a 4x8 sprite could potentially appear in 4 characters cells at once.

 

Dan

[Jetboot Jack]

Dan,

 

I was refering to the Shamus sprites 2X2 antic 4 characters - the routine to move these would need just 6 chars to achieve all direction smooth moving - albeit on complete characeter cell (for 4 - horizontal - or 8 - vertical - pixel movement cycles) boundaries and no diagonals.

 

12 characters is what I used in routines for a 16 X 16 object with the same restrictions as Shamus. A 16 X 16 with diagonal movement too requires just 15 cells.

 

The upside is you can have LOADS of sprites all moving for the cost of rotating the data once! And as most games of that era have waves of enemies you really only need to use 30 or so characters to provide awesome looking attack waves..

 

When Harelequin did Menace (I WILL release the demos as soon as I can - HEAVEN - BTW your vertical overscan scroller - didja release any demos with it?) we overcame 2 more problems:

 

A parallax overlapping scrolling playfield (2 layer, with large irregular objects in the foreground) and character sprites moving atop this, and fully masked in the dual layer scroller, plus bullets and missiles in chars too - all Antic 4 again and it looked pretty good, especially with a BIG colorful pmg player ship - well we had to use the Hardware sprites for something!.

 

We also did some demo routines to allow the char mode sprites to overlap - that used LOADS more characters, but looked great!

 

sTeVE

[Heaven/TQA]

re: "real" overscan demo

 

the whole fx started when i watched tons of atari ST demos where scrolling, sprites, digital music was THE state of the art and i realized that my atari 8bit machine has all build in as hardware feature and the 16 bit brother has not...

 

so i converted many fx to atari 8bit just for fun...big scrollers (1 scroller with chars larger than a pal-screen in height...), smooth parallax scrolling and so on...so the "overscan" fx was born...and really per accident. I released the demo on some usergroup disc ten years ago. maybe somewhere on the net (www.abbuc.de)

 

to be honest on 8bit atari we all use NO tricks...all is done well...what the machine is offering you and it is understandable and logical.

 

but f.e. atari st has no softscrolling (which i thought is standard as a successor...) no displaylist and uses weird bitplanes adressing compared to amiga (which has displaylist...linear bitplanes and many features jeff miner had in mind after designing antic/gtia for atari... )

 

on ATARI ST there are strange things:

 

f.e. opening the screen borders (hahahaha...on small atari poke 559,35 voila no borders...) waiting till rasterbeam is on the right border...switch into 60hz mode do some operartions and back to 50hz (interesting... what about NTSC atari STs???)

and your screen was opened...

 

and so it took 1 year later that someone came on this idea to use this for "real" hardware scrolling...

 

you know the atari ST can just put the screen adress on 256 byte boundaries...

 

more interesting stuff:

http://www7.in.tum.de/~brandtf/ataridemos.html

 

back again... there i had my ideas & impressions...

 

finall conclusion... the "real" overscan just worked on my tv set and was completly useless except for a scroller in gr. 2

 

re: international karate (world championship karate)

 

i think that this game is a perfect fighting game on atari 8bit and archer mclean did again a great job together with rob hubbard music....and this version looks much better than the c64 one...1st i though that the fighers have PM grafics on top for the suites... but as far as i can remember it must be charmode. the whole fighters are chars and they are smoth! (i patched times ago the DLI and set it to the $e0 built in charset and voila...)

 

one thing which is hard esp. when converting c64 games is that ataris charset contains just 128 definable chars and not like c64 512 one... this makes a lot difficult...

 

ok...i have to go to work... our PS2 game is waiting...