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 

Vincent Viaule

Posts 5
26 Oct 2017 07:03


@Samuel
Attached the link for Frank Wille's Quake2.3 source with Sysgui.h
EXTERNAL LINK 



Samuel Devulder

Posts 248
26 Oct 2017 07:52


Thanks :) I can see it also contains your fps modifications.


Samuel Devulder

Posts 248
28 Oct 2017 00:25


Ok, so I've managed to merge most of Frank Wille's asm code into my version. Code only compiles now with SAS/C and need some cleanup, but it resulted in an EXE that is more than two times faster than the previous version on my test-configuration. You can download a ZIP file containing both old&new EXE there:
                  EXTERNAL LINK
If someone can test them on his Vampire and report here the speed, this would be interesting. I doubt I can reach ClickBoom's speed. But I'm wondering how close I can get.
   
For information: The best combination of options I found to get the highest FPS is
quake.sasc.060.882 -nodither -nosound -nostatic -usemode 0x50001000
the "-usemode" selects UAE:320x200x256 (this is RTG).. You can remove it and pick the resolution you want on the requester (maybe 640x480x256 RTG if you dare ;) ). Then, look at message "Using modeid=0xNNNNNNNN" in the CLI to get the screenmode id you have selected. You can later put that id on the command-line to skip the screen-mode requester.
   
I've managed to make "timedemo" correctly prints the FPS when it finishes, but this has a side effect of running the demo really really fast. The computed FPS is however still correct. I have to figure out why it is doing so (it seems related to the absence of proper timing because there is no network support in my code.)
   
Also notice that this is not quite the same Quake-engine as Frank Wille. Mine is 1.01, a very early version. His is 1.09 which is likely to run a bit faster. But since I failed to make a running version with his sources, I'm stuck to the 1.01 engine. But anyway it is the engine I'm more familiar with.
   
While working on the ASM code, and particularly adapting Frank's source to the SAS/C abi[*], I've seen some places where I could improve the code by calling the functions using the faster SAS/C entry-points (expected gain: marginal though.)
    ___
    [*] passing functions parameters in regs (+stack if needed)
 
At least now I have some important piece of ASM in the code, there is space for efficient 080-specific optimizations. Talking about 080 optims, I wonder which of the two code style (V1 or V2) is best with regard to superscalar? (I use them almost on every function that takes more than 3 pointers as parameters)
V1:
      move.l foo+0(sp),a0
      move.l foo+4(sp),a1
      move.l bar(sp),foo+0(sp)
   
    V2:
      move.l foo+0(sp),a0
      move.l bar(sp),foo+0(sp)
      move.l foo+4(sp),a1

 


Claudio Guglielmotti
(Apollo Team Member)
Posts 185
28 Oct 2017 07:46


I tried them.
Quake.sasc.060.882.old works bad, it shows only the health bar in the lower part of the screen but do not shows the game.

Quake.sasc.060.882 works not too bad !
I have a lot of errors on the textures (many objects do not have them);
EHB do not works (black screen)
but it is fast. I had 7,0 fps in 640x480 and 15,2 fps in 320x240.




Samuel Devulder

Posts 248
28 Oct 2017 08:11


For EHB,
quake.sasc.060.882 -nodither -nosound -nostatic -usemode 0x21080
works for me. But beware, with the -nostatic the palette is computed for each frame. If there are 256 colors available, then it's fine. But if fewer colors are available like with EHB, a color reduction is performed for every frame, which takes some time. The quality is not good neither. Better use HAM6 (-usemode 0x21800).

Concerning the speed, 15fps is not that bad but it might be caused by missing textures.

The lack of texture is strange. Since this affects both the old and new version, it is unlikely that it is caused by hand-written assembly code. Does it look like trash on screen with deformed polygons or simply black areas with correct shape ? I wonder if it is related to the 68080 or not. Can someone try on a genuine 030+881(or better) and tell if the display is correct. If it's not related to the 68080, then it might be the expected PAK content that is different from mine.




Claudio Guglielmotti
(Apollo Team Member)
Posts 185
28 Oct 2017 08:37


I took a movie with my shitty camera...

Sorry for EasyBytez:
EXTERNAL LINK 



Mr Niding

Posts 459
28 Oct 2017 08:52


@Samuel Devulder

Thanks for sharing :)

Im wondering; are you planning to update the engine to utilize Vampire functionality, or tinkering with the engine more for fun than anything else?


Chris Dennett

Posts 67
28 Oct 2017 09:16


You can post videos unlisted at Youtube then post the link, it has the same effect as using one of these sites


Samuel Devulder

Posts 248
28 Oct 2017 09:18


@Mr Niding: I don't know yet. The code is right now  big mess. I need to clean it up a bit by keeping only the valuable optimizations. Regarding Vampire optimization, I don't know much of how to write optimal 080 code (see my question above regarding the V1/V2 code.)
 
@Claudio thanks! That'll be helpful to guess what's going on... oh sh*t! The link doesn't work :(
Access not possible
The access to this folder is currently not possible
Please try again at a later moment



Mr Niding

Posts 459
28 Oct 2017 09:22


@Sam

