Most objects on screen at same time in 16 bit era, think Amiga might win

[Amigajay]

Originally Posted by dreadnought

The Intel Guy strikes again


People in the Nineties:
People in the New Millenium:

Something can be slow and playable, just something can be fast and unplayable.

Yawn. These complaints were made about SNES games in game reviews at the time.

[dreadnought]

Originally Posted by Amigajay

Something can be slow and playable, just something can be fast and unplayable.

Nah, it's more like "if it happens on Amiga, it's ok, on any other platform it's terrible".

Originally Posted by Amigajay

Yawn. These complaints were made about SNES games in game reviews at the time.

The complaints were made, because it's perfectly normal to mention minor flaws (not to mention that slowdowns were also a thing to be expected on many powerful arcade boards) - alongside the mostly stellar +80% scores. It's only in modern times that these things have been hyperbolized, mostly by social media users who can't let go of old tribal beefs.

[buzzybee]

Originally Posted by Amigajay

Btw i don’t think console games were mostly 50fps at all, alot of 16-bit era were 30/25fps going into the Sat/PSX era too, with some exceptions of course.

As long as the game was playable, 17.5/25/50fps matters not, Snes seu’s were notorious for slowdowns when alot of stuff on-screen.

Quite simply No. I was responsible for taking screenshots at magazines that covered Amiga and consoles in the 90s. I can tell you that it was much more difficult to shoot MD and SNES than most Amiga games, as consoles mostly kept a refresh rate of 50 fps. This halves the time to shoot and store a picture compared to a 25 fps game. Keep in mind that in these old days, one could not simply record a pixel perfect video, and then grab the most beautiful moments like today. Back then, every single screenshot was hard labor. Video output expertise was essential.

Originally Posted by dreadnought

Nah, it's more like "if it happens on Amiga, it's ok, on any other platform it's terrible".

Exactly. Even in its slowest moment, Super R-Type keeps higher framerate than many "classic" Amiga shmups, like Xenon 2 and Blood Money.

Besides, the term "framerate matters not" simply does not compute when discussing visual tech stuff like object count or fill rate.

[AestheticDebris]

