14 replies to this topic

[peteym5]

I have been experimenting with player/missile graphics multiplexers to get more sprites on the screen. I manage to get 10 multicolor ones at 20 pixels tall just using players so they can only be 8 pixels wide. I did include setting the player double width and quad width for certain sprites. These may be use for a potential future game. I went through and drawn up some mythical monsters like Dragons, Spiders, Bats, Unicorns, Pegasus, Griffins, etc. I am consider making something that goes room by room (like 2600 adventure or NES Zelda) using Antic 4 mode for the walls and stuff in the rooms. I would like to build something original.

Attached Files

•  mc_spritedemo.zip   5.89K   137 downloads

[snicklin]

This looks like a good, working sprite multiplexor, well done on that, it couldn't have been easy.

I think that with a multiplexor that the flicker isn't ideal but it does enable you to have some extra freedom over keeping the sprites on different horizontal rows. Is there a game type which could maybe *tend* to avoid flicker, though allow it when required?

Also, it would be nice if your main character could be kept constantly on but only the enemies flicker between themselves.

[tjb]

Well done! It looks great, very colorful.

tjb

[fibrewire]

There is something about great atari graphics like these that give me a pang of anxiety and panic. A true tell-tale sign of great game characters!

I vote for an original Zelda / Metroid / Mario

[Heaven/TQA]

any chance, Pete, to get send me the source code, would like to test that multiplexor in my Beyond Evil RPG.

[peteym5]

I have not decided on a final game design if the project goes forward. I may limit 4 or 5 monsters per screen with the character. Maybe use a sprite for an item your character has to get. I use a copy routine that copies all the sprite data to the pmbase memory area all at once. Looks something like this.
LDY #19
LOADPLYRADDR1L = *+1
LOADPLYRADDR1H = *+2
STORPLYRADDR1L = *+4
STORPLYRADDR1H = *+5
LOADPLYRADDR2L = *+7
LOADPLYRADDR2H = *+8
STORPLYRADDR2L = *+10
STORPLYRADDR2H = *+11

SPCOPYLOOP
LDA src00, y
STA PMv00, y
LDA src01, y
STA PMv01, y
LDA src02, y
STA PMv02, y
LDA src03, y
STA PMv03, y
...
...
LDA src18, y
STA PMv18, y
LDA src19, y
STA PMv19, y
DEY
BPL SPCOPYLOOP

The Addresses get modified elsewhere in the VBI routine before the loop is executed. With counting down and a branch, it can copy 10 multicolor or 20 monocolor sprites at once. The BPL can at most branch 128 bytes back and is the reason for one of the limits here. This loop has to be completed before the scanline reaches the top of the playfield or else some of the sprites get cut off.

Edited by peteym5, Sat Aug 13, 2011 12:06 PM.

[Heaven/TQA]

and how is your multiplexor working? sprite sorting? and how do you flicker?

[Allas]

Awesome work!, thanks for take your time to design those detailed PMs. Great work engine!, great graphics!, great animations!

[Philsan]

Awesome Peter!

[peteym5]

Heaven/TQA, on Sat Aug 13, 2011 12:16 PM, said:

and how is your multiplexor working? sprite sorting? and how do you flicker?

The Flicker cannot be helped because as you know the Atari can only has 4 players and 4 missiles. Since we are combining groups of 2 for the 3rd color, we end up with 2 in one of the DLI zones. Which sprite number we start with increments every frame and when the start number reaches the number of sprites, it resets to zero. Within the sort loop, I increment the sprite number by 3 and decrement by 10 if greater that 10. So all the sprites get checked in an order like 0,3,6,9,2,5,8,1,4,7,0. Since we started with 0, it knows what value to end the loop at. It looks at the vertical position to determine which zone to put the sprite so the DLI routines know where to set the hoz position, color, and width. I use a 256 byte long table to quickly figure out which zone the sprite will start and end in. Since I have a DLI on every line, the table goes something like 1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,etc. for areas out of the playfield, it is filled with a value greater than 128 so the negative flag is trigger and tells it to skip the sprite. When the sprite is used a flag is set so the next sprite will be set for player 2&3. If more than 2 sprites are on the line, the rest are not drawn for current frame.

    LDA SPRITENVERTPOS,Y
    BEQ SKIPSPRITE        
    TAY
    LDX DLI_TABZONE,Y
    BMI SKIPSPRITE
    STX FIRSTZONE
    ADC #21    
    TAY
    LDX DLI_TABZONE,Y
    BMI SKIPSPRITE
    STX LASTZONE
    LDA SPRITEUSE,X       
    LDX FIRSTZONE
    ORA SPRITEUSE,X
