I saw that cracktro here:
https://www.youtube.com/watch?v=hoWG01yZ0gE

And it immediately reminded me of this:
https://www.youtube.com/watch?v=Ae_jD8yF0J4

Exactly the same principles used, just take 2 or 3 sprites and split them all the way down to move across the screen at random speeds, off the left and reappear on the right. Relatively simple to do on the Atari 8-bit, but REALLY simple on the Amiga with the Copper. :cool

It just goes to show the similarity in the two hardware chipsets. :great

Copper?
I've not touched it for this effect ;)

One positive thing about Amiga sprites is that they are available with HAM.

Still, the limited support means this is hard to take advantage of.

With slightly better sprite support a nice vertical scroller using a HAM background would have looked nice.

I described in my opening post how sprites are used for text scrollers and captions with HAM effects, but yes, games are very impractical with HAM.

my first thought too :D

https://www.pouet.net/prod.php?which=12454

Neither does the starfield in the Inviyya titlescreen...
:D

:great

The damned spaceship uses 4 sprites!
Not resorting to copper usage, in a 256y screen I can use max 256/2*3=384 sprites (I've a light overscan, so lost sprite7).

But probably I've more layers and subpixels usage :p

How do you split up a few sprites as I've shown above without the Copper then? The same principle as the Warhawk game on the Atari?

Sprites on Amiga uses sprite_list in memory.
Position on screen is not defined, like on C64, setting custom registers by CPU (well, actually you can also do it).

On Amiga sprites DMA fetches position/dimension/features from this list, then start fetch real data on the same line it need to visualize.
At end, DMA reload position for a new sprite (or NULL if you want to stop it).

From this you can understand that if you display a sprite in a line then reload the position in the next, then display a new sprite in the next line, you can use the same sprite (1 line high) 128 times on a 256 lines screen.

And this not using any copper trick :)

okay, but you have to busy wait with VPOSR with the CPU right?

Not if you double buffer the sprite_list.
Then simply switch with copper at VB time (or double buffer also the copper_list).

Moreover Copper pointers are buffered so you can set it when you want during frame.

The CIAs provide resources for syncing the CPU with the display. That and cycle counting can allow the CPU to write to chip registers at specific times relative to the beam. There is potential with this for using the copper to drive the blitter while the CPU does what the copper normally does.

I really believe that Jay Miner expected Amiga programmers at times to use the CPU in a way like that done with the Atari 2600. The availability of sprites' manual mode further supports this.

Again, the implementation of the sprites was a little flubbed.

If a programmer is really careful, a MOVEM.L might be useful with manual mode.

This thread is really interesting to read. When I started reading on Sprites on Amiga, I thought, that they are so clumsy and ineffective that I wonder why one would use them at all, especially when compared with the C64. But now that I read this thread, I revised my opinion and think that they have more potential than I initially thought, when I had just read the docs.

All in good spirit. ;) Comparing the whole (games) can give rise to unfounded generalisms, but a technical comparison might reveal the details. It really was the best sprite chip on the market. Sometimes we forget that.

I'm pretty sure nobody would tolerate halfres sprites on Amiga, let alone call them better. Vertical stretching is possible, but with all the RAM in the Amiga you'd rather have them fullres (i.e. just 'tall') to begin with.

Yes, PC graphics cards at the time had 1 sprite dedicated to a pointer. You explained your reply well, though, so I understand what you mean - my mention of it was to point out that Amiga's main competitors weren't anywhere close, and only a few consoles that came out after Amiga had more sprites, in the time window before the era of mostly 3D games.

The Amiga always had the blitter as the main source of power. If I am remembering it right the team got the blitter idea from early eighties graphic workstations.

I guess because the blitter and copper are in the chipset they didn't put much effort into the sprites, more of a bonus than the kingpin of your arcade/action game engine on things like Famicom/C64.

I don't know of many computers/consoles that share sprite palettes with bitmap background palette entries like Amiga (Atari 8bit?) and 3 colours+16 pixels wide with max 8 per scanline is 1983 Famicom/MSX territory. There is also nothing you can do with OCS sprites like rotate, expand etc like you can on C64/Famicom hardware.

You can certainly multiplex C64 sprites, with 1 wasted scanline between each sprite above/below so you have to be careful, it's just not as easy as the Atari 400/800 display list hardware. I believe the fist end of level guardian of C64 Turrican (?) uses lots of sprite multiplexing. If you want to see the true power of C64 sprites combined with the unusual quirks of C64 character based screens to do fake parallax effects and mixed lo-res/hi-res backgrounds on the same scanline check out Enforcer, one of the most astounding shmups ever released on the C64.

AGA sprites when used with workarounds for the restrictions like C64 Supercycle/Outlander has to deal with can be useful for scaling roadside objects on each side but staggered in vertical position so there's never more than 8 per scanline. That's something I hope to get a chance to do some experiments with one day.

AGA sprites are also very useful for SF2/MK2 type game engines, you can easily get two 128 pixel wide fighters on screen.

The real problem is writing games for OCS/ECS then adapting them with minimal changes to AGA meant the AGA sprites never got pushed to the limit. I don't actually think there is an AGA game that pushes the A1200 to the max like the starting overground level of Beast 1 or Turrican 3. Not enough A1200 units sold I guess and Commodore weren't around for that long after the late October 1992 A1200 launch (UK).

