What i thought about when typing "type-ifier" - if you want to use this type of displaying an image more than once (the background) you may workout a "type" like the "TBigImage" which can be found here in the forums/codearchives.
If you want to code it by yourself:
One class/type holding the sliced parts of a big image: eg. TBigImageParts
One class/type holding the whole image and a list of the parts: TBigImage
Make a Creation-function which params an image, then lock this image, copy the desired parts of the image's tpixmap creating new TBigImageParts.
Add those parts to the list and unlock the image.
Make a Draw-method for TBigImage which runs through the list of parts and draw them.
You can define by yourself whats the width/height of each part, so you can split e.g. an 800x600 backgroundimage into:
top: 512x512, 256x512, 32x512
bottom: 512x128, 256x128, 32x128
To make the sizes get generated automatically you just code a loop which may look like (its neither tested nor checked for correct syntax):
local partWidth:int = 2
local maxWidth:int = 512
local minWidth:int = 32
local spaceLeft:int = Image.width
repeat
while (partWidth <= spaceLeft and partWidth <= maxWidth)
partWidth:*2
wend
'creating the new part-Image
spaceLeft:- partWidth
...
print "maximum partwidth fitting into the image:"+partWidth
until minWidth >= spaceLeft
'creating the last part
print "last part reached: creating part with rest of the image"
You can - I'm sure, shorten the loop to also include the last part ("frame") and to loop through the height of the image too - but my brain is kind of slow in the mornings.
Using this methods you save minimize the unneeded usage of VRAM. Drawing a 1024x768 image as a "block" will internally blow its dimensions up to 1024x1024, producing 256x768xdepth of not needed bits. Using 800x600 this is even blown to 1024x1024 making the methods mentioned above more useful than in your application.
---
To your problem with the fps: do your sprites use all the same timage or has each of them its own instance or random timage?
If they share the same base (they also may use "frames" of a image): it's much faster to draw them straight one after another than doing something like:
for local obj:mytype = eachin self.list
DrawImage(obj.img, obj.x, obj.y, obj.frame)
DrawImage(Overlay, obj.x, obj.y)
next
optimized:
for local obj:mytype = eachin self.list
DrawImage(obj.img, obj.x, obj.y, obj.frame)
next
for local obj:mytype = eachin self.list
DrawImage(Overlay, obj.x, obj.y)
next
Using the last method you will obtain an measurable increase of your fps because internally there would be no need to "switch" between images.
As you sometimes need to draw an "overlay" over a sprite which is then partly covered by another, you may include something like "layers" or "z"-values - corresponding to them you loop through the two loops above (loop until "z" changed and so on).
Short: avoid switching between images as often as you can. Place "small" images into one imagestrip (eg. all tiles for one theme of a level-set).
splitting it this way you may even speed up your app when you can be sure that one typ doesn't need alphablending, you may set the blend to solid before a whole list of sprites/images is drawn and then set it to alpha back again.
Ok enough, tired ;D
bye MB