Grzyb wrote:

Heh, let me clarify... My original post in this thread was because: […]
Show full quote

Heh, let me clarify...
My original post in this thread was because:

Grzyb wrote:
Back in the Wolfenstein/Doom era, it was commonly believed that one of the major reasons why Amiga can't into 3D is the fact it only has bitplanes, and not chunky.

...and, after a quarter of century, I finally want to know to what extent that belief was true.

It's not true. google a video about one of the many 'actual' 3D games mentioned in this thread previously that run on Amiga and see for yourself.

Grzyb wrote:

Yes, there are 3D games other than Wolfenstein 3D and Doom...

They are NOT 3D. Just 2D faking perspective in some respects... but failing in others (demonstrated by looking up or down in the case of Doom... or failing to be able to look up or down at all in the case of Wolf3D)... in the case of Doom this is why it is called 2.5D (not 3D)... and Wolf3D is 3D by name only.

Grzyb wrote:

...but in that era these were the most common 3D games...

Not 3D... check out terminal velocity or descent for actual 3D using proper perspective projection. And in both these cases, its only the environment and enemies that are '3D'... the powerups are billboards/sprites (Enemies in both Doom and Wolf3D are billboards/sprites too).

Grzyb wrote:

...so such claims were precisely about them, and now I'm naturally focusing on them.
And I can't accept comparing them against games that lack some of their features, including, but not limited to, 256-color graphics.

Amiga had HAM. Thats 4096 colours, so even if your focus was remotely coherent, it would be nothing to do with the colour depth.

Grzyb wrote:

Also, see another of my questions:

Grzyb wrote:
How does the video memory layout affect performance in 3D games?

Drop the whole idea of this being related to '3D'. It doesn't.

Grzyb wrote:

When comparing bitplanes vs. byteplanes vs. chunky, it must be noted that both byteplanes and chunky on VGA (and probably any common graphics hardware of that era) are 256-color, so - when comparing them with bitplanes - I demand bitplanes in 256-color mode as well.

I'm willing to accept that the lack of Wolfenstein and Doom on Amiga in the era (and poor performance of later ports) was all about slow CPU and lack of knowledge how to optimize such stuff for bitplanes, and nothing about inherent deficiences of bitplanes, but I need a proof.
Like, any Doom-like game, running on any CPU, on two different video adapters: planar and chunky, at the same speed.

Nothing to to do with it. Best you can do is compare same code on the same CPU with different VGA cards. No VGA can 'hardware accelerate' 3D operations. There are loads of threads benchmarking this on vogons.

I used to have Doom on a Casio calculator.

Grzyb wrote:

Of course, I accept two versions of the game, each optimized for different video memory layout, but they must produce identical output.

tbh I don't think you understand or know what you are asking?

Grzyb wrote:

Heh, I guess I need to wait for a few decades more 😜

You will be waiting a long time as your question makes no sense. It's like asking why doesn't my floppy drive read my CD. Your time would be better spent learning about what 3D cartesian space is, how it is represented, and how computers utilise this and end up displaying an image. Or drop the whole idea of this being related to '3D'.

To add to that: neither 'bitplane' nor 'chunky' really have a single definition.
Bitplane is just a design philosophy, and can be implemented in a number of ways.
Atari ST, Amiga and EGA all are designed around bitplanes, but they all use them in different ways. Atari ST stores the bitplanes interleaved in memory. The Amiga has the blitter to accelerate operations on bitplanes. And EGA has its ALU to perform simple operations on multiple bitplanes in parallel.
Same with chunky. What is chunky exactly? Any kind of format with the bits of a pixel grouped/packed together? Is CGA chunky? Is Tandy chunky? I'd say it is (But confusingly enough, they separate the even and the odd scanlines in two separate buffers, because of limitations of the 6845 CRTC. These buffers are often referred to as 'bitplanes').
Of course, these pixels are not 8-bit, so they are not as easy to address as VGA's 256-colour mode happens to be.

I think the bottom line is that the philosopy of bitplanes is that the pixels are grouped by bits. Each bit can be assigned a certain property (a colour, transparency, translucency, mask, or whatnot). Bitplanes allow you to efficiently perform operations only on specific properties of a pixel.
Or to put it in other words: you don't have to use all bits in a pixel, you can only update the bits you're interested in. This can save bandwidth and/or redundant read-modify-write operations in certain cases.

I think chunky basically *only* has an advantage if the pixels happen to have a convenient size, such as 8-bit, 16-bit or 32-bit, so they can be read/written easily by the CPU, without additional masking.
In most other cases (such as CGA, which packs 4 pixels of 2 bits into each byte), it's quite inconvenient to update individual pixels. And there is no way to save bandwidth, you always have to read and write the whole pixel/byte, even if you're only interested in 1 bit.

An example of a bitplane trick:
If you have a 3D cube, you can always only see 3 faces at most, at any orientation.
You can render each visible face into a single bitplane. Then you can set up your palette so that each bitplane has its own colour. You can update the palette to perform lightsourcing.
So you only require 1 bit for each pixel of the entire cube, even though you can use all available colours to shade the cube.
You only need 3 bitplanes in total, which is enough to give you background colour and 3 face colours (000 as background, and 001, 010 and 100 as faces).
If you would render it on VGA in chunky mode 13h, you'd need to write 8 bits for each pixel, so technically you need 8 times the bandwidth/fillrate.

(Scrolling text is also a good case for bitplanes: you only need to use 1 bitplane for text)

spiroyster wrote:

Amiga had HAM. Thats 4096 colours, so even if your focus was remotely coherent, it would be nothing to do with the colour depth.

AFAIK there was precisely one Amiga game using HAM during gameplay, and maybe 2-3 only in the menu as a background. Mentioning HAM is just muddying the water unless you want to show us Wolfenstein in HAM mode 😜 could probably run at acceptable fps on Vampire.