@ImmortalA1000, Amiga certainly didn't have any competition from any other computer with regards to sprite hardware. Maybe there's a niche computer somewhere? But no mainstream computer like the Amiga in 1992.

I know people who were happy to play dinky oldtimer console and PC games in 1992 with visual performance far below the A1200.

I worked in London at this crucial time, and I think game developers showed much too much faith in consoles and PC than was warranted at the time. They paid for it, and probably the money they lost by distraction ended many independent companies.

Dev teams were very small, development times required to beat last year's games were increasing far beyond the one-man 8-bit arcade ports, and even though consoles continued with limited arcade and PC tried 1970s games again, there were only a few that could continue to drive the new type of games the independent companies on Amiga started.

Many of the new game ideas didn't involve lots of sprites at all; even arcade teams persisted with this for a few years before it died, too.

But it's still a great question which computer could have matched the A500 and the A1200's capability for arcadey graphics and sprites at time of release. I know a lot of computers, and I can't name one. Can you?

Well the PC Engine can generate much more sprite pixels per scanline, and they don't waste 50% of the background bitmap palette to assign colours to the sprites ;)

As I said, 16 pixels wide max AND no separate sprite colour palette made them inferior to C64 (up to from 24x21 hi-res monochrome to 48x42 pixels wide and unique dedicated palette) and NES (same sort of size but dedicated sprite palette). The Amiga sprites are indeed the weakest part of the A1000, the rest of the specs are crushingly superior to any computer on sale in 1985/86 even at 4 times the cost of A1000. On the Amiga you have to waste half your 32 background colours to make 15 sprite colours and if you want better than 1983 Famicom you only get 4 per scanline at 16 pixels wide which is VERY naff for the 1987 A500 era sprite hardware.

Like I said the blitter was really where the power was and that is where you get Konami/Irem arcade quality BUT converting sprite based arcade games to a blitter would be a headache for the highly professional Japanese developers let alone the kind of unqualified programmers working on games for Amiga 99% of the time. I don't care for 'problems' developers have, if you can't fix the engine on my car you shouldn't be at my local garage trying and then charging me lots of money for the botch job...same attitude to Amiga developers, I never forced them into those jobs, they should have gone and stacked shelves at the supermarket if they couldn't manage Amiga 1000 quality developments (roughly Megadrive quality graphics/SNES quality sound when done professionally and no greed/incompetence involved from the second the arcade license is acquired). There is also zero excuse for all the 16 colour Amiga games like New Zealand Story. I paid my money I expect quality.

Technically it doesn't matter about Amiga OCS/ECS sprites as the goals of Jay Miner and Co. were more about 'realtime animation' ability of hardware which sprites can't deliver. I think they made the best choice, sprites are nice but a blitter in the right hands, any blitter, is more flexible.

The AGA sprites like I said are pretty hot, two paired up to give a 32 colour 128 pixel wide pair of sprites for each beat em up character overlaid onto a HAM8 background.....the mind boggles at what they could have done with AGA SF2 or MK port.

On OCS the sprites are really relegated to doing bullets not the main action sort of role vs blitter. Like I said the blitter is there so it doesn't matter if the sprites are 1982/83 quality on 1985 blitter equipped A1000 and beyond. Turrican 3 does just fine with the OCS/ECS hardware as is and replicates the Megadrive experience nicely just as many PS3 and Xbox 360 games are close enough hardware differences make no difference. In the wrong n00b hands....sprites are more forgiving that's all...especially doing 16bit arcade conversions.

... and it's even an 8 bit CPU based system. ;)

Do you have any sources for this? Well, I don't think so...

It seems that you have no knowledge about the Amiga at all?

Ronald Pieket Weeserik said about choosing 16 colours:
Also he explained why SWIV is running 'only' at 25 FPS:
Probably he was one of the 99% unqualified programmers...

In short: OCS/ECS amigas have limited bandwidth. You want 32/EHB colors? Expect limited framerate or smaller screens. You want full screen? Expect 16 colors or dual playfield. You want mayhem? Expect 16 colors, dual playfield AND limited framerate OR 32 colors but small screen AND limited framerate.

Did shatter the expectation i had as a twentie but considered results i can live with it.

The unpopular truth is: the weakest part of the Amiga is the OCS/ECS chipset itself but it was also the strongest part in the early years.

When you'd have some knowledge about the Amiga hardware you should also know why developers decided to use 16 colours for certain games.

Actually it was rather simple: choose wisely the things the Amiga hardware DMA bandwidth offers (screen resolution, bitmap depth => number of colours, sprites, copper effects, chip RAM memory limits, sound channels) and find the best solution for your needs. Be aware that the result might disappoint you. This was the real problem programmers had.

In some cases you simply take a CPU based solution and you're done. Sometimes these approaches are called 'Atari ST shovelware' because many do not understand that a 'perfect' Amiga version is impossible to realize.

So in conclusion you have to design and develop a game around the limitations of the Amiga and it will shine but M68k based Arcade games like CPS are out of reach for a perfect port.