Wolfenstein 3D IS technically possible on stock A500 shocker!

[Louis Dias]

Planar is good for certain things.  Fades to grey.  HAM.  For a planar chip to be efficient, it would need to be triple-cored...so that each core could handle one of the three primary colors.  That is the only way to get the speed out of it.

Amiga's bus is 3.57MHz.  Early Amigas only move 16 bits at a time.  I think the 3000 had a 32 bit bus.   The reasons accelerators make just a difference in procession is the memory is 32 bit and the memory bus is faster to the cpu.  It's not just the cpu that gets a bump in clockspeed, but the memory over the stock Amiga is greatly improved.

In the end, Amiga's pixel-pushing capabilities can be measured by it's memory bus.

I think the only change in the memory bus over the years was making it 32bit instead of 16bit...which moves twice as much data though at the same speed.

DRACO is considered an Amiga-compatible machine and it features a memory bus that can move 30MB/s.  An A500 moves 3.57MB/s.  See the difference?  This is why RTG works good on Draco...a fast memory bus.  Natami's bus will be capable of 3200MB/s using DDR2-400 memory, fyi.  Minimig used SDRAM, fpgaarcade uses DDR1.

To get back on topic...
An A500 can probably run a World of Warcraft client.  But at some point you got to ask yourself what you consider 'acceptable'.  Saying you can run Wolfenstein 3D on a C64 is nice but when you think about the 1 color 32x32 resolution, you really have to ask yourself if it's worth it.  'Ports' are only worth it if the difference in the end result between platforms is 'small'.

Good ports will allow the small sacrifices to happen but also improve areas where the new platform can excell.  So for instance an Atari ST game might feature gread sound and good graphics but on the Amiga it would have great graphics and good sound.  See the difference?  Accept the differences.  Know when to draw the line.

[Louis Dias]

I have no idea how you came to this conclusion. HAM would be a lot easier to address had it been chunky/packed pixel. Fades to gray is a matter och changing the palette, not shuffling bitplanes. In 4, 8bpp or higher, I can't see any particular application which benefits from planar format, except maybe for some low fi transparency effects.

HAM is unnecessary in other formats.  To change a color in a planr mode, you have to update 3 bit planes.  It doesn't matter how many bits per plane you've dedicated.  With chunky format you only need to update 1 plane every time.  All HAM does is hold 2 planes fixed and changed the 3rd.  This is why sometime you need 2 or 3 pixels to change colors horizonatally...

What can be limited on chunky displays is the pallette.  HAM eliminates the limited pallette but you can only change the 1 color plane per horizonatal pixel.

In HAM is you have a black pixel(0,0,0) and you want to make the pixels next to it white, you have to change the green plane from 0 to 255, then next pixel you change red from 0 to 255, then finally in the third pixel you change blue from 0 to 255 and it finally looks white where as the first looked green and then it looked yellow.

http://en.wikipedia.org/wiki/Hold_And_Modify

So HAM opens your full pallette but limits how significant the color can change from pixel to pixel.  HAM is good for real-life images but not good for precise displays such as a sharp-edged desktop.

If Amiga's display resolution got up to 1920x1080p, BUT we were limited to 4MB of video ram (6MB is required to display that resolution in 24 bit color).  HAM would be useful to fill that display if the chipset was capable of doing HAM.  Does that make sense?

HAM allowed you to do more colors with less memory.  In video cards since today and for some time, HAM is un-necessary and irrelevant.
...
Digressing, in both chunky and planar modes, you need 6mb to display a 24bit 1080p image.
In planar mode, the memory is allocated as such:
-2MB for red plane (1 byte, 8 bits per pixel)
-2MB for green
-2MB for blue

In chunky mode, 6MB is allocated but arranged in bytes of 3:
1 byte for red, 1 byte for green, 1 byte for blue * # of pixels (1920x1080 * 3 bytes for color)

For writes, if your memory bus is 32 bits wide, you can update a pixel in 1 write operation in chunky mode.  In planar mode you have to issue 3 separate writes since the color data is not sequential.  You have to jump to different addresses.  This is where planar mode loses.  It requires 3x the bandwidth.

[Louis Dias]

@lou_dias

You seem to be confusing something here. All HAM does is alter the way the most significant bits of a pixel are interpreted. Whether the pixels are planer or chunky is irrelevant. Nobody ever bothered creating an 8-bit chunky implementation that does it, but chunky pixels are no barrier to entry for the HAM concept. To prove it, you could easily write a software routine that converts 8-bit "HAM" pixels to 24 bit. Straight off the top of my head:

Code: [Select]


uint32 convertPixelSpan(uint32* dstARGB, const uint8* srcHAM, const uint32* paletteARGB, uint32 lastPixelARGB, size_t num)
{
  /* assumes destination and palette are 32-bit ARGB words, A always 0. */
  while (num--) {
    /* read next HAM pixel and decode to RGB */
    uint32 pixel = *srcHAM++;
    switch (pixel & 0xC0) {
       case 0x40: /* change upper 6-bits red */
         lastPixelARGB = ((lastPixelARGB & 0x0003FFFF) | (pixel & 0x3F) << 18);
         break;

       case 0x80: /* change upper 6-bits green */
         lastPixelARGB = ((lastPixelARGB & 0x00FF03FF) | (pixel & 0x3F) << 10);
         break;

       case 0xC0: /* change upper 6-bits blue */
         lastPixelARGB = ((lastPixelARGB & 0x00FFFF03) | (pixel & 0x3F) << 2);
         break;

       default: /* use palette value  */
         lastPixelARGB = paletteARGB[pixel];
         break;
    }
    *dstARGB++ = lastPixelARGB;
  }
  /* return the last calculated pixel for future calls */
  return lastPixelARGB;
}


Such an implementation would be trivial in hardware, I would suggest actually using planar graphics makes it more difficult rather than less (except in the case of HAM6 where there's no convenient chunky representation).

Not sure what you were replying to but what is the point of converting HAM to chunky?  Unless ofcourse you're trying to port graphics to another platform...and they were natively saved as HAM images...

HAM is used as a lossy image conversion/display when you need to display more colors with limited RAM.  The trade off for saving memory is you can only 'modify' 1 plane at a time.

It's 24bit Chunky that gets converted down to HAM for displaying purposes.  No one goes back the other way...

[Louis Dias]

You seemed to be implying that planar pixels were somehow advantageous for implementing HAM. They're not; the HAM concept can work just as well if the pixels were planar or chunky. The code was just to demonstrate how a chunky 8-bit HAM mode might work (though in any real system you'd implement it in HW).

In fact, it might even be the case that it would take less logic to implement a chunky HAM system than a planar one.

Ah.

Well my point is if you have a 24bit chunky mode HAM is irrelevant.  HAM was only an advantage in the old days of limited RAM and inability to display lots of colors on the screen at once.  It's a lossy format...just like most people feel about 80% jpeg compressed images and 128kbps MP3's...

HAM is one piece of tech that can go the way of the dodo bird since about 1994.