English Amiga Board

English Amiga Board (https://eab.abime.net/index.php)
-   Nostalgia & memories (https://eab.abime.net/forumdisplay.php?f=18)
-   -   Sprites are the weakest part of the Amiga specification (https://eab.abime.net/showthread.php?t=100356)

Photon 10 January 2020 13:49

Hm. Not sure why you create this argument, because the facts are well-known and they... kinda refute you on all points. :spin

Let's see.

In general, you can't compare computers and consoles because computers do so much more! :great

But you'll notice that any consoles that beat Amiga for sprites came after Amiga. Amiga 500 had the best sprite chip on the market, while its main competitors the ST and Archimedes had nothing.

You can't compare the Amiga's visionary design with a jack-a-buck budget imitation of specialized arcade PCBs. The Megadrive and SNES were absolutely horrid as soon as you wanted to do something that didn't fit within their narrow limitations, whereas on Amiga you could and can make any game you want.

Lastly, Giana and Turrican are objectively technically better than Mario and Metroid.

Now, to showcase the Amiga's sprite hardware fully, you have to take advantage of it. By adapting your game idea to Amiga (as was done on consoles because that's all they could do), lots can be done, and the Amiga is capable of full dynamic multiplexing with fallback to bobs, but AFAIK few games implemented the full tech.

Foebane 10 January 2020 18:02

Quote:

Originally Posted by Photon (Post 1370683)
Hm. Not sure why you create this argument, because the facts are well-known and they... kinda refute you on all points. :spin

Oh, I know, I consider my topic title fully DEBUNKED. Now if only a Moderator would change the topic title accordingly... ;)

th4t1guy 10 January 2020 19:23

Quote:

Originally Posted by Photon (Post 1370683)
Giana and Turrican are objectively technically better than Mario and Metroid.

I've never understood the obsession over Giana as I always viewed it as an embarrassingly cheap ripoff.

saimon69 10 January 2020 20:06

Quote:

Originally Posted by sokolovic (Post 1370637)
I just don't understand why this hudge difference seems to be completely obliterated by people constantly comparing the 2 systems.

Is mainly due to teenage expectations; the Amiga was the DREAM ARCADE machine at home for majority of european teens, that did not even knew of the existence of x68000 - i did learn it by reading a review on a japanese magazine - Technopolis - that a father of a friend of mine brought from japan - and was kinda devastated!
We teen amigans wanted the moon and the stars that dpaint screenshots promised to us, rather than the dark room with a white baloon and christmas lights ceiling that european software houses were giving us mostly :/

saimon69 10 January 2020 20:07

By the way, question: can amiga sprites be stretched out like on c64 and Atari?

Foebane 10 January 2020 20:09

Quote:

Originally Posted by saimon69 (Post 1370768)
By the way, question: can amiga sprites be stretched out like on c64 and Atari?

No, and Atari sprites could only be stretched out on the X-axis. C64 could do both X- and Y- axes, which makes them even better. WHY THE HECK didn't the A8 spec use the same principles for Y movement as they did for X??

mcgeezer 10 January 2020 22:52

Quote:

Originally Posted by roondar (Post 1370444)
A good example of AGA sprites in use is Rygar AGA, which does a lot with sprites. IIRC all (or at least most) enemies are actually hardware sprites. As I understand it, Reshoot and Reshoot-R create all the enemy bullets with sprites - apparently up to 100 of them.

*) yeah, shameless plug alert :p

For some enemies I hold two copies of the their sprites in memory, a hardware sprite version and a BoB. The playfield has zones, upper, mid and lower and each hardware sprite is multiplexed (re-used) in each zone meaning the game pushes 12 hardware sprites, if the hardware sprites are all in use at the time then it falls back to using the blitter (bobs)

Due to colour limitations some sprites are simply set as bobs (the Blue robotic dude being one example).

Put to good use..the hardware sprites can make for some pretty awesome effects in games....but an Amiga programmer has to work harder to exploit them than a console programmer (in my opinion).

AmigaHope 11 January 2020 21:30

Quote:

Originally Posted by saimon69 (Post 1370768)
By the way, question: can amiga sprites be stretched out like on c64 and Atari?

