Amiga sprites behind background?

[oRBIT]

I suck at sprites, sadly. I wished I've worked more with them back in the days.. Anyway, got one question for all skilled people here.. Is it possible to have Amiga-sprites appear "behind" the background/bitplanes?
Consoles (NES comes to mind but probably others too) have bits to set for single sprites to have them appear behind the background but I don't think I've seen this for the Amiga... Or?

[Galahad/FLT]

Originally Posted by oRBIT

I suck at sprites, sadly. I wished I've worked more with them back in the days.. Anyway, got one question for all skilled people here.. Is it possible to have Amiga-sprites appear "behind" the background/bitplanes?
Consoles (NES comes to mind but probably others too) have bits to set for single sprites to have them appear behind the background but I don't think I've seen this for the Amiga... Or?

Yes, you can change hardware sprite priority in BPLCON2

http://amigadev.elowar.com/read/ADCD.../node0159.html

[idrougge]

The reason you haven't seen it on the Amiga is that hardware sprites are less often used for "sprites" – instead, they are used for overlays or as parallax backgrounds.

[Coagulus]

For JetHunt, the main Sprite, bomb, explosion and lasers all go in between the front and back playfields. :-)

The sprite priority is switched to right into the foreground when displaying the "paused" sprite.

[Shatterhand]

Originally Posted by idrougge

The reason you haven't seen it on the Amiga is that hardware sprites are less often used for "sprites" – instead, they are used for overlays or as parallax backgrounds.

Actually I feel a lot of properly programmed games use sprites for the main character and reuses them for overlays. And smartly coded ones also reuses them for extra layers of parallax as you said.

But I really feel they are used very often to draw the main character. It's a nice way to get more colors for the main hero when you are using Dual Playfield

[mcgeezer]

In Rygar I use the hardware sprites quite extensively as enemies with the hardware sprite appearing in front of the bitplanes.

However I quickly came up against a problem in that the sprites often glide above the play area into the upper and lower panels so instead of clipping them I used a non-transparent Black in the panel areas and switched the sprite priorities at the start of the main game area.

[buzzybee]

In RESHOOT R I use sprites just like Shatterhand proposed, for displaying the main ship, bullets, parallax background and score.

Using the Amigas copper it´s possible to switch bits in BPLCON2 at almost any given x- and y-position on the screen. Therefore one sprite can be on top of a playfield in the, say, the middle of the screen. And can be behind a playfield at farther to the right - a technique used for the score display at the very right top and bottom corner of the screen.

The fifth level of RESHOOT R switches priorities quite a bit – have a look [ Show youtube player ] ...

[phx]

Using sprites for the main character has never been an option to me in the past, because their display priority is limited to foreground or background. Theoretically you can also place them between two independant playfields, but I always wanted my OCS games with 32 colors. When using background- and foreground-tiles it becomes impossible to render a sprite between those tiles.

I'm using sprites a lot for displaying scores and parallax layers, though.

[aros-sg]

If foreground tiles overlap player sprite copy real sprite to some scratch sprite buffer and NAND over the foreground tile masks.

[Shatterhand]

Originally Posted by phx

Using sprites for the main character has never been an option to me in the past, because their display priority is limited to foreground or background. Theoretically you can also place them between two independant playfields, but I always wanted my OCS games with 32 colors. When using background- and foreground-tiles it becomes impossible to render a sprite between those tiles.

I'm using sprites a lot for displaying scores and parallax layers, though.

For platform games at least, usually the games that most impressed people had Dual Playfield + Sprite for main character and HUD overlay (score, lives, etc). Lionheart, Mr. Nutz, Turrican 3, both Chuck Rock games,

I've seen some games using both the Back and Front playfield to draw enemies, so you could either use the back palette or the front palette for them (I think the Chuck Rock games do that, not 100% sure though).

Or, yes, you do the 32 colors thing and forget about dual-field parallax (Ruff 'n' Tumble, Superfrog).

Turrican 2 would switch between modes, though I think in "single" playfield mode the bitmap was always at 16 colors anyway. It's really funny to see the last boss on that game when the tiles on the background "switches" its colors in real time while the game switches from single playfield to dual playield to allow the big boss to appear as a single bitmap on the background. That was some really smart coding there.

[oRBIT]

I've been experimenting a bit with BPLCON2 (a few years later), BPLCON2 obviously affects the entire scanline.. Assuming I have a few sprites on the exact same scanline, but only a few should be in the background, this won't work?

[Rock'n Roll]

is possible.
1. spritepriority in groups of two 0,1 2,3 4,5 6,7 (sprite 0,1 in front (higher priority), sprite 6,7 behind)
2. single- or dual-playfield?
2a) single-playfield 1-6 bitplanes use only bits PF2P2-0
2b) dual-playfield 2*(1-3 bitplanes) use PF2P2-0 and PF1P2-0
3. dual-playfield: playfield 1 - bitplanes 1,3,5 and playfield 2 - bitplanes 2,4,6
4. P2PRI if set - set playfield 2 higher priority over playfield 1
5.
PF2(1)P2-0=0 (000) p-s-s-s-s ; p-playfield, s-sprite
PF2(1)P2-0=1 (001) s-p-s-s-s
PF2(1)P2-0=2 (010) s-s-p-s-s
PF2(1)P2-0=3 (011) s-s-s-p-s
PF2(1)P2-0=4 (100) s-s-s-s-p