Why does this work?
I''m reading the same book. The macro works...but I have no idea what''s happening. Im not to good with the whole macro and bit operation thing. Does anyone know of a good tutorial to help me out?
either the author was high when he wrote the book or made some serious typos which the editor missed. NEVER use plus in anything that is combining bits like this. it is messy that way. also never use the AND operator to clamp values when you are supposed to scale them. finnally NEVER use floating point in anything that is realtime and involves combining color componnents into pixels.
#define _RGB16BIT555(r,g,b) ( (r&0xF8) << 8)) | ((g<<5)&0x3E0) | (b>>3) )
more efficent then previous macros, though you should be able to come up with this from the info given. make sure all the inputs are longs or at least shorts or things wont work. ints are fine as well (for those not in the know, (ints can be 16bit or 32bit depending on the compiler, most nowadays have ints as 32bit).
#define _RGB16BIT555(r,g,b) ( (r&0xF8) << 8)) | ((g<<5)&0x3E0) | (b>>3) )
more efficent then previous macros, though you should be able to come up with this from the info given. make sure all the inputs are longs or at least shorts or things wont work. ints are fine as well (for those not in the know, (ints can be 16bit or 32bit depending on the compiler, most nowadays have ints as 32bit).
Author
Thanks for the suggestiongs, folks. I knew something was fishy when I saw that. I''ve actually been please with LaMothe''s code so far. I''ve had to correct a few things that wouldn''t compile, but I figured that had more to do with my compiler than anything else (I use Dev-C++. I think the compiler begins with ''M''. hehe).
I''ll fix the macro so that is scales the colors properly. I don''t know what Lamothe was thinking.
Oh, and good point, buzzy_b. 0 and 1 would really mess things up.
---signature---
People get ready.
I''m ready to play.
I''ll fix the macro so that is scales the colors properly. I don''t know what Lamothe was thinking.
Oh, and good point, buzzy_b. 0 and 1 would really mess things up.
---signature---
People get ready.
I''m ready to play.
''a person'', you must be smoking the same thing as LaMothe, because your macro is actually more broken than the original. 
The mask values and bit shifts are all wrong, and you managed to break the rule that YOU mentioned about using AND to scale values.
As for doing floating point to scale the values, there''s really no other way to do it. You just have to bite the bullet and do the scaling, hopefully caching the result to be reused for several frames. Most applications don''t require explicit format conversion on a frame by frame basis anyway (most only need it at load time if at all).
--
Eric
The mask values and bit shifts are all wrong, and you managed to break the rule that YOU mentioned about using AND to scale values.
As for doing floating point to scale the values, there''s really no other way to do it. You just have to bite the bullet and do the scaling, hopefully caching the result to be reused for several frames. Most applications don''t require explicit format conversion on a frame by frame basis anyway (most only need it at load time if at all).
--
Eric
Author
I think I''m just going to stick with 0-31, actually. Writing a bunch of code to scale the numbers when I could just get used to 0-31 is plain lazy, and I''d rather have the speed that comes with not having to use the FPU and doing the multiplies and pushing more variables on the stack.
I mean, scaling would be hella useful if I were writing a graphics library for someone else, but I''ll just be using this myself, so...
---signature---
People get ready.
I''m ready to play.
I mean, scaling would be hella useful if I were writing a graphics library for someone else, but I''ll just be using this myself, so...
---signature---
People get ready.
I''m ready to play.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
