Hi!
Well, I still could imagine circumstances where non transformed functions are good to have, but you may say that I have very good imagination...
I would agree to keep them as "partially internal". Would you suggest a naming scheme?
Hmm, I personally preffer something like GP_RLine() (for Raw Line).
Now there is a good flame! Lets feed it a little:
I disagree with RLine - HLine is the name "Horizontal line", but raw/nonraw is orthogonal to that. I would hate to have [ridiculous example] "ATRHLine" for antialiased, translucent, raw and horizontal line. Compare with AA_HLine_RAW, HLine_AA_Raw or HLine_AR (as one-letter flags, but still prune to collisions)
Okay, you have a good point here. The _RAW suffix sounds good to me.
In general, it is a good question which separate variants to generate for combinations of Antialiasing, Transparency and Raw(nontransformed).
Having {normal, AA, software transparency} x {_RAW, normal} makes 6 differnt variants...
It's quite a number, but still I think that it makes sense.
Another general point is that we might want to split drawing functions off core to a different "module", keeping putpixel and perhaps writepixels.
Hmm, I think that having drawing in core makes sence. I proposed moving the text part out of it, because there is text loader/saver and there is possibility that the number of feauters would grow => it should not live in core.
Maybe something like "If it utilizes file format loader" it's not a core. Or more like, only basic drawing primitives and blits in core.
I was thinking about adding "transformed w/h" to GP_Context to speed up GP_ContextW (avoid swap_axes checking), but that is probably not useful and can be added later.
I understand that, but there are at least two more problems with that:
- having two w/h is confusing
- with two w/h context could be in inconsistent state
- you must add number of checks into the code
I understand that having two public attributes would be confusing, but if we really want to keep it "secret", then I do not see the confusion problem.
Well, that is not easy done in C. Either the whole struct is public or not. And if it's not, you can't create it statically...
How would you get inconsistency in GP_Context? Context and its attributes are once set-up on context creation and then never modified again (only clipping may be modified afterwards).
Inconsistency can either be introduced upon creation - either in core lib (we can have a debug check tests there) or manual initialization (should be forbidden); or by modification afterwards - either manually (if anybody modifies these, no CHECKs can save her from doom) or by memory corruption (then the CHECK is useless anyway and not much more informative that SEGV).
It is a pity that C does not have const struct members as C++ classes do.
Hmm, you could create const int real_w; member and change it from library code as:
int *real_w = (int*) &context->real_w;
*real_w = context->w;