Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Running Games and Apps.

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

Samuel Devulder

Posts 248
22 Oct 2017 22:14


21->26, that's makes 24% faster :)


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
22 Oct 2017 22:54


Samuel Devulder wrote:

21->26, that's makes 24% faster :)

Oh, I think there is a lot more potential.

I recompile of QUAKE and 35 FPS or more in QUAKE should be possible.
But we do not have time to do everything, any Quake fans here which like to contribute to this?




Wawa T

Posts 695
22 Oct 2017 23:00


but this is a regular 68k binary so far?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
22 Oct 2017 23:06


wawa t wrote:

but this is a regular 68k binary so far?

 
Yes, this is the old ClickBoom binary.
 
Only having a very quick look I see several easy to "fix" areas.
a) The game per default renders in a of screen framebuffer,
and then copies this buffer to the screenbuffer.
This makes sense for Zorro GFX card, but is totally unneeded for SAGA.
 
b) I had a quick glance at the FPU ASM.
Its not good code for 68k, it looks like POWERPC code.
  Example:
 

  FMOVE.S (A0),FP0
  FMOVE.S (A1),FP1
  FMOVE.S (A2),FP2
  FADD    FP0,FP1
  FSUB    FP2,FP1
 

 
As you see the code never uses (EA) in FPU instruction.
The 5 instructions could be done in 3 instructions on 68K.
The game could run much faster on 68K, if better compiled.



Gregthe Canuck

Posts 274
23 Oct 2017 00:03


Is the source code for the ClickBoom version out there somewhere?




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
23 Oct 2017 00:55


gregthe canuck wrote:

Is the source code for the ClickBoom version out there somewhere?

Not that we know.
I only looked at the disasm of the binary real quick.



Vojin Vidanovic

Posts 770
23 Oct 2017 03:12


Gunnar von Boehn wrote:

  Not that we know.
  I only looked at the disasm of the binary real quick.

No, clickBoom never released sources.



Samuel Devulder

Posts 248
24 Oct 2017 00:26


Gunnar von Boehn wrote:
 
I recompile of QUAKE and 35 FPS or more in QUAKE should be possible.
But we do not have time to do everything, any Quake fans here which like to contribute to this?

I spent this afternoon digging in my archives and found the sources of Quake I was working on back in 1997 or so.
     
At that time I was trying to make it work on my GVP530, with very moderate success. Well it ran between 2 and 5 spf.. Yes SPF, seconds per frame and not the reverse :) :) :)
     
Anyway I had fun back then when I was trying to optimize it (no FPU at that time) or tune it to support native amiga modes of my A500, including HAM6 and Workbench (try the -usepub argument).
     
If anyone interested, I spent few times re-compiling that source-code with the various compilers I have around: GCC-2.95.3, GCC-3-2-2, latest VBCC, SASC for various CPU/FPU configuration: 030, 040, 060. The binaries are available here: EXTERNAL LINK     
     
Please note that you must ensure to have a stack big-enough for the binary not to crash. I suggest 300kb or more. I typically use 500kb to be on the safe-side.
     
As said above these versions support (almost) all amiga native modes (including 2, 4, 8 colors, EHB or even HAM6) as well as RTG modes. If you launch it without argument, a requester will ask you to choose a screen size & mode. Alternatively you can use the "-usepub" argument to make it run in a window on the workbench. If the workbench is not interlaced, the window size is halved to take the 1:2 pixel-ratio into account. If there are less than 8 colors available it switches to a gray-output. This can be forced using the "-usegray" command-line argument. Dithering is also used to simulate more colors (try 640x480 with 8 colors for fun). This can be disabled by adding "-nodither" on the command-line. Sound is produced via audio.device but the "-useahi" option makes it use ahi instead. Well I think that's all about this version.
     
I'd be glad to know if these version work on the Vampire, and how-fast it runs. I presume they won't be as fast or stable[*] as other amiga versions because this a development started 20 years ago and never finished because my 68030 was desperately too slow for such 3D things.
____
[*] do not resize the window, there's a bug in there!


Simo Koivukoski
(Apollo Team Member)
Posts 601
24 Oct 2017 06:44


Samuel Devulder wrote:
  If anyone interested, I spent few times re-compiling that source-code with the various compilers I have around: GCC-2.95.3, GCC-3-2-2, latest VBCC, SASC for various CPU/FPU configuration: 030, 040, 060. The binaries are available here: http://www.cjoint.com/doc/17_10/GJxxdgbMgCr_quake-sam.zip

Cool, could you please ping us on IRC.



Sebastian Blanco

Posts 148
24 Oct 2017 14:12


Samuel Devulder wrote:

