• ### Popular Now

• 10
• 12
• 12
• 14
• 17

#### Archived

This topic is now archived and is closed to further replies.

# Why isn't this faster?

This topic is 6448 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I am working on a 2D tile-based RPG using Visual C++ and DirectX 7.0a. The resolution I''m using is 320x240x16bpp. Currently, fading is being done by a software function since I don''t know anything about Direct3D, and I can''t figure out why it''s still slow. I saw a tutorial on this somewhere, which I didn''t understand very well. Anyway, I''m using a huge lookup table: int clut[20][65536]; The current fade percent is always a multiple of 5, so fade percents 5%-95% use the appropriate column of this lookup table. If the percent is 100%, the function simply returns without doing anything, and if it''s 0%, it just uses ZeroMemory(). Now, this is what my fade looks like:
  pct/=5; USHORT* clut_sp = &clut[pct][0]; // do the fade for (y=0; y<240; y++) { for (x=0; x<320; x++, ptr++) *ptr = clut_sp[*ptr]; ptr+=step; } 
In this code, ''pct'' is an integer between 5 and 95, since the extreme cases of 0 and 100 have already been taken care of by this point. The ''ptr'' is a pointer to the surface memory that has been taken from a call to IDirectDrawSurface7::Lock(). Finally, ''step'' is equal to the memory pitch in bytes, minus 640, to account for irregular pitch. The problem is the speed. The example code I saw that implements something like this seemed to be going faster than my code, using a 640x480 resolution! How can this be running on one-quarter as many pixels and still be slower? I would think the way I have it now is about as fast as it''s going to get, but... any ideas? -Ironblayde  Aeon Software

##### Share on other sites
You have to realize "for" loops are slow in manually editing graphics. I to edit the whole screen takes over (320 * 240) mov statements. A quick fade can be done by using the DDraw gamma controls. Or, if you are totally bent around manually editing pixel data, try to use a memcpy for an entire line because memcpy''s are SOOOOOO much faster than a manual incremental location moving using the "=" operator. But I''d recommend using DD gamma controls. They have an article on that here at game dev. Check it out.

-IOFILE

##### Share on other sites
What surface are you locking? The primary surface? (Video memory?) Reading and writing from video memory is incredibly slow. You want to be mucking with a surface in system memory, and then blit it all at once to video memory.

##### Share on other sites
I thought the DirectDraw gamma controls were unsupported on most video cards, and didn''t have any counterpart in the HEL... was I wrong?

This is the back buffer I was dealing with, and yes, it was in video memory, not system memory. I didn''t know manual edits would be faster in system memory, thanks!

And actually, after posting this, I got the Direct3D solution working instead, so now I don''t even have to speed this up, but hey, it''s still good to know.

-Ironblayde
Aeon Software