Quake 2 on Falcon030

[dml]

Had enough time last night to rewrite part of the code based on one of the new structures - but it doesn't really work properly. Polygons are drawn but sorting is all messed up. Probably won't get to debug it until tomorrow night. It is drawing something though and a lot of instructions have been collapsed out so it should be worthwhile once fixed.

There is a second structure which is going to be more difficult to recode, used in lots of places. It will take a bit longer to do - probably won't get results on that until next week.

[dml]

Had very little time last night, but did fix the bug.

grab0016.png

This view originally ran at 4-5FPS in the first test, then 6-7FPS after the initial improvements, and now 8+.

It peaks at around 12-15FPS in simpler views.

There are still places where it drops to 4FPS, but much improved over the 1-2FPS in the first version for those views.

Still working through the many DSP optimizations as time allows. Might get more done over the weekend.

[kristjanga]

Looking great Doug

[dml]

Looking great Doug

Thanks, I'll upload a new video over lunch showing a much tougher map.

I think the original testmap (fatal1) is now mostly tamed, for flatshading. It now runs ok at all locations.

[dml]

Here:

https://www.youtube.com/watch?v=RFbTfX7 ... e=youtu.be

I'm moving around the map in a confused, clumsy way because I recently flipped the mouse-y axis and keep getting disoriented

[EDIT]

I might have to upload that one again, it seems to have got mixed up with 3 other videos. Probably Hatari overwriting the same AVI without truncating it?

[dml]

Edge processing part of spanbuffer now also upgraded, speed improved a bit more. Won't bother with a video though until something looks visibly different. The previous view captured at 8fps is now close to 9fps.

There are probably a few more useful optimizations that can be done to the spanbuffer but the main ones are fading out.

From tests, it seems that the slow, detailed areas (for one test, around 4.3fps) spend approx 15% time on spanbuffer processing and that works out at 1.8 vblanks, from nearly 12 consumed in total by all stages of drawing. I'm not sure that optimizing it further is going to make a big difference to the speed of this thing.

So I'll finish this bit off and start looking at the other expensive areas.

[dml]

Somebody sent me a link (thanks!) to some Playstation Q2 maps rebuilt for PC, which should run faster than the PC ones and take less space. Not tested them yet but I imagine they should work ok.

[dml]

An update from yesterday - Falcon version can now run with (nearly) original colour data.

It's a bit muddy but I should hopefully be able to sort that out another time.

I'm busy just now so I'll explain more later.

grab0017.png

grab0018.png

grab0019.png

grab0020.png

grab0021.png

grab0022.png

grab0023.png

[dml]

Same, short vid from Hatari:

https://www.youtube.com/watch?v=Vp7CHxY9H2I

[Scarlettkitten]

Even with flat polygons like that, with those colours it looks amazing

[dml]

Even with flat polygons like that, with those colours it looks amazing

I thought it was worth a go before going near actual textures. A useful fallback if it just ends up being too much...

Still, I'll do a bit more towards getting the choppy framerate improved in the open areas and strange sticky bits in some of the maps before trying that.

[CiH]

Awesome work Doug, the original colours really make it, but I think you owe this chap a debt of gratitude for the whole idea of FPS in the first place.

doomydoomed.jpg

Oh noes, how can we live without the Amiga 5000!

And here's a link to Atari Age

http://atariage.com/forums/topic/230918 ... tsc/page-2

[dml]

Awesome work Doug, the original colours really make it, but I think you owe this chap a debt of gratitude for the whole idea of FPS in the first place.

Oh dear.

[dml]

Have fixed an annoying bug which caused lots of maps to hang - there was a limit of 15 edges per face, and some maps were expecting 16-20.

It's now possible to run the huge q2dm8 map - 'warehouse'. Not exactly fast, but it runs.

[dml]

Vid showing the larger map running: https://www.youtube.com/watch?v=kILvl6Kzj18

[EvilFranky]

Amazing, great stuff Doug!

[dml]

Amazing, great stuff Doug!

It seems I screwed up the last vids - code was built with DSP handshaking on, which slows it down. It's running faster now.

Trying to do too many things at once without tidying up.

[FedePede04]

as always Doug, you are amazing

[dml]

And here's a link to Atari Age
http://atariage.com/forums/topic/230918 ... tsc/page-2

Thanks CIH - now this is going to haunt me forever:

https://www.youtube.com/watch?v=_m6jqymC1D0

I don't know what's worse. Him singing... the same line over and over... or the badly auto-tuned voice.

Consider me scarred.

