Wolfenstein 3D IS technically possible on stock A500 shocker!

[shoggoth]

Wolfenstein 3D is technically possible on a 500:a, but it's not necessarily a smooth ride. There is a port to the Atari ST (don't confuse this port with the one for the 8-bitters), and it runs rather "well" on a stock machine (like 10fps).

However, the ST has one advantage in this case - bitplanes use a 16-bit interleave. For all other purposes, this is completely retarded and hopeless to work with, but in this case it does enable the use of a faster low-resolution C2P procedure using the movep instruction. This trick can't be used on the 500:a since the smallest copper interleave possible is 32-bit (ironically the trick was evented by Amiga sceners, I've been told).

But again - ofcourse it's possible. But who would invest the time to do it?

[shoggoth]

Planar graphics, we has them!

Yes - and the point is that planar graphics stinks if you want to use textured walls a'la Wolf3D.

From a CPU perspective, it's a go; the 68000 will most likely perform just as well as an old 286. What else do we have? Memory? I don't know anything about the memory performance of OCS Amigas, or 286 PC's for that matter. I'm sure someone else here can enlighten us, but regardless, I think both platform have enough juice.
Both the Amiga and the 286 will be able to play sounds over DMA (assuming that piece of PC junk has a soundcard), no problem there.

The 68k is better equipped for this stuff compared to the 286. Ironically.

The only difference is the video hardware. I'm no expert, but having to do several writes to fill each pixel, when the PC only needs to do it once seems like major disadvantage for the Miggy. Thus, we need to rely on c2p conversion to get things done at a reasonable speed.

C2P is the only realistic way to achieve this, since it somewhat reduces the number of reads & writes required to address individual pixels.

The question is: Can one of you clever coders get blazing fast c2p conversion done on a 68000? Or can you do some miraculous planar 3d engine? If not, we will have to accept that our beloved little miggies were behind even contemporary PC's, at least in some aspects.

Never say never, but I'm fairly sure this is well charted territory. There is a physical limit.

[shoggoth]

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.

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.

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

That's true on a faster machine (i.e. 040/060) with fastmem, because the C2P conversion can be done at copyspeed anyway (i.e. you get the C2P-conversion for "free"). However, on a lower spec machine, the planar format is definitely a severe limitation.

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

[shoggoth]

Damn right - but changing 16 aligned consecutive pixels in planar mode requires the same amount of instructions. C2P from 16 chunky pixels in fast ram to chip RAM does save a lot of bandwidth over the worst case scenario.

Changing 16 aligned consecutive pixels in planar mode is fairly useless in a texturemapper in a typical Wolf3D scenario And I'm not sure it's true either - in chunky mode you'd do that with a single movem, but in planar mode you'll have to take into account that the bitplanes have a 32-bit interleave (copper interleave).

It's just that pretty much any programmer would implement this - however C2P involves a lot of ORing and shifting - precisely what Akiko does for free on the CD32. I'm sure someone has done something fast with pre-calculated lookup tables but on a 7MHz 68000 it's still very heavy.

It doesn't do it for free. You have to write 32 pixels and read them back, then copy them to the screen. I agree it's better, but it still stinks compared to having a real chunky mode.

But doable in a smaller window, 2x1 pixels, lower framerate (not for action FPSes, but fine for RPGs), etc.

Indeed! Wasn't Legends of Valour released for the Amiga?

If a 4MHz Z80 can render a semblance of Wolf3D graphics (http://www.youtube.com/watch?v=COH55Uj53TY) then an A500 can as well.

I'm not sure it's a good comparison. The problem is not CPU speed, the problem is that the pixel format of the framebuffer isn't suited for that kind of stuff. The CPU has more than enough juice to do it.

[shoggoth]

What's "copper interleave" - the only references I can find on Google are this thread, and another post by you regarding Atari ST emulation on the Amiga

Ah. Clarification. On the Amiga, bitplanes are ordered consecutively (i.e. it's like multiple monochrome bitmaps layered on top of each other).

On the ST, they're interleaved (1 word from plane 0, followed by 1 word from plane 1, by one word from plane 2, one word from plane 3, one word form plane 0 ... etc).

Using the copper, it's possible to create something similar: 1 longword for plane 0, 1 longword for plane 1, 1 longword for plane 2, 1 longword for plane 3 etc. I suspect that it's fairly useless to do so however, and hence it's possible that the term "copper interleave" isn't very common at all.

Note: Word in this case is 16 bits, longword is 32 bits.

[shoggoth]

given isa bus limitations and ocs superiority joystick polling is integral to the discussion. If you send 15 megs over the bus in vga snoopdog mode and 10msec later poll the joystick port, you get flashed by the planar chick. Amiga has Paula (i dated a girl named paula once, nice girl, nicccely chunky:) ) and you can poll the port every nth nanosecond.

with or without popcorn!

lol It's just a matter of time now.