Wanderer wrote: I have mesured it by observing the frames-per-second with various amounts of object moving on the screen.
I dont know exact numbers anymore, but the numbers were something like this: (using smart object refreshing, not full screen refresh, means I did not restore the background with a full screen blitbitmap, I restored only regions that have been damaged, which is very fast if there are only few and small objects)
The conculsion is, that single buffering has almost no overhead (obviously), while blitbitmap and ChangescreenBuffer have suspiciously similar overhead. If ChangeScreenBuffer would just change the pointer, one would asume an overhead close to single buffering, not close to a full-screen bitmap swap.
And as you see, I have not only tried ChangeScreenBuffer(), also the lower-leveled ChangeVPBitmap() and ScrollVP(), all have performance in a very similar range. I was even desperate enough to try an auto-scroll oversized screen with double height and scrolled it, but that was ridicously slow.
If this is interesting topic for anyone, I could provide a demo with all those methods and you can run this on your Amiga to see the performance. But I have done this before, I doubt you will generate different results.
Yes, I would be interested to try out your test code. However, without seeing the code itself, I won't be able to say if you're getting the optimal performance out of it.
Both WaitTOF() + Blit and ChangeScreenBuffer() should be locked to the monitor's frame-rate, unless rendering takes longer than one frame period. This assumes that you're using ChangeScreenBuffers "wait until ..." message functionality. So, on a 65 Hz screen, the maximum frame-rate that you should be getting would be 65 fps. This makes your first results of 500fps/490fps look suspicious. I'm not sure what you're doing.
Regardless of your tests, Picasso96 does proper full-screen double-buffering. Like I said, I've seen the code.
Yes, this is correct. ChangeScreenBuffer and ChangeVPBitmap are both synced to the Monitors refresh rate and therefore the FPS is clamped. The actual speed has to be messured by adding more and more objects till the FPS starts to break down.
However, at least under my WinUAE, it is not the real refresh rate, it is some pseudo timer that is close, but not exact the Monitor Refresh. So scrolling is not smooth, it shows some tearing.
I will prepare a demo showing all variants of double buffering. I am quite interested how that works on NG Amigas.
It contains several binaries using several double buffering methods. In addition to that, you can select the syncing method when the demo is running. For ChangeScreenBuffer and ChangeVPBitmap, always use no sync, since they do their own syncing.
Strangely enough, I get only half the Monitor Refresh rate when using the those two dbl Methodes, as well when I use WaitTOF() or WaitBOVP() for syncing. Must be something wrong in WinUAE? I am pretty sure, when I tried this yesterday, I got the correct rate... hm...
It contains several binaries using several double buffering methods. In addition to that, you can select the syncing method when the demo is running. For ChangeScreenBuffer and ChangeVPBitmap, always use no sync, since they do their own syncing.
Strangely enough, I get only half the Monitor Refresh rate when using the those two dbl Methodes, as well when I use WaitTOF() or WaitBOVP() for syncing. Must be something wrong in WinUAE? I am pretty sure, when I tried this yesterday, I got the correct rate... hm...
Thanks. Unfortunately, when I tried to run it, it asked for zlib.library. I have a z.library, but have no idea where I could find zlib.library.
Thanks, I can get it running now, and it looks like there is something seriously wrong with Picasso96's ChangeVPBitmap(). I get 30 fps on a 60 Hz screen with a Radeon HD 4850, even with 0 objects.
For some reason the full-screen tests seem to hang with my Sam460ex + Radeon X1950 pro. My monitor switches off, and pushing escape doesn't quit.
Anyway, there is a bug in Picasso96 that needs fixing. Thanks for the test program. Hopefully I can track down why it won't start on the Sam460.
Yes, as I wrote I have the same trouble under WinUAE. That made me wondering if I made a mistake when implementing ChangeScreenBuffer. But ChangeCPBitmap behaves exaclty the same, and this is entirly different code.
And if I use e.g. BlitBitmap Methode, it runs at 500FPS, and when I set the timer to WaitTOF() or WaitBOVP(), it also slows down to 30Hz. (which is half the monitor). That implies that the bug is in WaitTOF()/WaitBOVP(), which is probably used by the self-timed double buffering functions.
But I am pretty sure, that I had a WinUAE configuration once, that did 60Hz. But I cannot reproduce it right now.
If you are interessted, I can give you the code of the demos for download. Actually the code is in the Amiblitz3 distribution, but the timing demos "main" is not.
EDIT: you seem to be quite knowledgable with Picasso96 internals. Did you develop drivers or somethingß
Wanderer wrote: Yes, as I wrote I have the same trouble under WinUAE. That made me wondering if I made a mistake when implementing ChangeScreenBuffer. But ChangeCPBitmap behaves exaclty the same, and this is entirly different code.
I have since discovered that it only happens when vblank interrupts are not available. Interrupts aren't implemented for Radeon HD cards yet, but they are for the Radeon X1000 series and older.
As I suspected, the graphics cards are so fast that it's hard to tell the difference between screen buffer swapping and doing a final blit. The only possible evidence that I can give you is the following: dbl_BltBmap nosync 3 objs: 314-318 fps dbl_scrollvp nosync 3 objs: 326-331 fps
Using dbl_changescreenbuffer and setting dbl_BltBmap to use WaitTOF(), both start dropping the frame-rate gradually at about the same point.
Quote:
If you are interessted, I can give you the code of the demos for download. Actually the code is in the Amiblitz3 distribution, but the timing demos "main" is not.
Yes, the source-code would be handy, although I have never used Amiblitz.
Quote:
EDIT: you seem to be quite knowledgable with Picasso96 internals. Did you develop drivers or somethingß
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
