Demos using a GFX mode please !

[Crumb]

@Darkcoder

the usual HAM8 is a planar mode. The 18bit HAM8 is a technique to do a sort of truecolor chunky mode. (yep a fake one, as Agony says)

I know that HAM8 is a planar mode... what I want to know is why no one has done a routine that converts
a 24/16bit chunky pixel fastram buffer to lores planar ham8 screens. TurboEVD uses a HAM8 mode to display modes like 640x480 in pseudo 15bits. TurboEVD seems to have done it without using a SHIRES screen mode.
I'm not talking about putting 1 Red 1 Green and 1 Blue pixel in SHIRES very near to fake a 24 bit mode, I'm talking about a screen where each colour depends on the previous pixel... a ham planar one. And a routine that turns a 16bit or 24bit chunky buffer in a ham8 planar screen. Chunky to planar but using more colours in the buffer and ham8 in the screen. Now am I explaining better what I want to know?

@crumb
because may be slower. and, if deltas from one color to another is big  (you can change only 1 component at time) you don't know the result ( in lowres for sure). if you use a hires display the difference may not be so noticeable, but you double writes and calculation from each pixel. oh,  you may use the 64 "real" color from the palette in lowres to adjust the difference, but calculating the best or an acceptable palette for each frame is  very very slow. try for example to convert a 32bit jpeg to an ham8 screen in PPAint....  

[darkcoder]

with ham8 you can change only one component of the previous pixel. So if you have two pixels close to each other with 2 different components you are in trouble. Es
$ff00ff  $ff8888. You can use a "base color" for the second pixel, i.e. not define the second as a difference from the first one. But you only have 64 base colors, so you can do this only 63 times (the first color of the display have to be a base, I think (well, never tried a HAM display starting with a "changed" color...don'tknow what will happen)). Well, of course you can use copper to change the value of base colors.
But then you need a dynamic copperlist which is very complicated to build. And since copper is "8-pixel slow" I can provide easily an example of rasterline which is imposible to exactly reproduce in HAM8: (all values in hex 24bit)
00000 010101 020202 .... ffffff
It is only 255 pixel long, but you cannot obtain any pixel from the previous one. So the first 64 pixel you use all the 64 base colors. During that time you can only reload 8 color registers, so you have enough till color 64+8. During the extra 8 pixel you gained, you can even reload another color register and gain 1 extra pixel. But then it's over!
You can do an approximate conversion to ham8, i.e. changhing color a bit. Ex say you have
008800 00cc33 here 2 components change, you need to use a new base color. But if you transform the 2 pixels in 008800 00cc00 you change a bit the picture but you don't need a base color. I am not expert of color conversion algorithms, but I suspect as Agony says that they are not very fast. You have to analyse all the color used in the picture, make calculation, divisions..
anyway I'll give a look at Aki's work! maybe there is some possibility I don't see.

[Karlos]

Hi all,
All this AGA HAM-8 technical stuff, whilst most interesting, is melting my head slightly ;-)
I realise that this has probably already been answered, but is it possible to create a reasonable emulation of a 15 or 16 bit display? Something that could be refreshed quickly enough for a low resolution (read 320x256) game-like app?
Also, could it be coded such that it  that can be used in conjunction with os legal code?

-edit-

It's kinda funny, early on in this thread people worrying that the demo scene is dead/dying etc. Just look at how big this thread is now :-P

[Crumb]

@Darkcoder&Ag0ny
thank you for your explanation. The rasterline example is very good to show the limitations of the ham mode.

Umm remember the values of chipram speed given by that URL? In the TurboEVD documents Aki shows the difference of chipram access speed using different screenmodes, it's quite interesting.
Screen mode Speed in MB/s
PAL: Lores 320x256x2 6.2 MB/s
PAL: Lores 320x256x256 5.2 MB/s
DBLPAL: Lores 320x256x256 4.2 MB/s
PAL: Hires Lace 640x512x2 6.2 MB/s
PAL: Hires Lace 640x512x16 6.0 MB/s
PAL: Hires Lace 640x512x256 4.3 MB/s
Multiscan: Productivity 640x480x16 5.7 MB/s
Multiscan: Productivity 640x480x256 2.1 MB/s

I don't know what machine he used for testing but it gives a good idea about how AGA performance drops when you increase the resolution.

The speed Aki achieves with his ham8 mode is only a bit slower than using a normal 8bitplane screen in shapeshifter... without using the compare buffer it may be even faster.

@Karlos
I don't think that it would produce a perfect picture in lo-res, but it seems to be 100% system friendly and is quite fast...

[Karlos]

Ooh,
If 320x256x8-bit gives 5.2 MB/s, isn't that actually a bit faster than Zorro-2? So does AGA outperform Z2 graphics cards for direct writes to video ram?

I wonder what my BVision gives in a comparable resolution...

[MagicSN]

Yes, AGA actually does outperform Z2. (*Z2*, note... )

darkcoder:

Firewire would only be relevant if there would
be Drivers (Also it could get added as
PCI Card to A1 if really needed).

As to the price: OS 4 is included in the price, remember this also.

Interested in AGA ? Sorry if this sounds arrogant,
but this sounds like a terrible waste of time
to me. I explained several times that with AGA
a lot of people cannot use your demos... so any
AGA Support should be optional at best.

And I think if there are two option where one (AGA) does not give ANY major advantage (and it
doesn't !!!), and RTG Support would also make
demos run on

a) more current systems
b) AmigaOne

RTG support should be used (And AGA at most optional).

Steffen

[darkcoder]

@magicSN

Do you mean that I can add a Firewire interface to an A1 *for free*?? :-D
Os 4 is included in the price but...they don't give it to you because it is no ready! I don't like to pay today for something I will receive in ?? months. And note that the OS4 is included *only* in the earlybird *special* offer.

I think that my best time is the one which i spend enjoying myself. Since I enjoy coding AGA, for me it's not waste of time. Your posting would sound much better if you add "in my opinion" somewhere in between. Your words sounds like orders.
I already explained that for me and my work AGA has many advantages so nothing more to say..