Jump to content
  • Advertisement

Archived

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

cyberben

16bit RGB DDraw Macro's.

This topic is 6473 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

Hi there, I know this comes up all the time, however I wen through the last 6 posts to do with this and none of them helped. I need a macro for VC++ 6 which will create a 16bit color when supplied the 24 bit color. Here''s what I''m using now: #define RGB16BIT555(r,g,b) ((b%32)+((g%32)<<5)+((r%32)<<10)) #define RGB16BIT565(r,g,b) ((b%32)+((g%32)<<6)+((r%32)<<11)) And then I use code like this:
    
	ddbltfx.dwSize = sizeof(ddbltfx); 
	if (Is_555)
		ddbltfx.dwFillColor = RGB16BIT555(0,green,0);   
	else
		ddbltfx.dwFillColor = RGB16BIT565(0,green,0);   

	green++;
	if (green > 254)
		green = 0;
    
Then I do the normal bland out the BackBuffer with lpBackBuffer->Blt, etc... flip... And now if I replaced green in the color macro''s with 255 I get a nice perfect bright green, if I put in 128 I get that middle green that we all know so well. So I presumed it was working I also tried other colors like red and blue and yellow. However as soone as I started cycle the colors like this, it fades from black to green about 4 time then the next four go from red to yellow!?!? Then it starts over with black to green fades (Which is what I''d expect...) Any ideas? Oh and green is a char or byte. I''m new to C++ but I''ve done this in assembler many a times easy! Also what''s the fastest macro you guys got on hand? I''ve tried 3, this is the fastest. One of them would actually slow the frame rate, being called 1 per frame! Ridiculous.... Thanks, Ben __________________________ Mencken's Law: "For every human problem, there is a neat, simple solution; and it's always wrong."
"Computers in the future may weigh no more than 1.5 tons." - Popular Mechanics, forecasting the relentless march of science in 1949

Share this post


Link to post
Share on other sites
Advertisement
Oh and are macros anty *faster* than functions? Cause otherwise I''ll just make a function with a
    
_asm
{
}


and put in my assembler that I used...
Thanks,
Ben

Share this post


Link to post
Share on other sites
If you''re using C++, just use an inline function, which will give you the same speed benefit as a macro would. The use your _asm{} as you normally would, and you''ve got the best of both worlds, as far as speed goes.


random-nomad

[still searching]

Share this post


Link to post
Share on other sites
g%32 gives you the integer rest of the division of g by 32, so:
g g%32
0 0
1 1
. .
. .
. .
31 31
32 0
33 1
. .
. .
. .
63 31
64 0
.
.
.

so don''t understand how 128 gives you a middle green. (128%32 should give 0, black)?

You know, I never wanted to be a programmer...

Alexandre Moura

Share this post


Link to post
Share on other sites
Well I got the same results with other macros so the logic must be in with the shifting there....

I didn''t sit down and think out the logic, but maybe I should...
Anyone have some other color macros for me to look at and maybe use? I''m interested to see, I might just attempt to right my own macro out of my assembler version...

We''ll see....
Thanks,
Ben

Share this post


Link to post
Share on other sites
these might be slower...

#define RGB16BIT555(r,g,b) (((b&0xF8)>>3) +((g&0xF8)<<2)+((r&0xF8)<<7))

#define RGB16BIT565(r,g,b) (((b&0xF8)>>3) +((g&0xFC)<<3)+((r&0xF8)<<8))

(I haven''t teste the shoft values, might have some errors in them, but try them up. They use 0 to 256 interval for r,g and blue, though)

You know, I never wanted to be a programmer...

Alexandre Moura

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
#define RGB16BIT555(r,g,b) ((b%32)+((g%32)<<5)+((r%32)<<10))
#define RGB16BIT565(r,g,b) ((b%32)+((g%32)<<6)+((r%32)<<11))

should be

#define RGB16BIT555(r,g,b) ((b>>3)|((g>>3)<<5)|((r>>3)<<10))
#define RGB16BIT565(r,g,b) ((b>>3)|((g>>2)<<5)|((r>>3)<<11))

(sooner or later I ought to register)

Share this post


Link to post
Share on other sites
Yup! You guys got it. Thanks a lot... it appears the reason my macros go so slow is that my compiler will only compile in Debug mode... I''m still learning C++ and got the introductory edition free in my book... Is this true the Intro version only compile in Debug mode? If not please tell my how to change it! Cause I couldn''t figure it out!

See ya,
Ben

Share this post


Link to post
Share on other sites
what compiler is that? VC++? if so try to go to the build menu and "set active configuration" then select release (I don''t know if your version will have that option though)

You know, I never wanted to be a programmer...

Alexandre Moura

Share this post


Link to post
Share on other sites
cyberben: It could very well be that your macros are slow because of the modulus operations. The result of a modulus operation is gotten with a division, I think. The two numbers are divided, and you get two results: the result of integer division, and the result of modulus.

Anyway, if you want to use a modulus of a power of two, like you were doing in your original macros, remember that you can do the same thing with bit masks. For instance, (r%32) is equal to (r & 0x1F) if r is an 8-bit variable. If r is an int, just use (r & 0x0000001F) instead. This is only for positive numbers though; something odd would probably happen if you tried it with a negative number.

-Ironblayde
 Aeon Software

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!