What is the reasonable config for SuperHires (1280x200x4) 3D games ?

[VladR]

Since I currently only have time to work on a 4 KB executable GFX compos, that's what I've been doing and recently got my EHB 320x200x64 codebase up&running for an OCS A500. This is working fine under WinUAE. After some clean-up, I'd like to upload a build and get it tested on real HW.

Last week, I was reading up on ECS and I got intrigued by SuperHires. It's quite a nice resolution for the time ! 1280x200x4. That's 4x pixels as my Atari's 320x192 (which was monochrome), but 4 colors (or more via Copper).

I got it up&running under WinUAE and since I already had code that was dealing with EHB's 6 bitplanes, switching to just 2 BPLs was easy. So, this is not just a what-if scenario, as I got the basics up&running and understand the work involved.

From my understanding, 030 is at the end of the non-060 performance group, so I was thinking a 25 MHz 030 would be a nice minimum config to run the demo (at, say, 7-10 fps, with cockpit HUD covering half of screen), with 50 MHz 030 being the target for playable framerate (say, 15-20 fps) and 040-060 providing option for 30-60 fps (full-screen, no cockpit HUD).

There's not a whole lot of precedent for this particular resolution, but given that the CPU is effectively butchered (due to DMA to about 54% of cycles per frame), we really only have CPU available during HBLANK/VBLANK.

Thus, after DMA, even a 50 MHz 030 barely provides minimum MIPS required to fill all those pixels. I reckon this is why this wasn't a popular resolution choice...

I wrote couple versions of the DrawPixel routine and I would like to run a benchmark to see how the last version with multiple LUTs (to avoid any multiplication and bitshifting for MaskAND + MaskOR).

Does anyone here have an actual physical machine with proper monitor (Multisync, I reckon, for 35 ns) capable of running this resolution?

[VladR]

I've attached a screenshot from Moire-like artifacts when drawing lines at full screen. That's a lot of pixels for ECS machine in 1990 !

The background contains all 64 colors that are possible in the SuperHires palette.

I wonder what they look like on real Multisync monitor...

My search for SuperHires on these forums didn't exactly yield a lot of results...

[Minuous]

Even more than the DMA issue, I suspect the reasons were (a) requires ECS and therefore leaves out all ICS/OCS users, and (b) superhires pixels are not easily discernable on an RF modulated signal.

[eXeler0]

Nice to see you’re back VladR.
Anyhoo, regarding 1280x200 or 1280x256 (PAL) is one of those resolutions that don’t make much sense unless you run in Interlace.
1280x512 is already a weird aspect ratio, as 1280x1024 is where it actually starts looking normal.
So I cant really remeber any good practical examples of this resolution. And as already mentioned, ppl were limited by quality of either TV signal or monitors.. Several limitations working against each other there.
On a similar topic, I used to think 640x256 could have been used in more AGA games.

[VladR]

Interlace ? That's automatically forcing flicker (30 Hz), no ? Although, I think I recall reading something about some amiga workaround for that (was it flicker fixer or similar?).

In 3D, the aspect ratio isn't a problem as you merely adjust your projection matrix coefficients so nothing is squeezed. Drawing Pixel Art for this res might be an issue, but ISO games would look great with 4x more detail. And you render the assets for an ISO game in 3dsmax/Maya, so it doesn't really matter that the aspect ratio is 4x stretched, it merely takes 4x as much RAM, but this is not a Jaguar with fixed 2 MB of RAM, plus you have a HDD, so space is not an excuse either. Not to mention that plenty OCS games often ask for more than 512 KB RAM anyway...

Especially screen-based ISO games where you redraw each screen upon entering it - this would basically make the performance penalty virtually non-existent.

I haven't yet implemented Sprites in either EHB or SHRES, but I reckon this mode should allow additional color via sprites just like any other mode, so with Copper, 16 colors per screen shouldn't be a problem for those games (especially if you have a classic 2D HUD Bitmap at the top/bottom of the screen).

It took me, like an afternoon, to get this mode up&running (though, I already had base EHB codebase working) - which is why I am puzzled why there aren't at least 3D games (especially on AGA, which should erase the DMA penalty via 4x Fetch mode) where aspect ratio isn't an Art Asset production issue.