[AdamK]

Doug, somebody has to stop you

Is it possible ro run full game with your current code? With enemies etc? If so, can you provide a sneakpeak?

[dml]

Thanks Fede,Adam.

Is it possible ro run full game with your current code? With enemies etc? If so, can you provide a sneakpeak?

Unfortunately I can't run the enemy AI without rebasing/transporting a lot of code between the test engine and Q2 itself - and probably a whole bag of new problems.

However I was going to try to get some things working in the current code, such as doors and pickups, transparencies, the player weapon etc.

It should be possible to draw objects currently but I expect there are going to be awesome depth-sorting issues to deal with. Q2 used zbuffer for all the 'small stuff' and for transparencies. They don't go through the same system used for walls and floors. I don't have a zbuffer at all, so it's going to require some engineering work to sort meshes into scenery nodes efficiently.

In fact very similar to the endless woes I had with Doom, sorting sprites into sectors without using the top/bottom window clip thing used in the original code (it would have run poorly on F30 so I had to find another route)

I don't really know if its possible to do this correctly or not because the problem is quite involved, but I'd be ok to give up some minor/occasional sorting issues to keep speed up.

[Zamuel_a]

Thanks Fede,Adam.

Is it possible ro run full game with your current code? With enemies etc? If so, can you provide a sneakpeak?

Unfortunately I can't run the enemy AI without rebasing/transporting a lot of code between the test engine and Q2 itself - and probably a whole bag of new problems.

However I was going to try to get some things working in the current code, such as doors and pickups, transparencies, the player weapon etc.

It should be possible to draw objects currently but I expect there are going to be awesome depth-sorting issues to deal with. Q2 used zbuffer for all the 'small stuff' and for transparencies. They don't go through the same system used for walls and floors. I don't have a zbuffer at all, so it's going to require some engineering work to sort meshes into scenery nodes efficiently.

In fact very similar to the endless woes I had with Doom, sorting sprites into sectors without using the top/bottom window clip thing used in the original code (it would have run poorly on F30 so I had to find another route)

I don't really know if its possible to do this correctly or not because the problem is quite involved, but I'd be ok to give up some minor/occasional sorting issues to keep speed up.

Wouldn't it be better to use a simpler deep sorting routine for smaller objects instead of a z-buffer? If the polygons are small, there shouldn't be to much errors and it would be faster than a z-buffer.

[dml]

Wouldn't it be better to use a simpler deep sorting routine for smaller objects instead of a z-buffer? If the polygons are small, there shouldn't be to much errors and it would be faster than a z-buffer.

Currently there is no ZBuffer, and I'm hoping not to have to add one.

Many of the objects are small, but some are not (platforms, doors and really big rotating thingies!). Some objects will sit on (or beside) others.

In fact the troubles I mention are much less about sorting objects against each other, and more to do with sorting them against scenery.

Q1/Q2 use a write-only zbuffer mode for the scenery, and a read/write zbuffer mode for objects.

I will be trying to use BSP keys to sort as much as possible, but it will be quite tricky.

I expect there are also some hybrid options available - use keys to sort objects vs scenery, and use a read/write ZBuffer for only the interior pixels of objects.

It's still better to use keys for as much as possible as it helps solve a few other problems e.g. sorting faces by z means having to solve the z-plane for polygons being fed into the scene, rather than solving only for polygons with visible spans coming out the other side (the current arrangement).

So I'll see what looks feasible without a ZB but I think it will be some time before I have a decent solution for all the cases which can occur.

[CiH]

Thanks CIH - now this is going to haunt me forever:

As I am not a nasty cruel person, I only posted the link to the Atari Age forum, and not the *shudder* YouTube link directly here. Unlike someone else!

It was then entirely up to you whether or not you plunged in, both feet into the musical "extravaganza" - I stopped watching at 0.09 minutes and got the hell outta Dodge, avoided scarring.

[dml]

As I am not a nasty cruel person, I only posted the link to the Atari Age forum, and not the *shudder* YouTube link directly here. Unlike someone else!

I should have posted a caution over the content behind the link - true. Sorry to all those who got damaged.

Is it possible ro run full game with your current code? With enemies etc? If so, can you provide a sneakpeak?

I will try to bring some of the ingame objects to life in the next versions. I doubt it will be anything like final but there will at least be something moving in the scene other than the camera.

I won't attempt AIs because as I explained the relevant code is not present in this engine, and transplanting big things in either direction will take a lot of time and effort. The data structures are not compatible yet, although things are being improved slowly in that direction.