Gunnar von Boehn wrote:
 
  I recompile of QUAKE and 35 FPS or more in QUAKE should be possible.
  But we do not have time to do everything, any Quake fans here which like to contribute to this?
 

  I spent this afternoon digging in my archives and found the sources of Quake I was working on back in 1997 or so.
       
  At that time I was trying to make it work on my GVP530, with very moderate success. Well it ran between 2 and 5 spf.. Yes SPF, seconds per frame and not the reverse :) :) :)
       
  Anyway I had fun back then when I was trying to optimize it (no FPU at that time) or tune it to support native amiga modes of my A500, including HAM6 and Workbench (try the -usepub argument).
       
  If anyone interested, I spent few times re-compiling that source-code with the various compilers I have around: GCC-2.95.3, GCC-3-2-2, latest VBCC, SASC for various CPU/FPU configuration: 030, 040, 060. The binaries are available here: EXTERNAL LINK     
       
  Please note that you must ensure to have a stack big-enough for the binary not to crash. I suggest 300kb or more. I typically use 500kb to be on the safe-side.
       
  As said above these versions support (almost) all amiga native modes (including 2, 4, 8 colors, EHB or even HAM6) as well as RTG modes. If you launch it without argument, a requester will ask you to choose a screen size & mode. Alternatively you can use the "-usepub" argument to make it run in a window on the workbench. If the workbench is not interlaced, the window size is halved to take the 1:2 pixel-ratio into account. If there are less than 8 colors available it switches to a gray-output. This can be forced using the "-usegray" command-line argument. Dithering is also used to simulate more colors (try 640x480 with 8 colors for fun). This can be disabled by adding "-nodither" on the command-line. Sound is produced via audio.device but the "-useahi" option makes it use ahi instead. Well I think that's all about this version.
       
  I'd be glad to know if these version work on the Vampire, and how-fast it runs. I presume they won't be as fast or stable[*] as other amiga versions because this a development started 20 years ago and never finished because my 68030 was desperately too slow for such 3D things.
  ____
  [*] do not resize the window, there's a bug in there!

Very cool, sure this will run fast on the vamp.



Simo Koivukoski
(Apollo Team Member)
Posts 601
24 Oct 2017 14:59


@Samuel Devulder: Thanks for the tips on IRC. For some reason your build does not show FPS line on Quake's console after running timedemo.


Samuel Devulder

Posts 248
24 Oct 2017 18:22


... and later it worked. Strange! This is old code. I can't see what might cause this except the fact that its an early version of the id-software engine that has been modified in many places to make it compile on various amiga C compilers. That might have induced bugs in dark corners of the code :)
   
  Another option to test speed is to type in the console "timerefresh". It will turn the camera around the current scene and produce a FPS indication. It overestimates the in-game FPS but gives the full speed of the 3D engine because only it is tested, not the sound nor the IA of the game.
 
You can display a speed graph on screen to see where the engine is lowing down by writing "r_timegraph 1" in the console.
 
To speed up you can remove texture&illuminations by doing in the console "r_drawflat 1". Disabling dither (-nodither), the sound (-nosound), the colors (-usegray), the remapping of colors (-noremap) on the command line might also help a little.
   
All versions should run the same (at least they do in my UAE setup[*]). If some version fails to launch or display garbage this might indicate either an ugly bug in a dark corner, or some incompatibility with the vampire. The first option is of course more likely.
___
[*] my Amigas are quite far-away from me right now. I mounted an UAE setup with my backup disks containing the archive of my development of that time :)
   
I tried to compile Frank Wille's version from aminet ( EXTERNAL LINK ), but it wasn't simple:
    * PhxAss is required to compile ASM-parts. I hoped vasm would do, but I didn't succeed to provide the include path to vasm via "vc" on the command-line. Too bad! VASM would help writing AMMX code.
    * A file is missing from the archive preventing the compilation of several c files.
    * The OS-include I have contains the CONST keyword that VBCC doesn't quite like at all: It nagged about bad assignments in pieces of code that didn't contain any assignments.
    * Some include header were also missing (mainly network related stuff), or wrongly used (<proto/something.h> instead of <clib/something_proto.h>).
 
Well, after a long time struggling with the makefile, the missing includes, the missing file, I finally succeeded to compile a version :)