spiroyster wrote:

Drop the whole idea of this being related to '3D'. It doesn't.

pseudo 3D, back then it was all the 3D we knew 😉

Grzyb wrote:

When comparing bitplanes vs. byteplanes vs. chunky, it must be noted that both byteplanes and chunky on VGA (and probably any common graphics hardware of that era) are 256-color, so - when comparing them with bitplanes - I demand bitplanes in 256-color mode as well.

its simple, every time you want textures bitplanes will be xN times slower, x being number of bitplanes. No more clever let me draw this flat polygon to only one bitplane trickery.

spiroyster wrote:

Nothing to to do with it. Best you can do is compare same code on the same CPU with different VGA cards. No VGA can 'hardware accelerate' 3D operations. There are loads of threads benchmarking this on vogons.

wasnt there an EGA Wolfenstein project somewhere?
maybe https://github.com/CatacombGames/Catacomb3D could shed some light on efficiency/inefficiency

spiroyster wrote:

Grzyb wrote:

Of course, I accept two versions of the game, each optimized for different video memory layout, but they must produce identical output.

tbh I don't think you understand or know what you are asking?

I think he does, he just cant accept the answer due to Scali coming up with clever tricks nobody ever used like Amiga blitting flatshaded polygons 😀

rasz_pl wrote:

AFAIK there was precisely one Amiga game using HAM during gameplay, and maybe 2-3 only in the menu as a background. Mentioning HAM is just muddying the water unless you want to show us Wolfenstein in HAM mode 😜 could probably run at acceptable fps on Vampire.

Well I'm sure your google-fu can pick an example, tbh when I mentioned HAM, it was just to suggest that the Amiga is not limited like VGA in it's colour depth. I couldn't even mention a game that uses it so it is obviously not a limiting factor in this case.

rasz_pl wrote:

pseudo 3D, back then it was all the 3D we knew 😉

🤣... speak for yourself, trust me, true '3D' graphics have been around a long time before the Amiga or 8088 were even the glint in the milkmans eye. tbh This comment explains it all to me. Also see previous comment about true 3D perspective projected geometry exsiting on Amiga... long time before Doom or Wolf3D? Look up history of flight simulators for example... and I'm not talking about ones you can load up and slideshow on your home computer.

And then theres this gem

rasz_pl wrote:

I think he does, he just cant accept the answer due to Scali coming up with clever tricks nobody ever used like Amiga blitting flatshaded polygons 😀

I don't think he does, and I don't think you do either.

Since you seem to think it is such a valid question...proove you understand...

I'm all ears please explain to me then how video memory layout impacts '3D' games then please?

I see goalposts shifting again...
First people were adamant that bitplanes were just a dumb design that couldn't possibly have any advantage over chunky modes.
Then I explain how bitplanes can save bandwidth, and now somehow we have to prove that Amiga games used the bit blitter (of which I fail to see the relevance anyway: if the question is how memory layout can affect (3D) rendering algorithms, then does it matter whether a particular algorithm was ever actually applied in games? I don't think that's relevant)?
I hate to break it to you, but the example I gave does not imply using the blitter in any way. It merely explains how the memory layout allows you to update only the bits you are interested in. Whether you do that with the blitter or the CPU is irrelevant. It's the same bits you'd be updating.
Not to mention it's not an Amiga-specific example either, because as already said, F29 Retaliator uses the same approach on PC (snd that is a very unique example, I don't know of any other flatshaded polygon game on PC that is anywhere near as efficient. In fact, all 3D poly games from that era on PC that I know, are considerably slower in EGA mode than in VGA mode. Probably because the programmers couldn't get their head around the EGA design).
It's just a generic bitplanes vs chunky example, not implying any specific machine or blitter or anything.

Scali wrote:

First people were adamant that bitplanes were just a dumb design that couldn't possibly have any advantage over chunky modes.

Those are the same people not realizing Commodore scammed everyone by selling same computer for 9 years until going bankrupt.
Bitplanes made perfect sense in 1985, were ok in 1987, but started to suck really bad around 1990. I would go as far as calling it fraud past 1992 😀 Poor souls buying into A1200 with promise of all those colors, just to end up watching slideshows of popular at the time 3D games (of the ones they got anyway).

Scali wrote:

Then I explain how bitplanes can save bandwidth

undeniably, brilliant for limited color sprites/primitives, useless for textured games unless you enjoy 4 color walls.

Scali wrote:

and now somehow we have to prove that Amiga games used the bit blitter (of which I fail to see the relevance anyway: if the question is how memory layout can affect (3D) rendering algorithms, then does it matter whether a particular algorithm was ever actually applied in games? I don't think that's relevant)?

no, but mentioning it in the first place when it was never? used is somewhat sneaky 😀 especially when replying to someone constantly rambling about textured games (Grzybs wolf/doom).

Scali wrote:

I hate to break it to you, but the example I gave does not imply using the blitter in any way. It merely explains how the memory layout allows you to update only the bits you are interested in. Whether you do that with the blitter or the CPU is irrelevant. It's the same bits you'd be updating.

you implied blitter could do it faster, not that would change anything
looks like even Akkio didnt help all that much https://forum.amiga.org/index.php?topic=51616.0

Cammy wrote:

DoomAttack -forcedemo -timedemo demo3 […]
Show full quote

DoomAttack -forcedemo -timedemo demo3

A1200 030/50Mhz 32Mb (Optimised 020 C2P) - 8481 realtics (8.8 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised 020 C2P) - 18971 realtics (3.9 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised Akiko C2P) - 12872 realtics (5.8 fps)