I uploaded it to youtube;

EXTERNAL LINK


Chris Dennett

Posts 67
28 Oct 2017 09:26


Some of these console variables might help to achieve a consistent framerate EXTERNAL LINK 
Check especially the ones for particle effects


Samuel Devulder

Posts 248
28 Oct 2017 11:01


Mr Niding wrote:

      I uploaded it to youtube

Thanks!
     
I can see 3 major issues:
      1) in the very beginning of the demo (say at 5sec), the texture for the floor and the left/right walls is too blocky compared to the texture of the distant wall and the ceiling.
 
      2) every so often, there are transient 32pix horizontal segment that appears as black/grey.
 
      3) the water at the end of the demo (e.g. @1min10sec) is totally mangled.
     
None of these appear on my testing setup (UAE, with or without JIT).
     
I think I've already seen issue 2) on a video running the clickboom version. The width of the segments might indicate that this is related to the data cache. I don't know if the cache can be disabled on the vampire, but it might be interesting to test without it.
     
Issue 1) and 3) might be the same actually and related to a wrong calculation of the dx/dy steps in the texture.
     
Before making blind hypothesis, I think it is important to test with the same data file that I have. So here is my PAK+config file: EXTERNAL LINK   
 
Can anyone test with these files and tell if these issues shows up on their Vampire as well. I'd also like to have feedbacks on 060 or 040 (or 030) amigas to see if these only affect the Vampire or not.
     
In any case, these issues are interesting to study. I didn't expect the display being so different from mine :/


Samuel Devulder

Posts 248
28 Oct 2017 12:05


Oh I also noticed that the Gun (!) is appearing/disappearing every so often. That's very very odd, but it makes me suspect a defact in the  FloorDivMod() function. That function temporary changes the rounding mode of the FPU and it is possible that FEmu doesn't handle this correctly on the Vampire.


Claudio Guglielmotti
(Apollo Team Member)
Posts 185
28 Oct 2017 12:24


I tried your pak and it is the same.
About the gun... it is strange because i had the issue only when i grabbed the movie... nor my quake nor your quake gives the issue now !!


Samuel Devulder

Posts 248
28 Oct 2017 12:29


I'd say that the big Gun is busy at amiga32.. this might explain the erratic apparitions :) :) :) :)
 
Depending on the reports for tests on genuine 680x0 setup, the issues might be related to some weakness in the FPU emulation by FEmu or not. Quake is stressing the FPU a lot. I'm pretty sure that the rounding mode is a good suspect.


Thierry Atheist

Posts 644
28 Oct 2017 13:20


Samuel Devulder wrote:
I'd say that the big Gun is busy at amiga32.. this might explain the erratic apparitions :) :) :) :)

LOL!!!!!!


Samuel Devulder

Posts 248
01 Nov 2017 00:11


Ok, I've successfully ported the ASM code to all four compilers (SAS/C 6.58, VBCC 0.906, GCC-2.95.2 and GCC-3.2.2).
   
I've optimized the ASM a bit more, got rid of the stack being too small by default, and fixed a few issues that I didn't expected (gcc returning floats in d0 whereas all others compilers use fp0  and a nasty issue in sin(very small values) resulting in a left tilt/roll of the view while walking[*]).
   
Now with most of the rendering and 3D calculations being written in ASM, there are less differences in speed between the compilers. On my test machine (virtual: it's uae) the speed boosted from 45fps up to 133fps roughly (~3x speed increase) with the following command-line that starts quake on a 320x200x256 RTG screen:
quake.xxx.yyy.zzz -usemode 0x50001000 -winsize 320 200 -nosound

You can test these new versions on your vampire and other accelerator boards by downloading the zip file here: EXTERNAL LINK (temporary link)
 
I don't know if the issue with the texture has been fixed or not. Please tell me as I can't observe them on my test-machine. It might be related to one of the fixed issues above.
____
[*] that only appears with the gcc versions running under UAE. It's likely to be a bug in fpu emulation related to rounding mode change not being correctly reset, but I must also check on real machines because it's maybe something about the FPU that I'm doing wrong. I asked the french amiga fans to help me with that, see this thread for french speakers: EXTERNAL LINK


Gregthe Canuck

Posts 274
01 Nov 2017 00:51


Hi Samuel -

Very cool. Getting a clean portable compile is a huge step. Well done sir.

Looking forward to future updates. Cheers!


Simo Koivukoski
(Apollo Team Member)
Posts 601
01 Nov 2017 06:37


Samuel Devulder wrote:
You can test these new versions on your vampire and other accelerator boards by downloading the zip file here: EXTERNAL LINK (temporary link)

21.0fps quake.vbcc.030.881
18.8fps quake.sasc.030.881
26.0fps quake.clickBOOM.060



Claudio Guglielmotti
(Apollo Team Member)
Posts 185
01 Nov 2017 07:05


I tried Quake too, but on a 320x240 screen.
The textures issue is still there.
gcc version refuse to work (it says bad pak or something like that)
sasc works at 15 fps (like the previous executable)
vbcc works at 16,5 fps
Clickboom's quake run at 21fps (on the same 320x240 screen)

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