Hi,
2011/7/18 Cyril Hrubis metan@ucw.cz:
Hi!
As you may see I've fixed the generate branch to compile (that is good).
Thanks for fixing the rest of the library. Were there bigger problems in core?
Not really, besides the GP_SET_BITS() only small things like offset for RGB colors backwards (compared to how X server needed them for drawing).
You mean in pixeltype defs?
But still there are some problems that arised and needs to be fixed:
- The GP_SET_BITS() used in GP_PutPixel_Raw doesn't work correctly
unless you explicitly cast the result from GP_PIXEL_ADDR_32BPP() to (uint32_t*) (and same for each pixel > 8BPP).
Uhh ... right. GP_SET_BITS is meant to be general and respects the parameter type size. Thanks.
Would you pretty please fix that (I would rather leave that to you).
I would leave GP_SET_BITS as is and add the explicit cast. In my TODO.
Why is GP_Context.pixels of type "uint8_t *"? Wouldn't "void *" make more sense? (they are generally not individual bytes after all). This would help catch this bug (as "typeof(void)1") and future similar ones.
- The GP_PutPixel and GP_GetPixel now uses transformation flags for default
but the rest of the library doesn't (eg. gfx part). Should we simply rename GP_TLine to GP_Line and GP_Line to GP_Line_Raw and so?
I would be in favor of that. The user should not need it and there are always the Raw variants.
Okay, will do.
Great. What about the Raw/RawNoclip distinction?
Tomas