Hi!
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.
I wouldn't be against a little more straightforward code eg. less nested macros but that is up to you.
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.
Sounds reasonable.