CHECK_SPRITE_1
    LSR
    BCS CHECK_SPRITE_2
    ..
    LDA SPRITEUSE,X       
    ORA #1
    ..
CHECK_SPRITE_2
    LSR
    BCS SKIPSPRITE
    ..
    LDA SPRITEUSE,X       
    ORA #2
    STA SPRITEUSE,X       
    DEX
    CPX FIRSTZONE....
    ..

I know people have other ways to indicated with sprites are in use and I am continuing to experiment with this thing.

You have to keep in mind I am showing the multiplexer at its max, all 10 sprites active. What I have in mind is only 4 or 5 monsters per room. Maybe have some monster types patrol its own quadrant of the screen.

[Heaven/TQA]

it is interesting. because my sprite multiplexor works in zones, too... i had done radix sort or ocean sort and then putting DLIs and setting shape etc. but never achieved the flickering as my ring buffer approach did not worked out... so I went to take soft sprites for Beyond Evil.

[Heaven/TQA]

Pete, the interesting is... what happens when sprite is "overlapping" a zone?

[snicklin]

peteym5, on Sat Aug 13, 2011 10:12 PM, said:

I increment the sprite number by 3 and decrement by 10 if greater that 10. So all the sprites get checked in an order like 0,3,6,9,2,5,8,1,4,7,0. Since we started with 0, it knows what value to end the loop at.

Absolute genius algorithm here.

I was wondering how you'd cycle through the sprites.

[peteym5]

Heaven/TQA, on Sun Aug 14, 2011 2:17 AM, said:

Pete, the interesting is... what happens when sprite is "overlapping" a zone?

It is always overlapping zones because the sprites are 20 pixels high and there is a DLI for every antic 4 line (8 pixels tall). What I did was fill the DLI zone table with the need values with the sprite info. When the sorting is done, the use table has to all zeroed for the next frame.

        LDX FIRSTZONE
PMLOOP1
        LDA SPRITE_HOZPOS,Y	
	STA DLI_HOZSET1,X
	LDA SPRITE_COLOR0,Y
	STA DLI_COLORSET2,X
	LDA SPRITE_COLOR1,Y
	STA DLI_COLORSET3,X
	LDA SPRITE_WIDTH,Y
	STA DLI_WIDTHSET,X    
        LDA SPRITEUSE,X
	ORA #2
	STA SPRITEUSE,X
	CPX LASTZONE
	INX
	BCC PMLOOP1

Edited by peteym5, Sun Aug 14, 2011 9:48 AM.

[peteym5]

I did some optimizations to speed up what you see above. One is just store the sprite number source in the table and let the DLI load and set the registers.

  PMLOOP1
  TYA
  STA SPRITE_SOURCE1,X
  LDA SPRITEUSE,X
  ORA #1
  STA SPRITEUSE,X
  ..
  ..

DLI
  ..
  LDX SPRITE_SOURCE1,Y
  LDA SPRITE_HOZPOS,Y  
  STA HPOSP2
  STA HPOSP3
  LDA SPRITE_COLOR0,X
  STA COLPM2
  LDA SPRITE_COLOR1,X
  STA COLPM3
  ..

Some little limitations to this multiplexer are that 20 sprites can be done within the sprite image to PMBase area. To do more than 20 sprites, you will need to do something like this...

..replace..
  DEY
  BPL loopstart
.. with ..
  DEY
  BMI loopend
  JMP loopstart
loopend

Which now is taking up a few more clock cycles and more time to process.
Also all the sprite image source is best to come from the same "bank" if you want to use extended ram banks or 32k+ cartridge. Can do a single LDA #banknum, STA $D301/$D5xx before the loop. Carts with 8k banks can hold 204 multicolor sprite images at 20 pixels tall. A work around is to use RAM for extended sprites. The multiplexer itself has to copied to ram since it uses all self modifying code for speed.

I manage to get around 400 bytes of sprite data copied before the scanline reaches my intended playfield area. That is 200 pixel height for the multicolor sprites. I am doing the erase at the last DLI at the bottom of the Display List. The Sort and copy routine are done immediate VBI. I also use a custom NMI vector routine. So it requires a 64k machine with the 16k (12k) under the OS activated.

Edited by peteym5, Tue Aug 16, 2011 10:34 AM.