3D FPS like this on Amiga
 

OK, so I finally found almost perfect example of fast paced fps that's been on my mind, for some years, that (maybe) could be done on Amiga;

Watch, exactly from 2 minutes:
https://youtu.be/OipJYWhMi3k?t=119

Ok, so let's say we have 4 to 8 colors in total, and for enemies, I have no idea what is faster. either 4 colors drawn characters, either 1 color vector shapes.
And of course, this is Quake, so much less polygons then this. :)

Do you think it would be possible on A500 1MB, and having (almost) constant 50 fps?
If yes, what do you think is the polygon maximum count on the screen?

And basically, add whatever thoughts you have.
---------------------

P.S. I know about Behind the Iron Gate, and I really, really like it. But I am thinking on gameplay more closer to doom....

I have been searching in vain for the past hour trying to find a Monochrome FPS I saw on steam that I thought looked real stylish, I could not find it as the search is pretty useless.

This was the closest I could find, obvs no chance on the Amiga BUT shows that you dont need 24bit colour graphics to look good!
https://www.youtube.com/watch?v=3bPNSGgMtoQ

The fastest polygon engine I can think of on the A500 is No Second Prize, which has very few polygons and doesn't have to deal with 360 degree movement.

More appropriate would be something like Knights of the Sky which runs at about 10fps on an A500 but is sort of playable as a Doom clone. But having seen the videos of Dread, who knows what is actually possible.

That is Quake and it is already on Amiga.

4DShooter was an effort to simplify the models and maps in Quake so that it can run on slower machines.

http://eab.abime.net/showpost.php?p=1105019&postcount=1


Maps like White Room show how stylised maps can alter the feel of the game.

https://www.quaddicted.com/reviews/whiteroom.html


Virtual World is a Tron style map.

https://www.quaddicted.com/reviews/digs02.html


Noir is a simple pallete change to play Quake in greyscale

http://www.quaketastic.com/files/sin.../mods/noir.zip

Tnx guys.

@lilwshu
Exactly my thoughts.
No Second Prize is amazing piece, and even the enemy bikes are 3D. They should've release source code for it.
Hmm... if source code is not lost, maybe we could bother them to death on email, until they give us. :)

https://www.youtube.com/watch?v=dW-RJyI8LGs

SuperHot, perhaps? It's an incredible game, had the chance to play it in VR. As a bonus, it includes plenty of Amiga references in the in-between phases :)

Hey are you by chance mentioning Unfinished Swan?
Unfinished Swan preview

What a cool game - something different! Sadly its available only for PS3 and not for PC.

I wonder if with some adjustment a similar dynamic could be used with the 500 doom engine, like make a maze to escape using painting the walls, no ladder or such

So, I can actually chime in with my experience on Jaguar, as I burnt a lot of time on benchmarking and optimizing my 3D flatshading engine to get to 30/60 fps with a Quake scene.


I recreated the room at the start of Quake, where you choose the difficulty.


I have very quickly observed that the vertical pillars are the killer of FPS, because you have these very thin (4-8 px) pillars that span almost whole screen height, and you have to do scanline traversal and spin up Blitter up to 200x per each triangle, to only fill couple pixels.
Now, even if you only have 6 such pillars in the scene, this is how it breaks down:
- 6 pillars = 6*2 visible rectangles = 6*2*2 = 24 triangles

Up close, those 24 triangles have up to 200px height. That's 200 scanlines. Per Triangle.

That's 200*24 = 4,800 scanlines. In just few thin pillars. Not even 26.6 MHz RISC GPU running out of cache can traverse that many scanlines at 60 fps. And there's 10x more polygons around.


Now, on Jaguar, it was possible to configure the Blitter in a way that does vertical blits. It is much slower (per pixel written) than a classical horizontal blit, but there is a threshold where it's faster to do the slower vertical blit rather than series of faster (but many more) horizontal blits.


Not sure if Amiga's Blitter can be configured the same, to achieve the vertical lines - someone with Amiga experience could perhaps confirm/rule out this ?

You are asking way too much of a 7 MHz 68000.


Even on Jaguar, where I had my 3D engine running on 26.6 MHz RISC GPU, (and I was getting around 13-14 MIPS out of it) and Jag had a Blitter sitting on the same 64-bit bus as the GPU, your scanline throughput was very limited.


If I recall correctly, my fastest scanline traversal version (I wrote about 6 of them) could do about 2,200 scanlines at 60 fps (I am in NTSC area), assuming you devoted full 100% of the 26.6 MHz GPU to just that and nothing else. That was RISC assembler code running fully from within the fast 4 KB cache, without any access to slow RAM.