Btw this might be the one Grzyb was waiting for - Doom running in either bitplanes mode (C2P on CPU) versus chunky (simulated with Akkio on same hardware platform (cpu/ram).
Still a little bit cheated by using a fastram - no gaming Amiga ever shipped with one, I think Its implied in that thread lack of fastram tanks cpu C2P conversion speed.

Scali wrote:

In fact, all 3D poly games from that era on PC that I know, are considerably slower in EGA mode than in VGA mode. Probably because the programmers couldn't get their head around the EGA design).

I wager a guess that in case of ones with both EGA and VGA versions(maybe Stunts?) they couldnt be bothered because CPU was already fast enough

rasz_pl wrote:

Those are the same people not realizing Commodore scammed everyone by selling same computer for 9 years until going bankrupt.
Bitplanes made perfect sense in 1985, were ok in 1987, but started to suck really bad around 1990. I would go as far as calling it fraud past 1992 😀 Poor souls buying into A1200 with promise of all those colors, just to end up watching slideshows of popular at the time 3D games (of the ones they got anyway).

Well, thanks for sharing your opinion, but it's nothing more than that.

rasz_pl wrote:

no, but mentioning it in the first place when it was never? used is somewhat sneaky 😀

The irony is that this argument was initially used by the Amiga crowd: "Yea, Atari ST does 3D just as well, because Amiga games are just Atari ports, and don't make use of the blitter".
I have no idea how much truth there is to this statement. And I certainly am not going to disassembly every single 3D game on Amiga to see which of them use the CPU and which use the blitter.
But if I had to make an educated guess, then I would say there would certainly be some games that are just Atari ports, and only use the CPU. However, people in the demoscene started using the blitter for 3D at an early stage (around 1988 or so), and many of these democoders became game developers. So I expect that there would be games in 3D that made use of the blitter for drawing polygons.

Regardless, this doesn't have anything to do with having a blitter or not. It certainly is possible to create a blitter for chunky memory as well, and later SVGA cards did have such a bitblit engine (although it was never used in DOS games because it was not standardized).
The thing is, the bitplane layout means that the blitter is agnostic to the actual amount of bits per pixel.
The blitter operates on a single bitplane at a time, and blitting operations can easily be repeated for multiple bitplanes when more colours are required.
This gives the Amiga the flexibility to set up any video mode from 0 to 6 bitplanes. The blitter is agnostic of this, and the code can mostly be agnostic as well. You write a blitter routine for 1 bitplane, and repeat it as often as you need for the amount of colours you want.

If you have a chunky memory layout, then blitter operations such as linedrawing or area fill would need to be agnostic of the actual pixel format used, making the hardware more complex.

rasz_pl wrote:

you implied blitter could do it faster, not that would change anything

I didn't imply that, I explicitly explained that a few posts ago: the blitter can operate on memory at the maximum memory bandwidth, because the blitter doesn't need to fetch and decode any instructions, like the CPU has to (the Amiga is a shared memory system: every memory cycle that the CPU needs to fetch an instruction is a cycle that can't be used to draw to memory).

rasz_pl wrote:

I wager a guess that in case of ones with both EGA and VGA versions(maybe Stunts?) they couldnt be bothered because CPU was already fast enough

I highly doubt that. I was there when these games came out, and I had a 386SX-16 with a fast VGA card at the time (Paradise SVGA). My PC was the fastest PC of all my gaming friends at the time (many were still using 8088/V20 machines, some had a 286).
These games were completely unplayable in EGA, and generated acceptable framerates in VGA at best. And that was on a fast SVGA card. On a real EGA card they'd probably be unplayable period, even if you strapped it to a Pentium CPU. The overhead is not just on the CPU, it's also inefficient use of the ALU and memory bandwidth. That won't speed up with a faster CPU, that's the limitation of the EGA hardware (yet this seems to be the PC mentality: "Oh, a faster CPU will fix everything"... It won't).
As I say, I think the developers just didn't know how to write an efficient EGA renderer.

Scali wrote:

rasz_pl wrote:

Those are the same people not realizing Commodore scammed everyone by selling same computer for 9 years until going bankrupt.
Bitplanes made perfect sense in 1985, were ok in 1987, but started to suck really bad around 1990. I would go as far as calling it fraud past 1992 😀 Poor souls buying into A1200 with promise of all those colors, just to end up watching slideshows of popular at the time 3D games (of the ones they got anyway).

Well, thanks for sharing your opinion, but it's nothing more than that.

5 fps games are a fact, and Cammys DoomAttack benchmark results finally answers our "how much do bitplanes suck for 3D games" question.

Scali wrote:

So I expect that there would be games in 3D that made use of the blitter for drawing polygons.

me too, and yet I cant remember a single smooth fullscreen 3d pre 1995 Amiga game running on stock hardware.

Scali wrote:

rasz_pl wrote:

I wager a guess that in case of ones with both EGA and VGA versions(maybe Stunts?) they couldnt be bothered because CPU was already fast enough

I highly doubt that. I was there when these games came out, and I had a 386SX-16 with a fast VGA card at the time (Paradise SVGA). My PC was the fastest PC of all my gaming friends at the time (many were still using 8088/V20 machines, some had a 286).
These games were completely unplayable in EGA, and generated acceptable framerates in VGA at best. And that was on a fast SVGA card. On a real EGA card they'd probably be unplayable period, even if you strapped it to a Pentium CPU. The overhead is not just on the CPU, it's also inefficient use of the ALU and memory bandwidth. That won't speed up with a faster CPU, that's the limitation of the EGA hardware (yet this seems to be the PC mentality: "Oh, a faster CPU will fix everything"... It won't).

any example titles?

Scali wrote:

As I say, I think the developers just didn't know how to write an efficient EGA renderer.

If Ocean could, everyone could, they just didnt bother.

rasz_pl wrote:

5 fps games are a fact

Yes, and?
There's also a huge library of games that run at a silky-smooth 50 fps, with hundreds of colours on screen, and very nice music (often better than the OPL2/OPL3 music on PCs at the time, let alone the PC speaker).

rasz_pl wrote:

and Cammys DoomAttack benchmark results finally answers our "how much do bitplanes suck for 3D games" question.

Well no, because as already mentioned:
1) '3D games' is not the same as DOOM/Wolf3D
2) These are unofficial ports by hobbyists, which use c2p in the dumbest way possible: take the entire PC rendering engine, with unoptimized C code, then render to an offscreen buffer, and convert the entire buffer to bitplanes after-the-fact (technically you could argue that this 'test' can be disqualified because it doesn't even make an attempt to render into bitplanes in the first place. The renderer is entirely chunky).
3) Nobody argued that bitplanes were better than chunky VGA for textured games anyway. In fact, go back to my earlier post:
ATI Graphics Solution

VGA marks the turning point: once you go up to 8 bitplanes, you basically have a 1:1 mapping of byte-to-pixel. So at this point, updating entire pixels becomes relatively simple, while at the same time 8 inidivdual bitplanes now become significant overhead.

And here:
ATI Graphics Solution

It wasn't until the early 90s that texturemapped software rendering in 3D became a thing, which VGA just happened to be reasonably well-suited to. Even so, many early games, such as Wolf3D and DOOM, still opted to use the undocumented mode X, which is still a sort of bitplaned-mode, over the standard chunky mode 13h.

I merely showed Cyberwolf as an example that you certainly can write an efficient raycaster on Amiga/in a bitplaned video mode, if you know what you're doing, and make the right tradeoffs.
I never claimed that the Amiga would be a better platform for Wolf3D or DOOM, because there are many reasons why it isn't. But the gap isn't necessarily as large as some of you want to claim it is.

rasz_pl wrote:

me too, and yet I cant remember a single smooth fullscreen 3d pre 1995 Amiga game running on stock hardware.

Again, this does not make sense.
There are various reasons why an Amiga would have trouble with fullscreen 3D, which have nothing to do with bitplanes or the blitter.
Lack of processing power is a good one. Lack of memory bandwidth is another.
Sure, the blitter can make the rasterizing process more efficient (but perhaps only 20-30% over a well-optimized CPU routine), but you're still running on an outdated 68000 CPU, which needs hundreds of CPU cycles to perform a multiply or division operation.
With reasonably complex scenes you might not even be able to tell the difference between CPU and blitter filling, because most of the time is spent on 3D calculations. You know, that phenomenon that gamers now know as 'being CPU limited': putting a faster GPU in your machine won't make your game run faster, because the game spends all its time waiting on the CPU, not on rendering operations.

rasz_pl wrote:

any example titles?

I already gave plenty of example titles. As far as I know, anything that is not F29 Retaliator, suffers from this.

rasz_pl wrote:

If Ocean could, everyone could, they just didnt bother.

You are talking about 'Ocean', who is just a publisher, not a developer... This is the late 80s. The DOS version of F29 Retaliator was programmed by a single person: Jas C. Brooke. Someone who was very clever, and one of the first to develop a fast EGA rendering routine, as far as I know (his is the one I studied at any rate, because it was the first I know, it predates even the Spacepigs and Triton demos that use the same idea).
These were the days before the internet, so I doubt his knowledge was shared throughout the entire PC gamedev community.
If anything, they probably didn't bother, because EGA was a niche market. Most people skipped straight from CGA to VGA. But, given the complexity of writing a good EGA renderer, I would say that many gamedevs at the time simply weren't up to the task, and Jas C. Brooke was an exceptional talent (much like John Carmack and Michael Abrash, they pushed the boundaries with Wolf3D, DOOM and Quake. Games that were made possible because they derived all sorts of clever hacks that nobody had thought of before. Their ideas were often cloned, but not many gamedevs could reach the quality and performance of the original).

May I also remind you that you come off as extremely arrogant and 'all-knowing', while just a few pages ago, you clearly didn't even understand Wolf3D/DOOM's double-buffering, and made some nonsensical statements about 'tearing' and vsync.

Also, I'm not quite sure how we've gotten from an ATi thread to bitplanes to some ignorant Amiga haters.

Scali wrote:

There's also a huge library of games that run at a silky-smooth 50 fps, with hundreds of colours on screen, and very nice music (often better than the OPL2/OPL3 music on PCs at the time, let alone the PC speaker).

none of them 3d

Scali wrote:

1) '3D games' is not the same as DOOM/Wolf3D

do you have better example of 3d textured multiplatform game suitable for comparison?

Scali wrote:

2) These are unofficial ports by hobbyists

