Duke Nukem 3D and Quake for Atari Falcon 060!

[calimero]

sorry for resurrecting thread but I would like to post timedemo demo1 results from different Quake ports on different computers

I will start with Amiga (and add Falcon results when I get home):

Clickboom 060 exe, 060 66mhz
320x200 aga - 15,1 fps
320x200 rtg - 11,8 (11,82) fps

AQuake
320x200 aga - 10,1 fps
rtg didn't work

ref: http://www.amiga.org/forums/showthread. ... 831&page=5
ref: http://tech.groups.yahoo.com/group/Amig ... ssage/1653

Mikro port for Atari Falcon CT63 (68060, bus 16MHz) WITH MiNT:

320x200 - 13,6 fps at 75MHz
320x200 - 15,3 at 85MHz!

than we have PC pentium 200 mmx /48mb ram / gfx card: cirrus logic 1mb (PCI)
300x200 - 26 fps
300x240 - 24 fps (my comment: maybe 300 is type error?)

and Amiga with PPC 604e 233MHz PPC (software mod):
320x200 - 33.8 fps
640x480 - 12.6 fps

ref: http://www.amiga.org/forums/showthread. ... 831&page=6

old PC Am5x86 133MHz (basically overclocked 486):
320x200 - 8.5 fps

even older PC 486DX 33MHz:
320x200 - 3.5 fps

ref: http://www.youtube.com/watch?v=KbcFvUOGA44
---

BONUS: history of ClickBoom Quake port! > http://www.amiga.org/forums/showpost.ph ... stcount=74

"the first illegal Amiga port of quake 68k was done in 1997 in Montevideo/Uruguay by a guy called MAX ...he done it in his A4000 + spectrum gfx card
it not was called coolquake....I still have this ancient port

but the history started in 1997 when by mistake quake sources were scattered around the web...this guy MAX download them and stared the Amiga port in 1997
in same year Clickboom contacted him and purchased his work that was almost 90% done and working
then in 1998 clickboom retouched the port and realize it legal for the Amiga"

[calimero]

lol!

I got 6.4fps on CT63 / 75MHz!

something isn't right but I do not know what could be the problem... :/

[Xerus]

Your cache is probably desactive.
Go in the CT60 CPX and chooses the good option

Select the Boot selection and modifies the TOS option.

[calimero]

^
that is first thing that I checked!

it is turned on (normal, without alert).

next I try kronos and CPU and FPU figured are OK!

I really have not idea what is wrong with my Quake fps... Can somebody else measure timedemo demo1 fps?

[Xerus]

Maybe you don't use the right version of Quake ?
There are two version, the Quake port of PM, very slow (C+SDL) and the fast version of MiKRO available here : http://mikro.naprvyraz.sk/

[calimero]

It is Mikro quake for sure!

Maybe I should try it from MiNT?!

And can please somebody make timedemo demo1 on its ct63?

Thanx!

[dml]

If you're testing Quake ports there's one more you can try if you have time.