But, you're right. I have not seen this mode in action back in the day, over RF cable...
Then again, back then, we weren't used to perfect square pixels from an LCD, so I am not sure if we would be even complaining about the image quality - which wouldn't be an issue with a Multisync monitor.


Especially for 3D games, there could at least be an option for the resolution, it's not like you need to rewrite the 3D engine - it's just couple constants, and even if you are a super lazy coder, with compile-time resolution constants sprinkled throughout entire engine, you can still simply provide a separate executable for this resolution, if you're too lazy to use variables for screen resolution...

[VladR]

I just checked my sources for Jaguar and I support about 7 resolutions. Took me about 2 days to implement full support for those resolutions (and it's a bit more involved given the GPU RISC doing rendering in parallel with 68000), and that's a gaming console, not a computer like Amiga that could have dozen different accelerator boards, RTG, etc.

Not to mention that there's a whole range of CPUs from 7 MHz 68000 all the way up to 68060, so one would think that supporting multiple resolutions for a 3D Amiga game is, basically, a basic requirement.

What am I missing ?

[lmimmfn]

Bottom line is you only have a maximum of 3.5 Meg per second Chipram writes with OCS/ECS and double that for AGA. Using super highres of 1280 is just going to kill performance on ECS.

It's similar to 640x256 4 bitplane performance in OCS which is awful(even just look at DPaint performance in that mode never mind trying to do 3D in it).

For 3D on these older machines without dedicated 3D hardware 320x256 or ideally 320x200 is where it needs to be.

BTW, last I checked, on ECS hardware 1280 super highres is only available with 2 bitplanes and if remember correctly the palette is limited to 64 colours only(I could be wrong on the latter part as its from memory and never had an ECS machine or limited an A1200 to ECS mode).

[VladR]

Originally Posted by lmimmfn

Bottom line is you only have a maximum of 3.5 Meg per second Chipram writes with OCS/ECS and double that for AGA. Using super highres of 1280 is just going to kill performance on ECS.

It's similar to 640x256 4 bitplane performance in OCS which is awful(even just look at DPaint performance in that mode never mind trying to do 3D in it).

For 3D on these older machines without dedicated 3D hardware 320x256 or ideally 320x200 is where it needs to be.

Correct, which is why I suggested 030@25 MHz as a min.req. to run the 3D game (at perhaps, 6-10 fps), 030@50 MHz at around 12-15 fps and 060 for 30-60 fps.

But, an ISO 2D game, where you only need to redraw couple tiles around player and enemies should be totally doable on lesser non-AGA configs.
At which point, even Blitter would be of use (especially for ISO tiles).

Originally Posted by lmimmfn

BTW, last I checked, on ECS hardware 1280 super highres is only available with 2 bitplanes and if remember correctly the palette is limited to 64 colours only(I could be wrong on the latter part as its from memory and never had an ECS machine or limited an A1200 to ECS mode).

Yes, but 64 color palette is plenty for flatshading. BTW, I attached screenshot earlier in this thread with the 64-color palette.

And if you start doing checkerboard fill (AB,AC,AD, BC, BD, CD), you suddenly have 4+6 = 10 "colors". Plus Copper. Plus Sprites (unless someone chimes here with proof that Sprites don't work in this mode on non-AGA configs).

The actual filling of triangles can be quite fast, as for 2 out of 4 colors, you write only to a single bitplane.

It does not get any faster than that on Amiga.


Besides, from experience, there were plenty monochrome games on atari at 320x192, so a 4-color mode is quite nice. But even at monochrome, the added detail created a very different experience. Which could be pushed further with 1280x200...

I could understand if this mode arrived 2 years after AGA (at which point Amiga was effectively dead), which would be too little too late.

But it's been here since 1990, hence my WTF.

[eXeler0]

Yes, it came in 1990 with ECS on A3000 which was the only Amiga to actually feature a built in scandoubler. So 1280x512 PAL Interlace was doable for text applications I guess.

[VladR]

So, the scandoubler removed the flicker ? You could have 1280x512, flicker-free in 1990 ? That's, like, almost a decade before PCs could start using that resolution. I think I was on Duron 750 MHz + GeForce 2 TI when I could play few games in that resolution, which would be around year 2000.

Still, thinking about it, even an ECS machine, could still pull off a simple 2D game with sprites in that res.

And you still had the VBLANK CPU time. Sure, that's not enough to redraw 1280x512, but more than enough to redraw small portions of the screen - so adventure games, strategy games and even simple platformers (with couple sprites) should run in that even on ECS, no ?
I've had plenty games that took 2-3 seconds to redraw screens (upon switching) on A800 and it was fine. I don't think anyone would complain about that in such extreme res.

[eXeler0]

I should probably drag out my A3000 and testbit because memory is flaky here, but It might have been that the Amber chip (unique to the A3000, and maybe some Commodore branded flicker fixer card) had a limit regarding Super Highres mode.
Might have been it only worked ”normally” up to highres. So then 640x512 de-interlaced to 31kHz would have been a thing + overscan but maybe not 1280x512

[Locutus]

I vaguely remember 'back in the day' my A3000 attached to a 17" CRT would produce nothing legible in SuperHires through Amber as far as a Workbench screen mode goes.

[AestheticDebris]

Yeah, I believe Amber effectively always works in Hires mode, so in Super Hi Res it just ignores every other pixel. It's also worth bearing in mind that the flicker fixer isn't really improving the resolution - it's just buffering alternate frames. That means your effective maximum frame rate is still 25fps and it'll also lag ever so slightly because of the buffering.

[VladR]

Originally Posted by eXeler0

I should probably drag out my A3000 and testbit because memory is flaky here, but It might have been that the Amber chip (unique to the A3000, and maybe some Commodore branded flicker fixer card) had a limit regarding Super Highres mode.
Might have been it only worked ”normally” up to highres. So then 640x512 de-interlaced to 31kHz would have been a thing + overscan but maybe not 1280x512

Nah, I wouldn't ask to drag the machine out. I know how that is. That's a pain.

Originally Posted by Locutus

I vaguely remember 'back in the day' my A3000 attached to a 17" CRT would produce nothing legible in SuperHires through Amber as far as a Workbench screen mode goes.

I can't imagine having to read text on 17" CRT in anything other than 640x480. For games, though, it's not an issue. You wouldn't use a 8x8 font for the game as a developer.

Originally Posted by AestheticDebris

Yeah, I believe Amber effectively always works in Hires mode, so in Super Hi Res it just ignores every other pixel. It's also worth bearing in mind that the flicker fixer isn't really improving the resolution - it's just buffering alternate frames. That means your effective maximum frame rate is still 25fps and it'll also lag ever so slightly because of the buffering.

Right, but removing flicker in itself is enough. There's great many demos on other platforms that simply do not get any enjoyment merely because of the interlace flicker. Amiga has a solution for this, which is great.

[redblade]

I know that going 640x480 would have been great for professional work, CAD, Word processor, IDEs but 1280x256 or 1280x512.. Was wide screen a thing back then?

I can only think of two Taito arcade games which went wide screen https://www.system16.com/hardware.php?id=653. They were Darius 2 and Ninja Warriors and both were ported to the Amiga. Both were released in 1989

[VladR]

Of course, it's not about widescreen.
You have much sharper 3D graphics as you have 4x more pixels.

I would argue that it might have made sense to great many people to use this res for word processing.

Instead of 40 columns in 320x200 or 80 columns in 640x200, you could have 160 columns using the same font.
Or, to increase readability, 128 columns with a 10x8 font.

I've known plenty people who used the standard font at 1280*1024 on PC on a 17" CRT. I'm sure they would not complain if they had this option...

[Samurai_Crow]

I remember playing ADoom on my A1200 with a Blizzard 1230 50MHz back in the day. It was playable at 320×240 in PAL, 320×200 NTSC was possible but the framerate was no faster. 640×400 NTSC or 640×512 PAL interlaced was just a slideshow on anything below an '040.

Also consider that the 4× page mode fetch rate only affected the display DMA. The blitter was still 16 bit fetching as was the Copper, making super highres graphics useless for games. AGA was half-done at release and never saw completion.

[robinsonb5]

Another thing to consider: very few (if any) LCD monitors will properly display 1280 horizontal pixels when connected directly to an Amiga.
They generally look at the incoming signal, guess how many pixels per line they're likely to see, and only sample that many times each scanline. The number of pixels they expect to see at 15KHz (or even scandoubled to 31KHz) is much less than 1280.

[VladR]

Originally Posted by Samurai_Crow

I remember playing ADoom on my A1200 with a Blizzard 1230 50MHz back in the day. It was playable at 320×240 in PAL, 320×200 NTSC was possible but the framerate was no faster. 640×400 NTSC or 640×512 PAL interlaced was just a slideshow on anything below an '040.

True, but textured 3D is only one subgenre of all 3D games (even if most popular). Setting aside how would Doom look with just 4 colors (Spectrum version comes to mind) , here's couple genres (from top of my head, I'm sure plenty more could be added) where low framerate is not an insurmountable issue:

1. Flight Sims
   - I recall playing Solo Flight on A800 in about 3-5 fps. Landing was still fun.
2. Golf games
   - Plenty games took 3-10 seconds to redraw the screen. Trees/grass in this res would look great!
3. Turn-Based action 3D games
   - doesn't matter framerate is 5 fps. Hell, I played such games on beefy PCs at sub-10 fps...
4. Submarine games from Microprose (Silent Service)
   - here the res is beneficial in zooming and seeing targets from distance
5. ISO games (Knight Lore-style)
   - redrawing only couple tiles during VBLANK around player/enemy.
   - ISO tiles would be rendered from within 3dsmax, so no human cost would be incurred in drawing 4x as many pixels.
6. Racing
   - given how abysmall framerate was in certain 3d driving games on A500, I'm sure 030@50 MHz could do better at this res.
   - And it's still just an option, player could always select 640x200 or 320x200 for higher framerate. In flatshading, the additional engine work is minimal to support higher scanline length fills.
   - It's not like it's either 1280x200 or nothing...

[VladR]

Originally Posted by Samurai_Crow

Also consider that the 4× page mode fetch rate only affected the display DMA. The blitter was still 16 bit fetching as was the Copper, making super highres graphics useless for games. AGA was half-done at release and never saw completion.

Yes, which is why I was proposing 68030.
Here's a quote from different thread:
https://eab.abime.net/showpost.php?p...9&postcount=28

Total DMA slots/cycles available (NTSC): 59212 (226 slots * 262 lines)
320x200x4 DMA slots used: 16000 ((320/16)*200*4)
640x200x4 DMA slots used: 32000 ((640/16)*200*4)

           CPU speed (full frame/NTSC)
320x200x4: ~100% (due to interleaving)
640x200x4:  ~54% (32000/59212)

Assuming I am getting this correctly, the DMA impact on CPU in 1280x200x2 (BPL) is same as 640x200x4 (BPL), hence the roughly ~54% figure of available CPU cycles on a non-AGA HW.
Am I correct here ?

A 50 MHz 68030 thus has about 50,000,000 / 60 = 833,333 c per frame at most.
54 % out of 833,333 is about 450,000 c. Of course, that number is still mostly hypothetical due to instruction stream decoding RAM access (and dozen other issues that were discussed in the thread above).
But, HBLANK and VBLANK time should be fully available to the CPU

I haven't done any benchmarking on real HW, as I don't have one, but I would hazard a guess that 3D transformations done during frame time might actually be faster brute-force computed on a 030, instead of CPU waiting half of a scanline to look up the number in the tables.

 CPU Cycles from the 68030.pdf
28 c: muls.w
44 c: muls.l
56 c: divs.w
90 c: divs.l

It probably could be computed, how many reads from RAM does a CPU get in a non-AGA HW in this mode during the 200 lines of DMA - meaning how much data can realistically CPU read/write (e.g. read 3D vertices, transform, clip, write 2D coords to array).

However, on an AGA HW, with 4xFetch mode, this DMA penalty should be gone, right (aside from slightly different batching which affects Copper, but not a big deal for CPU)?
So, would a CPU then get all DMA slots ? E.g. not just the 54%, but 100% ?
Because that would be a significant difference from 3D engine perspective.