Wolfenstein 3D IS technically possible on stock A500 shocker!

[nicholas]

Ooh that brings back some fond memories of the 90's for me.

I never tire of reading this book:

http://www.drdobbs.com/high-performance-computing/184404919;jsessionid=14VZ5MDXC5NHRQE1GHPSKH4ATMY32JVN

The mode most used in Vga that is called planar is mode x, and it works a bit differently (better) than the amigas planar mode. here is a quick description of it:

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

notice two lines in that article:

Planar memory arrangement splits the pixels horizontally into groups of four. For any given byte in the PC video memory aperture, you can access four pixels on screen, by selecting the plane(s) you require.

Planar mode allows up to 4 adjoining pixels to be modified in one byte write operation, which is ideal for solid filling of objects such as polygons, rectangles, lines, etc.


Mode x was tricky to handle but could actually be faster than chunky graphics. On the Amiga Planar graphics are always slower for this type of operation. The way the Amigas graphics hardware was setup made mode x impossible or not any faster

here is a really in depth programming article on mode x:
http://www.gameprogrammer.com/3-tweak.html

[KThunder]

Ooh that brings back some fond memories of the 90's for me.

I never tire of reading this book:

http://www.drdobbs.com/high-performance-computing/184404919;jsessionid=14VZ5MDXC5NHRQE1GHPSKH4ATMY32JVN

Nice, I'll have to check that site out.

I have a ton of old programming books, that have lots of info on EGA, VGA and early SVGA modes including the first VESA versions.

I think it is cool that these video modes are still with us today, my newest video card is a geforce 9 series card and it can still run CGA stuff.

[djnick]

I liked Testament II game - was very playable at that time

http://www.youtube.com/watch?v=VpagvEPllKM&feature=related

[Hattig]

There is one way around writing multiple writes for a single pixel, but it isn't very good: 2 color graphics. You can use sprites to color things up, and a copper list to provide some "shading" top to bottom but thats about it.

Unfortunately C2P on a 68000 can't go fast enough. 4 color might be close but that is 4 writes per pixel, in addition to the half dozen instructions needed to calculate the pixel in the first place.

I thought the point of fast C2P was to calculate a chunky buffer of graphics data 16 pixels wide (32 on AGA, any height as Wolf3D/Doom engines are column rendered due to the ray casting mechanism), and then do the C2P on this buffer into planer graphics memory? You still do the write per plane, but you do it for 16/32 pixels at a time rather than 1, thus saving writes.

[Speelgoedmannetje]

Planar graphics, we has them!

From a CPU perspective, it's a go; the 68000 will most likely perform just as well as an old 286.

AFAIK EGA was also planar based.
The Catacomb Abyss uses only ega and has texture mapping just like Wolfenstein 3d.

[commodorejohn]

The documentation I provided that showed exactly what mode x was and why it was so fast. It is a planar mode, it is much faster, and it was present in even the earliest vga systems. You could call it a hack, but it was used so extensively in games, and programming books; it was a very well known, well documented, well used hack.

Well, I don't mean to imply anything negative when I call it a "hack" - it's definitely a useful mode, if a bit difficult to wrap your head around at first. I just mean that it's not a planar mode in the usual sense, where the bits of a pixel are spread across multiple linear bitmaps - each pixel is contained in one byte, it's just that the bytes for consecutive pixels are strangely interleaved by the VGA's normal planar hardware.
 

I never tire of reading this book:
http://www.drdobbs.com/high-performance-computing/184404919;jsessionid=14VZ5MDXC5NHRQE1GHPSKH4ATMY32JVN

Yes. Michael Abrash is a terrific writer, and his stuff is well worth the read even if you're never going to touch 80x86 programming or low-level EGA/VGA programming. His stuff did more to help me understand code optimization than anything else I'd read on the subject.

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

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

[KThunder]

I thought the point of fast C2P was to calculate a chunky buffer of graphics data 16 pixels wide (32 on AGA, any height as Wolf3D/Doom engines are column rendered due to the ray casting mechanism), and then do the C2P on this buffer into planer graphics memory? You still do the write per plane, but you do it for 16/32 pixels at a time rather than 1, thus saving writes.

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.

In other words there is no hardware "magic" like with mode x on vga that makes it faster.

If you use 2 color (wireframe or pattern) graphics there is only one plane so it is as fast as chunky.

[KThunder]

Well, I don't mean to imply anything negative when I call it a "hack" - it's definitely a useful mode, if a bit difficult to wrap your head around at first. I just mean that it's not a planar mode in the usual sense, where the bits of a pixel are spread across multiple linear bitmaps - each pixel is contained in one byte, it's just that the bytes for consecutive pixels are strangely interleaved by the VGA's normal planar hardware.
 

Yes. Michael Abrash is a terrific writer, and his stuff is well worth the read even if you're never going to touch 80x86 programming or low-level EGA/VGA programming. His stuff did more to help me understand code optimization than anything else I'd read on the subject.

I didn't think anything bad when you said "hack" I just meant that it is such a feature that it works perfectly on every single IBM and compatible clone cards. IBM had bios modes that were a subset of what the vga chip could actually do, and the clone cards included it.

mode x also had "square" pixels so no scaling was neccisary before displaying graphics.

Its kind of like ham in a way, its not a normal method of graphics output but it has some excellent uses. Ham displayes more colors, Mode x is very fast. Ham may have been more designed into the hardware though.

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

[Linde]

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.

??

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

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

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

[shoggoth]

@lou_dias: No, you completely missed the point of my argument. It was about the most efficient way of addressing single pixels in a framebuffer. If that's HAM, a truecolor mode, or a CLUT-based mode is of no importance.

Changing a single pixel in a planar mode requires a shitload of instructions, whereas changing a chunky pixel requires 1 instruction. The required bandwidth to do so is a different discussion, but if we do take it into the equation, planar format makes the bandwidth issue even worse when addressing single pixels, since changing a single pixel means both reading and writing data to screen memory and requires several accesses to finish.

The workaround for this is to use an accelerated machine, and have a chunky buffer in fastmem. All accesses are performed against the chunky buffer, which then has to be converted and copied to chipmen. This method can't be used efficiently on a stock machine, but a stock machine would instead benefit a lot from having chunky pixel format instead of planar.

[whabang]

AFAIK EGA was also planar based.
The Catacomb Abyss uses only ega and has texture mapping just like Wolfenstein 3d.

Yeah, I thought about that a few days ago. Too bad it's not open-source like Wolfenstein is.