The Cray you're describing there is nothing but a block of pure processing power. You're not describing any sort of input or output, so the question is very vague. You could put any sort of rendering front-end onto a generic computer like that:
- Older 8-bit home micros could have bitmap modes, or tile modes with sprites, or some combination of these, making them a lot more console-like than computer-like.
- Bitplaned graphics like the Commodore Amiga series OCS chipset. Memory efficient, but requiring finesse to draw arbitrary graphics.
- Chunky graphics like 320x200 13h VGA. Accessible, easy.
- A fully-hardware accelerated graphics card capable of hardware transform and lighting etc. The processor lines up the shots and the graphics card takes them.
I'm going to assume by the way you're mentioning the memory size and computational throughput, you want to know more about the software rendering capability of a computer of that level of sophistication, which sounds to me a lot like how DOS games were rendered into VGA-style chunky output.
Let's take a typical early-nineties VGA card and attach it to our Cray. Something like the Trident TVGA9000C (http://old.vgamuseum.info/zaatharens-collection/69-trident-microsystems-inc/1129-trident-tvga9000c.html). It's got a flat framebuffer, with no acceleration whatsoever. No block image transfers (blits), no hardware scrolling beyond a couple of coarse register tricks. It's just a rectangle of memory in the Cray's memory space linked to a 256-colour palette.
Now we can have a look at a couple of DOS games:
Here's the minimum requirements for Quake in DOS. https://gamesystemrequirements.com/game/quake
IBM PC and Compatible Computers
Pentium 75 MHz processor or better (absolutely must have a Math Co-Processor!)
VGA Compatible Display or better
DOS -- 8 MB RAM required
CD-ROM drive required
Hard Drive Space Needed: 80 MB
That'll get you 75 fps 256-colour palettized 320x200 3D graphics with some lighting effects. That's all software rendered in DOS Quake.
Here's the minimum requirements for Jazz Jackrabbit in DOS. https://pcgamingwiki.com/wiki/Jazz_Jackrabbit
Operating system (OS) 5.0
Processor (CPU) Intel 386 33 MHz 486
System memory (RAM) 4 MB
Hard disk drive (HDD) 13 MB
Video card (GPU) VGA
Sound (audio device) Gravis Ultrasound, Sound Blaster, Sound Blaster Pro, Sound Blaster 16, Pro Audio Spectrum 16
Controller Gravis Gamepad or generic joystick
Jazz Jackrabbit is a very console-like game with tiled backgrounds, sprites (let's say 64 16x16 sprites going around if there's a lot of bullets, explosions and enemies), software-mixed music. The game offers levels of detail settings, which I believe affects things like coloured sky, amount of explosion sprites, etc.
Jazz also has a 3D bonus stage section that resembles SNES Mode-7 graphics with overlaid sprites, with Jazz running around a flat but textured landscape in pseudo-3D collecting floating gems.
All that fast math is going to be a great help for these games!
Let's move up a level to the original Unreal: https://wiki.beyondunreal.com/Legacy:Unreal
Operating System WIN 95/98/NT/Linux
CPU Intel Pentium 166 MHz
Memory 16 MB RAM
Hard Disk Space 100 MB
CD ROM or CD/DVD ROM 4x
Audio System Windows® compatible sound card
Video System Video Card 1MB
Unfortunately, the Cray isn't going to cut it software rendering Unreal. It might be able to do a low resolution mode or something, but it won't be pleasant.
Here https://www.alternatewars.com/BBOW/Computing/Computing_Power.htm the FLOPS of a Pentium 100 is given as Benchmarks: 0.09 GFLOPS (i.e. 90 MFLOPS).
You said:
The system had limited parallelism. It could issue one instruction per clock cycle, for a theoretical performance of 80 MIPS, but with vector floating-point multiplication and addition occurring in parallel theoretical performance was 160[11] MFLOPS.
So, as a back-of-the-envelope, like-for-like comparison of the various attributes, as a computer, it resembles a 1994/5/6 DOS 6.22 machine. I'd say you'd be playing Jazz Jackrabbit, Quake, Need For Speed 1&2, Theme Hospital, Dungeon Keeper, Sim City 2000, Tomb Raider, Little Big Adventure, Abe's Oddysee and Command & Conquer on your Cray - DOS machine.
And, looking at that list of games, what console does it most closely resemble in visual output power for real-time gaming? A PlayStation 1.
But depending on how things work out in this fictional computer - I'd say it would be heavily fill-rate limited due to the memory rather than the processing power. For either 2D or 3D, there's going to be lots of copying backwards and forwards of blocks of memory.
For purely 2D output, it'd be juicier than a SNES I would say, since there are SNES emulators for DOS. Other 2D consoles it would be able to completely encompass: Spectrum, C64, Master System, NES, Amiga 500/1200/CD32, Mega Drive, PC-Engine.
I'd say it would be within ±20% of what a Neo Geo's display hardware can do, in terms of independent layers and sprites. https://en.wikipedia.org/wiki/Neo_Geo_(system)
Here's a video of Metal Slug on the Neo Geo AES: https://www.youtube.com/watch?v=qsMWIbnKrqk
Your entirely-software-based rendering system would have no restrictions on layer or sprite size since they'd just be (masked) rectangle copies. The limitation would simply be how much memory assignment power (i.e. the fill rate) was available. Rotating and scaling sprites in software would be a large cost - to be avoided by prescaling in advance when the game assets where made, or just-in-time scaling in memory before whatever scene needed them began.
(Bear in mind that the Neo Geo uses cartridges to contain all the source graphics. Would your hypothetical Cray-console have that?)
Edit - Addressing alephzero's comment:
All this is probably an overestimate of the Cray performance for this type of application, since memory was word (64-bit) addressable only, there were no 64-bit integer machine code instructions, and there was no "quick" way to do anything with 8 or 16 bit data. The maximum performance (in reality 132Mflops not 160, because of vector start up overheads) was only possible with 64-bit floating point operations on vectors that were a multiple of 64 elements long, which is pretty irrelevant for a video game. "Scalar" performance was typically about 5 Mflops, not 132
You're right alephzero, insofar as the values 80-160 MFLOPS are at maximum, fully-populated vector performance, and that outside this ideal, the scalar performance would be low. However for many kinds of 2D games under DOS the amount of decision-based, highly-branching computation is pretty low. Assuming again that the asker is interested in shmups, fighting games and other Neo-Geo-like titles with large bgs and sprites, there's going to be a lot of predictable, repeated, direct rectangular copying going on. Since the Cray-1 has a "memory-memory" (see Wikipedia) architecture, the vector instructions will be ideal for block memory reads, masks and copies!
The vector operations are not necessarily floating point: they can be scalar. The following operations can be performed by the scalar logical units with their contents populated, advanced and written to memory by the vector system. (See 2240004 3-11 C in the Cray-1 Hardware Reference Manual http://ed-thelen.org/comp-hist/CRAY-1-HardRefMan/CRAY-1-HRM.html#p3-3) Sure, this might be not particularly great match for the interface of the standard VGA card I described, but for the case of getting values around from one place to another, it would be somewhat helpful.
The contents of a V register are transferred to or from memory by specifying a first word address in memory, an increment for the memory address, and a length.
From the sounds of that, it might be possible to have these vector operations working on a byte granularity, satisfying the use of a VGA card in 13h with chunky pixels. (And if not, then you'll have to use word-aligned sprites perhaps?)
Unmasked direct rectangular blit:
DEST = SRC
The contents of the lines of graphics within SRC overwrite those in DEST.
This is what you could use for filling the screen, drawing rectangular layers where the underlying content is unimportant, or drawing rectangular objects. (Alternatively, you can use it as a scrappy way of drawing sprites if you don't care about weird corners disappearing.)
Masked rectangular blit:
DEST = DEST & MASK
DEST = DEST | SRC
Where MASK contains all 0s in pixels occupied by visible pixels of the sprite (that should be erased before the sprite is copied) and all 1s where the sprite is transparent.
This will let you draw graphics while keeping the background intact, for sprites, GUI elements, etc.
Also, note the following:
A result may be received by a V register and re-entered as an operand to another vector computation in the same clock period. This mechanism allows for "chaining" two or more vector operations together. Chain operation allows the CRAY-1 to produce more than one result per clock period.
This means that the operation DEST = (DEST & MASK) | SRC could be performed without the intermediate write to memory taking place.
More complicated algorithms for texture mapped graphics might benefit from the vector floating point performance as the pixels of a textured/shaded triangle are drawn in a vectorisible fashion.
