I thought all Pentiums after 200 mhz were MMX... or maybe it was 233. Anyway, I can confirm I used to run Quake II on my Pentium 133 (not mmx), but at full screen the frame rate was a little low, I would take the borders in 2 steps. I can't remember how much RAM I had at the time, it definitely ran on 32mb but I may have run it before then on 16mb. Not sure.

The PC version of Quake 2 uses a FPU trick (the rasterizer is coded in i386 assembly) to speed up texturing. The portable (compiled C) version of the code I'm using can't replicate this trick effectively so its a good bit slower when tested on the same PC. Also the portable version is a reference algorithm and slightly errs on the side of correctness, compared with the asm version which takes a few extra shortcuts for speed.

Still the whole engine assumes FPU performance from that generation onwards so it doesn't fit very well on these old chips. The Pentium FPU can execute something like 20-50x more work per single clock, probably even more for most ops.

It also assumes virtually mapped / logical memory - e.g. it requests a flat 16mb of scratch space just to load a map, required or not. That sort of thing doesn't work too well on a Falcon Fortunately those problems are solved with the F030 rasterizer, but the FPU performance problem remains hanging over the game code - which is what I'm investigating atm.

I think the conclusion in the end will be close to what I guessed though at the beginning...

A plain Falcon should be able to run the whole engine providing no AIs are awake on the map and moving around. The costs I've seen appear to be quite manageable even for the attract mode replay (I have to assume for now the attract mode demo replay is *not* properly running collisions or predictions because the cost for these is too low).

It should be able to run deathmatch mode on an empty map, and (hopefully) with pickup items and 2 players moving around the map (with some optimisation effort applied). This is what I was hoping for.

It is likely to struggle though with singleplayer AI content awake and moving around a map. I haven't seen this yet in the profiling but I think it will become evident when I get it to boot properly into a singleplayer game instead of just falling into attract mode. I can't even guess if that's worth trying to fix but it's probably a stretch. Will look at the other cases first.

Trixster wrote:Hi,I've just been trying to get the test release 2 and 3 from earlier in the thread working but I'm getting a black screen after launching either of them. Both archives have been decompressed with strip into their own folders. This is on a falcon with newly formatted hd, 14mb ram and 68882 fpu.Thanks!

Ok I'm having a look at it just now. The q2testpublic3.zip I shared a while back does seem to run here but I only checked in Hatari 2.00 just now. It was tested on HW before releasing it but I was planning on releasing a small update soon anyway and that needs tested again on HW.

You do need to specify which map to load on the commandline otherwise it won't run. So type in 'fatal1' for example. There are 3 maps prepared:

fatal1ikdm2ikdm9

You can't run other maps unless I preprocess them first - the real maps use texture names which exceed 8.3 format and so produce lots of texture errors. I have to convert them and place 8.3 hashed versions in a tex83/ folder which the maps then refer to instead. Other than that the maps are the same format as Q2.

Yeah I released the demo in a hurry and the startup code is a bit of a mess. You get warnings about missing PAK file (it has unfinished PAK support) and no error messages for common mistakes... but at least it works

Well, I can only say it's incredible. I read this thread from start to finish (and the Badmood one) over the Christmas break whilst I waited for my Falcon to arrive (you might have guessed I'm a complete noob at everything Atari - this falcon is my first one, I'm an Amiga guy!) and I just can't comprehend what you've achieved so far. So impressive.

Amazing as usual Doug. I did laugh as it the straight port of the PC code seems to be running at the same FPS as some 3D construction kit games I reckon it might be playable for people like me who are quite happy with things running at anything over 5fps (60fps - pah!)

You probably know of these already, but I thought to mention anyway something I noticed when tracing GEMDOS operations...

All environment files are first tried to be loaded from "env\" dir, before Quake tries the correct "data\baseq2\env\" path, and all player files are first tried to be loaded from "players\male\" before Quake tries the correct "data\baseq2\players\male\".

And the game tries to load these, but fails (dir missing), I guess when I clicked the mouse button:* models\objects\rocket\tris.md2* data\baseq2\models\objects\rocket\tris.md2

When loading the map BSP file, Hatari GEMDOS emulation complains that it needs to cut extra characters from the file name. Is there perhaps some string termination missing?

Good to know it still works - although it can't use TT ram with the current build since it's stealing the PMMU hardware and enforcing 24bit addressing as a side effect. However it shouldn't matter for the maps provided - they all fit in memory ok.

Eero Tamminen wrote:All environment files are first tried to be loaded from "env\" dir, before Quake tries the correct "data\baseq2\env\" path, and all player files are first tried to be loaded from "players\male\" before Quake tries the correct "data\baseq2\players\male\".

A lot of this has to do with nonworking PAK support, which results in fail/retry behaviour in the log. So currently it's 'normal' even if it looks ugly.

Eero Tamminen wrote:And the game tries to load these, but fails (dir missing), I guess when I clicked the mouse button:* models\objects\rocket\tris.md2* data\baseq2\models\objects\rocket\tris.md2

It does try to load meshes for entities which are present on the map (and for things like weapons, rockets etc), but is currently unable to draw them. So I wasn't careful about providing the meshes it doesn't really need yet.

Eero Tamminen wrote:When loading the map BSP file, Hatari GEMDOS emulation complains that it needs to cut extra characters from the file name. Is there perhaps some string termination missing?

I've seen this but haven't looked closely yet. This one probably a real bug yes.

I find this very interesting from a 68060 point of view given that a 512kb l2 cache 200Mhz Pentium will apparently only return 7.8fps (albeit at 320x240) whereas an 80Mhz 68060 can return 8.5 fps (albeit at 320x200). That seems somewhat off-kilter! Maybe it's 640x480.

Last edited by Trixster on Thu Jan 12, 2017 6:29 pm, edited 1 time in total.

I find this very interesting from a 68060 point of view given that a 512kb l2 cache 200Mhz Pentium will apparently only return 7.8fps (albeit at 320x240) whereas an 80Mhz 68060 can return 8.5 fps (albeit at 320x200). That seems somewhat off-kilter!

you refer to NovaCoder 68060 Amiga version of Quake II, right?

Doug said that rendering part of original Quake II is writen in x86 assembler so NovaCoder manage to outperform ID software on "inferior" hardware (in regard of bitplane graphics that Amiga AGA use...) and lack of 512KB cache in 68060 (it has only 16KB!). Impresive!

- re-optimised the indexing of faces, which saves 5% on that stage- converted some of the surface cache routines code to use self-modifying code during setup, to reduce access to stack variables- started looking at ways to redo the collision detection so it's never dealing with leaf node meshes - just a pure bsp algorithm. this makes it easier to optimise for size/cache.

Have also looked at whats involved in coupling the new renderer to the Q2 engine. But there is some work to do on it first.