A 7 MHz 68000 is absolutely crippled compared to 26.6 MHz RISC. Probably about 30x-50x slower. On top of that, you need to do 3D transform, clipping and scene management.


And we're going to assume here that since we're talking indoor FPS shooter here, we don't have to do a clear of the framebuffer, as it will be guaranteed that each pixel will be redrawn. Thus, you don't waste any cycles on clearing screen.


Still, a 7 MHz 68000 has only around 116,000 cycles per frame at 60 fps (probably slightly less than that due to system design). Great many instructions take 16-24 cycles. Even if we take just 20 cycles as average, that's only ~5,800 ops.


You can't really do much of a 3D with ~5,000 ops. And that's assuming LookUp tables for 3D transform (forget about doing MUL/DIV on 68000 at 60 fps unless we're talking THREE polygons)




Your best compromise at 60 fps is to reduce the viewport size drastically (halving vertically will halve amount of scanline traversal stage which is the worst offender) and rendering just some distant polygons (never allow object to cover whole viewport vertically).

To offer some sort of answer to your question, the fastest 3D scene will have just few scanlines, so your level design must be strictly horizontal - e.g. very wide polygons that are very short vertically.


Kinda like the floor + few short walls in that Quake video you linked (without the tall walls). Something like that, could run at 60 fps. Though, then you have a problem as you aren't clearing framebuffer, and your scene covers just bottom portion of screen, so you must come up with some smart clearing mechanism, that only clears minimum amount of scanlines possible...

You can do a vertical fill by using 2x the target buffer as source, one line apart, and then use an XOR minterm (but no fill mode). Like D = D ^ (D - 1). It then works like a horizontal blitter fill, with the distinction that source and target have to be the same.

This has, however, also the same problem as a horizontal blitter fill - if you want it to work efficiently, e.g. in one pass for the whole scene, you have to break up overlapping polygons, which is rather non-trivial and time consuming. But to render Doom-like walls without overlap it should work well.

EDIT: Actually D = A ^ (D-1) should also work, with A being the outline buffer - then you only have to clear the outlines, not the whole buffer.

Thanks.

Also, you reminded me of the single pass approach on Amiga.

That's very different from the spinning up the Blitter thousand times per frame.

I don't have experience with this approach so don't know the limits involved.

It's quite possible that very complex scenes could be done by this way...

If you by "spinning up the Blitter thousand times per frame" mean a blitter-based span filler, I do not think that's a feasible approach on the Amiga. For pure clear the CPU is as fast as the blitter (every 2nd mem cycle), and most probably instruction fetch/register setup time for a movem is less than blitter setup/waiting overhead.

Yeah, I meant using blitter for drawing each scanline of a polygon - meaning you traverse the edges, line by line, compute endpoints (xpStart, xpEnd) and set the Blitter registers for the scanline.


Then, in parallel, while Blitter is busy drawing the current scanline, the CPU continues the loop and is computing the endpoints for the next scanline.


Only when it's time to submit new endpoints to the Blitter, you initiate a WaitForBlitter.


On Jaguar, I interleaved the RISC code in a way that the BlitterWaitTime was only around 8% of frame time. So, not too bad. But, if you simply waited right after each scanline, then the waittime jumped to ~25%.


Not sure, how parallel the execution of 68000 vs Blitter on Amiga is like.


What's the CPU priority on the bus when Blitter is accessing RAM? Or does Amiga's Blitter have separate read/write access lines to RAM on Amiga ? Thus, it won't block CPU ?

On the Amiga, the Blitter steals cycles from the CPU. There are two options:

• The Blitter gets all cycles it needs, the CPU gets zero during Blitter activity on the bus
• The Blitter gives one cycle to the CPU every time the CPU has been waiting on DMA for at least three cycles in a row.

There are some caveats here because not all Blitter operations can actually use all of the bus (some things, such as clearing, have idle cycles during which the Blitter does not access memory even when running). But in general, the above holds.

Ouch :)


Dude, you're making me appreciate Jaguar's sh*tty architecture more and more :) !

Just in case it wasn't clear, the blitter steals cycles from the CPU when the CPU's running from or accessing Chip RAM. Fast RAM, if present, is on a separate bus which isn't affected by the blitter.

For a span filler and solid polygons the blitter is in clearing mode (D only)*, so the idle cycles become relevant, meaning the CPU can work at full speed in parallel to the blitter here if no other DMA is active. That might be useful for large spans - but probably the overhead to setup the blitter makes it still slower than a CPU-only routine.

* apart from the first and last word