Frames per second with graphics demo.

sccoupe

I am playing with the graphics demo and stripping it down for my own needs. I have basically remove everything but the large number that counts in the upper left corner of the screen. I then moved that to the right side of the screen, made the number much larger in size and thickness and added the number "14" in front of it. So basically I have 14X on the screen with the X counting up. A screenshot is attached. My·problem is that·I only get about 3 frames per second. I have it set to count and repaint the screen as fast as it can just as the graphics demo does, but the demo seems to have a much better framerate with much more happening on the screen. Any ideas as to the cause?

Thanks

VIRAND

Are you refreshing the onscreen buffer more than once per count?
I think it works with a BYTEMOVE, from offscreen to onscreen, which is FAST but
you only need to do it once per each count number not once per each digit.

If that's not the problem, look to see if the code in Graphics.spin that draws numbers or text or char is in PASM or SPIN.
If it's in SPIN, it will be a slow process to plot all the pixels for the THREE LARGE DIGITS compared to all the smaller
things in the demo. It might speed up if you make the digits just a little bit thinner and smaller.
Also, if you are counting and reusing the code that draws the digits, there might be a faster way
to count and break the number into digits than you are using. Is each digit counting separately
or are you counting to 999 and breaking the number into digits with / and // ?
It might be faster also if you can put the number in a string and display it as a string.
(Try to think of simplest fastest counting and displaying method.)

I recently modified the demo to work on TV and VGA screens at the same time, and everything didn't fit,
so I took out some stuff and added another digit, and it did slow down a little tiny bit I think.

Post Edited (VIRAND) : 2/2/2010 12:03:56 AM GMT

Jim Fouch

I've found that the Graphics.spin driver is pretty slow at drawing strings/text. When you increase the width of the lines that are used to display text it will slow down quite a bit more. If you're simply looking to create a counting number, you would better off using bitmap copy. Or depending how many characters you need to display you could change the color palettes behind the tiles and that would require almost no time to create a changing display. It would change a tile in one refresh of the display.

Based on 4 colors/tile, you could split the tiles to get a higher resolution.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch

FOUCH SOFTWARE

sccoupe

Here is the basic code that im using. Its right from the graphics demo but with all of the stuff except the number removed. I dont have the full code in front of me but this is basically it. Ignore the colorwidth, text size, and location·as I just threw this together from memory to show what im working with.

  repeat
    'clear bitmap
    gr.clear
 
    'draw incrementing digit
    if not ++numx & 7
      numchr++
    if numchr < "0" or numchr > "9"
      numchr := "0"
    numchr2 := "1"
    numchr3 := "4"

    gr.textmode(14,14,6,5)
    gr.colorwidth(2,12)
    gr.text(90,10,@numchr)
    gr.text(-90,10,@numchr2)
    gr.text(10,10,@numchr3)
 
    'copy bitmap to display
    gr.copy(display_base)
 
    'increment counter that makes everything change
    k++