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?

[Piru]

@mr_a500

If you search Aminet now, there are a very small number of programs supporting dynamic-highres, SHAM or PCHG.

...and there ever fewer back then. There's your answer, I guess. 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).

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

[Merc]

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.  

I don't think it was usable for anything other than showing still images, for the same reason HAM wasn't used for many games, but it was very impressive at the time.

[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).

[Piru]

@mr_a500

Yes, maybe speed of conversion is one reason.

I was not talking about conversion speed, but displaying.

displaying dynamic highres is about the same speed of displaying a regular IFF (or a couple microseconds slower).

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, especially when combined with the highres 4 planes DMA drain...

[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.

[SamuraiCrow]

Custom copper-lists were used extensively in games but typically only the background color and possibly some sprite colors were changed to keep the copper from hogging too much bandwidth.  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.

Also, since AGA supported HAM8 in full super-high-resolution, the hardware solution solved much of the software kludging.  Secondly, using TrueBrilliance on the AGA chipset combined both techniques for better 24-bit resolution images.

[KThunder]

the problem was in the implementation. older programs sometimes changed more than 7 registers per scanline and that broke compatibility on some models. the copper has enough time to change 7 registers per scan line with no help other than setup from the cpu.
the problem with sham (sliced ham eg. lowres) was that it was designed for ntsc modes so it didnt work that great for pal.
when i frist found out about al this i thought it was great and downloaded developer docs and stuff on it but i didnt use them a real lot.
these images do look really good, but they cant do gradients very well.
pch was an effort to standardize pallete change stuff across all amiga models and display modes and it works really well. if you can find hamlab you can play around with it really easily because you can try different settings quickly and see how it all works.

[Piru]

@mr_a500

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)

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.

[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.

[Piru]

@SamuraiCrow

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.

That was likely to be bug of the application displaying the pictures. Copper needs special attention at vertical position 200 and beyond. Properly coded programs should have no problem with this, however.

[SamuraiCrow]

@Mr_A500

The Copper is a separate processor unto itself.  It has 3 kinds of instructions: move, skip, and wait.  Wait is executed by allowing the blitter to have the time that the Copper would have used if it were executing another instruction until the raster reaches a certain screen position.  Skip is usually used to skip over a wait instruction if the raster has already passed a certain position.  Move is the most common one: it pokes values into the custom chip registers.

The reason the system doesn't seem to slow down is becuase the custom chips have a separate bus called the CHIP bus with their own CHIP memory.  The FAST bus allows the CPU to continue processing regardless of the bandwidth conditions of the CHIP bus unless you have no FAST memory.

There are DMA channels on the Chip bus that are allocated according to usage.  Dynamic highres inserts a lot of Move instructions into the Copper-list (program) that is being executed so more bandwidth is spent by the Copper to execute these moves than if it were simply executing a wait instruction.  The more bandwidth is used by the bitplanes and the copper, the less bandwidth is left for the blitter and, if necessary, the CPU.

As a side-note:  Copper-chunky is a form of screenmode that changes color palettes as fast as possible on a 0-bitplane (1 color) screen.  Since there are no bitplanes in use, the blitter can execute its copy instructions directly on the Move instructions in the Copper-list which is much faster.

Unfortunately the Copper DMA only executes once every 8 lowres pixels on ECS therefore limiting Copper-chunky to 80x256x4096 PAL or 80x200x4096 NTSC.  AGA has a faster copper so it can do 160x256x4096 PAL and so on.

IMHO the ideal modern Amiga chipset would do nothing but Copper-chunky all the time and just optimize the Copper instruction set to execute faster with byteruns so it could copy multiple pixels to a queue with a single instruction.  It could even have a special byterun for emulating HAM8 mode if you wanted it to.  The only problem with this idea is that we'd have to figure out a way around an NVidia patent on graphics streaming and we'd be in the clear.

[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)

[jarrody2k]

Piru wrote:
That was likely to be bug of the application displaying the pictures. Copper needs special attention at vertical position 200 and beyond. Properly coded programs should have no problem with this, however.

It's little caveats like this that make me wish I devoted time to hacking around the Amiga system. If only I had more hours in the day I would have a crack at it!

[TjLaZer]

Wasn't Dynamic Hi-Res from NewTek? In Digi Paint from what I remember?