Some games can be slow and still fine (because they're more cerebral) and some games work better when they're as responsive as possible (reaction based shooters etc).

But that's a little bit beside the point. If you're trying to get some metric for "most objects on the screen" you sort of need some kind of benchmark time period for managing those objects or comparisons become meaningless. There's no real limit for how many objects you can have on the Amiga screen, if you're happy to be measuring in Frames per Hour.

It doesn't really matter if pick a frame rate of 50fps or 17fps to compare, although consoles will probably skew towards being better at high frame rates and the Amiga better at lower ones (because consoles start being bounded by sprite hardware where the Amiga is only bound by drawing time).

[AestheticDebris]

Originally Posted by buzzybee

I can tell you that it was much more difficult to shoot MD and SNES than most Amiga games, as consoles mostly kept a refresh rate of 50 fps. This halves the time to shoot and store a picture compared to a 25 fps game.

Partly this is because "frame rate" is often a misnomer on these old machines. Unlike a PC (and to some extent the Amiga) each frame isn't composited in advance and then all updated as one.

Half the sprites might move on odd frames, the other half on the even frames. This leads to the frame changing at 50fps, although the game only really plays at 25fps. And that's before you start getting into games that move the main player sprite every frame, but enemies only every few frames etc.

[roondar]

I do agree that any max object count should be considered only for games running at full framerate and without slowdown. On both Amiga and other systems. And of course, without tricks like 'only update half the Sprites every frame'.

Edit: I removed the off-topic part of my reply, as I don’t feel it’d have led to useful discussion.

[bluescrn]

'Max object count' is a silly metric

There's numerous demo effects creating starfields and tunnels out of large numbers of dots. The Amiga did pretty well there, as dedicated demo coders spent many years trying to push the limits of the machine.

But in terms of moving useful-for-games objects around, an unexpanded A500 or A1200 just couldn't keep up with the SNES or Megadrive, they simply had more capable sprite+tilemap hardware designed specifically for making impressive 2D games.

[oscar_ates]

Arcade machines have also amazing hardware capabilities on sprites. Otherwise cpu of the arcades were not that powerful

[CCCP alert]

Game engine frame update for display is only part of the story of 'arcade quality', how often you measure controller input and what you do with that input is the whole story. You don't need 50fps etc sure, you do need consistency though.

Dual developments that share this section of code with ST and Amiga, usually written with a compiled high level language (or bespoke tools in the case of Cinemaware), are where the problem occurs because of inconsistency not actual final frame rate.

And that's really what 'console' or 'arcade quality' really means, it's frame locked consistent game engine that connects screen update with controller input with you doing the interfacing between the 2.

[lionagony]

I was playing NY Warriors last night and forgot just how intense a game it is. It's almost a bullet hell at points with the amount of stuff on the screen. Take for example 20:45 onwards here [ Show youtube player ] Not sure if there was slowdown on real Amigas but it's pretty darn impressive, especially for 1989 when it was made, the Arcadia ROMs say 1989 but the regular Amiga version didn't come out until 1990.

[CCCP alert]

Personally, I find the actual mb/s throughput of all bitmap graphics (inc sprite pixels) more useful than a woolly vague term like most objects on screen.

I think it was either ACE or TGM magazine that mentioned the Acorn A3xx/A4xx series of Archimedes had enough grunt to update the entire screen multiple times per 50th of a second etc, that is more useful to know than demo coder type "10000 Bobs on screen" etc IMO.

The only time max onscreen objects come into play is probably in bullet hell shmups, so systems that have massive hardware sprites can't really use them for bullets, don't know enough about the MD/SNES to know how they get around the issue, naturally a blitter is better in this situation as it just comes down to chipset bandwidth/hz

[AestheticDebris]

I know what you mean but MB/s is very much based on the assumption you are actually drawing something. For example, the bullet hell type shooters on a console will typically just multiplex sprites to manage the bullets - which might only require updating a couple of bytes per bullet, which is much less than the equivalent of actually having to draw them using a blitter. And the kind of tile based displays they use are far more efficient than raw bitmaps (for the kinds of 2D game we were mostly playing), so again they need to spend much less MB/s to achieve better results

[roondar]

Originally Posted by AestheticDebris

I know what you mean but MB/s is very much based on the assumption you are actually drawing something. For example, the bullet hell type shooters on a console will typically just multiplex sprites to manage the bullets - which might only require updating a couple of bytes per bullet, which is much less than the equivalent of actually having to draw them using a blitter. And the kind of tile based displays they use are far more efficient than raw bitmaps (for the kinds of 2D game we were mostly playing), so again they need to spend much less MB/s to achieve better results

While this is certainly true, as always, it is more nuanced than just having HW Sprites on consoles vs the Blitter on the Amiga.

As it turns out, both the Mega Drive and SNES GFX chips actually have quite a bit more bandwidth than the Amiga custom chips do (apart from AGA's 4x bitplane/Sprite fetch speeds, which are competitive with them). The exact speed for the SNES is not so easy to find, but the MegaDrive VDP has 13MB/second of bandwidth to VRAM, which is nearly 2x what the Amiga custom chip set can manage - and it doesn't need to share any of that with the CPU due to it's dual ported design.

It gets even more complex when you realise that OCS Amiga HW Sprites theoretically max out at something like 0,25MB/sec, yet can be multiplexed vertically as often as you like - through the HW, so no special tricks needed. Which can in turn lead to quite a few 'bullets' being dealt with by just the HW Sprites if that is what you want to so. Sure, you'd be limited to 8 bullets per scanline, but even so, you can still do a lot of bullets that way.

Just for fun, here's a back-of-the-envelope example: if bullets are 8x8 pixels and you'd want at least 8 pixels vertically between each bullet (which is quite restrictive), you could use just the HW Sprites on OCS to get 128 bullets on a 256 pixel tall screen - for virtually no DMA or CPU cost. And all that can be done using the built-in HW multiplexing, no need for special Copper trickery. Of course, some caveats apply here and you'd pretty much need to specifically design bullet patterns very specifically so that this will work, but it's still possible.

Like on the consoles, at that point the real issue is more one of calculating new positions, collisions and updating the bullets. Not so much the drawing time.

[Lilura]

no. of on-screen Bobs/sprites:

Battle Squadron of 1989: 50+ objects
Datastorm of 1989: 128 objects
Sidewinder 2 of 1989: 80 objects
Wings of Death of 1990: 90 objects
Anarchy of 1990: 80 objects
Mega Typhoon of 1996: 100+ objects (runs on original hardware)

[CCCP alert]

I only know of Battle Squadron being on both Amiga and MegaDrive, not sure if it is more graphically intense but the sonics are not good vs Paula audio. Probably look more or less the same I bet as the MD has 31 colours for tiles and 15 for sprite layer IIRC and nobody would re-do all the art just to utilise the extra 14 possible colours due to the different architecture. Only intense arcade game I can think of on Amiga, MD and PC-E is Shadow of the Beast 1 but couldn't say which is pushing the most pixels about off hand.

[buzzybee]

Originally Posted by Lilura

no. of on-screen Bobs/sprites:

Battle Squadron of 1989: 50+ objects
Datastorm of 1989: 128 objects
Sidewinder 2 of 1989: 80 objects
Wings of Death of 1990: 90 objects
Anarchy of 1990: 80 objects
Mega Typhoon of 1996: 100+ objects (runs on original hardware)

For such a comparison to be meaningful, you should limit the table to games using the same framerate. For a fair result, this framerate can only be 50 fps on Amiga, as console games typically run at 50 fps. This eliminates almost all Amiga games in this table, except for "Mega Typhoon".

It's obvious that Amiga games that run on 20 or 25 fps can move and draw many more objects at the cost of flow and responsiveness.

Btw. "Reshoot Proxima 3" sometimes displays close to 100 moving objects @50fps, of which most are based on DMA multiplexed sprites.

[dreadnought]

Originally Posted by buzzybee

For such a comparison to be meaningful

"Meaningful" and "fair" are noble ideas, but they would make most of these threads 1-2 pages long max