Quake 2 on Falcon030

[shoggoth]

Almost... Unreal(TM).

[dml]

Thanks everyone - it's been quite a bit of effort to get it this far and visible change from version to version is gradual. Making videos look different is a problem! Happy that it's still being followed with interest

Will see what can be done next.

[dml]

Small bonus extra...

The last thing I did was enable the dynamic model rasterizer - which is still pretty broken but does draw the map objects spinning on their spawnpoints. It also draws weapons and player skins.

The object drawing code has several problems . It is all still in C and very slow. It doesn't understand the truecolour framebuffer properly, and can't access a z-buffer. So everything is visible through walls. It's not connected properly to the PVS so stuff appears and disappears at random.

It's little more than a placeholder, to be replaced from the ground up. Still, it's a start... a matter of time and work.

....aaaand a little more patience would have fixed that colour bug before grabbing the video!

grab0065.png

[dml]

Have replaced the previous video with a new one after two important bugfixes:

-----

It would also be nice to get the doors working, or at least visible...

[EDIT] YT encode was broken, uploading new one

[dml]

Problems encoding the last vid, uploaded again: https://www.youtube.com/watch?v=h4ycoB6 ... e=youtu.be

If I don't re-convert each video recorded from Hatari, YT seems to drop at least half of the frames out of the video.

[shoggoth]

I'm guessing the step from Z-buffer to 3D clipping isn't exactly trivial! Does it perform an 8-bit->hicolor + z-buffer lookup atm, or did I misinterpret your post?

[dml]

The current code is based on the original C code, and it wants to read/write the Zbuffer - but there isn't one so I had to stub it out.

The final version could use one of a few options (including a full zbuffer, or an encoded lookup as you suggest) but the one I'll attempt first is without a Zbuffer, integrating with the wall-drawing code which is view-dependent BSP-ordered by encountered leaves. Leaves contain objects (approximately) so its a fair place to start with sorting.

[Zogging Hell]

It's amazing how just rendering the grenade launcher and a few pick ups in there makes it look more like an actual game rather than a very impressive demo. I actually finally brought this on Steam for the PC, to actually see what the original looked like as I'd only ever had the N64 version before (completely different level layout). Keep up the good work DML.

[dml]

It's amazing how just rendering the grenade launcher and a few pick ups in there makes it look more like an actual game rather than a very impressive demo. I actually finally brought this on Steam for the PC, to actually see what the original looked like as I'd only ever had the N64 version before (completely different level layout). Keep up the good work DML.

Yeah enabling the object stuff makes it run very slow currently but it does give a very different impression. Should improve greatly once the code is all rewritten and integrated into the scenery drawing.

[dml]

I think that textures should probably be dropped from objects because polycount is relatively high relative to size on-screen. Setup overhead will be high, especially for objects at distance (and there are no LODs in the game for distance drawing).

I had the idea that the object drawing should be an extension of the alpha/transparency part of scenery drawing - polygons get sorted/occluded/clipped but they do not themselves occlude, even if they look 'solid' - they don't hide pixels behind them. This keeps scenery drawing fast while supporting fast throughput for small polygons in the object meshes.

The transparency system itself is still being worked out - because.... Q2 again uses a zbuffer and tests the distance of every transparent pixel! I'm going to try to integrate it into the spanbuffer logic instead so it can emit multiple spans at various depths simultaneously, without z-testing. It is worked out on paper but currently unsure what the impact will be on the code. Still its worth trying if it solves transparent surfaces (glass, water) in scenery and object drawing at the same time.

[Zogging Hell]

Yeah enabling the object stuff makes it run very slow currently but it does give a very different impression. Should improve greatly once the code is all rewritten and integrated into the scenery drawing.

Considering you literally just switched on and 'bodged' it working, I thought it was surprisingly fast - it's already more responsive than Core's Corporation on the ST..

[dml]

There is quite a lot of 'not seen' material in the current engine which has no drawing path. The model (.MD2) drawing stuff is quite bad for Falcon and none of it will remain so it has been turned off again.

The doors and other BSP map objects however look like they can be integrated directly with scenery drawing since their geometry is stored/indexed in the same .BSP map structure and just requires some extra stuff to position, rotate and backface them. The rest is mostly the same as for walls. I'll probably try that first.

