Quake 2 on Falcon030

[Shredder11]

Now every Amiga 1200 fans have a good opportunity to proof that the Amiga is best. They only need to make a Quake2 conversion that runs at a stock machine and beats this and the discussion is over

Hang your head in shame!

Embedded Video

[FedePede04]

you know guys, there's a reason why close relative can't have children

Now every Amiga 1200 fans have a good opportunity to proof that the Amiga is best. They only need to make a Quake2 conversion that runs at a stock machine and beats this and the discussion is over

Hang your head in shame!

Embedded Video

[Zamuel_a]

There were so much talk in anothere thread here, that the Amiga was better at 3D than Atari, but he didn't give any good examples of that so now it's up to proof
(I think the conclusion of that discussion was that an accelerated Amiga 4000 was better than an Atari ST)

[CiH]

Do not press play on that video!

D O - N O T - P R E S S - PLAY ! ! !

R E A L L Y, - D O - N O T - C L I C K - I T ! ! ! !

[Mindthreat]

Can't press play if I wanted to. The embedded videos do not work for me and I have no linky to see where they go. Someone mind posting the link instead please? Thanks

[Shredder11]

http://youtu.be/_m6jqymC1D0

[TheNameOfTheGame]

Can't press play if I wanted to. The embedded videos do not work for me and I have no linky to see where they go. Someone mind posting the link instead please? Thanks

Well you asked for it!

[dml]

I just watched and hat off to you Doug!!!
I newer thought something like that would be possible on plain Falcon. And you still have ideas how to improve ...

TBH, I wasn't 100% sure either to begin with. Thought it was worth trying though

Regarding hardware ... there is already FireBee available with more CPU power as 060 and if there would be more FPGA developers participating as alexh is it wold be also hardware compatible with the Falcon ...

It is certainly the way to keep the platform alive (alongside emulation of course). I'm sure this will evolve with time if more developers get involved.

Well ... really great and now as I have Falcon and CT60 with SuperVidel waiting to be installed, I will reconsider to ruin original machine with it

I keep a plain, unmodified board handy, almost entirely to keep myself honest!

[dml]

(I think the conclusion of that discussion was that an accelerated Amiga 4000 was better than an Atari ST)

I'm glad they cleared that one up for us

[dml]

Hang your head in shame!

This is clearly one of the downsides of embedded video. I remember the scarring content just from the thumb.

[dml]

There were so much talk in anothere thread here, that the Amiga was better at 3D than Atari, but he didn't give any good examples of that so now it's up to proof

I read through that thread as well - TBH apart from some sparks of lucidity here and there, it read mostly as speculation, fallacies and distractions. I don't think we'll get much sense out of that particular discussion.

Every discussion I have seen of this kind ends by changing the subject in order to spin the argument onto apparently solid ground - which often works if you don't notice the trick... Like you, I prefer to stick with examples an facts as much as possible


IIRC there are at least 4 different ways to accelerate polygon filling with a blitter on Amiga, assuming flat colour fill and bitplanes. One of them is very Amiga-specific, relating to area fill capability. One of them is blitter-specific, possible on both platforms, and refers to a logic trick described in a Siggraph paper from the late 80's or early '90s (I have a print copy in storage). One relates to parallelism, possible on Amigas and Falcon. The fourth relates to vertical column filling vs horizontal spans, which I believe isn't much used, probably because of the big problems it has with corners and diminishing returns on small polys.

If you're filling a massive cube or some 'Glenz vector' thing, then Amiga has some advantage - particlarly A500 vs ST. Probably less so on Falcon vs A1200. This is because it can use the hardware methods to assist 'contrived scenery'. I won't go into the details of the contrivance - suffice to say that you need to be damned careful about what you're drawing or you run into serious problems.

If however you want to draw lots and lots of surfaces for a game, you're going to find it difficult to use the hardware tricks, and probably stuck with exploiting parallelism, which also works on a Falcon.

So while the devil is in the details, I think the Amiga argument sticks for certain things, and then runs out of steam very rapidly as you try to render something arbitrarily complex like a game.

