128 Pixel sprite

[Wickeycolumbus]

I was experimenting with reseting the h position register mid line in several spots during the line and I came up with this kernel. It puts Each sprite on the screen 7 times for a total of 14 sprites or 112 pixels and saves 22 cycles for housekeeping with no flicker. I dont think that it is possible to change the graphics of each copy though...

SpriteDemo.zip

Edited September 22, 2008 by Wickeycolumbus

[Wickeycolumbus]

Optimized a bit. Now you have ~19 cycles at the begining for housekeeping, then you have 5 cycles for graphic changing in between resetting horizontal positions. There are also 16 sprites now for a total of 128 pixels.

spriteDemoChange.bin

[Wickeycolumbus]

Kernel greatly improved. Still 128 pixels, Removed WSYNC write and saved 11 cycles. Here is the template for the kernel if anyone is interested:

 

somewhere in game:

 

	lda #%00000011
sta NUSIZ0
sta NUSIZ1

 

Main Kernel:

 

	sta WSYNC
Kernel

nop
nop
nop
nop
nop
nop	 ;; 20 cycles for house keeping
nop
nop
nop
nop

sta RESP0
sta RESP1

nop 0  ;; 5 cycles for graphics changing
nop

sta RESP0
sta RESP1

nop 0
nop

sta RESP0
sta RESP1

nop 0
nop 0;; 11 cycles for house keeping
nop 0
nop

dey
bne Kernel

 

attached is an example.

 

EDIT:

I miss calcualted. You can have up to 10 cycles in between each reposition of the sprites, enough to change the graphics of player one and two.

spriteDemoChange2.bin

Edited September 22, 2008 by Wickeycolumbus

[vdub_bobby]

Kernel greatly improved. Still 128 pixels, Removed WSYNC write and saved 11 cycles. Here is the template for the kernel if anyone is interested:

[...]

 

EDIT:

I miss calcualted. You can have up to 10 cycles in between each reposition of the sprites, enough to change the graphics of player one and two.

Kinda cool, though fairly limited since the graphics have to be of the form: ABABCDCDEFEFGHGH

 

Though your demo doesn't change colors and uses 2-line resolution for the sprites, I assume that neither of those are a necessary limitation?

[Wickeycolumbus]

Though your demo doesn't change colors and uses 2-line resolution for the sprites, I assume that neither of those are a necessary limitation?

 

Yea, sprites can be 1 line and you can change colors as long as you have enough time to. I'll put together another demo demonstrating this sometime.

[Wickeycolumbus]

This demonstrates 1-line resolution sprites that change color every line. It can easily be adapted to change graphics one or two times also.

spriteDemoColor.bin

[roland p]

Any chances in positioning the sprites at equal distances? You could create nice grid-like graphics then.

[vdub_bobby]

Here are some screenshots:

1st ROM:

2nd ROM:

[Eckhard Stolberg]

Any chances in positioning the sprites at equal distances? You could create nice grid-like graphics then.

It is possible to position the sprites at equal distances, but you'd either have to increase the gap between them a bit or fill the entire line using 9 copies of each player. Increasing the gap might be too much for a nice looking grid. But it has the advantage that the sprites could be disabled individually. Christopher Tumber uses this in his game Space Instigators.

 

Filling the entire line with 18 spites allows you to display a nice grid. But there isn't enough time to update the graphics and colours for both players in each scanline. I posted some experiments with this effect to the [stella] mailing list about 10 years ago. Multi5.bin displays a screen filling pattern. Grid2.bin displays a grid that you can scroll left and right. And extra18.bin displays 18 sprites that you can hide with the joystick. The sprites in the last one aren't positioned at equally distances though.

 

multi5.binGRID2.BINEXTRA18.BIN

 

 

Ciao, Eckhard Stolberg