The model drawing and transparency will take a lot of combined effort so I expect a quick version of that won't appear for a while, and might not make another appearance until later.

[dml]

I think I may have a way to draw the doors (BModels) properly without a z-buffer. I tried first linking them off BSP leaves to see how it looked but since they are large they tend to occupy more than one leaf, and the drawing order ends up wrong depending on where you are viewing from.

However there is a clue in the Q II source which splits BModels by BSP planes to get smaller pieces mapped to leaves, acquires BSP sort keys for the pieces then z-sorts them against other stuff. I can't do the z-sorting part in the same way but the splitting step is useful. The difference is I need to reference the split pieces off the BSP and trigger them at traversal time to get the sort keys in sequence with the BSP. This should eliminate the scenery/BModel sorting issues.

This is quite complicated to set up so it won't appear in the F30 version for a while.

It also doesn't deal with dynamic models but I'll use another method for those.


I did get door portal logic working tonight so the map now turns on/off sections behind doors when they move. Since doors are still invisible this means you get an empty void at door junctions for now until you walk near them.

[Eero Tamminen]

I think that textures should probably be dropped from objects because polycount is relatively high relative to size on-screen. Setup overhead will be high, especially for objects at distance (and there are no LODs in the game for distance drawing).

What if you drop textures just from objects that are further away?

Before that they could even have some "hey, I'm here" color so that player notices them better despite smaller resolution...

[dml]

I think that textures should probably be dropped from objects because polycount is relatively high relative to size on-screen. Setup overhead will be high, especially for objects at distance (and there are no LODs in the game for distance drawing).

What if you drop textures just from objects that are further away?

Before that they could even have some "hey, I'm here" color so that player notices them better despite smaller resolution...

