08 Mar 2018 08:13
|How about Quake 2 68k? ;o)|
08 Mar 2018 22:23
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..
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.
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)
Video: EXTERNAL LINK
26 May 2018 14:22
|Thatís awesome! :)|
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):
(best scores. YMMV)
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-2.95.3.040 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-3.2.2.040 1.01.build#3483 (02/10/2019)
969 frames 32.89 seconds 29.46 fps
quake.gcc-3.2.2.060 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-3.2.2.030 1.01.build#3482 (02/10/2019)
969 frames 32.78 seconds 29.56 fps
quake.gcc-2.95.3.060 1.01.build#3481 (02/10/2019)
969 frames 32.75 seconds 29.58 fps
quake.gcc-2.95.3.030 1.01.build#3479 (02/10/2019)
969 frames 32.68 seconds 29.65 fps
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.
14 Feb 2019 17:41
|Which Quake engine version/variant was the base for this port?|
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 ;)
15 Feb 2019 00:53
I'm surprised that the gcc 6.4 builds weren't much faster than the older gcc versions...any idea why?
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.