Thread: the effects of textures on my frame rate

Check your video card settings.

PROBLEM SOLVED:

My frame rate is now: 60 fps (with textures)

That was the weirdest freakin thing in the world....

Seriously...

When I built this computer I installed the AGP drivers that came with the motherboard, but not my video card drivers.

After playing a few games I thought I didn't need to. All my games got GREAT frame rates. (Warcraft 3 included).

But for some reason MY project WASNT getting great frame rates. So I decided to install my vid card drivers today and boom my frame rates skyrocket....

Isnt that just so freakin gay....

>>Isnt that just so freakin gay....
No, it's common sense

Sorry, I just had to say that

Okay, first of all, let's get back to basics (ie, what is performance really about)-- I won't $$$$$, but this is what I've been trying to tell you all for years about understanding how your machine works.

I'm gonna address a few items, by no means all, but these alone will create dramatic improvements in performance in this code:

1) Work with 8-bit textures, not 24. This is by far the biggest time saver. In a game, the eye cannot distinguish 24-bit color sufficiently to make it useful. At best, don't go more than 16-bit. The fact that you are moving 3 bytes per pixel per frame, is INCREDIBLE the amount of work that is creating.

2) Don't waste time clearing buffers-- just put new data in them. It's faster. Remember the golden rule: Touch each pixel only once per frame.

3) Do not do a lot of testing (if's, fors, etc.) in your frame drawing-- tests are expensive in terms of time.

4) do not use local variables in your frame drawing code-- use globals, and registers where you can. Everytime you enter a function that gets and returns parameters, the system has to spend precious time setting up a stack frame. Don't waste that time.

5) Don't use functions where you don' t have to-- recode the item as a macro-- this eliminates stack-time altogether.

6) Don't use ints, and bytes for holding numbers, use the largest native word-size you can. This way, the processor doesn't have to waste time masking memory to work with just a few bits. In a 32-bit processor, you would use an unsigned long. I don't care if you're just counting to 8, use an unsigned long. It's not about the value the number will hold, it's how the processor handles it.

7) Put everything in memory so you aren't hitting the disk.

8) precalculate all your data so it's just sitting there, waiting to be displayed. Don't waste time manipulating data, if you can trade RAM for speed. Use the RAM instead of manipulation (ie. Store more data, even if redundant, if it's faster to access, rather than so, rotating a bitmap 90 degrees or whatever).

-----

Remember:

1) DON'T work with more data than you have to
2) DON'T do more work than you have to per pixel
3) DON'T do more work than you have to per frame

To get performance you trade one of two things (all are resources to you): You trade RAM for speed, or you trade code for speed.

For example:

The two fastest methods to swap the bits in a byte, end for end, come down to trading one resource or another for speed. In this case, You can use a table (uses RAM), or you can eliminate your loop and use more lines of nearly identical code-- one line for each bit being swapped)-- (uses code size).

enjoy.

>>recode the item as a macro
Just thought I would point out, inline functions are supposed to be just about the same speed

ah, but there's no guarantee of inlining, macro's always work.

Ah right, my bad. Although if you're using MSVC you can use __forceinline