It has been built for 030+FPU but should run on 060. It was originally ported for AB040 but some stuff has been unwound recently to make it more Hatari friendly for testing. I have no idea how this version performs now (except that it's sloooow on 030).

It does contain a lot of assembly language optimizations in the renderer part so it's interesting to know how it runs on 060 if runs at all.

Important: You will need an unpacked ID1 directory (approx 18mb of files) - it won't run from the PAK file. You also need at *least* 16MB FastRAM. I don't guarantee it works from MiNT either, although it may...

Make sure the fastram flags are set in the program header. I haven't checked it myself.

If it doesn't run (or runs poorly) I'll take a closer look sometime on my own 060 once I get free from other stuff.

[rian_ata]

If I run the latest mikro build from his site (http://mikro.naprvyraz.sk/files/aq-103.zip) on my Falcon CT63 @95MHz with 512MB SDRAM with ID's shareware pak file (timedemo demo1), my outcome is:

969 frames / 82.2 seconds / 11.8fps

When I try to run Quake with dml's TTP it doesn't start and states:
PAK CRC is wrong for normal game
...
FindFile: can't find gfx.wad
..
I_Error: W_LoadWadFile: couldn't load gfx.wad

This is porbably related to dml's comment "you need an unpacked ID1 directory", but I don't know how to unpack the PAK0.PAK file

[Xerus]

You can use Dragon UnPACKer to unpack the file.

[Eero Tamminen]

It does contain a lot of assembly language optimizations in the renderer part so it's interesting to know how it runs on 060 if runs at all.

Btw. Did you do something for the (newer) MiNTlib time functions stuff that was visible in the profile you sent of your own build?

(Those aren't visible in the profile I posted to BM thread of my build of your Q1 sources as I'm using older GCC & MiNTlib.)

[dml]

Btw. Did you do something for the (newer) MiNTlib time functions stuff that was visible in the profile you sent of your own build?
(Those aren't visible in the profile I posted to BM thread of my build of your Q1 sources as I'm using older GCC & MiNTlib.)

That is not fixed in the version I posted here so time sampling will probably be a drag on performance. I did take a quick look at it a few weeks ago and the time/date stuff had *already* been replaced so the real cause of this problem will still need to be found - it's not where I thought it would be.

[Xerus]

Well, I found your problem Calimero, you start Quake under TOS because at home I have only 9.6FPS (with bus overclocked).

Here is my results (after a second run) with a FalconCT60 100MHz - BUS 25MHz /Freemint / RGB monitor and latest MiKRO build:
- timedemo demo1 = 19.4 FPS - 969 frames - 50.0 seconds
- timedemo demo2 = 20.1 FPS - 985 frames - 49.1 seconds
- timedemo demo3 = 18.5 FPS - 1090 frames - 59.1 seconds

For the version of Doug, there is a strange bug, timedemo mode works well but at the end there is not any result in the console!

[dml]

For the version of Doug, there is a strange bug, timedemo mode works well but at the end there is not any result in the console!

Oops! So no use for timdemo tests then, unless you use a stopwatch. If you do manage to get any figures I'd be interested, although as Eero says - there's a fault in the posix time handling which needs a bit more porting work, and is slowing things down a bit.

[EDIT]

err.. I guess if you see no results at all then even a stopwatch won't help. I'll need to investigate it.

[Xerus]

The console is always active and does work, you can put all commands that you want, so maybe you had deactivated a line in your source for the timedemo mode?
Otherwise your port is fast but not as much as the MiKRO version

[dml]

Ok, thanks for letting me know! It isn't 060 optimized (mostly 040 hacked back to 030+882 - there were no 060's around at the time) and it has some other problems as mentioned above so it's not too surprising if it's a bit slower. I'll get a closer look when I have my 060 up and running.

[calimero]

Well, I found your problem Calimero, you start Quake under TOS because at home I have only 9.6FPS (with bus overclocked).

cool! will try tomorrow!

[Eero Tamminen]

Well, I found your problem Calimero, you start Quake under TOS because at home I have only 9.6FPS (with bus overclocked).

That (really) slow posix timezone stuff I mentioned above, gets called twice under TOS, because MiNT calls return errors under TOS.

MiNT maintainers applied my simple patch which fixes that TOS issue, but I'm not sure whether it catches all paths through which it can happen and it only solves halve of the problem (slow stuff getting called 2x under TOS, not the slow stuff itself).

[mikro]

That (really) slow posix timezone stuff I mentioned above, gets called twice under TOS, because MiNT calls return errors under TOS.

Whoa, whoa, let's not jump into fast conclusions. Maybe Doug's port does that but mine checks for MiNT and if it's not found, it uses Timer C instead. Not exactly the best solution (could have used clock() for this) but avoids gettimeofday() for sure.

[calimero]

I got 13,6 FPS at 75MHz (under MiNT)...

so ClickBoom port is quite quicker than yours Mikro... did you see history of ClickBoom Quake?

[dml]

My port doesn't use gettimeofday() - it was removed and replaced with a hack that just advances time by a constant fraction (so there is no proper time handling - was just enough to get frames to tick over).

However I discovered recently that MiNTlib uses gettimeofday() regularly when performing disk operations though the posix fileio interface. It is probably using it in other places too. Since I did the original port using native GCC 2.7.3 (which didn't use MiNTlib) the new build is probably not performing very well by comparison - it's probably slower than the old native build. Eero's recent profile of the code seems to back this up (gettimeofday() seems to be high on the list of costs even without direct time queries and without loading stuff from disk which is weird).

I also noticed in BadMood that the fileio operations performed by the assembler module through TOS/Bios are very quick - the levels load rapidly. However all of the fileio operations performed through MiNTlib take **ages**. The game code loads the sound samples and it takes the game code longer to load a few samples from the same WAD than BM takes to load the whole level.

Note that this may not affect Mikro Quake at all, but it does look like my recent rebuild of '040 quake is probably taking a hit from having MiNTlib attached to it without much analysis of where its getting used.

[EvilFranky]

Not really a 100% fair comparison.

Are we 100% sure they are using the same timedemo?
How many runs were taken of each? Need at least 3 without quiting to the desktop to give a good average.

I have no idea how much Mikros port is optimized specifically for the Falcon.

Really need to get some up to date benchmarks ran for each platform with very specific parameters.

[Eero Tamminen]

However I discovered recently that MiNTlib uses gettimeofday() regularly when performing disk operations though the posix fileio interface. It is probably using it in other places too. Since I did the original port using native GCC 2.7.3 (which didn't use MiNTlib) the new build is probably not performing very well by comparison - it's probably slower than the old native build. Eero's recent profile of the code seems to back this up (gettimeofday() seems to be high on the list of costs even without direct time queries and without loading stuff from disk which is weird).

The file operation was probably stat(), as stat structure includes time information about the file and I guess with newer MiNTlib that goes also through the slow timezone stuff...

[calimero]

Not really a 100% fair comparison.

Are we 100% sure they are using the same timedemo?
How many runs were taken of each? Need at least 3 without quiting to the desktop to give a good average.

I have no idea how much Mikros port is optimized specifically for the Falcon.

Really need to get some up to date benchmarks ran for each platform with very specific parameters.

best I could do is to dig results from net.
"Need at least 3 without quiting..." - On CT63 I always get same result.
all results should be done with "timedemo demo1".

[mikro]

I got 13,6 FPS at 75MHz (under MiNT)...

so ClickBoom port is quite quicker than yours Mikro... did you see history of ClickBoom Quake?

Of course it is. ClickBoom guys had optimized it to death. While "my" port uses fairly optimized but still not that optimized, routines in 040/060 assembler (+FPU). More important than your CPU clock is actually your bus clock. Nemesis/Phantom gives Quake the true speed up. Of course, 90 MHz + 25 MHz is the dream team :)

[mikro]

lol!

I got 6.4fps on CT63 / 75MHz!

something isn't right but I do not know what could be the problem... :/

Believe or not but I found the culprit today (why it's so slow in TOS). So my current build gives roughly the same numbers in all OSes. And for FreeMiNT, I'm not using gettimeofday() (a.k.a. the slow one) function anymore.

Btw, I've patched it to detect/run on the SuperVidel (using the move16 method), it performs better than the unofficial PeP's version (sorry, Peter ;)) but still the gain is only about 2-3 fps? I expected much more, strange...

EDIT: Actually, it's really true. Without ST-RAM/SuperVidel-RAM involvement, I'm getting only 0.5 FPS (!!!) improvement over the move16 method. So in the end, it's really about horse power. The faster CPU you have, the faster game you get. Interesting, I had never measured this in the past.