I couldn't believe the results I found with this test program. Clearly, clearing the screen with a Cls command is hundreds of times more efficient than drawing 'blank' pixels.
I was testing to see if clearing the screen with a cls command and then redrawing only the upper about 1/3 of the screen would be more efficient than just drawing the entire screen (in one shot) with an image that covered the whole screen but contained 'empty' pixel info (0, 0, 0) in the majority of the image.
The image was something like this (0 represents empty pixels):
Interesting as well, DrawImage actually outperformed DrawBlock by 30%. I always assumed a DrawBlock would be faster since it didn't bother to check for masked pixels, but clearly not drawing the masked pixels at all is faster.
Cls = 6 millisecs
DrawBlock = 3150 millisecs
DrawImage = 2153 millisecs
That makes the Cls command 500 times faster than the DrawBlock command (350 times faster if you subtract 33% for the upper portion of the image being drawn). There must be some kind of Graphics card optimization being used there.
So, by using a Cls, and then only redrawing the top 1/3 of the screen, I was able to save 60% time.
and here's the code I tried:
- - - EDIT - - -
Oops, I realized now that the majority of the speed reductions was due to my loading the image as a type 4 image due to it being used as a title screen.
So, the stats still apply, but only to a type 4 image. When I loaded it as a type 1 (the default), then my test results weren't as significant, but still showed some improvement.
Cls = 6 millisecs
DrawBlock = 225 millisecs
DrawImage = 126 millisecs
That's still 37 times faster than the DrawBlock command.
And to show comparison, the same test program with images loaded as type 2s:
Cls = 6 millisecs
DrawBlock = 168 millisecs
DrawImage = 179 millisecs
DrawImage isn't any more efficient anymore with a type 2.
I was testing to see if clearing the screen with a cls command and then redrawing only the upper about 1/3 of the screen would be more efficient than just drawing the entire screen (in one shot) with an image that covered the whole screen but contained 'empty' pixel info (0, 0, 0) in the majority of the image.
The image was something like this (0 represents empty pixels):
0111111111111110 0111111111111110 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Interesting as well, DrawImage actually outperformed DrawBlock by 30%. I always assumed a DrawBlock would be faster since it didn't bother to check for masked pixels, but clearly not drawing the masked pixels at all is faster.
Cls = 6 millisecs
DrawBlock = 3150 millisecs
DrawImage = 2153 millisecs
That makes the Cls command 500 times faster than the DrawBlock command (350 times faster if you subtract 33% for the upper portion of the image being drawn). There must be some kind of Graphics card optimization being used there.
So, by using a Cls, and then only redrawing the top 1/3 of the screen, I was able to save 60% time.
and here's the code I tried:
Graphics 640, 400 ;load main menu image MenuBG = LoadImage("testmenu_bg.png", 4) Flip Delay 2000 time = MilliSecs() For iter = 1 To 1000 Cls Next time2 = MilliSecs() For iter = 1 To 1000 DrawBlock MenuBG, 0, 0 Next time3 = MilliSecs() For iter = 1 To 1000 DrawImage MenuBG, 0, 0 Next time4 = MilliSecs() Cls Text 0, 0, time2-time Text 0, 30, time3-time2 Text 0, 60, time4-time3 Flip WaitKey End
- - - EDIT - - -
Oops, I realized now that the majority of the speed reductions was due to my loading the image as a type 4 image due to it being used as a title screen.
So, the stats still apply, but only to a type 4 image. When I loaded it as a type 1 (the default), then my test results weren't as significant, but still showed some improvement.
Cls = 6 millisecs
DrawBlock = 225 millisecs
DrawImage = 126 millisecs
That's still 37 times faster than the DrawBlock command.
And to show comparison, the same test program with images loaded as type 2s:
Cls = 6 millisecs
DrawBlock = 168 millisecs
DrawImage = 179 millisecs
DrawImage isn't any more efficient anymore with a type 2.