sounds like you are calling them bad names 😜 those filthy "hobbyists" couldnt code their way out of a paper bag 😵

Scali wrote:

which use c2p in the dumbest way possible: take the entire PC rendering engine

yep, so its comparable

Scali wrote:

with unoptimized C code

has assembler 020/030/060 optimizations, 060 one for example runs 8x?(according to forum.amiga.org posters) faster than 020 on same 060 cpu

Scali wrote:

then render to an offscreen buffer, and convert the entire buffer to bitplanes after-the-fact (technically you could argue that this 'test' can be disqualified because it doesn't even make an attempt to render into bitplanes in the first place. The renderer is entirely chunky).

1 did you come up with planar way of rendering 256 color pixels that is more efficient than chunky?
2 wouldnt you consider bulk conversion as a form of loop unrolling?
3 Amiga pride and joy, 18th best game of all time by Amiga Power, Gloom didnt run any better. 8fps at 1/9 the screen on A1200, those pesky incompetent hobbyist programmers

Scali wrote:

3) Nobody argued that bitplanes were better than chunky VGA for textured games anyway. In fact

in fact that was Grzybs original question all along

Grzyb wrote:

Back in the Wolfenstein/Doom era, it was commonly believed that one of the major reasons why Amiga can't into 3D is the fact it […]
Show full quote

