Page 1 of 1

HW scrolling - What should I expect?

Posted: Wed Jul 01, 2015 10:30 pm
by TheMartian

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.

@REQUIRE "glgalore"
@BRUSH 1,"Test.bmp",{hardware=True}
@DISPLAY 1,{Width=1024, Height=768, Title="JSPs Test display", Color=#BLACK}
For x=0 To 2000 Step 4
NPrint(n) ; Checking that I do indeed have a HW brush

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.


Re: HW scrolling - What should I expect?

Posted: Thu Jul 02, 2015 1:40 pm
by airsoftsoftwair
Are you testing this in fullscreen or windowed mode on the X1000? In windowed mode vertical synchronization is currently not perfect on AmigaOS and compatibles. In fullscreen mode, however, there should be perfect synchronization since GL Galore uses dedicated hardware double buffering routines provided by the OS.

Re: HW scrolling - What should I expect?

Posted: Sat Jul 04, 2015 8:28 pm
by TheMartian

Ok. I was testing in Windows mode. With Fullscreen mode it is much better. The original test ran smoothly, so I decided to see if there was a limit somewhere. I set up a 1920 * 1200 display and painted it over twice with tiles in size 128 pixels (six corners, so there is some overlap). To do so and including a few rows/columns outside the visible area to cover pixeloffsets and partially displayed tiles I needed 19 *16 *2 tiles done 60 times a second. I ran 2048 iterations. With an expected 60 iterations/second it ran for about 34.7 seconds This is actually very close to the expected 34.13 seconds. But there were some jitters every second or two, which accounts for the extra half second. Assuming that the calculations use a fixed amount of time per iteration, the limitation must be with the displaying of tiles. The Windows version did run at about 34.13 with its more powerful graphics card. Am I disappointed? Not at all. The thing is, I was displaying nearly 36500 brushes every second! Once I dropped the number of columns and rows a bit, the display became steady, and timing stood at about 34.13. I have not established exactly how many tiles I can display every second. But probably around 30.000 per second. So that is what I have to stay within.

Fullscreen implies some sort of autoscaling of displayed graphics, but I guess that I can set up my window and calculate the proper number of rows/columns based on the ratio returned by #ATTRHOSTWIDTH and #ATTRHOSTHEIGHT so my hexacon tiles don't get flattened or elongated when autoscaled.

But 30.000+ tiles displayed per second.... I am impressed! :D


Re: HW scrolling - What should I expect?

Posted: Sat Jul 04, 2015 11:05 pm
by airsoftsoftwair
But 30.000+ tiles displayed per second.... I am impressed!
Welcome to the wonderful world of hardware-accelerated texturing :)