Wolfenstein 3D IS technically possible on stock A500 shocker!

[Karlos]

A wolf3d-clone would most certainly be possible on a stock (1MB) A500 in 4096 colors, just have a look at this http://www.youtube.com/watch?v=GbBGxmJVasg at around the 2:23 mark.

Was it running on that hardware or an OCS machine with a faster CPU?

[Karlos]

I think Behind The Iron Gate is a pretty good FPS engine for 7Mhz Amigas. It's not fully texture mapped, but it does have some occasional textures and nice depth shading.

[YOUTUBE]Q_rFTtQ9Kuk[/YOUTUBE]

Reminds me of Corporation, only more FPS and less RPG

[Karlos]

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

[Karlos]

c2p or chunky to planar is any algorythm that takes a chuncky frame buffer and writes to a planar graphics arrangement. There are lots of ways to do it, and none are as fast as simply writing a chunky buffer. Because one chunky pixel has to be broken into bits and stored in each plane of the output

Whilst this observation is true in theory, in practise you can hit other bottlenecks first. On the amiga, the speed at which you can write to Chip RAM soon becomes a limiting factor (not for vanilla 68000, but certainly for 68040/68060) such that the time it takes to perform the C2P is masked by the time it takes to simply shovel the data from Fast RAM to Chip RAM. Once you hit that wall, your routine is indistinguishable in performance terms from simply copying, the data.

[Karlos]

??

BTW, does someone have an example of HAM c2p? Sounds kind of processor intense but it would be cool

There are various 18-bit C2P routines on Aminet, IIRC.

[Karlos]

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

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.