The astonishing unpopularity of "dynamic-highres"

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

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

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

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

[Piru]

@mr_a500

jpg is "lossy"

Use jpeg quality setting of 100% ?