The astonishing unpopularity of "dynamic-highres"

[mr_a500]

I remember reading a 1990 magazine with a small advertisment for "MacroPaint", a paint program which claimed to be able to display 4096 colours in high resolution without any add-on hardware. They showed two pictures and said "This is your Amiga on HAM...This is your Amiga on MacroPaint." The MacroPaint imaga did look like high-res HAM!

It sounded great, but I never heard anything about it after that and I couldn't find the program anywhere for 15 years. This year I finally got MacroPaint. The program isn't that great, but it does actually display 4096 colours in high-res (with some streaking). It's called "dynamic high-res" (also SHAM and PCHG) and is possible by changing palette on every line.

Then I found HamLab which can convert images to dynamic-highres. I started converting jpegs and gifs into dynamic high-res (and display with Visage) and it's amazing! Some pictures have problems with streaking, but about 90% of the images are waaay better than HAM or dithered 16 colour. Some pictures are so crisp and colourful, they look like 16bit! (now I'm converting most of my images to dynamic high-res on my A500)

So I'm wondering - why wasn't it popular? Why weren't there more paint programs or image converters to use dynamic-highres? AGA didn't come out until 1993 and dynamic-highres was around since 1990. It's unbelievable that for 3 years before AGA, there was the possibility to display 4096 colours in highres using software-only, but very few people were interested.

Was it the "dynamic-highres streaking" that turned people off? Digi-Paint allowed you to paint in HAM while minimizing HAM fringing, so it shouldn't have been hard to make a dynamic-highres paint program which minimized streaking. If you search Aminet now, there are a very small number of programs supporting dynamic-highres, SHAM or PCHG. Yes, AGA killed the need for dynamic-highres, but it had a whole 3 years to get popular and failed. Why?

[mr_a500]

...and there ever fewer back then. There's your answer, I guess.

That's not my answer - it's my question. Why are there so few? You'd think it would become THE way to display 24bit high-res images on OCS/ECS.

Another thing is that the palette changes would take considerable system resources (I guess it was done by using the copper, but still it would suck time from other stuff).

Yes, maybe speed of conversion is one reason. Still, I recall that all image conversion back then was slow - and people then weren't as impatient as they are now. You'd think they wouldn't mind waiting a bit longer for a much better image.

BTW, PCHG is the name of the IFF chunk for the "Palette CHanGes".

Yes, I know. It was Sebastiano Vigna's attempt to make a "new standard" for multi-palette (dynamic highres) images. I guess it didn't really catch on.

Merc wrote:
Well I seem to remember displaying those SHAM pictures would bring my A500 to almost a standstill, and any pull down menus etc brought over the picture would trash the image completely.

Displaying them slowed it down? On my accelerated A500, displaying dynamic highres is about the same speed of displaying a regular IFF (or a couple microseconds slower). Maybe the program you used to display it wasn't very good. I think I'll try it on my unexpanded A500 to check the speed. About the trashing - that's one drawback to dynamic highres. I know it's no good for games (except maybe static-screen graphic adventure or title screens). I was saying it should have been used more for displaying static images, artwork or for slideshows (instead of HAM).

[mr_a500]

And how did you measure this? I don't mean the decoding the picture and writing it to memory... that is pretty much as fast as regular pictures. The slowdown comes from the copper banging the colour registers, for the whole duration the picture is displayed. With stock A500 this would take pretty much all time from CPU.

If that is the case, then I have no way to measure it. I would need to open a CPU load monitor on the dynamic highres screen I am viewing because flipping to another screen to view the CPU load would mean the image is no longer using CPU time, right? (..and I just tested this: I opened Scout CPU monitor and it showed no usage for background dynamic highres image)

If dynamic highres was used just for image display (like in slideshows or static title screens), do you really need to worry about CPU usage? If back in 1991 you were running a slideshow, you wouldn't think of also running a huge CPU intensive program in the background at the same time would you? Amiga was a "multitasking" computer of course, but with limited memory and CPU speed of the time, most people "monotasked". In this case, using most CPU for image display wouldn't be a problem.

[mr_a500]

Also, the SHAM file format was hard-coded to a vertical resolution of 200 pixels IIRC and therefore didn't look right on a PAL screen.

Yes, that's what I read, but I've been displaying SHAM images with 1024 vertical pixels on a scrolling screen with graphics overscan of 232 vertical height (NTSC). Maybe the program I'm using to display the images (Visage) is doing something to overcome the hard-coded limit. All I know is that the image 800x1024 displays perfectly fine.