When it comes to using anything other than flat-fills, Falcon will always have more options available.

I'm happy to see someone take that argument apart however - particularly with a concrete example.

[Shredder11]

It's all a bit of fun and no 16-bit wars re-invoked The Amiga 4000 is probably more powerful than the entire top end of the Atari range, but that does not mean I would want to use the Amiga for what I did back in the 90s / 00s, which was mainly music sequencing and production and the Atari was in mine and many others opinion, the only choice to make. It's not all about power and specifications either, the Atari had both but it also appealed to musicians for its feel, simplicity and great range of software....not to mention that wonderful if small 12" monochrome SM124 monitor!

If anyone requires any psychological help after watching THAT video, I am sure there will be people here that can assist!


OK topic back on track which is errr oh yes.....Quake 2 on Falcon 030!

[dml]

OK topic back on track which is errr oh yes.....Quake 2 on Falcon 030!

Yep certainly don't want to invoke the old war here, and I've got nothing against Amiga itself - was writing code on it long ago . But a great deal of confusion ensues when 3D is discussed on these platforms.

[dml]

One of the things which will be done after the performance is good enough, is to fence off the Quake2 specific areas (really, the BSP model reader and some related parts) as adapted inputs to the main engine. In this way the engine is not tied to Quake2 at all, but can still deal with data from that toolchain. Quake1 support will likely be included because it is very close.

This seems reasonable because the Falcon rendering pipe is not built from the Q2 sources (although I do refer to it to help implement and fix stuff relating to Q2 BSPs). It's completely independent of that.

So I can probably create adapters for other data sources e.g. .DXF models, Blender, Maya etc. etc. At the bottom level, the rasterizer will be independent of these and can be used directly, for drawing polygons from arbitrary data. So if somebody wants to plug it into a game they are making it should be possible to do that at more than one level.

[Zamuel_a]

One of the things which will be done after the performance is good enough, is to fence off the Quake2 specific areas (really, the BSP model reader and some related parts) as adapted inputs to the main engine. In this way the engine is not tied to Quake2 at all, but can still deal with data from that toolchain. Quake1 support will likely be included because it is very close.

This seems reasonable because the Falcon rendering pipe is not built from the Q2 sources (although I do refer to it to help implement and fix stuff relating to Q2 BSPs). It's completely independent of that.

So I can probably create adapters for other data sources e.g. .DXF models, Blender, Maya etc. etc. At the bottom level, the rasterizer will be independent of these and can be used directly, for drawing polygons from arbitrary data. So if somebody wants to plug it into a game they are making it should be possible to do that at more than one level.

That is very cool! So does it means you could rather "easy" adapt it to other games? For example Descent which seems like a good Falcon game and that would benefit from your texture mapper.

[dml]

That is very cool! So does it means you could rather "easy" adapt it to other games? For example Descent which seems like a good Falcon game and that would benefit from your texture mapper.

Yes that was the plan from the start - get an equivalent technology working on Falcon, general enough to use for other stuff. I deliberately avoided just porting the Id code so this would be possible - as small and general purpose as I could manage. I think it's working out pretty well so far (i.e. not rigidly stuck with Quake game data).

Remains to be seen if anyone wants to pick it up and use it, but it will be available to do so if anyone wants it.

[calimero]

That is very cool! So does it means you could rather "easy" adapt it to other games? For example Descent which seems like a good Falcon game and that would benefit from your texture mapper.

I think that what Doug would like to say is that some of us could start to build complete new game for Falcon based on his technology...
...I know that I would gladly take a part in such crazy journey if there are others interested!

[dml]

Yes thats the idea!


Yesterday I made some changes which allow rendering to work with a common/shared geometry format, instead of being BSP-centric. So far it has been difficult to draw a skybox (or other stuff) without specific code and there's not much DSP space left for new code, so with these changes it's possible to define separate models for the world, doors, sky, game objects and have them rendered by the same path.

Later it should also be possible to draw multiple BSPs as a generic model type, so you can have more flexible choices - e.g. build a spacecraft in Quark and have it prelit automatically and then load and use it as a dynamic model. This way you get all the benefits of radiosity and self-lighting on the model, and can still have dynamics e.g. wings that fold, using BModels + some basic AI to control rotation. You also get accurate collision brushes for free that way.

