HW scrolling - What should I expect?
Posted: Wed Jul 01, 2015 10:30 pm
Hi
Having replaced a 6000 series Radeon in my X1000 with a RadeonHD R7 250X 1 Gb graphics card and getting the newly released 3D driver I was curious to see how good scrolling of large areas worked using HW acceleration. I am a great fan of Civilization and wanted to see if I could make a smooth scrolling playfield using tiles with six sides showing a background and a foreground and possibly a grid imposed on both. I tested using either 128 pixel or 64 pixel width tiles. This means that for each redraw (Flip()) I have to draw 2-300 brushes.
This will work and I can do smooth scrolling on my Windows machine. (A big brute with 6 cores 3.3 GHz and a graphics card to match.) On the X1000 it scrolls nicely for maybe 50-100 iterations and then there is sort of a ripple running up or down like it is missing a redraw before again scrolling nicely for a second or two and then the ripple ting happens again etc. The intervals are not fixed. This is not really visible if you scroll 1 pixel for eacp Flip(). But then scrolling an entire screen takes ages. If I scroll say 4 or 8 pixels per Flip() it gets increasingly noticable - not more frequent, just more noticable, as the movements are larger.
So I thought that maybe the system had problems finishing the calculations for plotting the many tiles every now and then. Therefore I created a large brush and simply scrolled it as in the code below... The code is from the Windows version of my test. On the X1000 I tested with a brush loaded from mpeg or png format files. I used DisplayBrush() on the X1000 for the tiles and I use DisplayBrushPart() in my Windows Test here because I have one large 'tile' and displays part of it.
@VERSION 6,0
@REQUIRE "glgalore"
@BRUSH 1,"Test.bmp",{hardware=True}
n=GetAttribute(#BRUSH,1,#ATTRHARDWARE)
@DISPLAY 1,{Width=1024, Height=768, Title="JSPs Test display", Color=#BLACK}
BeginDoubleBuffer(True)
For x=0 To 2000 Step 4
DisplayBrushPart(1,x,0,0,0,1024,768)
Flip()
Next
EndDoubleBuffer()
NPrint(n) ; Checking that I do indeed have a HW brush
WaitLeftMouse
The ripple effect was seen here too on the X1000 whereas the Windows system scrolls perfectly, and it is perhaps more frequent, which I did not expect, because I thought it was an issue with calculation time.
If I understand this correctly the combination of GLGALORE and Flip() should force the redraw to match the displays refresh rate. This seems to be the case because I get a slightly higher framerate if I use HW brushes without activating GLGALORE and just let the system draw whenever it is ready with the calculations. This too causes similar ripples. But if I use GLGALORE and Flip() redraws in sync with the display - what causes the ripple effect? Is it simply that this is a limitation in hardware on the X1000. After all the PC is about 10 times more powerful (Both CPU and GPU). Or is there a trick to this? Is so, please someone tell me. I have just started my summer vacation and the plan was to spend the next few weeks getting this project on to a good start - and getting a tan and all the other stuff you do on a vacation.
In any case I must say that GLGALORE has made life so much easier, when it comes to do fast moving graphics. Thanks Andreas.
regards
Jesper
Having replaced a 6000 series Radeon in my X1000 with a RadeonHD R7 250X 1 Gb graphics card and getting the newly released 3D driver I was curious to see how good scrolling of large areas worked using HW acceleration. I am a great fan of Civilization and wanted to see if I could make a smooth scrolling playfield using tiles with six sides showing a background and a foreground and possibly a grid imposed on both. I tested using either 128 pixel or 64 pixel width tiles. This means that for each redraw (Flip()) I have to draw 2-300 brushes.
This will work and I can do smooth scrolling on my Windows machine. (A big brute with 6 cores 3.3 GHz and a graphics card to match.) On the X1000 it scrolls nicely for maybe 50-100 iterations and then there is sort of a ripple running up or down like it is missing a redraw before again scrolling nicely for a second or two and then the ripple ting happens again etc. The intervals are not fixed. This is not really visible if you scroll 1 pixel for eacp Flip(). But then scrolling an entire screen takes ages. If I scroll say 4 or 8 pixels per Flip() it gets increasingly noticable - not more frequent, just more noticable, as the movements are larger.
So I thought that maybe the system had problems finishing the calculations for plotting the many tiles every now and then. Therefore I created a large brush and simply scrolled it as in the code below... The code is from the Windows version of my test. On the X1000 I tested with a brush loaded from mpeg or png format files. I used DisplayBrush() on the X1000 for the tiles and I use DisplayBrushPart() in my Windows Test here because I have one large 'tile' and displays part of it.
@VERSION 6,0
@REQUIRE "glgalore"
@BRUSH 1,"Test.bmp",{hardware=True}
n=GetAttribute(#BRUSH,1,#ATTRHARDWARE)
@DISPLAY 1,{Width=1024, Height=768, Title="JSPs Test display", Color=#BLACK}
BeginDoubleBuffer(True)
For x=0 To 2000 Step 4
DisplayBrushPart(1,x,0,0,0,1024,768)
Flip()
Next
EndDoubleBuffer()
NPrint(n) ; Checking that I do indeed have a HW brush
WaitLeftMouse
The ripple effect was seen here too on the X1000 whereas the Windows system scrolls perfectly, and it is perhaps more frequent, which I did not expect, because I thought it was an issue with calculation time.
If I understand this correctly the combination of GLGALORE and Flip() should force the redraw to match the displays refresh rate. This seems to be the case because I get a slightly higher framerate if I use HW brushes without activating GLGALORE and just let the system draw whenever it is ready with the calculations. This too causes similar ripples. But if I use GLGALORE and Flip() redraws in sync with the display - what causes the ripple effect? Is it simply that this is a limitation in hardware on the X1000. After all the PC is about 10 times more powerful (Both CPU and GPU). Or is there a trick to this? Is so, please someone tell me. I have just started my summer vacation and the plan was to spend the next few weeks getting this project on to a good start - and getting a tan and all the other stuff you do on a vacation.
In any case I must say that GLGALORE has made life so much easier, when it comes to do fast moving graphics. Thanks Andreas.
regards
Jesper