Hi,
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.
We may change that, but then you need to cast it explicitly in some macros that expect it to be pointer bytes (in GNU C void* is actually byte addresable). And it's kind of common sense to reffer to buffer as buffer of bytes.
So my conclusion is change that if you want, but fix the surrounding code.
I will think about it. Any other solution you would suggest? (As generated GP_SET_PIXEL must be changed anyway to remove the overflow warnings) I would like to keep GP_SET_PIXEL general, but another variant would be a viable option.
- 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?
Needs to be settled down, but having each drawing algorithm in Raw and RawNoClip variant seems to me like quite duplication.
I meant RawNoclip to exist only for very low-level operations (get/putpixel, h/vline). Drawing function can then decide whether it should take care of clipping itself (easy with line), leave clipping to putpixel (any complicated shapes) or do something in-between (very optional, e.g. your smart circle example).
Just as a side-remark: most drawing functions may want to do some crude clipping to avoid too many calls to (clipped) putpixel.
Tomas