Techniques and Antic modes of the sports games

[+Cafeman]

I was checking out various sports implementations on A8/5200. I was wondering what would be the best way to implement multiple teammate men on the hardware. Your goals would be to have more than 1 color per man, and to have minimal or no flickering.

For example, I played around with RS Soccer - it is Antic C with horizontal scroll set. That's only 2 colors - green field and white lines. (!) Each man appears to be his own PLAYER, and the programmer has a kernel (not DLI's) which dynamically changes the colors of each man - head color,shirt,pants. At least I think that's how its done. There is barely if ever any flickering - it looks like the game controls it so that only 4 men are on the same vertical part of the screen (high, center, or low-field).

If you decide to use a kernel for A8/5200 engine, then is it true that you can't use DLI's ? Because they 2 methods would be fighting each other during screen-draw time?

I can't figure out RS Football, but it is in Antic E. It doesn't look like he is using hardware scrolling. I think he is blitting each man onto the screen, not using the PLAYERS for the team men at all. There is no flicker and every teammate can be on the same horizontal scanline area - no flickering at all. Does anybody know more on this game's use of the hardware?

EDIT - added some pics from AtariMania to illustrate.

[phaeron]

RS Football is indeed using software sprites for the team members.

 

You can mix DLIs and a kernel, but you can't do them in the same portions of the screen. In my Raiders of the Lost Ark port, the main screen is drawn with a kernel while the status bar is driven by DLIs. The CPU can only do one or the other, and practically it takes about two scanlines to service a DLI. Also, you can't launch a DLI right after a kernel because the DLI needs most of the previous scanline to have time to interrupt the CPU and sync up to WSYNC, which would interfere with a kernel trying to draw that scanline.

 

If you need changes on every scanline, you need a kernel, because DLIs can't fire fast enough. However, it's very costly in CPU time, because not only do you lose all of the CPU time during the kernel, it also usually takes some additional time outside of the kernel to prepare data for it. Realsports Soccer, for instance, has to maintain tables of color values per scanline. On the other hand, an interrupt solution can run at coarser granularity like every 4 or 8 scanlines, and allow for some CPU time during the active region to be recovered.

[Rybags]

Jungle Hunt also uses a kernal, from memory shared among all levels with specific branches depending on what level is in play.

Inefficient CPU-wise but conserves Rom space. For some parts they probably could have gotten away with a roving DLI but it is what it is.

I boosted the efficiency of the game by using seperate DLIs per level, and also eliminated some CPU cycle wastage by using multiple DLIs and shortening the kernal size on the vines level to allow better speed in NTSC.

 

Also, the old Atari Basketball cartridge. Possibly the first ever game on the system to use the technique, it was a pretty early release.

[popmilo]

Couldn't resist so I made you a simple example converted from my sprite routine demo:

 

char_sprites.xex

 

8x8 pixels large sprites in vertically double expanded character mode with 5th color used for player shirts. Fully masked software sprites in 25fps (24 of them).

My guess you could make a nice sport game with it

 

There are color clashes when players get close to each other but could be solved with currently controlled player replaced by hardware (PM) sprite and AI that wouldn't let rest of players from opposite teams too close. Sprites with same color can overlap no problem.

 

Only other problem I see is lack of colors for background... You only have black, green and that light red for whole screen... Some other color palette could maybe fix that problem.

 

 

[+Stephen]

Couldn't resist so I made you a simple example converted from my sprite routine demo:

soccer sprite test.png

 

char_sprites.xex

 

8x8 pixels large sprites in vertically double expanded character mode with 5th color used for player shirts. Fully masked software sprites in 25fps (24 of them).

My guess you could make a nice sport game with it

 

There are color clashes when players get close to each other but could be solved with currently controlled player replaced by hardware (PM) sprite and AI that wouldn't let rest of players from opposite teams too close. Sprites with same color can overlap no problem.

 

Only other problem I see is lack of colors for background... You only have black, green and that light red for whole screen... Some other color palette could maybe fix that problem.

 

 

That's excellent!

[emkay]

Only other problem I see is lack of colors for background... You only have black, green and that light red for whole screen... Some other color palette could maybe fix that problem.