Back in the Wolfenstein/Doom era, it was commonly believed that one of the major reasons why Amiga can't into 3D is the fact it only has bitplanes, and not chunky.
So what's the real problem with Amiga here?
And don't tell me that there's no problem...
https://www.youtube.com/watch?v=_jrMuesQQqk link to aWolf3D running at 7fps on Amiga 1200 aca030/28

and your

Scali wrote:

Nothing really... The technique of raycasting for Amiga's bitplane mode was just not perfected yet. Here's a preview of Cyberwol […]
Show full quote

Nothing really... The technique of raycasting for Amiga's bitplane mode was just not perfected yet.
Here's a preview of Cyberwolf, shown at Revision 2019:
https://www.pouet.net/prod.php?which=81051
Video: https://youtu.be/MyYCdd0Z88w?t=405
This runs on a stock 7 MHz Amiga 500.
So it certainly was possible, programmers simply didn't know how yet.

Nothing really? while linking to 4 color demo? 🙁

Scali wrote:

I merely showed Cyberwolf as an example that you certainly can write an efficient raycaster on Amiga/in a bitplaned video mode, if you know what you're doing, and make the right tradeoffs.

I wouldnt call 4 colors a right tradeoff unless it was C64 game (7fps fullscreen Scarabaeus) or demo (5fps Mood) https://www.youtube.com/watch?v=X3Oqz5WjDPI

Scali wrote:

I never claimed that the Amiga would be a better platform for Wolf3D or DOOM, because there are many reasons why

but you did say "Nothing really"

Scali wrote:

With reasonably complex scenes you might not even be able to tell the difference between CPU and blitter filling, because most of the time is spent on 3D calculations.

Doom Attack:
Amiga CD32 68020/14Mhz 8Mb (Akiko Optimised C2P) - 12872 realtics (5.8 fps)
Amiga A1200 030/28Mhz 64Mb (Blitter 020 C2P) - 12727 realtics (5.8 fps)

with only difference being hardware versus screwing with bitplanes manually you need ?3x? the CPU to reach same pitiful result, and Akkio isnt exactly ideal case (still needs to copy 8 bytes at a time)

Scali wrote:

May I also remind you that you come off as extremely arrogant and 'all-knowing'

no need, I am pulling your leg ever since "Nothing really" post 😵

Scali wrote:

while just a few pages ago, you clearly didn't even understand Wolf3D/DOOM's double-buffering, and made some nonsensical statements about 'tearing' and vsync.

nonsense you say

John Carmack wrote:

Its planar, but not bit planar (THAT would stink). ... It is still a lot of grief, and it polutes the program quite a bit, bu […]
Show full quote

Its planar, but not bit planar (THAT would stink).
...
It is still a lot of grief, and it polutes the program quite a bit,
but texture mapping directly to the video memory gives you a fair
amount of extra speed (10% - 15%) on most video cards because the
video writes are interleaved with main memory accesses and texture
calculations, giving the write time to complete without stalling.

Going to that trouble also gets a perfect page flip, rather than the
tearing you get with main memory buffering.

https://groups.google.com/d/msg/alt.games.doo … K0/m1VR6LiJRQMJ

but what does he know, probably another incompetent hobbyist
Btw Doom Alphas up to at least version 2 used pure 13h.

Scali wrote:

Also, I'm not quite sure how we've gotten from an ATi thread to bitplanes to some ignorant Amiga haters.

Im pretty sure ATI thread was about additional bitplane modes

rasz_pl wrote:

none of them 3d

And?
What you said is this:

Those are the same people not realizing Commodore scammed everyone by selling same computer for 9 years until going bankrupt.
Bitplanes made perfect sense in 1985, were ok in 1987, but started to suck really bad around 1990. I would go as far as calling it fraud past 1992 😀 Poor souls buying into A1200 with promise of all those colors, just to end up watching slideshows of popular at the time 3D games (of the ones they got anyway).

As if 3d games were the only thing you could ever do with an Amiga, and Commodore 'scammed' people.
Not quite.

rasz_pl wrote:

yep, so its comparable

Well no, it isn't. The PC engine is highly optimized for the specific PC architecture. Most of the assumptions in the design simply do not hold on a totally different platform like the Amiga.

rasz_pl wrote:

has assembler 020/030/060 optimizations, 060 one for example runs 8x?(according to forum.amiga.org posters) faster than 020 on same 060 cpu

Yea, the c2p code might have. Kalms released a pack of c2p routines that were highly optimized for the TBL demos. Many Amiga coders have since used those.
Still doesn't make for the most efficient type of renderer. For starters: Kalms' c2p routines are basically as fast as the hardware will go ('memcpy speed'). But writing to chipmem isn't that fast. So if you update entire framebuffers, you cannot physically go faster than 25 fps, no matter what you do.
Ironically enough, this exact same limitation is why Wolf3D and DOOM opted to use mode X instead of mode 13h, as I already said earlier: copying an entire frame from system memory to video memory would be slower than rendering 'natively' in mode X, and then flipping buffers.
And in the PC's case, you can even just memcpy the buffer as-is, you don't need to convert it from chunky to planar.

rasz_pl wrote:

1 did you come up with planar way of rendering 256 color pixels that is more efficient than chunky?

More efficient than chunky on Amiga?
Britelite already demonstrated that with Cyberwolf. The same concept can be applied for 256 colour pixels, and it would result in a more efficient game than the current "render to chunky buffer and then c2p".

rasz_pl wrote:

2 wouldnt you consider bulk conversion as a form of loop unrolling?

No, I consider it a redundant operation, much like memcpy'ing your memory around.

rasz_pl wrote:

in fact that was Grzybs original question all along

No, it wasn't. He was talking about 3D games in general, but when he found out that Amigas were actually pretty good at other types of 3D rendering (they were also excellent at vectorbob-style stuff by the way), he narrowed things down to only things that PC+VGA was relatively good at.

rasz_pl wrote:

