Overview Features Instructions Performance Forum Downloads Products OrderV4 Contact

Welcome to the Apollo Forum

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



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Performance and Benchmark Results!

16 and 24 Bpp - Performance Question..

Mateusz S.

Posts 50
29 Dec 2020 21:49


Hello,
  So I watch lots of diffrernt and demanding games running on Vampires like Doom, Quake, Duke, Diablo etc. and they all run very well, I even saw Doom running on 640px width not to bad.. so the vampire cpu performance combined with RTG and fast memory is really good..
 
  I would like to ask, maybe someone has done some test:
  I guess that all those examples run in 256 indexed color pallete (8 bit per pixel).. I wonder if Vampire still keep 50fps when need to generate 320x240 screen in 16 or 24 bpp - I wonder if the memory bandwith will manage?
Edit: I am talkin only on generating pixels to output buffer - not using blitters, coppers etc.
 
  Let take simple, optimized Raycaster engine (like wolf3d) - I wonder how the performance will change when dealing with 16bpp or 24bpp.. the 8 bit runs very well of course :)


Gunnar von Boehn
(Apollo Team Member)
Posts 5314
30 Dec 2020 07:24


Mateusz S. wrote:

I would like to ask, maybe someone has done some test:
  I guess that all those examples run in 256 indexed color pallete (8 bit per pixel).. I wonder if Vampire still keep 50fps when need to generate 320x240 screen in 16 or 24 bpp - I wonder if the memory bandwith will manage?

Yes you can easily do 16bit, 24bit or 32bit.

We did some full screen texture map demo with
doing biliniear filtering = 4 texel lookup per screen pixel
using screen resolution of 640x360 in truecolor.

Here is a video of the result.
EXTERNAL LINK 


Mateusz S.

Posts 50
30 Dec 2020 09:11


Great, thanks :)


Mateusz S.

Posts 50
05 Mar 2021 23:38


Hello again Gunnar,
Could You please share some info how did You render that image? I mean did You use P96API functions like WritePixelArray to copy buffer into screen? I tried that function on WinUae emulator with rtg but is so slow even in 320x256.. Is that demo relays on AmigaOS functions or was "hard coded" in asm?

Thanks in advance..


Gunnar von Boehn
(Apollo Team Member)
Posts 5314
06 Mar 2021 08:52


The Demo was coded in ASM.
But also with WritePixelArray you can get smooth display.
Doom game for example uses WritePixelArray to update screen.


Kamelito Loveless

Posts 184
26 Apr 2021 14:06


Gunnar von Boehn wrote:

  The Demo was coded in ASM.
  But also with WritePixelArray you can get smooth display.
  Doom game for example uses WritePixelArray to update screen.
 

 
  Since Fblit is open and is patching many gfx functions to speed up things why not integrate it into ApolloOS for RTG modes? It has an MIT license so not sure if it is compatible with AolloOS one. It is written in assembly and I suppose that it could be tuned for 080 to even more performance.


Robo Kupka

Posts 23
26 Apr 2021 15:05


I think Gunnar already posted info about rewritting line/fill rendering routines in the ApolloOS to AMMX 080 code, so it is much much faster now. So it makes sense that the native OS routines are AMMX-fast, why "patch" them using FBLIT ?


Kamelito Loveless

Posts 184
26 Apr 2021 16:28


Robo Kupka wrote:

  I think Gunnar already posted info about rewritting line/fill rendering routines in the ApolloOS to AMMX 080 code, so it is much much faster now. So it makes sense that the native OS routines are AMMX-fast, why "patch" them using FBLIT ?
 

 
  I donít wriote patch them but instead of rewriting all gfx functions that Fblit patch use the code directly in the functions themselves in ApolloOS for RTG while improving them with AMMX along the way. I donít remember Gunnar saying that he rewrote them all but a handful of them. Morover Fblit code has been tested and are stable so why reinvent the wheel if the license permit the usage of the code?

posts 8