Overview Features Instructions Performance Forum Downloads Products OrderV4 Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.

All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Running Games and Apps.

Quake ;)page  1 2 3 4 5 6 7 8 9 

Jan Vonka

Posts 60
08 Mar 2018 08:13

How about Quake 2 68k? ;o)


Daniel Sevo

Posts 299
08 Mar 2018 22:23

@Jan Vonka

NovaTheCoder had it running fairly fast on a 060 + AGA 5 years ago.
I expect Vampire can do much better with a bit of AMMX optimizations.. etc..

Jan Vonka

Posts 60
09 Mar 2018 08:02

His configuration is 060/80 MHz and his Quake2 runs at 320x200 with lowest details possible (no particles, no shadows, no lighting effects). I used just default Quake2 at 320x240 and I bet I can make it faster when I disable all effects and details as well.

Not sure if AMMX will help (someone would have to recompile Q2 then), maybe faster clock will help or faster chip will be better.

Jan Vonka

Posts 60
23 May 2018 20:22

Last weekend we had a small party and connected together 4 Amigas and played Quake:

A600 (Vampire 600v2 + PCMCIA ethernet)
A2000 (Vampire 500v2+ + Deneb + USB ethernet)
A4000 (CSMK3 060 + Sonnet G3/500 + Voodoo3 + Deneb + USB ethernet)
A4000T (CSPPC + CVPPC + Deneb + USB ethernet)


Mallagan Bellator

Posts 381
26 May 2018 14:22

Thatís awesome! :)

Samuel Devulder

Posts 246
13 Feb 2019 16:36

Samuel Devulder wrote:

My version doesn't support the mouse, nor the joystick (yet).

Yes, but it works very faaaast ;)
Here is the fastest speed I measured with "timedemo demo1" on a plain RTG screen (320x200, nosound) for various compilers on my A500 with a gold 2.11 core (V500_5851_G211_433-450):

  quake.sasc.040 1.01.build#3477 (02/10/2019)
  969 frames 35.46 seconds 27.33 fps
  quake.sasc.030 1.01.build#3476 (02/10/2019)
  969 frames 35.42 seconds 27.35 fps
  quake.sasc.060 1.01.build#3478 (02/10/2019)
  969 frames 35.28 seconds 27.47 fps
  quake.gcc-6.4.1b.040 1.01.build#3471 (02/10/2019)
  969 frames 33.67 seconds 28.78 fps
  quake.gcc-6.4.1b.060 1.01.build#3472 (02/10/2019)
  969 frames 33.18 seconds 29.21 fps
  quake.gcc- 1.01.build#3480 (02/10/2019)
  969 frames 33.11 seconds 29.27 fps
  quake.gcc-6.4.1b.030 1.01.build#3470 (02/10/2019)
  969 frames 33.08 seconds 29.30 fps
  quake.vbcc.040 1.01.build#3474 (02/10/2019)
  969 frames 33.06 seconds 29.31 fps
  quake.vbcc.030 1.01.build#3473 (02/10/2019)
  969 frames 33.00 seconds 29.37 fps
  quake.gcc- 1.01.build#3483 (02/10/2019)
  969 frames 32.89 seconds 29.46 fps
  quake.gcc- 1.01.build#3484 (02/10/2019)
  969 frames 32.87 seconds 29.48 fps
  quake.vbcc.060 1.01.build#3475 (02/10/2019)
  969 frames 32.83 seconds 29.51 fps
  quake.gcc- 1.01.build#3482 (02/10/2019)
  969 frames 32.78 seconds 29.56 fps
  quake.gcc- 1.01.build#3481 (02/10/2019)
  969 frames 32.75 seconds 29.58 fps
  quake.gcc- 1.01.build#3479 (02/10/2019)
  969 frames 32.68 seconds 29.65 fps
(best scores. YMMV)
Pretty close to 30fps, isn't it ;) It seem that my work at eliminating fpu wait-states gave a big boost these last weeks.
I promise, I'll stop optimizing at 30fps. But this might be an unreachable goal since it is now very very very hard to gain the extra little fraction of fps since most, if not all, fpu-related bubbles are purged from the asm code.

Daniel Sevo

Posts 299
14 Feb 2019 17:41

Which Quake engine version/variant was the base for this port?

Samuel Devulder

Posts 246
14 Feb 2019 22:28

As said earlier in this thread, it is based on original ID 1.01 version with 20+ years of 68k mixed c/asm optimizations. Recent speed gain comes mainly from fine-tuning the asm to reduce pipeline stalls.
  Upto now, no compiler is able to do this correctly for the 680x0. This requires humain brain, but this is a really interesting brain-challenging task because it requires to think different from a plain C (sequential) coder. The computations have to be reordered so that there is no wait-state due to regs being "locked" in the pipeline.
  Not all functions need to be optimized. A good profiler (e.g. AProf) helps spotting the functions that require optims. Strangely-enough, it is not the obvious ones that needs optimizations. For instance the rasterization routine is not the most costly stuff in the engine.
  Asm-optimizing by hand is nice, but don't expect huge speedups at once. For instance, I can spend a full night on a few lines of asm to gain 0.1fps. But accumulating those little 0.1fps one by one eventually lead to +1fps and then +2fps relative to other quake implementations (on my setup Clickboom does 27.7fps IIRC). Small streams make big rivers ;)

Nova Coder

Posts 27
15 Feb 2019 00:53

Very impressive.

I'm surprised that the gcc 6.4 builds weren't much faster than the older gcc versions...any idea why? 

Samuel Devulder

Posts 246
15 Feb 2019 18:08

The difference (<1sec, e.g. <3%) isn't significant with respect to the ~33secs length of "timedemo demo1". The interrupts or other background tasks/widgets can steal that many amount of cputime to the game.
For information, if I
SetTaskPri 20
in the CLI before running the test, I get 29.99fps for both gcc6.4 and gcc2.95.3. This mean multasking costs about ~0.4fps.
So give or take, GCC6 does almost as good as other gcc versions. That's quite logical because now the top used functions are actually the same ASM-code for all compilers. C has only marginal impact on full screen RTG execution now that ASM optims are more massive.

posts 170page  1 2 3 4 5 6 7 8 9