| 16 and 24 Bpp - Performance Question.. | |
|---|
|
|---|
| | 
Mateusz S.
Posts 53
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 6284
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 53
30 Dec 2020 09:11
| Great, thanks :)
| |
| |
Mateusz S.
Posts 53
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 6284
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 263
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 53
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 263
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?
| |
| | 
Nick Fellows
Posts 187
29 Nov 2021 13:47
| Q:
so why reinvent the wheel if the license permit the usage of the code?A: If FBlit is no longer maintained actively ( aminet archive last updated 2004 ). Actively maintained software is always preferable.
| |
|
Performance and Benchmark Results!