Wolfenstein 3D IS technically possible on stock A500 shocker!

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

[Hattig]

@Changing a single pixel in a planar mode requires a shitload of instructions, whereas changing a chunky pixel requires 1 instruction.

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.

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.

But doable in a smaller window, 2x1 pixels, lower framerate (not for action FPSes, but fine for RPGs), etc. If a 4MHz Z80 can render a semblance of Wolf3D graphics (http://www.youtube.com/watch?v=COH55Uj53TY) then an A500 can as well.

[Linde]

But doable in a smaller window, 2x1 pixels, lower framerate (not for action FPSes, but fine for RPGs), etc. 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 definitely agree with you, but I just have to point out that your video example is not entirely real time - it's still far from from an interactive engine in that distances and texture coordinates are precalculated, as is explained in the video description. I'm sure you know this, but just before anyone else goes into a frenzy

[Hattig]

I definitely agree with you, but I just have to point out that your video example is not entirely real time - it's still far from from an interactive engine in that distances and texture coordinates are precalculated, as is explained in the video description. I'm sure you know this, but just before anyone else goes into a frenzy

True, but we are talking about the rendering aspect at the moment, rather than the calculation aspect. :-) I expect the calculation will kill the Z80 version, and be tough on a 68000 even with lookup tables.

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

[Hattig]

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?

It can't be relating to ILBM, as that's a file format that merely stores planar graphics on a row-by-row basis.

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

[commodorejohn]

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

Given that HAM is by necessity fixed at a certain bit-depth, there's certainly no advantage to its being planar (besides the relevant one for OCS, that it allows reuse of the existing planar hardware.)

[whabang]

The amount of epeen in this thread is growing rapidly.

/me sits back, grabs popcorn, and waits for someone to bring joyport polling into the equation.

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

[KThunder]

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!

[yakumo9275]

You do have to ask, Would Gary Busey poll the josystick port at such frequency tho? Stellan Skarsgård might but would Gary Busey?

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