Any alternative to cls?

dpixel · Post by **dpixel** » Dec 12, 2008 6:56

Just screwing around with a few of my recent programs I've noticed that elininating cls in the loop increases my speed by about 20%. I'm only on a 900 mh computer...so the slowness might be multiplied. I have one program which I'm running about 18 FPS on aprox. 9500 calculations per loop and I get rid of the cls and it goes to 25-26 FPS. It just seems like a lot for clearing the screen buffer. maybe I'm wrong. I'm just wondering if anyone else noticed that and what other people may use. I'm just using freebasic graphics(fbgfx.bi)
And I also notice just the screenlock/screenunlock gives me the best performance instead of page flipping, etc. Does that sound accurate?
I'm not complaining or anything. I love this compiler...coming from a 14 year vb user...this is extremely fast.

SSC · Post by **SSC** » Dec 12, 2008 8:09

if you draw over the entire screen then there is really no need for cls, however if you dont you could either use cls, draw a box around the entire screen, or use a different graphics lib (SDL / OpenGL). I honeslty have never tested speed so I can't tell you how fast any of it is.

Post by **counting_pine** » Dec 12, 2008 14:11

The fastest way to clear the screen is probably just to write zeroes to the screen memory:

Code: Select all

#include "crt.bi"
sub ScreenClear( byval col as ubyte = 0 )
    
    dim as ubyte ptr scrbuff = any
    dim as integer scrpitch = any, scrheight = any, scrsize = any
    
    scrbuff = screenptr
    
    if scrbuff = 0 then exit sub
    
    screeninfo( , scrheight, , , scrpitch )
    scrsize = scrpitch * scrheight
    
    screenlock
        
        clear( *scrbuff, col, scrsize )
        
    screenunlock
    
end sub

dim as integer fps, frames = 0
dim as double t = timer

screenres 800, 600

do until len(inkey)
    
    #if 0
        cls
    #else
        ScreenClear( )
    #endif
    
    frames += 1
    if abs(timer - t) >= 1 then
        fps = frames
        frames = 0
        t = timer
        windowtitle "fps: " & fps
    end if
    
loop

ScreenClear is faster then Cls - although not drastically - and allows a limited amount of freedom with the color.
Note in this test that both ops cause a screen refresh, hampering the speeds a bit. The penalty won't apply if the screen is already locked.

rolliebollocks · Post by **rolliebollocks** » Dec 12, 2008 14:14

Ya. I never had a problem with CLS in my main loop and I doubt that page flipping to an empty screen would be any faster, but you can try it.

It would entail setting multiple screens with

screenres x,y,colordepth, numpages

and then screencopy-ing the blank screen over the new one.

Let us know if its faster. CLS is a nice way to clean up a screen.

rb

Lachie Dazdarian · Post by **Lachie Dazdarian** » Dec 13, 2008 0:45

Well, in fbgfx LINE (0,0)-(ScreenWidth, ScreenHeight), RGB(0,0,0), BF is notably faster than CLS.

D.J.Peters · Post by **D.J.Peters** » Dec 13, 2008 1:23

box filling drawing is faster than CLS you must turn off the fbgx thread
screenlock
line (0,0)-(w-1,h-1),0,BF
screenunlock

the box filler used fast MMX and must not handle any text and gfx cursor stuff

Joshy

wolfstar · Post by **wolfstar** » Dec 13, 2008 6:24

If there's not too much going on on the screen it's much faster to just draw over the old sprites with the background colour.

Code: Select all

circle (oldx, oldy),radius,backgroundcolour 'a boxfill would be even faster
circle (newx, newy),radius, spritecolour

So you're potentially just doing small boxfills instead of the entire screen.

Lachie Dazdarian · Post by **Lachie Dazdarian** » Dec 13, 2008 16:17

Well, of course. If your background gfx content erases all the content from the previous loop, using any sort of screen clearing statement is pointless and redundant.

dpixel · Post by **dpixel** » Dec 13, 2008 19:26

Thanks for all the ideas. It looks like line(0,0)-(ScreenWidth, ScreenHeight), 0, bf is a bit faster.

And I only used a box to fill what I need which saved some speed also.

ScreenClear() is flickery..I took the screenlock\screenunlock out of the sub and the flicker was gone.

Code: Select all

Sub ScreenClear( Byval col As Ubyte = 0 )
    
    Dim As Ubyte Ptr scrbuff = Any
    Dim As Integer scrpitch = Any, scrheight = Any, scrsize = Any
    
    scrbuff = screenptr
    
    If scrbuff = 0 Then Exit Sub
    
    screeninfo( , scrheight, , , scrpitch )
    scrsize = scrpitch * scrheight
    
        Clear( *scrbuff, col, scrsize )
    
End Sub

The speed seems the same as cls.

I'll have to mess around with this a little further.
Thanks agian.

Post by **counting_pine** » Dec 14, 2008 0:14

What sort of flickering are you getting with ScreenClear?

Note: don't use it without the screenlock/screenunlock statements: you shouldn't write directly to the screen buffer while the screen is unlocked.

I won't be offended if you choose a different method, particularly given Line's simplicity and the ability to work on portions of the screen. I would be interested in feedback though, if the code's not working properly.

dpixel · Post by **dpixel** » Dec 14, 2008 5:38

It's a pretty extreme flickering as if you put cls before the screenlock in the loop. I have a screenlock/screenunlock in the main loop already and I thought the screenlock/screenunlock in the sub screenclear() might be working against each other somehow. So I pulled them out and the flicker went away. It works just as cls.
I also tried it the other way for the hell of it...Pulling the screenlock/screenunlock out of my main loop and leaving the sub unchanged and the flicker is still there.
I also tried leaving just the screenlock in the sub and just the screenunlock at the end of my loop and that worked with no flicker but with the same performance as cls.
If I'm locking the screen in the main loop wouldn't screenclear() just clear the screen? Why would it need to lock the screen if I already had a screenlock or page flipping?
I'm using version 0.18.5. Might that be a problem?

I'm very open to all methods. Everything is always a work in progress anyways. lol

Thanks for all the input. This is very interesting to me as I'm always looking for speed and another way to skin a cat. (i love cats btw)

nkk_kan · Post by **nkk_kan** » Dec 14, 2008 9:09

Ideally, you shouldn't put screenlock/unlock in a sub..It can create problems
You should just have a one pair in main loop and only put the drawing part between screenlock/unlock since if you have some code that loops infinitely or something, then it will freeze the program and you'll have to kill the process.

Sisophon2001 · Post by **Sisophon2001** » Dec 14, 2008 10:22

Ideally!

Remember that every single FB drawing function locks the screen before drawing to screen, so the ideal situation may not apply.

Garvan

Post by **counting_pine** » Dec 14, 2008 14:27

dpixel wrote:I'm using version 0.18.5. Might that be a problem?

Oh right, that is the problem.
The most recent version of FB allows locking the screen multiple times, unlocking the screen only when all the locks are cleared. This allows you to put lock/unlock statements in your sub without having to worry about whether the screen is already locked.
If you're sure the screen will already be locked when you call it, then it's OK to remove them. But if you're using the latest FB, then they just give you an additional level of safety.