Jump to content
  • Advertisement

Archived

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

Ironblayde

Why isn't this faster?

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
Share on other sites
Guest Anonymous Poster
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 this post


Link to post
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

Share this post


Link to post
Share on other sites
DirectDraw GammaCOntrol is emulated in version 7 if hardware is unavailable.

------------------------------
#pragma twice

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!