Nothing really? while linking to 4 color demo? 🙁

Does anyone else see only 4 colours in Cyberwolf? Because I can see considerably more.

rasz_pl wrote:

but you did say "Nothing really"

Not in that context.

rasz_pl wrote:

Doom Attack:
Amiga CD32 68020/14Mhz 8Mb (Akiko Optimised C2P) - 12872 realtics (5.8 fps)
Amiga A1200 030/28Mhz 64Mb (Blitter 020 C2P) - 12727 realtics (5.8 fps)

We were talking about full 3d polygon games. DOOM is a raycasting game, which as a result has very simplified maths, and is a completely different ballgame.

rasz_pl wrote:

but what does he know, probably another incompetent hobbyist

The problem is not what he says, it's how you interpret it.
Everything he says aligns perfectly with what I said, about avoiding a system memory buffer:
"with main memory buffering."
The extra buffer would be slower, as he said (and I believe he means that you get tearing because you can't copy the buffer fast enough on an ISA system, you're racing the beam). Without the extra buffer, you'd get something way worse than tearing. But it would be faster than mode X.

I'm really not sure why you even try to participate in this thread. You have no idea what you're talking about.

rasz_pl wrote:

Btw Doom Alphas up to at least version 2 used pure 13h.

Yes, and then they optimized it, see your own quote.

rasz_pl wrote:

Im pretty sure ATI thread was about additional bitplane modes

I'm pretty sure you're a moron then, because the ATi Graphics Solution doesn't hvae any bitplane modes.
It only has CGA-style chunky modes.

Scali wrote:

As if 3d games were the only thing you could ever do with an Amiga, and Commodore 'scammed' people.
Not quite.

3D was the main thing selling in mid nineties. Tons of interviews with developers/publishers from the era stating how market changed overnight after Doom and everything had to be 3D.

Scali wrote:

But writing to chipmem isn't that fast.

hence all Cammys benchmarks used fastram configs

Scali wrote:

rasz_pl wrote:

1 did you come up with planar way of rendering 256 color pixels that is more efficient than chunky?

More efficient than chunky on Amiga?
Britelite already demonstrated that with Cyberwolf.

by drawing 8 color walls, aka touching 3 bitplanes.

Scali wrote:

rasz_pl wrote:

2 wouldnt you consider bulk conversion as a form of loop unrolling?

No, I consider it a redundant operation, much like memcpy'ing your memory around.

so what would you propose instead, read/write/read one pixel at a time? or assembling them by temporarily storing in 8 separate registe.. oh wait

Scali wrote:

Does anyone else see only 4 colours in Cyberwolf? Because I can see considerably more.

Sorry, I went back to the video and counted colors again, its actually 8, 3 bitplanes dedicated to walls.

Scali wrote:

rasz_pl wrote:

but what does he know, probably another incompetent hobbyist

The problem is not what he says, it's how you interpret it.

no, its how you painted yourself into a corner to the point of reinterpreting what Carmack himself meant when he clearly wrote
"Going to that trouble also gets a perfect page flip, rather than the tearing" as something other than Vsync without tearing.

Scali wrote:

Everything he says aligns perfectly with what I said

which part, the "nonsensical statements about 'tearing' and vsync." or "bit planar (THAT would stink)"? 😀

Scali wrote:

I'm really not sure why you even try to participate in this thread. You have no idea what you're talking about.

neither does Carmack according to you 😀 Im biting myself for lost opportunity of using his usenet post without quotes and having you call it stupid again 😀

Scali wrote:

rasz_pl wrote:

Btw Doom Alphas up to at least version 2 used pure 13h.

Yes, and then they optimized it, see your own quote.

to avoid tearing

Scali wrote:

rasz_pl wrote:

Im pretty sure ATI thread was about additional bitplane modes

I'm pretty sure you're a moron then

Whoa, no need for ad hominems, chill man. We argued, you said some questionable stuff, life goes on.

Scali wrote:

because the ATi Graphics Solution doesn't hvae any bitplane modes.It only has CGA-style chunky modes.

Plantronics "bi-planar technology" 4 color 640x200 sure looks planar

rasz_pl wrote:

3D was the main thing selling in mid nineties. Tons of interviews with developers/publishers from the era stating how market changed overnight after Doom and everything had to be 3D.

Yes, and?
It's a huge leap from there to "Commodore is scamming people'".

rasz_pl wrote:

hence all Cammys benchmarks used fastram configs

Oh please, the stupid, make it stop! This is getting really tiresome.
What is chipmem? Memory that can be accessed by the chipset.
What is fastmem? Memory that can be accessed only by the CPU.
What generates the output signal for your display? The chipset.
So where do you have to store your pixeldata? In chipmem.
Chipmem is basically the equivalent of video ram on a PC.

The fastmem is where the chunky buffer is stored. Which, as I said is entirely done by the CPU, not making any use of the Amiga's hardware (it has to be, else it can't be in fastmem, because blitter and other chips do not have access).

rasz_pl wrote:

by drawing 8 color walls, aka touching 3 bitplanes.

Oh, it's 8 colours now? Earlier you said it was 4.
I think it's more than 8 anyway.
Besides, that doesn't really matter, as said earlier. You can scale up to use more bitplanes, if you have the extra processing power to burn. So on an A1200 you could use ta similar approach, but with more colours.

rasz_pl wrote:

so what would you propose instead, read/write/read one pixel at a time? or assembling them by temporarily storing in 8 separate registe.. oh wait

No, you have to stop thinking in pixels and start thinking in bitplanes.

rasz_pl wrote:

no, its how you painted yourself into a corner to the point of reinterpreting what Carmack himself meant when he clearly wrote
"Going to that trouble also gets a perfect page flip, rather than the tearing" as something other than Vsync without tearing.

I didn't paint myself into a corner at all. You just don't have a clue what you're talking about (like with the above fastram remark).

