Jump to content
Sign in to follow this  
Allas

Multiplexing sprites in A8

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Rybags

Share this post


Link to post
Share on other sites

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 :D

Share this post


Link to post
Share on other sites

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 by NRV

Share this post


Link to post
Share on other sites

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 by Allas

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Allas

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...