PMg is your friend, as you could rebuild the lines of the field with them ... without a lot CPU

Edited February 15, 2017 by emkay

[+Cafeman]

Couldn't resist so I made you a simple example converted from my sprite routine demo:

 

 

 

It kept not working for me, but I finally got to see it in Altirra - I think I had to set it at RAMBO mode, every other mode had gobblyy-gook messed up charset screen. Anyway, that is fantastic looking!

 

Thanks for the replies. I don't have much to say in replay right now .

 

So Football is all softsprites, well those are some pretty ugly softsprites. 1-color and very low-res and blocky. Are the PM's used for the lines and dashes on the field?

 

And for Soccer, why do you think the programmer chose Antic C instead of Antic D ? I guess he got higher resolution but reduced colors, but I wonder if a better field could have been rendered with 4 colors instead of just 2. Antic E would be the best solution, but maybe that takes too much CPU resources when you have a kernel ?

[phaeron]

And for Soccer, why do you think the programmer chose Antic C instead of Antic D ? I guess he got higher resolution but reduced colors, but I wonder if a better field could have been rendered with 4 colors instead of just 2. Antic E would be the best solution, but maybe that takes too much CPU resources when you have a kernel ?

 

CPU time is indeed an issue:

  1683: 96: 90 | A=88 X=35 Y=36 (   I  ) | 7069: 8D 14 C0          STA COLPM2
  1683: 96:108 | A=88 X=35 Y=36 (   I  ) | 706C: 8C 15 C0          STY COLPM3
  1683: 96:112 | A=88 X=35 Y=36 (   I  ) | 706F: A5 C5             LDA $C5
  1683: 97:  9 | A=00 X=35 Y=36 (   IZ ) | 7071: 8D 12 C0          STA COLPM0
  1683: 97: 13 | A=00 X=35 Y=36 (   IZ ) | 7074: A5 C6             LDA $C6
  1683: 97: 17 | A=88 X=35 Y=36 (N  I  ) | 7076: 8D 13 C0          STA COLPM1
  1683: 97: 22 | A=88 X=35 Y=36 (N  I  ) | 7079: E8                INX
  1683: 97: 26 | A=88 X=36 Y=36 (   I  ) | 707A: BD 04 03          LDA $0304,X  ;$033A
  1683: 97: 34 | A=75 X=36 Y=36 (   I  ) | 707D: 8D 02 C0          STA HPOSP2
  1683: 97: 42 | A=75 X=36 Y=36 (   I  ) | 7080: E4 34             CPX $34
  1683: 97: 48 | A=75 X=36 Y=36 (   I  ) | 7082: D0 05             BNE $7089
  1683: 97: 54 | A=75 X=36 Y=36 (   I  ) | 7089: BD C4 03          LDA $03C4,X  ;$03FA
  1683: 97: 61 | A=00 X=36 Y=36 (   IZ ) | 708C: 85 C5             STA $C5
  1683: 97: 65 | A=00 X=36 Y=36 (   IZ ) | 708E: BD 84 04          LDA $0484,X  ;$04BA
  1683: 97: 70 | A=DA X=36 Y=36 (N  I  ) | 7091: 85 C6             STA $C6
  1683: 97: 74 | A=DA X=36 Y=36 (N  I  ) | 7093: BD 44 05          LDA $0544,X  ;$057A
  1683: 97: 80 | A=88 X=36 Y=36 (N  I  ) | 7096: BC 04 06          LDY $0604,X  ;$063A
  1683: 97: 85 | A=88 X=36 Y=36 (   I  ) | 7099: 8D 0A D4          STA WSYNC
  1683: 97: 90 | A=88 X=36 Y=36 (   I  ) | 709C: 8D 14 C0          STA COLPM2
  1683: 97:108 | A=88 X=36 Y=36 (   I  ) | 709F: 8C 15 C0          STY COLPM3

Altirra displays the cycle number of the first cycle of each instruction, so after the write to WSYNC the following STA executes its first cycle at 90 before the CPU is suspended until 105. That's only 14 cycles free. ANTIC C and D have the same bandwidth requirements on average, but D alternates between twice as much bandwidth on one line and no playfield DMA at all on the other.

