Assembly Gurus: Flicker-Free Multi Sprite Possible?

[+Gemintronic]

Assuming additional memory so sprites can be mapped to RAM can't you merge sprites as they pass horizontally? Is it a matter of not enough cycles or not enough draw time per sprite to merge them this way?

 

Please forgive me in advance for not knowing what the heck I'm talking about!

[Tjoppen]

That's not a lot to go on. Try drawing a picture or something.

[+Gemintronic]

Instead of resorting to having both player0 and player1 on the same horizontal line just add the pixels from player1 to the player0 sprite.. does that make any more sense?

[Tjoppen]

Sure, if they're both very thin sprites and close to each other. Like if your "sprites" are single pixels that somehow always keep close enough to fit in an 8-pixel sprite.

[+SpiceWare]

Are your sprites going to always have the same X position?

[+Gemintronic]

Hmmn.. I think I'm starting to see the fundamental flaw. When you see a title screen or 48 pixel sprite it's using all the available objects to draw that. So trying to merge two sprites to avoid flicker is pointless because you always just get 8 "pixels" to work with per horizontal line per player object?

 

You probably couldn't create a bitmap mode from a title screen like kernel because there's barely enough time to draw a static image from ROM on the screen. Is that assumption correct too?

 

I think I've got my answer (if I understand the problem correctly). Thanks for your time, guys

[Tjoppen]

Oh, you just want a 48 pixel wide bitmap? No problem - just use a normal 48 pixel kernel and read from RAM instead of ROM. Update the bitmap however you want during VBLANK. The maximum resolution should be 48x21 (126 bytes)

[roland p]

Oh, you just want a 48 pixel wide bitmap? No problem - just use a normal 48 pixel kernel and read from RAM instead of ROM. Update the bitmap however you want during VBLANK. The maximum resolution should be 48x21 (126 bytes)

I always wondered if a super mario land game could be made that way. I would call it super mario city

[Mr SQL]

Oh, you just want a 48 pixel wide bitmap? No problem - just use a normal 48 pixel kernel and read from RAM instead of ROM. Update the bitmap however you want during VBLANK. The maximum resolution should be 48x21 (126 bytes)

Tjoppen,

was just discussing this idea on another thread! Seems a 48x42 bitmap could live in CBS RAM or larger sizes up to 48x192 in some other formats.

 

The DPC+ kernel supports reading 40x192 titlescreens for playfield graphics and I believe, from RAM as a malleable playfield so it looks like there's plenty of addressable RAM in DPC+ land for reading 48x192 sprites from RAM.

[Tjoppen]

You don't need a DPC+ for that - just sufficient cart RAM.

[SeaGtGruff]

Being able to do hi-res stuff sounds potentially great-- but (1) the six-digit score "sprite" isn't wide enough to cover very much of the screen's horizontal real estate; and (2) you'd basically have to settle for using just one sprite color per scan line.

[+Andrew Davie]

you'd basically have to settle for using just one sprite color per scan line.

 

Even so, one sprite colour per scan line can do some nice stuff.

Swith the ROM-type in the attached to 3E if you're using Stella.

Cheers

A

ohno_colour.bin

[+SpiceWare]

Can't download the attachment for some reason - You do not have permission to view this attachment.

[+Andrew Davie]

Can't download the attachment for some reason - You do not have permission to view this attachment.

 

OK, I re-did it. Try again!

[+SpiceWare]

That worked, thanks!

[Jan Hermanns]

Even so, one sprite colour per scan line can do some nice stuff.

Swith the ROM-type in the attached to 3E if you're using Stella.

Cheers

A

 

Wow, that is some clever interlacing!

 

Very well done!

[Mr SQL]

You don't need a DPC+ for that - just sufficient cart RAM.

Tjoppen,

you would need DPC+ to do it with bb - it supports the superchip but not larger RAM sizes like CBS or the TigerVision format in Andrew's demo.

 

Andrew,

awesome!