rasz_pl wrote:

to avoid tearing

I'll let someone else explain it, because apparently I'm not getting through to you.
They can re-read my earlier explainations and try to paraphrase it in a way that you might actually understand.
What I said is simple and true. Carmack would certainly agree.

rasz_pl wrote:

Whoa, no need for ad hominems, chill man. We argued, you said some questionable stuff, life goes on.

I didn't say any questionable stuff. You however have made tons of retarded remarks which clearly demonstrate that you have no idea what you're talking about.
You just can't admit to that.

rasz_pl wrote:

Plantronics "bi-planar technology" 4 color 640x200 sure looks planar

Well, describe the pixel format to me then, because you keep failing to get to the point, and only making vague quotes which you yourself don't even understand.
Once you understand what pixel format Plantronics uses, you'll see that it is not like the Amiga or EGA, and as such does not quite have the same advantages and disadvantages.

rasz_pl wrote:

Plantronics "bi-planar technology" 4 color 640x200 sure looks planar

Yes and no. "Yes" in that it does indeed look planar, but "no" in that it is merely the easiest way to shoehorn additional modes into a combined CGA+Hercules card. Apart from that, it combines the disadvantages of both worlds.
You can neither write complete pixels in one go nor can you alter individual components. But what is most, you cannot write to both planes at the same time.

Let me try to drag this thread back to topic by quoting what I initially wrote about composite output off-topic in a different thread and then augmenting it with a few pictures. The ATI Small Wonder is a size reduced Graphics Solution, after all.

Benedikt wrote:

The colors in that video look suspiciously like the effects of a phase offset of n×90° between assumed and real NTSC color sub-c […]
Show full quote

Scali wrote:

Deksor wrote:

https://m.youtube.com/watch?v=-eRvF0aSYlc someone managed to get composite colors with this chip

Yes, that's me, with my Commodore PC20-III.
I also did one with an ATi Small Wonder, but its colours are all wrong in the 16-colour mode: https://youtu.be/eRVwYCq8X5w

The colors in that video look suspiciously like the effects of a phase offset of n×90° between assumed and real NTSC color sub-carrier, namely swapped and/or inverted redness and blueness components.
You are apparently not the first one to run into that problem: https://youtu.be/BdhvIfmRtvQ?t=393
But since that version of Commander Keen is a mod, anyway, there is still hope.

EDIT: In this particular case, both, the redness and the blueness component, are simply inverted.

That basically means that we are dealing with a phase offset of 180°.

I have taken these two frames from your Commander Keen video and inverted the two color components, manually.

It still doesn't look quite right, but this is more or less what you would expect via composite port.
Especially the yellow is ugly, but the original CGA couldn't output that properly, either.

This second example looks quite decent.

Either way, the tint control on a real NTSC TV set should be very helpful, because its very purpose was to allow the viewer to manually compensate for color sub-carrier phase errors.

Benedikt wrote:

rasz_pl wrote:

Plantronics "bi-planar technology" 4 color 640x200 sure looks planar

Yes and no. "Yes" in that it does indeed look planar, but "no" in that it is merely the easiest way to shoehorn additional modes into a combined CGA+Hercules card. Apart from that, it combines the disadvantages of both worlds.
You can neither write complete pixels in one go nor can you alter individual components. But what is most, you cannot write to both planes at the same time.

Aww, now you spoilt the surprise for him!

Anyway, wrapping up the Cyberwolf thing...
Here is the thread from Britelite on the English Amiga Board where he discusses development on his raycaster:
http://eab.abime.net/showthread.php?t=90115

