Oval slower than rect?
Blitz3D Forums/Blitz3D Beginners Area/Oval slower than rect?
| ||
| Wotcha folks, After several months of dipping my toes into DarkBasic, I'm back to Blitz once more (I should have learnt by now). Just to get me started I've typed in one of my bouning ball routines but am puzzled as to why it's coughing and spluttering along. Graphics 800,600,32,2 SetBuffer BackBuffer() SeedRnd MilliSecs() ;set up ball type Type balls Field x,y,xx,yy End Type createballs() ;main While Not KeyHit(1) Cls drawballs() Flip Wend End ;draw balls Function drawballs() For ball.balls = Each balls ball\x=ball\x+ball\xx ball\y=ball\y+ball\yy If ball\x>780 Then ball\xx=-1 If ball\x<1 Then ball\xx=1 If ball\y>580 Then ball\yy=-1 If ball\y<1 Then ball\yy=1 Oval ball\x,ball\y,20,20 Next End Function ;create balls Function createballs() For f=0 To 1000 ball.balls = New balls ball\x=Rnd(700) ball\y=Rnd(500) ball\xx=1 ball\yy=1 Next End Function I seem to remember writing something like this before and having literally thousands bouncing all over the place. Also, if you swap oval for rect, why is it faster? Have I missed something obvious? Many thanks in advance. Tobo. |
| ||
| Drawing rects is much faster than ovals. Drawing images is much faster than drawing rects :) |
| ||
| yup,... a much better way is to use an image. You should pre-draw a single oval into an image buffer, and then just use that instead of using oval every time. |
| ||
| kragoth74 and Pongo have the right of it. Drawing an oval needs computations as to where to draw the circular aspect of the ball. This involves floating point math, which is way slower than integer math. Hence, the Rect is faster because it is pure integer math. But, Drawing an image is faster still, because instead of computing pixels on a pixel-by-pixel basis (as do the Oval and Rect commands), you're just copying from the Image to the screen. I have a tiled-game I am writing, like the old Ultima series, which requires scrolling text to be printed. I tried using the Text command, but I could literally see the Text being draw to the screen line-by-line. I thought, this is way too slow. (It also showed me what other Blitzers have complained about in the past, that the Text command is slow). Then, I hit on the idea of creating an Imagebuffer, and drawing the Text to that, building a graphic image of text a line at a time. Then, I would just Drawblock that image containing all the Text lines to the screen. The Text is there as fast as a blink of the eye (faster, really). When the Text got to the bottom, I used CopyRect to move the whole "history" of Text-up one line, creating the illusion of scrolling text. The whole point is, drawing images is 'way faster than Text, and also faster than Oval and/or Rect commands, because in the case of these latter three, everything has to be computed, not copied as the DrawBlock/DrawImage commands do copying. Cheers! |
| ||
| Thanks for the help, Guys. Thing is, yonks ago, I wrote a screensaver thingie for my PC at work. It was along the lines of the above and had around 50-100 different oloured ovals bouncing around the screen. Within each of these ovals was another smaller white oval placed near the top left of the original, to give the impressions of light bouncing off of it. Thing is, on that, I must have around 200 ovals bouncing around the screen happ as larry. And that's using a crappy Duron 2400 with built in graphics card. So why is my Athlon 3k with Radeon struggling? Is there a way decompile Blitz Executables? I don't think I have the source code for that any more! Tobo. |
| ||
| The 2d performance on many new cards is pretty pathetic. I have seen much older cheapo cards out-perform top of the line 3d cards. It seems that once 3d cards came out, they stopped advancing anything regarding 2d drawing, so those are quite slow. |
| ||
| Decompiling Blitz Executables is (I think) a no-no. |
| ||
| Not meaning to hijack your thread but if bouncing balls screen savers are your thing then check out Watchaball - http://www.boiledsweets.com/Watchaball |
   |