It will still be possible to draw non-BSP models, but in that case there will be more to do manually to achieve similar effects.

[dml]

A bit more hacking tonight got the skybox to work on the PC build of the code, and the Falcon version is about 70% done. Needs some DSP work to catch up with changes to support multiple model contexts.

There were some headaches due to the size of the skybox, projection precision, zclipping precision... causing the edges to wander from their coordinates and created seams between the skybox faces. I fixed this in the PC version by making it a bit closer to the DSP projection math, and moved the near-z clipping plane farther away from the eye so the x/y coordinates didn't get so huge.

I try to keep the PC version using the same integer number ranges as the Falcon one so things like this can be investigated a bit more easily. But they are not exactly the same in all areas (like in this case), so I'm not sure what problems the Falcon will throw up yet. Just need to try it and then fix stuff that goes wrong.

As a last resort the skybox can use orthographic projection (or flattened depth values) so no zclip is required - just viewport clipping.

[dml]

Last changes yesterday resulted in a semi-working skybox on the Falcon. I won't get much time to improve on it until later in the week but it's moving along.

I had a bit of trouble with it initially but mainly because my PC test version was wrong, and just hid some problems (edge winding order was faulty in an obscure way). I also had to backface cull manually while testing a smaller version, so I wouldn't run into clipping issues early with big distances. It's one of those cases where backface culling + poly winding order + plane signs etc. all result in a silly number of nonworking permutations and only one is correct

Anyway the multiple-models upgrade works on the Falcon, and the skybox itself works up to the moderate size I tested with. The projection looks accurate so textures seams don't appear to be an issue (yet).

However the texturemapping fragment breaks at such large distances, and needs a 3rd mode to handle it. It does work up to about 1000 units then goes crazy. I already had 2 modes for near and intermediate distances so a 3rd probably isn't a big deal

The texture still draws incorrectly because the skybox textures are still 256 colour, and the renderer assumes TC.

grab0088.png

It does look like a minor change (and currently ugly) but significant upgrading was needed to deal with it, and lays some groundwork for fast model drawing for the ingame objects.

[dml]

Minor update:

Replaced the surface cache filler - which was a mixture of C and inline 68k - with a pure 68k optimized version, at least for tile rows. Tile columns are still a level above and in C and makes calls to the 68k per column. This outer part will get converted next so its all one nice compact block.

The result is already much better with less choppyness while moving around. Still not great but much better. A few changes still needed here.

I was able to test it finally on my 68040 machine but only with pedantic DSP synchronization per pixel. The framerate is perhaps 25% higher than a stock Falcon, limited mainly due to the fillrate bottleneck imposed by pedantic sync. But the speed remains much less variable across different locations and it works reliably.

I also tested in the newest Hatari, but found it explodes immediately with default settings. I had to disable cycle-accurate and prefetch modes to get it to work - and then it runs at a ridiculous 15-20fps in 030/16 mode. Which is clearly wrong. I haven't figured out whats going on here but it looks like the mixture of 68030 + 68882 + asm code is somehow upsetting the emulator and causing weird side effects not seen even on my 040 machine... this is going to take time to make sense of. I didn't see this effect on BadMooD (which doesn't use any compiled FPU code)

[dml]

Over lunchtime will try to make some changes which control filtering type in the surface cache so the highest quality lightmap filtering will be done only on the nearest surfaces. Intermediate distances will use center-average and the most distant will use a corner sample only. This should really accelerate filling for distant scenery coming into view, only needing about 60% as much code.

Earlier tests also showed that the surface cache filler greatly benefits from the 68030 datacache since textures are addressed as simple tiles of 8bit samples, in row-column order. A real Falcon is therefore measurably faster at this than Hatari (1.7-1.8 anyway, not sure about later versions yet).

[dml]

That worked. 'tis faster.

[Scarlettkitten]

yay

[shoggoth]

That worked. 'tis faster.

Prove it.