Multiplexing sprites in A8

[Allas]

Today I read this comment about Galaxian 2600:

 

Technically minded observers may notice that that this game displays 8 multicolored enemies on the same horizontal line, 35 enemies total, the player and the player's 'missile' all on-screen at the same time without any flickering. That is, on a real 2600, most emulators don't display this game properly. At this time in Atari 2600 development, it was the consensus that any more than 4 moving multicolored sprites was not possible without flicker or 'venetian blinds' type effects. Mark Ackerman figured out away to 'freak out the graphics chip by strobing the registers in exactly the right order at the right times.' So unique was his technique that he was granted a US patent.

 

In recent times programmers have been able to coax out of the 2600 hardware, 11 sprites per line and 48 total moving objects.

 

If this is the technical limitation for a 2600, what is the technical limitation for a 800XL ?

Anyone knows something about this algoritm. I reviewed old post from Atariage about multiplexing sprites, but this really promise a intense multiplexing. Maybe the technique could be udes in a 800Xl.

[Rybags]

You can change the HPOS registers on the fly to get a second copy of a given P/M.

 

There are problems/limitations.

 

DMA is one, especially if you have a hires mode going as well - plus you have the refresh cycles stolen which is a pain because the bulk of them occur during the first 2/3rds of the display area.

 

Then, there's the fact that you'll get the same image/colour unless you change the GRAF or colour register/s.

 

Hardware collision detection will be not as useful - you would have to do extra calculations to work out which "sprite" was affected.

 

So, taking things into consideration, you could probably get 3 or 4 replications happening on a scanline depending on what else is going on.

 

Problem is, you need a display kernal to do that - with the cycles you'd lose you'd (in most cases) be better off just doing software sprites.

 

There was a thread elsewhere in the A8 section sometime in the last year about documenting ANTIC DMA - it would be well worth digging it up to assist with calculations.

[Allas]

I've think one of the most great limitation is move vertically the multiplexing sprites, because is necessary to move all the 1K data sprites. Is there any other way to move vertically the sprites without copy the data. I think multicolor is posible if you change in the VBI the PM pointer and colors.

 

