Characters vs Players (PMG)

[atarilux]

I am in the process of writing a small game engine in CC65, so far basic things work quite well. However, I am curious to know people's views of two approaches in terms of performance etc when it comes to animating many characters e.g. more than the standard "sprite" limit.

 

- using many players from the standard PMG approach, and multiplexing them to get more interesting players

- using a set of custom characters which are animated (as seen in PETSCII Robots for example)

 

In both cases, I would like to do it to achieve not only more players but also more colours. I am building a simple platform game engine, so moving objects and characters are important.

[Synthpopalooza]

I think one good way is to store your animation data, then block copy it into the appropriate font location in memory.  This will then animate all copies of your character sprites simultaneously.  I got this idea from the Abbayes des Morts game coming out soon, the programmer used this technique to animate the 6 crusaders that chase Jean at the beginning of the game.

 

To get the smooth animation horizontally, set your display list for HSCROL to scoot your character one pixel at a time.

Edited August 26, 2022 by Synthpopalooza

[TracMan]

A quick summary that I've learned over the years and from the forum.

 

PMG are always very limited and work in some cases where there is not a lot of vertical positioning clash, eg. perfectly in Shanti's Gacek (version of Bombjack) and his The Last Squadron.  I would always just prototype the game using character graphic sprites, so at least you have it moving and can focus on the game and you get tiling and scrolling for the background much cheaper.  If you don't believe me, look at many ZX spectrum games like Golden Axe and Atari's own Donkey Kong Junior.  This will get you started and running much quicker.

 

So, the best way to think of Atari PMG so you don't get frustrated, is that you get a few objects per scan line that can do extra coloured bit planes which can be individual colours.  Instead of splitting them up, join them together with their missile or another player, eg. with a one player/ one missile pairing, you can get an extra 4 x 10 pixel bitplane for four sprites, offering up to 4 extra colours, or with a one player/ two missile pairing, you get an extra 2 x 12 pixel bitplanes in one colour and 1 x 16 pixel bitplane in another colour.  In some games, the character graphics mode 5th colour comes in very useful.  IMHO you shouldn't fear a small amount of colour clash when using that colour also.  Think of the flames of a flamethrower or fireball ie. something that doesn't matter if it illuminates a few extra pixels when passing across the background.  Additionally, never underestimate the power of allocating black and white colours to the screen.  They look great when mixed with a small amount of colour.  Games that have a black background and contain black in the sprites are also easier to do because you have a "free" colour.

 

So even with character graphics sprites, you can still multiplex the PMG vertically and put them on top of the sprites, but it is harder to multiplex in character graphics modes because you can't easily reuse them vertically except on a character line(bad lines).  Other methods rely on the screen being in bitmap mode, it is here where you have much finer control over the vertical positioning, hence can reuse freely PMG but you still only have the 4 foreground/background colours per character line.  But it's always useful to consider either bitmap or character graphics at the beginning, it's just that it will change the implementation a lot.  You can write your engine to use preshifted sprites and expect the game to not necessarily fit in 64k or you can try an implement the elusive just in time shifter which again, I wouldn't concern myself with to get something working.

 

Also, never underestimate the power of PMG underlays.  See the Atari version of IK and the IK+ demo.  This method is great when you have a foreground colour in your background like the ground and you simply cut out shapes and there is a doubled or quad size PMG block underneath that shines through over the true background colour.  This means that the same fighter graphics can be reused with a different coloured shirt, simply by using different colour underlays.

 

Finally, never rule out using a mono character graphics or bitmap mode instead of a colour one, where you position quad size player missile pixels down the screen to colour individual character graphic squares on top of hires graphics.  Your sprite colours 

are no longer restricted to 10 pixel bitplanes.  Sprites are often 16 pixels wide.  This is kind of similar to a ZX spectrum attribute map.  Look at Skool Daze, Saboteur, Way of the Exploding Fist or Light Force for the ZX spectrum.  These games often look fantastic when they use a dark pen on the coloured background, I often consider these games to be using a kind of "ambient lighting" as they work especially well with indoor scenes.

 

Edited August 26, 2022 by TracMan

[atarilux]

@TracMan and @Synthpopalooza, thanks for your help.

 

Given the comments above, I will probably use character based graphics and animations for all non-player characters. It would seem to be the best way to get potentially many character moving around. My prototype with some moving objects etc, currently uses Antic mode 4, which seems to be ok. So I can possibly get a reasonable number of colours per NPC. However, time to try fitting that into a character set.

 

 

[TracMan]

I used to worry about sprite coding a lot which always made me think I should at least document all the "base" routine designs and if an engine was coded, one could be cherry picked for the next individual game.  With experience, Atari programming is never simple, ie. there is no ideal routine for many games because people often try to emulate cool graphics that came after it's development (ie. on the C64 or ZX spectrum) and secondly, the only way to compete with those machines is programmatically.  Up front design is where programmmers have to spend our time a lot and there isn't much fun for artists until the issues are solved.

 

A programming error that I often used to make was trying to overuse the VBLANK routine for clearing sprites, moving them, drawing them and game logic.  An idea just came to me today that in a bitmap mode, you could lock the whole program in a loop, where, if you sort all software sprites vertically, as soon as you knew a scan line you had prepared for in advance had been presented on the screen (via the HW register VCOUNT), you could reverse the work you just did ie. put the saved background bytes for a line back on the line.  This works best when sprites are continually moving, but often we generally need to erase and draw all sprites on a line in case they cross each other.  

 

Any pointer to the start of the physical line or save buffer for that line is shared across all sprites, so you only have to load those once into a pair of zero pages pointers and you use the Y register as an offset for each Sprite horizontal position on the same line.  The hard bit would be having the right offset into the image data for each sprite, so you could possibly use a pair of zero page pointers for each and a different offset for each sprite.

 

You could also in theory suggest the HW changes for each extra color bitplane on the lines ahead eg. work out the PMG positions well ahead of the lines that you were working on as little routines which you call as part of the screen kernel manipulation.  If there is a line where the suggested HW changes clash, then you can do just the mandatory ones (for the player's sprite) and skip out both the bitmap screen lines AND the HW change.  This is an alternative to flickering whole sprites and just involves flickering sprite lines. 

 

When the scan line reaches the bottom of the screen, you can start on all the game logic, before the VBI would have kicked in.

 

Would any of this save much time?  Well, you will still require some mechanism for preshifted sprites and especially for the player's sprite, since you can't detect a player movement until the game logic occurs after you have read the joystick.  Maybe you could do this 25 fps at the top of the screen as normal, whereas the other sprites movement can be worked out ahead by using tables (assuming the player sprite is always drawn last).

 

It could be a crazy idea though with not having enough speed to do everything you want and as with every idea, only the final implementation decides how much better it really is.

Edited October 2, 2022 by TracMan
Removed the part about screen save buffer.