dramatic decrease in fps

I was doing a test of my game I am making....and while testing some new things I got a dramatic decrease in my frame rate.

First I changed the resolution to 640x480, which I guessed would decrease my frame rate by a little, but not a lot (I initially had it at 320x240).

I also changed my background map which I blit onto the screen. For all testing in the past, I have had a very simple background BMP which I through together in paintbrush, and using that background and at 320x240, I was getting 70 fps.

This time however, I took the time to get a nice background map to use so my game would look pretty. Using this nice background map at 640x480 fps, I got 27 fps.

This was a dramatic decrease in fps. I guessed it was soley because of the resolution change, and did not have anything to do with the change in bitmaps, because I was simply blitting the BMP's onto the screen. A blit is a blit, right? It is just a simple memcpy from memory of one location to another, so I guessed that the difference in detail of the BMP wouldnt matter, because it was just simply blitting the memory from one location to another...that simple...

So then I changed my res back to 320x240 to see if I would get my nice 70 fps frame rate back even when using the new background, but it stayed inside the 20-30 fps range every time I tested it....

So there are a couple things that might be the factor:

A. I forgot to change something back to its original factor in 320x240 mode after I had changed it to something else forr 640x480 mode, and that thing is somehow effecting my frame rate in a sorely negative way.

OR

B. The detail in a blit DOES matter, so the huge amount of increase in detail in my new background has dramatically decreased my frame rate.

What do you think it is? Does detail in a BMP really matter when you are blitting? Whats my problem?

what resolution is the original bit map? and the "detailed" one?
what are you using? asm?

Did you forget to change the size of the background back to 320x240?

Soln...

an update to the higher resolution [dimensional and i'm guessing color as well] means a much greater amount of copied data per blit, means frame rate go down down...

as for the background image, again depending on what API your using, loading images with higher color depths takes a greater hit on the frame rate as well... can you give us specifics about the bit depths of the modes as well as the picture file's size / native format?

/continue;

Reclaimer, one moment while I check the archive... dumm...hmmm..deee..ddummm...dooo....

Oh, there you are!

Here it is, Reclaimer:

Index 786537 provides a clear understanding of several key principles regarding indexed color models:

Quote:

---

1) pixmap requirements are calculated as follows: Pixmap
height times pixmap width times bits per pixel (bpp) or
"depth". Example:

320 x 240 x 8 = 614400 (or 615K per frame)

2) Addressing needs to be "aligned". Your rowbytes must
by aligned on 4-byte boundaries in order to allow the
processor to work in its native 32-bit favored word-
size. Memory accesses are faster because the processor
isn't having to waste cycle time masking and shifting bits
it isn't interested in.

3) Make sure all pixmaps are of the same depth. Usually
for most FPS (first person shooter's) this is 8 bits, which
allows a palette of 256 colors.

4) assembly is ideal for handling the actual drawing onto
the screen in drastically cut cycle times. Particularly for
operations such as per pixel calculations. For example,
on a 25Mhz processor, you might go through a
multiplication algorithm 7.2 million times in 3 seconds.
Converting this to an assembly macro can eliminate
incredible amounts of "stack time".

---

For your example, Reclaimer, you can see that by going from your 615K per frame model to something larger:

640 x 480 x 16 = 4,915,200 (or 4.9MB per frame)

Could substantially create a performance hit.