Does anybody know of any games using static dynamic highres screens? The "Agony" title screens look like dynamic highres, but they might be just very well made 16 colour highres.

[mr_a500]

This doesn't show up in CPU usage like that. The whole system is slowed down, it doesn't take CPU time for the task displaying the image.

Then the only way to measure it is to run a CPU intensive program in the background.

I know for sure that it has no effect on screen flipping and that's all I really need when displaying a bunch of images. I like to open 10 images or so on their own screens and flip between them. There is no (or minimal) difference in speed in opening 10 IFF or 10 dynamic-highres and flipping between them.

By the way, in case anyone's interested in dynamic highres: the best (only) conversion program is HamLab (version 2.1.0 has been made freely available by the author) and the best viewer is Visage. If you experience corruption when scrolling large images, try lowering the number of palette changes when creating the image (7 or less). Also, a different graphics overscan (for display) sometimes helps.

Other programs compatible:
Viewtek
AdPro (loads but does not save any dynamic highres format)
Mostra (doesn't seem to work with SHAM)
MacroPaint (does not load PCHG, does not save SHAM)

(please let me know if there are other good dynamic highres compatible programs ...except 2View, DynaShow, Shazam)

[mr_a500]

Digi-View 4.0 could create dynamic highres, but not Digi-Paint. It would have been awesome if Digi-Paint 3 could handle dynamic highres. I wonder why they didn't add it.

Were these formats not all the same though ?

The true "Dynamic Hi-Res (TM)" is by NewTek and does not display properly in Visage or Viewtek even though they display SHAM and PCHG. MacroPaint will only load SHAM and Dynamic and saves Dynamic. I think there are also a few other filetypes called AHAM, ARZ0 and ARZ1 (but they must be very old and obsolete because I've never heard them mentioned anywhere except in a HAM-E advertisement).

When I'm saying dynamic highres, I'm really talking about all the formats, not just the NewTek one.

[mr_a500]

I just did some speed tests to see how much the system actually slows down while viewing dynamic highres. I converted a jpg (CPU intensive task, I assume) with HamLab from Workbench screen without viewing it, then I converted the same jpg while viewing a 594x594 dynamic highres image in Visage and timed with a stopwatch. I set HamLab to beep when finished so I would know when it finished while I was viewing the dynamic image. I did three tests:

(in seconds)
No dynamic: 34.81  Dynamic: 35.02
No dynamic: 34.88  Dynamic: 35.04
No dynamic: 34.71   Dynamic: 34.96

As you can see, there's only a slight difference and this could even have been caused by flipping to the dynamic highres screen.

Then I tried the same thing on my Amiga 1000 (stock except 1Mb RAM), except viewing a 640x400 image in Shazam (Visage doesn't work in WB1.3) and converting a smaller jpg in HamLab. It was a whole different story:

No dynamic: 2:48.01  Dynamic: 6:42.38
(I only did one test because it took too bloody long)

So, the lack of "dynamic highres slowdown" on my A500 must have something to do with my upgrade (maybe Fast RAM?). Still, viewing a 640x400 dynamic highres image on an A1000 took "only" 7 seconds (and looked totally amazing for a 1985 computer!), so I still think dynamic highres should have become the standard for viewing high-colour highres images on the OCS/ECS Amigas.


@SamuraiCrow
Thanks for the detailed info. :-)

[mr_a500]

Forget the NewTek demo. Lots of old NewTek stuff crashes on my upgraded A500. Just get a copy of HamLab and load any jpg or gif (or even the NewTek image) and you'll have no problem.

[mr_a500]

I just found another great use for dynamic highres: displaying screenshots containing copper "rainbows" (game or Workbench screenshots).

Example: my "Rainbow Mania" screenshots (on Amiga.org) have blue copper rainbows in the background. I had to take the screenshots with WinUAE because there is no possible way to capture the rainbow on a real Amiga. When I then try to display the screenshot on my real Amiga, it can't be displayed at the resolution it was taken at because the copper rainbow uses up more colours than should be possible at that resolution. So, I can only view the highres screenshot in lowres HAM.

But with dynamic highres, I can view it in highres and still see the copper rainbow. Converting with HamLab (dithering off), it is nearly perfect. I say nearly because the original must be saved as gif and gif uses fixed 256 colour palette missing some colours the Amiga has (and jpg is "lossy"). Oh I wish HamLab could load PNG!

Edit: What am I thinking? I can just save the original as 24bit ILBM. duh.

[mr_a500]

Use jpeg quality setting of 100% ?

I already did. It still had artifacts after converting to dynamic highres.