speed issues?

[RaverDave]

When I have alot happening,well not too much, maybe 25 balls rebounding here and there  :P  But there seems to be a massive drop in speed, and indeed when i print out the fps it does drop from the forced 60fps to 36 or 37 fps!

Now ok its not gunna want 25 balls rebounding in my game, but I have yet to add alot of other checks, mainly some bouncing aliens running around the screen(think arkanoid!)

Now when it gets limited to just 3 or 5 balls the fps stays steady at 57-60fps
So I can only presume its because the for next loop is enlarged and also the number of checks against the maps level is increased. So is there a way to optimize this? I am not sure?!

[kevin]

A couple of tips

*  You've obviously enabled VSYNC.  Just to be clear, this forces the redraw to wait for a perfect top of frame.  In other words if your games processing slips over the amount of milliseconds required for 1 perfect Vsync (ie. monitor refresh), it'll happily sits there and does nothing until the top of the next Vertical blank is reached.   Thus each a long frame, halves the frame rate.  

* Small Blits (drawing and image) are 'slower' than large ones.  This means that drawing thousands of small say 8*8 images is much slower than bliting the equivalent number of pixels in a 16*16, 32*32, etc  sze.   As it the setup time to blit each tile, is generally more expense than the actually blit, so there's zero gain.    In terms of drawing  maps with small tiles. it's critical that you only drawn the number of tiles you need.  Drawing excess, is a huge  waste of time,

* Real time Vector gfx are slower than images.   Thus rather than drawing circles for your balls, cache the circle to an image and then draw the image in it's place.  

* Buffer Lock over head.  Every  time you draw anything, the destination buffer has to be locked   The locking is controlled by windows.   To obtain a lock on a surface can be instant, or can take a number of milliseconds.   Which can really up.  So if your drawing a bunch of vector gfx items, it's best to pre lock the buffer, draw the items, then unlock it again after.  This will minimize the locking overhead.  

 * Use PSUB's when calling a high frequency function.   They don't have the same call/return over head of function.  Also, their locals are Static by default !.  SO it's not always wise.

 * Drawing Text is slow.  Where possible convert your font to a bitmap, or import your own use a bitmap font.

[RaverDave]

damn! your right it was the circle commands,now there is no speed loss atall, but the collisions dont seem to work as good or not atall,is this to do with where the hotspot of the image is,or handle?you know what i mean? If so then how do i change it?
**Edit ****

Also when I take out the ScreenVsync On command it seems to jutter alot,like pauses the movement in a jerky fashion? even testing different sync rates from 0>>
But keeping it on and its fine!

[kevin]

damn! your right it was the circle commands,now there is no speed loss atall, but the collisions dont seem to work as good or not atall,is this to do with where the hotspot of the image is,or handle?you know what i mean? If so then how do i change it?

Either use sprites, or draw your image offset from the objects position (the balls X & Y position).  Also make sure the size of the image and the size being considered for collisions are the same.

ie.

Width=GetImageWidth(MyBallIMage)
Height=GetImageHeight(MyBallIMage)
DrawImage MyBallImage, Xpos - (Width/2), Ypos - (Height/2),true

Also when I take out the ScreenVsync On command it seems to jutter alot,like pauses the movement in a jerky fashion? even testing different sync rates from 0>>
But keeping it on and its fine!

Of  course, you are seeing the frame displayed to the monitor while it's actually being drawn.

[Digital Awakening]

Another thing to consider is to only update the parts of the screen that needs to be updated. Another and easier way seems to be using a camera and the world commands. I don't really know how these work as I've only read about them once but I think they should speed up drawing. With the world commands you set up the tiles and just draw the balls etc to the camera and when you need to remove the tiles just remove them using the world commands.

No vsync means that the screen is updated wherever the monitor update is so it usually starts somewhere in the middle cauing the image to flicker, but it's faster.