[snicklin]

Couldn't resist so I made you a simple example converted from my sprite routine demo:

soccer sprite test.png

 

char_sprites.xex

 

8x8 pixels large sprites in vertically double expanded character mode with 5th color used for player shirts. Fully masked software sprites in 25fps (24 of them).

My guess you could make a nice sport game with it

 

There are color clashes when players get close to each other but could be solved with currently controlled player replaced by hardware (PM) sprite and AI that wouldn't let rest of players from opposite teams too close. Sprites with same color can overlap no problem.

 

Only other problem I see is lack of colors for background... You only have black, green and that light red for whole screen... Some other color palette could maybe fix that problem.

 

 

 

That's a very nice little demo that you have there. It makes me think of Sensible Soccer a little. Imagine that on the A8?!

 

I think that 'Thorn EMI Soccer' shows us how to handle the colours quite well....

 

Green field

White lines

 

Make the shirts either from black or white, shorts the opposite colour, other team has it the other way around.

 

Pink legs

 

And then additionally a fifth colour of brown so that we don't just have one race in a game.

 

Then if you make it a vertically scrolling game, you can use a full height PM or two or three for adverts.

[popmilo]

Green field

White lines

Make the shirts either from black or white, shorts the opposite colour, other team has it the other way around.

Damn... Didn't think of that ! I knew there was a solution

 

White and black for shirts, add green and white for terrain, pink for legs and face and you still have 5th color to use for something.

 

Will try making demo with those colors these days and upload it here...

[emkay]

Make the shirts either from black or white, shorts the opposite colour, other team has it the other way around.

No. Because you get the colors mixed up , when the protagonists walk over the white lines, using the low resolution!!!!

Really, AND WRITTEN IN BIG LETTERS : KEEP THE PMg FOR THE WHITE LINES.

As almost every game would benefit by using DETAILS WITH BACKGROUND GRAPHICS and SCREEN WIDE ANIMATIONS DO BETTER WITH MULTIPLEXED PMg ....

Edited February 18, 2017 by emkay

[emkay]

..... GAAAAAHHHHH .....

[+Cafeman]

 

Then if you make it a vertically scrolling game, you can use a full height PM or two or three for adverts.

 

Which brings up another question I have. Why do most sports games on A8/5200 use a horizontal field? I'd think that using vertically scrolling field with DLI-style PM breaks might reduce flicker and allow you to use true hardware sprites) - I'm thinking of Megadrive EA NHL Hockey perspective, or EA Madden football perspective, for example, as opposed to all the A8/5200 sports games I've seen which has a horizontally laid-out field.

 

On 5200 - RS Soccer is horizontal. RS Football is horizontal.

On A8 - Thorn EMI Major League Hockey is horizontal. Thorn EMI "Soccer" is horizontal.

 

What advantages came from the horizontal playfield?

[emkay]

What advantages came from the horizontal playfield?

Soccer is usually displayed horizontally.

[BillLoguidice]

Soccer is usually displayed horizontally.

 

That's the obvious answer, but, considering some of the most popular soccer titles of all time (and countless other sports videogames for that matter) used a vertical playfield, that argument may be a tenuous one. Perhaps there really was a good technical reason to go horizontal in the case of the Atari 8-bit series?

[emkay]

There would not be such "Advantage" in vertically scrolling soccer games on the A8.

The problem is still, how they have been made.

The PMg can cheaply moved to the left and the right. Some DLIs would allow to have some ISO 3D looking. Normal playfield width would save a lot of CPU cycles. Double Scanline mode saves a lot of memory (thus memory handling ) .

[popmilo]

 

Which brings up another question I have. Why do most sports games on A8/5200 use a horizontal field? I'd think that using vertically scrolling field with DLI-style PM breaks might reduce flicker and allow you to use true hardware sprites)

Yes. My thoughts are just like that...

Look at Microprose soccer on C64, "Kick off" and Sensible Soccer on Amiga...

 

Game like Football makes much more sense in vertically scrolling scenario with 4 sprite limit in horizontal line.

That limit of number of sprites in line seriously limits standard horizontal football field game ...

[+Philsan]

