I'm not 100% sure, but it seems that working with images larger than a few thousand pixels in width (the currently used image is 3072*618 which displays the stage you are playing on) presents various speed problems with my FB program, particularly in the realms of drawing such an image to screen.
I understand the speed problems if I simply draw the entire image, only showing a segment of it due to the size of the graphics window. There are TONS of pixels to deal with, and that number will ONLY get bigger as the stages become much larger (possibly into the tens of thousands of pixels wide).
This is what I was doing originally. I noticed this, and instead now I only draw a select portion of that image (1024*618), which in theory shouldn't make the game too slow as when I was working with this stage size before, there were almost no speed deficiencies. Well, I was wrong. Absolutely NO speed was gained in doing so. I would have thought it would, because isn't selecting a portion of the image using (x, y)-(x, y) in the put command directly accessing said pixels, as if they were simply a memory location?
So it seems even remotely dealing with a very large image in a loop causes an FB program to slow down so drastically?
I have this question;
In what way can I make my FreeBASIC program run faster if I am working with such large images?
The large image I was referring to is dealt with only internally and does not save and load from an image file. I am currently using this:
Code: Select all
put (0, 0), graphic, (bg_x_offset, 0)-(bg_x_offset+1024, 618), pset
To draw my graphic to the screen, where bg_x_offset is a variable used for the scrolling engine to move the background along (i.e. select the 1024*618 portion of my stage graphic to display). I have commented out various parts of graphical updating and that hardly if at all influences speed at the moment. What does influence speed is that line, I am mostly sure. This tells me that: blitting an image onto another image is pretty damn fast, and blitting an image to the screen is comparatively slow. I'm pretty sure this was to do with how memory was managed for the screen?
I would post some code but I'm trying to keep it pretty closed-sourced right now. I will provide any details about my code you would like.