Why not a parameter to the line-drawing function? There’s the way SDL_ttf
handles text drawing, so we might have something like “AALineDraw()” or
"LineDraw()" if we go in that direction.
Personally I like the parameter kind instead of two different functions…
2009/12/23 Bill Kendrick > On Wed, Dec 23, 2009 at 04:16:38PM +0100, Vittorio G. wrote:
whether it is on or off, i guess the real solution would be to put the
enable/disable AA option in a very evident position, such as a
parameter
of SDL_Init (or one of its flag).
Why not at the time of drawing? Or have AA vs non-AA line-drawing
functions to call? Or is that cluttering the API up too much? :^/
Why not a parameter to the line-drawing function? There’s the way SDL_ttf
handles text drawing, so we might have something like “AALineDraw()” or
"LineDraw()" if we go in that direction.
Personally I like the parameter kind instead of two different functions…
Depends on the implementation. If it is like this:
void LineDraw(bool const antialias) {
if (antialias) // one algorithm
else // another algorithm
}
Then why not just split it up in 2 functions? That would be more natural.
Yes, you are right in this case, simple function parameters are not worth
it.
But, what if the line drawing function has another flags?
Some time ago people were talking about if the last pixel of the line should
or not be drawed, to prevent re-drawing it in case of chained line drawing.
This is just an example, but this behavior can be controled by flags, just
the same way you can turn on or off RLE acceleration on surfaces (in 1.2),
so it would look more like
void LineDraw(…, int flags) {
if (flags & AA) { /* aa way * }
else { /* no-aa way */ }
}
LineDraw(…, AA | LASTPIXEL | BLUR | /* whole lot of line-drawing
properties … */);
2009/12/23 Erik > Leonardo Guilherme skrev:
Why not a parameter to the line-drawing function? There’s the way SDL_ttf
handles text drawing, so we might have something like “AALineDraw()” or
"LineDraw()" if we go in that direction.
Personally I like the parameter kind instead of two different
functions…
Depends on the implementation. If it is like this:
void LineDraw(bool const antialias) {
if (antialias) // one algorithm
else // another algorithm
}
Then why not just split it up in 2 functions? That would be more natural.
More natural for the implementor, but I think not for the API user. When I was
herding cats in industry I would tell them “I don’t care how difficult it is
for you to do it, I care how easy it is for the customer to use it”. Even
with the FOSS I write today I try to stick by that philosophy. I suspect Sam
would agree with the philosophy if not its relevance to this issue.
JeffOn Wednesday 23 December 2009 11:56, Erik wrote:
Depends on the implementation. If it is like this:
void LineDraw(bool const antialias) {
if (antialias) // one algorithm
else // another algorithm
}
Then why not just split it up in 2 functions? That would be more natural.
I think in the spirit of SDL, it should not put AA on you by default.
The least surprising choice is to leave AA off to start.
What is this talk about a default? Make it a boolean argument to the
line drawing function or two different functions. Global state is
rarely a good idea.–
Rainer Deyke - rainerd at eldwood.com
When dealing with graphics rendering and similar, where operations tend to
need a lot of input data in various forms, designing “around” global state
quickly results in lots of slightly different function calls and/or function
calls that take countless arguments or structs of data.
Although there are ups and downs no matter how you do it, I strongly prefer
the OpenGL style of API design. It allows people without superhuman API
learning capabilities to read and write code without constantly reading the
API documentation in parallel.
Also, if you don’t want the state to be strictly global, you can always use
the “OOP style” of passing a state struct/handle as the first argument to all
calls where it applies. Or, you use some sort of MakeCurrent() call.
Of course, it’s a slightly different deal in languages with named arguments
and proper support for variadic functions. Can’t say if that automatically
makes eliminating global state (or “state objects”) a good idea, though…On Thursday 24 December 2009, at 00.50.11, Rainer Deyke wrote:
Jonathan Dearborn wrote:
I think in the spirit of SDL, it should not put AA on you by default.
The least surprising choice is to leave AA off to start.
What is this talk about a default? Make it a boolean argument to the
line drawing function or two different functions. Global state is
rarely a good idea.
–
//David Olofson - Developer, Artist, Open Source Advocate
Nooooooooooooooooooo… don’t mention programming languages!On Thu, 24 Dec 2009 01:03:27 +0100 David wrote:
Of course, it’s a slightly different deal in languages with named
arguments and proper support for variadic functions. Can’t say if
that automatically makes eliminating global state (or “state
objects”) a good idea, though…
DOH! Sorry… :-DOn Thursday 24 December 2009, at 01.06.56, Tim Angus wrote:
On Thu, 24 Dec 2009 01:03:27 +0100 David wrote:
Of course, it’s a slightly different deal in languages with named
arguments and proper support for variadic functions. Can’t say if
that automatically makes eliminating global state (or “state
objects”) a good idea, though…
Same method used in SDL_gfx for example. The lowest common denominator
of non-AA lines may be required in some applications. And if a global
state is the design, it would be trivial to write a wrapper that picks
the correct function.
Bill Kendrick wrote:> On Wed, Dec 23, 2009 at 04:16:38PM +0100, Vittorio G. wrote:
whether it is on or off, i guess the real solution would be to put the
enable/disable AA option in a very evident position, such as a parameter
of SDL_Init (or one of its flag).
Why not at the time of drawing? Or have AA vs non-AA line-drawing
functions to call? Or is that cluttering the API up too much? :^/
I think two functions is the best option. An above poster made mention of preferring ease of use over ease of development (something I myself agree with), but I don’t see how two functions would make it any harder for the user than a boolean or flags argument. Instead of calling DrawMyLineNowPlz(fx, fy, tox, toy, true) calling DrawMyAALineNowPlz(fx, fy, tox, toy) seems no more difficult. The extra burden here (although quite minimal) falls on whoever documents the functions, but this is as simple as adding a the text “anti-aliasing” in the description.
When creating the library becomes simpler for the developer without any (major) difficulty added for its users and whoever is working on documentation, that’s probably the right road to take.
…at the same time, it’s really no more difficult to make another function than to combine functionality of both into one. It tends to look a little queer, though.
My vote for two functions + maybe one inline function/macro with the AA as one
parameter.
Reasons:
AA and none AA versions will be different functions so don’t add that
unnecessary function for all.
If some application uses both versions it is more obvious, which version is
used and where if the function names are different.
This macro/inline function can be optimized away by the compiler if the AA
parameter is constant.
SamiOn Friday 25 December 2009 10:13:09 Andreas Schiffler wrote:
+1 for the idea of two functions.
Same method used in SDL_gfx for example. The lowest common denominator
of non-AA lines may be required in some applications. And if a global
state is the design, it would be trivial to write a wrapper that picks
the correct function.