Please, do make a good soccer game for A8, please...

 

I love Popmilo's sprites...

 

Another option would be to port ZX Spectrum Match Day 2, one of the best football games for 8-bit computers.

Graphics seems crude but ball physics are very advanced.

[emkay]

Yes. My thoughts are just like that...

Look at Microprose soccer on C64, "Kick off" and Sensible Soccer on Amiga...

 

Game like Football makes much more sense in vertically scrolling scenario with 4 sprite limit in horizontal line.

That limit of number of sprites in line seriously limits standard horizontal football field game ...

No.

 

 

 

Because, when the game is aligned vertically, the chance of having many Protagonists horizontally, is higher.

Edited February 20, 2017 by emkay

[emkay]

Again: The Atari is no C64 neither it has a reusable Sprite hardware.

Using Popmilo's Sprite engine, that is able to show 24 moving objects at 25 fps. Assuming a max. of 12 moving objects (plus a missile for the ball) , and PMg for the white lines... via DLI, will allow to have a lot of free CPU for good gaming physics.

[+Cafeman]

I got it to work in Altirra with standard memory, no Rambo needed.

 

So you are using Antic 5, a character mode, and you are dynamically redefining the character sets and plotting them to memory? That is what gives the '3D' effect I suppose where one play appears behind another.

 

Is it true there are no DLI's here or PM's ?

 

I added some more men, playing around with memory!

 

[popmilo]

So you are using Antic 5, a character mode, and you are dynamically redefining the character sets and plotting them to memory? That is what gives the '3D' effect I suppose where one play appears behind another.

Is it true there are no DLI's here or PM's ?

 

I added some more men, playing around with memory!

Nice hack

 

Yeah it's Antic 5. It's using so called "interleaved character sets". There are 6x4 character rows. Each row uses one of 4 charsets. So each sprite that is 8 pixels wide needs only 3 chars in one row. So something like a Footy game that needs 22-23 sprites (referee is one I guess) needs only 69 chars out of 128. Plenty left for Goals, lines etc...

 

And yes, no DLI's so far. No PMs at all... Wait a day or two and I'll upload version with one teams in black or white shirts so There's no more color clash. I'll add some background footy graphics also. Think it will look good

[popmilo]

No.

...

Because, when the game is aligned vertically, the chance of having many Protagonists horizontally, is higher.

Let's take a look on standard football formations that you can see on this image:

On first thought only one formation 4-5-1 has five players in a row... Even that is easily worked around with implementing limits in AI routine that controls players.

 

But ! And this is a big but There are two teams on field at one time !!! So there is possibly worst case when one side chooses 5 players defence and opponent is using same formation with 4 players in attack. That's at least 9+1 (referee) sprites in a row...

 

On the other hand looking at something like this makes me think that the other option (horizontal alligment) is maybe little better.... Goal keepers, players passing middle....

All of that can be easily avoided by simply not letting players be too close to each other.

 

There's too much action to make some kind of rigid rule that would work in all cases... Better to just focus on couple players that are closest to the ball and just make every other player move away a little... As sprites are only 8x8 pixels it want even be so much visible...

 

We need more code and need to test both options. Horizontal and vertical scrolling...

[+Philsan]

For 8 bit platforms I think horizontal scrolling is better for gameplay: International Soccer, Emlyn Hughes Soccer, Match Day.

 

Kick Off (I played tournaments) and Sensible Soccer were great but necessary speed and graphics are out of reach.

 

Microprose Soccer was not so good on C64.

But it could be interesting to check out the arcade game Exciting Soccer.

Very addictive and not many players are near each other.

https://youtu.be/H4GGdN7h-z0

[sack-c0s]

Again: The Atari is no C64 neither it has a reusable Sprite hardware.

Using Popmilo's Sprite engine, that is able to show 24 moving objects at 25 fps. Assuming a max. of 12 moving objects (plus a missile for the ball) , and PMg for the white lines... via DLI, will allow to have a lot of free CPU for good gaming physics.

 

You can multiplex sprites on the C64 too, although I wish they'd gone with more (12 for the same memory bandwidth requirement) 16x16 sprites instead of 8 24x21 per line...