For example MILLIPIDE, in higher levels, appears on screen a lot of white fly objects. All are multicolored sprites multiplexed and moves very, but very fast and the background still is in action. (NTSC version, I think PAL version don't work well in this flying objects)

 

Another help, what are the top game in using Multiplexing sprites technique? Millipede it seems to me, maybe there is another there.

[Rybags]

Vertical movement can be done without too much processing.

 

No need for massive block moves - with clever programming you just have a short loop which blanks out Y_PREVIOUS to Y_CURRENT-1, or Y_CURRENT + SPRITE_HEIGHT to Y_PREVIOUS + SPRITE_HEIGHT (dependant on which direction it's moving).

 

Then just copy in the sprite data at Y_CURRENT.

 

Not sure about how many games do multiplexing, but I'd imagine Millipede just uses the flicker method, and not HPOS tricks to get multiple instances per scanline.

 

As I said, the downsides of a kernal in most cases would outweigh the benefits - I wrote a software sprite engine that does a 12x24 pixel character sprite for mode 4 in around 18 scanlines to draw, and about 3 to restore.

Edited May 21, 2007 by Rybags

[Allas]

Yes, Millipide change the x axis, because when these flying object appears I stop the emulator and half of them disappear.

Those sprite dont flickering at all in NTSC monitor, but I suspect in PAL yes, because the emulator PAL mode works very strange.

 

The bad thing with software sprites is the color, but it could be a great for hardware sprites. You should do GNU your routine

[NRV]

Hi

 

Some months ago, I made some tests changing P/M values across the same scan line and, like Rybags says, moving up or down is basically "brute" force, and moving left or right is the hard part.. I was trying to start a simple space invaders like test game, only with P/M and a lot of cycle counting. I was using PMBASE and not the GRAFP registers and I think that I couldn't change the value of PMBASE across the same scan line (at least not in the emulator, I don't have a real Atari to test) so I couldn't change the shape of the players across the line, only the position and the colors.. does someone know if that is possible??

 

I didn't continue with the "game" because I ended in a lot of demos and techniques for software sprites (and the cycle counting for all the cases was making me mad ), but that is for another post..

 

NRV

 

(the test basically shows 3 players "multiplexed" through the same scan lines, to use just drop first.obx over the emulator)

 

 

test.zip

 

 

http://madteam.atari8.info/index.php?prod=gtia2

Edited May 21, 2007 by NRV

[Allas]

Good example. I didn't try to change the PMBASE in a middle of scan line, that sounds a good idea. It seems the obx don't change too into the source code.

 

But I think you could have extras PMBASE over the 64K and banking the memory in a middle of scan line. It could?

 

That GTIA extended is incredible, something as Videoboard, but its a pity there is no more information about how complex will be to add in a real Atari. Polish is hard to read.

Edited May 21, 2007 by Allas

[NRV]

But I think you could have extras PMBASE over the 64K and banking the memory in a middle of scan line. It could?

 

you mean changing the memory bank in the middle of a scan line?? that sounds like a good idea, I would like to know how a real atari and the emulator handle that case.. well you left out all the 64k users, but it sounds like an interesting technique, with a lot of practical uses..

 

NRV

[Heaven/TQA]

what is the GTIA upgrade? is it a second GTIA or what? havent a clue... can not read polish either.

[Rybags]

Changing PMBASE is pointless if you're doing replication across a line.

 

ANTIC only does DMA (if enabled) once for each object - the only way to alter the shape for a replicated object is to store into the GRAF register.

[Allas]

Well, at least we can change the PMBASE for fast animated sprites every VB.

 

In other way, if we need to change the GRAFP, the color and x coordinate. How much replications do you can have per player?

Edited May 22, 2007 by Allas

[Rybags]

I'm fairly sure I did a program that had 3 instances of the one player.

 

But they were static.

 

The other consideration is that when changing HPOS on the fly, you're very restricted with positioning.

 

If you're changing GRAF and COLOR, then you'd probably manage 2 instances of 2 players (but only just).

[Lord-Chaos]

You can change the HPOS registers on the fly to get a second copy of a given P/M.

 

There are problems/limitations.

 

DMA is one, especially if you have a hires mode going as well - plus you have the refresh cycles stolen which is a pain because the bulk of them occur during the first 2/3rds of the display area.

 

Then, there's the fact that you'll get the same image/colour unless you change the GRAF or colour register/s.

 

Hardware collision detection will be not as useful - you would have to do extra calculations to work out which "sprite" was affected.

 

So, taking things into consideration, you could probably get 3 or 4 replications happening on a scanline depending on what else is going on.

 

Problem is, you need a display kernal to do that - with the cycles you'd lose you'd (in most cases) be better off just doing software sprites.

 

There was a thread elsewhere in the A8 section sometime in the last year about documenting ANTIC DMA - it would be well worth digging it up to assist with calculations.

 

Is this possible without flickering? It's possible to

switch to GTIA mode in mid-scanline and it's also

possible to switch colors, but my last efforts

with players did always flicker.

 

I'm using players as "underlays" for software sprites,

that way multicolor sprites are possible, but 4 players/line

is a little bit limited.

[Allas]

Is this possible without flickering? It's possible to

switch to GTIA mode in mid-scanline and it's also

possible to switch colors, but my last efforts

with players did always flicker.

 

I'm using players as "underlays" for software sprites,

that way multicolor sprites are possible, but 4 players/line

is a little bit limited.

 

 

If you change HPOS coordinates in the same scanline, you get solid color sprites. Only if you change the HPOS sprites in a VB then we get flickering. Thought, NTSC can generate 1 change in VB without flickering.

[miker]

Ok, here are some sample sprite engines by tebe (with sources in MADS). They have been written a while ago and they DO use extented memory.

 

Have a look.

softsprt.zip

softsprt_OK_.zip

softsprt_OK__.zip

Edited May 23, 2007 by miker

[Hrivis]

On 5/23/2007 at 7:04 AM, miker said:

Ok, here are some sample sprite engines by tebe (with sources in MADS). They have been written a while ago and they DO use extented memory.

 

Have a look.

softsprt.zip 149.44 kB · 305 downloads

softsprt_OK_.zip 159.82 kB · 189 downloads

softsprt_OK__.zip 101.92 kB · 189 downloads

Thats nice...

 

[TGB1718]

On 5/22/2007 at 10:43 PM, Lord-Chaos said:

Is this possible without flickering?

I did a demo for fun some time ago and got 64 players on screen, all moving horizontally at varying speeds, no flicker.

I wrote the program just to see how much was possible and for fun.

 

Some of the sprites in the screen shot below are a "bit broken", that was me not taking enough care lining up

the DLI and the position of the sprite, but it did prove my point

btw, that's not all 64, some are off screen, just a shot of the moving screen