They can in AGA, but not in the way you're thinking. On the X axis they can't be any wider than a lores 140ns pixel, but they can be half or a quarter of that too. They can be doubled on the y axis for scandoubling purposes but I don't know if you can do this independently of the bitplanes.

jotd 12 January 2020 11:44

@mcgeezer: that's pretty impressive. All this to save CPU/blitter saving/restoring the background!

I'm upgrading my SDL-like engine so it can use sprites or bobs indifferently. Just the image type differs, and the SDL-like "blit" routine will adapt.

roondar 12 January 2020 13:03

Quote:

Originally Posted by saimon69 (Post 1370767)
Is mainly due to teenage expectations; the Amiga was the DREAM ARCADE machine at home for majority of european teens, that did not even knew of the existence of x68000 - i did learn it by reading a review on a japanese magazine - Technopolis - that a father of a friend of mine brought from japan - and was kinda devastated!
We teen amigans wanted the moon and the stars that dpaint screenshots promised to us, rather than the dark room with a white baloon and christmas lights ceiling that european software houses were giving us mostly :/

I too learned about the X68000 and wasn't that bothered to be honest, as I could never have afforded that machine. Perhaps that's an oddity in my way thinking though ;)

Slightly more seriously: these days we're all much more aware of how big the price difference really was, so surely we can see why the comparison is such a weird one to make?
Quote:

Originally Posted by mcgeezer (Post 1370803)
For some enemies I hold two copies of the their sprites in memory, a hardware sprite version and a BoB. The playfield has zones, upper, mid and lower and each hardware sprite is multiplexed (re-used) in each zone meaning the game pushes 12 hardware sprites, if the hardware sprites are all in use at the time then it falls back to using the blitter (bobs)

Due to colour limitations some sprites are simply set as bobs (the Blue robotic dude being one example).

That's a nice explanation, thanks. Pretty awesome, really.
Quote:

Put to good use..the hardware sprites can make for some pretty awesome effects in games....but an Amiga programmer has to work harder to exploit them than a console programmer (in my opinion).
Absolutely, Amiga sprites are much harder to use to great effect than console sprites.

wodan 12 January 2020 13:54

Quote:

Originally Posted by roondar (Post 1371110)
Absolutely, Amiga sprites are much harder to use to great effect than console sprites.


What makes console sprites easier?

Thomas Richter 12 January 2020 14:40

Quote:

Originally Posted by Foebane (Post 1370769)
No, and Atari sprites could only be stretched out on the X-axis.

Well, yes and no. There is a low-resolution setting of the P/M graphics in which Antic only fetches data every other line. But that's arguably not exactly the same as stretching them.




Quote:

Originally Posted by Foebane (Post 1370769)
C64 could do both X- and Y- axes, which makes them even better. WHY THE HECK didn't the A8 spec use the same principles for Y movement as they did for X??


Well, the C64 was like 2/3 years later, which was a lot of time given the speed of evolution back then. The Atari P/M graphics evolved from the even more primitive TIA display generator which did not even had a framebuffer (or playfield, to use the term from back then). Thus, P/M graphics are just a DMA channel and a priority generator.


You need to understand the evolution from the TIA to ANTIC/GTIA to learn why the P/M system is so primitive. It was the best and simplest they could do with the technology back then.


As far as I know, more than 1/2 of the C64 VIC is devoted to sprite generation and the sprite logic.

mc6809e 12 January 2020 16:27

The layout of sprite management bits in register space was a bit flubbed, IMO.

Manual mode would have been much more useful if horizontal position information for each sprite had been in a single register word instead of in two, and all sprite horizontal position registers collected together in a block of eight registers.

With such an arrangement the CPU could have been used to quickly move pairs of sprites to a new place on the same scanline with MOVE.L.

roondar 12 January 2020 23:06

Quote:

Originally Posted by wodan (Post 1371116)
What makes console sprites easier?

On consoles, you basically just get a whole bunch sprites* to do with as you please and you don't have to consider much other than what graphics to put in them and where on the screen to put them. There's obviously more to it than that, but that is the principle of the matter. On the Amiga, you also get a bunch of sprites to do with as you please in the same manner. But... There's only 8 of them without using multiplexing, and only 4 of them if you want more than three colours per sprite. They also have certain limitations when using a horizontally scrolling screen which the programmer will have to either accept or somehow work around.