(A bit unwell today, so can't do much useful except occasional messages )

I think there will be some aspect of this later, although mainly for walls. I was planning on mipping-out the textures towards average RGB (already used by flatshading) and switch to flatshading for the majority of small faces using that miplevel outwards. (There are 4 miplevels in the engine, so levels 4 or 5 onwards would be flatfilled).

This should account for a large number of FPU-intensive face setups and rebalances work towards pixel filling. There are many more distant, small faces than close-up faces - the number of texture setups needed drops dramatically.

Dynamic models however have other problems - it's plausible to push them through the flatshading path for walls, but not the textured path for walls (due to face setup costs, which are disproportionately high for small faces in that mode - perpsective correct plane equations).

Q2 dynamic models (.MD2s) use affine mapped triangles instead of zplane-mapped polygons used by scenery, stored in a different format. There isn't much DSP space left for another geometry pipeline for this kind of data, so that in itself creates new problems.

For now it looks like sharing the one pipeline sensibly among all tasks is the right way. Later, if I get DSP code overlays integrated, it may become practical to transmit specific code on demand for model drawing, and then begin to use affine mapped tris for game objects. (Obviously, involving more time and effort).

So I agree with the idea - but probably not until much later, for models. Sooner for walls.

[shoggoth]

I think there will be some aspect of this later, although mainly for walls. I was planning on mipping-out the textures towards average RGB (already used by flatshading) and switch to flatshading for the majority of small faces using that miplevel outwards. (There are 4 miplevels in the engine, so levels 4 or 5 onwards would be flatfilled).

This should account for a large number of FPU-intensive face setups and rebalances work towards pixel filling. There are many more distant, small faces than close-up faces - the number of texture setups needed drops dramatically.

This sounds really neat to me. Extremely neat. Could BadMood benefit from this approach as well (for walls/floors)?

[dml]

This sounds really neat to me. Extremely neat. Could BadMood benefit from this approach as well (for walls/floors)?

I think it would have made sense, if some other areas in BM engine were simpler/better planned - but it's rooted in an old design from the 90's and while I tried to fix the biggest problems, enough problems remain. A redesign would have given a much better result. As it is, the determination of visible scenery and flip-flopping between different things during that makes optimizations like the above less attractive...

I expect the current Q2 engine could render BM scenery much faster than BM can (flat filled at least!) just because the visibility pipeline is a lot better and doesn't involve any flip-flopping during intensive work steps.

[Eero Tamminen]

I think there will be some aspect of this later, although mainly for walls. I was planning on mipping-out the textures towards average RGB (already used by flatshading) and switch to flatshading for the majority of small faces using that miplevel outwards. (There are 4 miplevels in the engine, so levels 4 or 5 onwards would be flatfilled).

Does current BM and future Quake code get advantage from texture upscaling i.e. using smaller mipmap level than the most optimal one quality-wise? Or is that insignificant compared to skipping texture completely?

I assume mipmap selection is based both on distance and size of the texture. Is the (square of) suitable distance for each mipmap level added into texture data on conversion / load? If on load, there could be some option for mipmap level selection... (of which one value would given flat shading for everything )

[dml]

Does current BM and future Quake code get advantage from texture upscaling i.e. using smaller mipmap level than the most optimal one quality-wise? Or is that insignificant compared to skipping texture completely?

Yes, it does provide an advantage for fetching texels (datacache coherency) but it needs to be encouraged where possible e.g. rotating textures to maximize sequential fetches, or palette index compression/coherence if looking up rgb's from indexed 8bit.

However skipping textures completely should always be a win for both fillrate and setup time.

(It isn't a big win in BM because it was too complicated to make a bunch of new scenery paths for flatshading, except for the pixel-filling bit, which is trivial)

I assume mipmap selection is based both on distance and size of the texture. Is the (square of) suitable distance for each mipmap level added into texture data on conversion / load? If on load, there could be some option for mipmap level selection... (of which one value would given flat shading for everything )

In Quake it's based on the face's nearest Z (nearest vertex). So it's per-face, and fairly approximate. You can see the mip levels flipping in Dos Quake as you move around.

In BadMooD, it's based on the texel DV rate, and is calculated per-column, so there is no flipping - it glides across the surface

(Dos Doom didn't use mips)

Quake can be forced to use no mips but there are serious consequences - the surface cache tries to populate itself with the highest resolution image for every visible surface, and runs out of memory very fast. One hidden advantage of mips is that the amount of texture cache required is roughly linear with screen area (not quite - but you get the idea!) - the distant surfaces are more numerous, but also smaller, and use smaller mip pages in the cache. So it's important to use them when texturing, for storage alone.

[kristjanga]

This is awesome Doug,

[dml]

This is awesome Doug,

[dml]

Found another optimization, by accident this time, and got another few % out of it. Should also be quite effective in BadMooD so I'll cross-port the effort soon.

Started looking seriously at doors/moving geometry and transparency (especially water, glass windows) now. It's going to be quite difficult but I think still doable without ZBuffer.

[nemodhs]

Fantastic progress on the engine! I'm always looking forward to your updates.

I expect the current Q2 engine could render BM scenery much faster than BM can (flat filled at least!) just because the visibility pipeline is a lot better and doesn't involve any flip-flopping during intensive work steps.

Is this just hypothetical, or could the Q2 engine be fused with Doom/BM?

[dml]

Fantastic progress on the engine! I'm always looking forward to your updates.

Is this just hypothetical, or could the Q2 engine be fused with Doom/BM?

You could probably run the Doom game logic using the Q2 engine for the output stage - although rendering 2D billboard sprites may produce strange results - to avoid weird distortion effects they would need to be projected not as flat 2D billboards but as X/Y view-oriented objects in worldspace, with Z perp to the floor - which means they would look thin as paper if you looked down on them, visibly rotating towards the eye and spoiling the effect.

.MD2 proxies for Doom enemies could be used, but the horsepower needed to render so many enemy meshes probably isn't available.

Apart from these problems it's probably feasible and if the view axes are limited for billboards to work it would probably be doable.

[dml]

Last evening I coded up a new (untidy, but hopefully correct) version of the Falcon rasterizer which supports arbitrary depth complexity - more than one visible frontsurface. This should allow transparent polygons to be sorted in alongside the solid faces, and still prevent pixel overdraw except exactly where it is needed - and still without reading or writing a ZBuffer for each pixel.

It is quite complex - much more so than the previous algorithms - so it will probably take time to get existing functionality back for solid walls and see any benefits for transparents - but it would be cool thing to have in the engine. I haven't seen this done before without a ZBuffer in a software rasterizer so that's worth a stab in itself. It would also make transparent surfaces just about feasible on a Falcon, and provide another way to draw game objects later...

I should able to do a bit more on it tonight or tomorrow night with any luck.