3D FPS like this on Amiga

[VladR]

Originally Posted by robinsonb5

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.

Yeah, I definitely didn't realize that. I'm still new to the Amiga thingy and keep getting confused about all those terms, as I didn't spent last 3 decades reading up on all those terms.


I guess all my experience is only directly useable on a 060/080, as even though Jag also has a 68000 (@13.3 MHz) it is still feeding Blitter, which behaves quite differently on that architecture...

[VladR]

Originally Posted by chb

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

Yeah, I reckon for something like spaceships (say, in a game like Guardian), it would be faster to use a CPU-only codepath as most of the time, the spans would be just 2-8 pixels.


Large polygons - like a floor, or a road, would use a blitter codepath and would in parallel let CPU compute endpoints of next span.


Just not fullscreen on 7 MHz at 60 fps...

[roondar]

Originally Posted by VladR

Yeah, I definitely didn't realize that. I'm still new to the Amiga thingy and keep getting confused about all those terms, as I didn't spent last 3 decades reading up on all those terms.

Ah yes, I do apologise for not making that clearer. Yes, fast memory (and ROM for that matter) can be accessed by the CPU without impacting the Blitter or the CPU being impacted by DMA. The A500 normally has no fast memory though, so for that platform it would not matter.

Even the "trap door" memory expansion on the A500 is not actually fast memory, but something called "slow memory". That is the worst of both worlds: slow memory can't be used by the custom chips (because it isn't chip memory)*, but it is slowed down by DMA on the chip memory bus

*) note that even here there are caveats: from a certain revision onwards, the A500 contained a version of Agnus that can access (some or all of) trap door memory as chip memory. Confusion all around then

[d4rk3lf]

Originally Posted by VladR

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

Just to be clear on this.
I know that Quake reference I gave is waaay too much polygons.

Here is the better example:
Watch from 5:30
[ Show youtube player ]

Now, there's a lot's of attempts for 3D on Amiga 500 1MB, and many of them are trying to do fully textured 3D walls (Cytadela, for example).
I just wonder, why no one attempted very simple, single colored walls, but very fast and playful game, doom like, or wolf 3D style.
Architecture doesn't have to be more complex then above in the Moonfall sample.
There is a Behind of Iron Gate game, but it's played with mouse, witch, imho, ruins gameplay a little bit.
-------------------

Btw, you are probably aware of this guy 3D shooter attempt:
http://eab.abime.net/showthread.php?t=98654

But maybe you should look at very first presentation of that game, because KK explain some technical stuff on how his game works.
Somewhere at 1:30h mark is that explanation
(yeah, rewinding is tricky in that site)
https://scenesat.com/videoarchive/138

Now, this might be useful to you, or might not be, I am personally no coder, and I have no idea what he is talking about, but I thought, maybe it can give you some ideas for your own game, to run even faster.

Also, there's Britelite demo running really smooth at 7Mhz, here:
(and is also fully textured )
http://eab.abime.net/showpost.php?p=...4&postcount=14

P.S. I know your goal isn't 7Mhz 68000, but rather 060/080, but as I said, hopefully, some of the tricks might help you.

[VladR]

I understand you didn't mean Quake at 60 fps on A500, but a full-screen flatshaded 3d at 60 fps on 7 MHz 68000 is too much.

The Moonfall looks like Mercenary on 8-bit Atari. I haven't done the single-pass Blitter rendering on A500, so not sure if it can do it at 60 fps, but I doubt it.

I couldn't see the other videos you posted as they don't play in my browser, but I don't think it's fair to compare 60 fps with ~10 fps game. It's 6:1 in terms of CPU time.

If we settle on 12 fps, that's 5 frames of CPU time. That is enough even for 7 MHz A500 to do some nice flatshaded scenes.

Like those other games, 12 fps can be quite smooth, as long as you reduce the movement speed accordingly.

[VladR]

Originally Posted by d4rk3lf

Just to be clear on this.
P.S. I know your goal isn't 7Mhz 68000, but rather 060/080, but as I said, hopefully, some of the tricks might help you.

Not necessarily. I personally vastly prefer going down the rabbit hole of cycle optimization. It's always been my unhealthy obsession.


But to eke out living out of it, you need a product to sell and that's two orders of magnitude more work than few rendering routines. Granted, the complexity of game is my choice and it could have been simpler, that's for sure.




That being said, I wouldn't rule out a kickstarter which would fund (say, 250-500 copies as a target) the 7 MHz A500 target and spend 6-12 months implementing dozen+ algorithms to see which one is fastest.

[absence]

Originally Posted by roondar

note that even here there are caveats: from a certain revision onwards, the A500 contained a version of Agnus that can access (some or all of) trap door memory as chip memory.

It's worth mentioning that this is only relevant if you modify the motherboard, as the Agnus isn't connected to the trap door memory otherwise.

[robinsonb5]

Originally Posted by absence

It's worth mentioning that this is only relevant if you modify the motherboard, as the Agnus isn't connected to the trap door memory otherwise.

That's the interesting thing - ECS Agnus *can* see the trapdoor RAM - but it sees it at $80000, while the CPU sees it at $c00000. All the mod does is change the address of the trapdoor RAM.

(See http://eab.abime.net/showthread.php?t=36905)

[absence]

I should've double checked such old knowledge before commenting. The trap door memory is of course connected to the memory controller, which is inside Agnus... Interesting thread by the way, I'd never thought about that possibility, although it makes perfect sense looking at the schematics.

[robinsonb5]

Originally Posted by absence

Interesting thread by the way, I'd never thought about that possibility, although it makes perfect sense looking at the schematics.

Yes, likewise - it came as a bit of a revelation to me when Toni mentioned it in another thread a year or so back!