With multiplexing however, you can get way more sprites on screen.

Now, multiplexing itself does not have to be hard per se, but it is certainly harder than just picking a free sprite number. It can also get quite tricky to multiplex correctly depending on your needs (just read what McGeezer wrote about Rygar AGA earlier in this thread - that is way more complicated than just setting up some sprite coordinates).

Couple that with the lower width of OCS Amiga sprites (16 pixels) compared to C64 sprites (24 pixels), Mega Drive sprites (up to 32 pixels) and SNES sprites (up to 64 pixels) and you can see it becomes tricky to use the sprites in such a way they are as useful as they can be. It gets a bit easier with AGA because the sprites can be wider (up to 64 pixels), but you're still limited in terms of how many sprites you get without using multiplexing.

*) depends on the console, but the Mega Drive for instance offers you 80 of them at the same time.

Quote:

Originally Posted by mc6809e (Post 1371138)
The layout of sprite management bits in register space was a bit flubbed, IMO.

Manual mode would have been much more useful if horizontal position information for each sprite had been in a single register word instead of in two, and all sprite horizontal position registers collected together in a block of eight registers.

With such an arrangement the CPU could have been used to quickly move pairs of sprites to a new place on the same scanline with MOVE.L.

I agree with that. For AGA I'd add the (IMHO) nearly criminal oversight of not offering manual mode sprites for 32 and 64 pixel wide sprites. That is such an annoying limitation. IMHO anyway.

Tigerskunk 13 January 2020 08:11

What is "manual mode"?

roondar 13 January 2020 08:28

Quote:

Originally Posted by Steril707 (Post 1371227)
What is "manual mode"?

Manual mode is when you use the Copper or the CPU to manually set the sprite registers (including the sprite data registers SPRxDATA and SPRxDATB) instead of setting sprite pointers and letting DMA do that. This can be used to get back the missing sprites when using overscan for instance, or to horizontally multiplex sprites (or to multiplex without needing an empty line between each image).

gimbal 13 January 2020 10:54

Quote:

Originally Posted by th4t1guy (Post 1370761)
I've never understood the obsession over Giana as I always viewed it as an embarrassingly cheap ripoff.

It is an obvious copy, but it's hardly a cheap one. It plays quite well.

roondar 13 January 2020 11:25

RE: Giana Sisters/Turrican

In the context of this discussion, I have to agree with Photon. When looked at from a purely technical level, these games are indeed objectively better games than Super Mario Brothers or Metroid.

This does not need to imply they are better games to play, by the way. That, however, would be rather off-topic to discuss here so I won't ;)

chb 13 January 2020 14:37

Quote:

Originally Posted by wodan (Post 1371116)
What makes console sprites easier?

In addition to what roondar wrote above, sprites on the consoles usually have more flexible palettes - on the OCS Amigas, the sprite colors are always from the 17-31 range, and have fixed palette indices per 3-color sprite pair. That makes it more complicated to use sprites in 32 color mode, or to use 15-color and 3-color sprites at the same time. Often on the consoles you can choose a palette per sprite (out of e.g. 4 on the MD) or even per sprite tile.

Also consoles mostly allow horizontal and vertical flipping of the sprites, especially the former is not easy to do on the Amiga and usually requires storing both directions.

roondar 13 January 2020 17:19

The following is somewhat, but not completely off-topic. It's more about me being a completionist than anything else ;)
Quote:

Originally Posted by Photon (Post 1370683)
Archimedes had nothing.

I'd like to point out that this is not fully accurate. The Archimedes does in fact have a single hardware sprite: 32 pixels wide and just like the Amiga of "any height". Also, just like Amiga unattached sprites, it's allowed 3 colours out of 4096. Using clever software it's possible to multiplex this sprite at least vertically (I'm unaware if it can be multiplexed horizontally though, I'm not really an Archimedes expert).

Looking at the specs, I'd personally guess the intention of this hardware sprite is to be used as a mouse pointer or similar.

I'll freely admit that it's probably not what Archimedes coders generally relied on for games though. I just thought it was interesting and figured I'd add it here in the discussion as we've been comparing sprite hardware between the Amiga and other systems here.


All times are GMT +2. The time now is 22:55.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.

Page generated in 0.06111 seconds with 11 queries