It gives an insight into how it works.
He uses 4 bitplanes, and as you can read from the thread, a lot of it is to do with cleverly preparing your texture format and your 'chunky' buffer (not entirely an accurate name, since it's somewhat of a hybrid pixelbuffer with special data ordering).
So as I said: you have to stop thinking in pixels and start thinking in bitplanes. Sometimes rotating your data 90 degrees makes sense, or interleaving data from two or more scanlines etc. This way, part of the c2p logic is already rolled into your source textures and your 'chunky' column scaler.
From what I understood, the rest of the c2p logic is just some blitter passes, so making full use of the Amiga's hardware for best performance.

They also reference his earlier work, with a so-called 'copper chunky' routine. He used this in his demo Superoriginal: https://youtu.be/ZI8lMtjy8T8?t=144
This method uses a 'dirty' rendering routine where you render 'chunky' pixels directly into a copperlist (giving 12-bit truecolour, eat that, mode X!). You use black sprites to mask off some of the data.

Here's also an interesting video from that thread, showing the A500 renderer with actual Wolf3D data: https://youtu.be/6qsY8tXRFh0

Edit:
In the name of research, I also looked through some flatshaded Amiga 500 polygon games.
A title that came up was "No second prize", a motorcycle racing game, which was famous for having a very fast 3D engine.
There's also an Atari ST version, and someone compared them side-by-side:
https://www.youtube.com/watch?v=e4MLugmGSyk

Both versions are very good, difficult to tell which runs better.
As one of the comments says: the Amiga looks slightly better in the intro, but slightly worse in-game.
Which could boil down to the CPU-limitations mentioned earlier.
Some comments also theorize that the Amiga uses the blitter only in the intro, not in-game. Who knows.
What is clear to see though is that the Amiga uses more colours, for example, in the horizon gradient.
Regardless, both versions are well above '5 fps'.

Edit:
Also, to drive the point of double-buffering home... This is what happens when you draw 3D objects directly onto the frontbuffer:
https://www.youtube.com/watch?v=3Qb5mdGkt-o
You cannot 'race the beam', because your 3D stuff cannot be rendered left-to-right, top-to-bottom. This means that instead of just a vertical line with tearing, you get all sorts of flickering, because the beam shows some half-drawn objects.
In this case you can clearly see how the Amiga draws its polygons: first you draw the outline, then you perform an area fill. The flickering is because the beam passes through the frontbuffer somewhere halfway through the filling process.
The same would happen if you would render Wolf3D directly to the frontbuffer: you render top-to-bottom, while the beam goes left-to-right. So you will see some columns from the new frame, and some from the previous frame (or empty columns if the routine clears the screen first). Sprites would probably suffer the worst, because they're drawn on top of the walls, at the last step of the rendering process.
Which is why Carmack talks about rendering to a mainmem buffer, and then copying that to the frontbuffer in mode 13h. The copy operation is left-to-right, top-to-bottom. However, if your copy operation is slower than the beam (which it was on ISA systems: to stay ahead of the beam, you need to be able to write to vram with blocks of 320x200 bytes at 70 fps, which is 320x200x70 = ~4.5 MB/s, and you also need to read the same data from system memory, so you need ~9 MB/s total bandwidth for the copy operation. See here for a comparison, even the fastest ISA VGA cards can barely reach 5 MB/s, and that is in a Pentium III 800: ftp://78.46.141.148/docs/eliandas_isa_vga_roundup.pdf), you will see a horizontal tear at the point where the beam overtakes the copy loop: the rest of the display will be the previous frame.
(The 8088 MPH polygon renderer is somewhat unique in that it does render left-to-right, top-to-bottom, so it does not require a backbuffer, which CGA doesn't have, like mode 13h)

rasz_pl wrote:

Cammy wrote:

DoomAttack -forcedemo -timedemo demo3 […]
Show full quote

DoomAttack -forcedemo -timedemo demo3

A1200 030/50Mhz 32Mb (Optimised 020 C2P) - 8481 realtics (8.8 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised 020 C2P) - 18971 realtics (3.9 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised Akiko C2P) - 12872 realtics (5.8 fps)

Btw this might be the one Grzyb was waiting for - Doom running in either bitplanes mode (C2P on CPU) versus chunky (simulated with Akkio on same hardware platform (cpu/ram).

So... some random DOOM port (with unknown degrees of "optimisation") is running slowly on Motorola CPUs that are basically equivalent to high-end 286s and middling 386s? And that's supposed to tell us something about the relative strengths of video architectures? 🤣

Kind of silly to pretend that you're trying to find a serious answer to "planar vs. chunky for 3D", when you insist on such poorly chosen test subjects - unknown degrees of optimisation for different CPUs, unknown degrees of optimisation for different graphics architectures, and not venturing beyond *two specific games* that were PC/VGA-centric in the first place.

I've never owned an Amiga (never even seen one back when it was current), so I'm not emotionally invested either for or against it, but my bullshit detector is functional enough. 😉

More on-topic: how well would an ATi Graphics Solution (or regular CGA) handle 3D/Wolfensteinish games? 😀

rasz_pl wrote:

wasnt there an EGA Wolfenstein project somewhere?
maybe https://github.com/CatacombGames/Catacomb3D could shed some light on efficiency/inefficiency

Catacomb 3-D pre-dates Wolfenstein 3D, and can be seen as the 'prototype' (same team of devs, basically).
By the looks of things, it uses EGA write mode 2, and sets the mask register to draw a column of pixels into 4 bitplanes at a time, by just writing one byte to video memory (the low 4 bits are distributed to the respective planes).
So technically that is basically the same idea as Wolfenstein 3D, just adapted for the EGA logic rather than mode X logic.
I would expect performance to be about the same.
Edit: just tested both on my 286-20 (ET4000), and Catacomb 3-D is slightly faster. Even without the turbo (286-8), it is quite playable. Wolf3D is too sluggish (could be because the rendering itself is about the same speed, but Wolf3D has larger levels with more enemies and such, but I'd say it's about 5 fps at 8 MHz. Certainly slower than Cyberwolf on a stock A500).

To also conclude the blitter-debate:
I asked one of the WHDLoad contributors. And indeed, there are a lot of games that use the blitter for drawing/filling polygons on Amiga.
Microprose games such as F-117A and F-19 were mentioned as specific examples.
Edit: No Second Prize was also mentioned as a game that uses the blitter extensively for all 3D drawing.

Aside from that, I suppose it is low-hanging fruit for any game to at least use the blitter for clearing buffers and performing memcpy, even if you wouldn't actually draw the polygons. So I wouldn't be surprised if at least some games used the blitter in that way, even if they're otherwise 'Atari ST ports'.

Okay, I think it's now safe to stick to ATi Graphics Solution discussion 😀

Scali wrote:

Catacomb 3-D pre-dates Wolfenstein 3D, and can be seen as the 'prototype' (same team of devs, basically). By the looks of things […]
Show full quote

rasz_pl wrote:

wasnt there an EGA Wolfenstein project somewhere?
maybe https://github.com/CatacombGames/Catacomb3D could shed some light on efficiency/inefficiency

Catacomb 3-D pre-dates Wolfenstein 3D, and can be seen as the 'prototype' (same team of devs, basically).
By the looks of things, it uses EGA write mode 2, and sets the mask register to draw a column of pixels into 4 bitplanes at a time, by just writing one byte to video memory (the low 4 bits are distributed to the respective planes).
So technically that is basically the same idea as Wolfenstein 3D, just adapted for the EGA logic rather than mode X logic.
I would expect performance to be about the same.
Edit: just tested both on my 286-20 (ET4000), and Catacomb 3-D is slightly faster. Even without the turbo (286-8), it is quite playable. Wolf3D is too sluggish (could be because the rendering itself is about the same speed, but Wolf3D has larger levels with more enemies and such, but I'd say it's about 5 fps at 8 MHz. Certainly slower than Cyberwolf on a stock A500).

Wolf3d needs you to shrink the viewport to achieve viable framerates on a 286, although the system in question (back in the day) was also sporting a shit OTI video card.