I tested it, but it crashed :-( with guru 80000006 or 80000004 even before entering in the main() function. I must have broken it real badly somewhere.. too bad :(

It isn't a complete failure because I might study the asm-optimisations he made later :)



Wawa T

Posts 695
24 Oct 2017 22:23


just compiled aros port of quake for amiga-m68k, as usual cant though get data install right. that mess always puts me off..


Vincent Viaule

Posts 5
25 Oct 2017 12:22


Nice, it's the 68020 version of Clickboom or the 68060 ?
Google QUAKE060.LHA or contact me, that last clickboom's quake exe for 060 cpus with RTG supports. On my Blizzard 1260@64Mhz 15.3fps in PAL AGA with addon FastPatchQuake
EXTERNAL LINK 
If you want FPS display on screen, here the C code to modificate:
EXTERNAL LINK  It is this code that I replaced in the version Quake68k of Frank Wille.

@Samuel Devulder
Frank Wille haved update the source file of Quake_src.lha V2.30  sys_gui.h was missing of Aminet source.
http://mail.pb-owl.de/~frank/quake1/2.30/Quake_src.lha
Thx Frank




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
25 Oct 2017 12:49


Its nice that Quake runs to well on the Vampire.

Saying this, there is room for improvement.

The FPU coded could be tweaked for APOLLo, and 100% speedup of the FPU code is a possible and realistic target.

Also the TEXTURE mapping code could be highly improved.
APOLLO can provide AMMX acceleration of high quality bilinear texture mapping - which would improve the visual quality of the game
a lot.



Manuel Jesus

Posts 155
25 Oct 2017 16:41


Here is quake running on my Vapire Black 600 assembled by Kipper2k.

So this is proof that it's not just running on 1 team member Vampire setup.

EXTERNAL LINK


Samuel Devulder

Posts 248
25 Oct 2017 17:37


Vincent Viaule wrote:

      Nice, it's the 68020 version of Clickboom or the 68060 ?
No it isn't. It's a version of the 1.01 engine that leaked 20 years ago. I used it to test various GFX rendering modes that I included in UAE.

      Frank Wille haved update the source file of Quake_src.lha V2.30  sys_gui.h was missing of Aminet source.
        http://mail.pb-owl.de/~frank/quake1/2.30/Quake_src.lha
   
Yeah, the version from aminet doesn't compile. Fixing the missing file can be done by simply recreating the file with the missing function prototypes.
     
      The link you provide doesn't seem to work for me. Apparently the domain is for sale :-/
       
      During the last 24h hours I tried to include Frank's asm optimizations in the 3D engine I have.
     
      It's not a simple task as the compilers and ABI are a bit different. I'm also facing a long forgotten aspect of developing under Amiga. It's a long series of: edit/compile/launch/guru... with no help whatsoever to figure out what is wrong in the code.
     
      Strangely enough, when I was younger these things didn't bothered me. But right now, with far less available time, I barely stand this endless loop of reboots. Even the UAE debugger is not useful because the crashing part is not the buggy one (and also because the loading address of amiga program is always changing). The bugs are all caused by data corruption or ill computations. The induced bug only shows up much later in time, with no direct relation to the cause of the corruption.
     
      Well that's the curse of Amiga developers I guess. Dear! I almost forget this for 20years. Somehow, developing for embedded devices on development boards seem easier to me because there are external debuggers well integrated with an IDE so that one can easily put (conditional) breakpoints, watch points, perform step by step execution, etc. I'm lacking all these goodies :)
     
      With patience, I'll surely fix all these issues and get a faster engine.... patience... Sure It's been 15 or 20 years that I haven't compiled something big for the Amiga... a few more days to wait isn't that much after all ;)


Niclas A
(Apollo Team Member)
Posts 219
25 Oct 2017 18:07


Samuel Devulder wrote:

    Yeah, the version from aminet doesn't compile. Fixing the missing file can be done by simply recreating the file with the missing function prototypes.
         
          The link you provide doesn't seem to work for me. Apparently the domain is for sae.
   

   
    Try this web archive link
    https://web.archive.org/web/20090609024957/http://mail.pb-owl.de/~frank/quake1/2.30/Quake_src.lha
 


Artur Jarosik
(Apollo Team Member)
Posts 94
25 Oct 2017 19:20


Is that GCC-3-2-2 for 68k.
Can you share it ?


Samuel Devulder

Posts 248
25 Oct 2017 23:09


@Artur: Yes it is. It came with GeekGadget IIRC ( EXTERNAL LINK ). I used it to compile stuff for pOS ( anyone recalls of that OS ?). Unfortunately aminet has no trace of gcc3 anymore :(
     
  Anyway here is a temporary ZIP of my "gg" folder: EXTERNAL LINK       

            assign gg: path:to/folder/gg
            execute gg:sys/s/gg-startup

@Niclas: wayback link seems to be working :) but it is lacking sys_gui.h :(

Anyway here is a new version containing some ASM from Frank Wille's version (not all of it.. it takes time to integrate&debug): EXTERNAL LINK 

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