Re: [AD] Pixel graphics routines and transformations

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On March 22, 2010, Pavel Sountsov wrote:
> One of the last bits that still does not play completely well with
> transformations are the pixel drawing routines (al_draw_pixel,
> al_put_pixel and al_get_pixel). It is no problem, of course, to
> implement the appropriate functionality... but the question is what to
> do with the primitives addon, which relies on them reasonably heavily.
> The software component of the addon does all the transformations itself,
> and requires the pixel putting routines to be untransformed. It uses
> al_draw_pixel for blended primitives, and al_put_pixel for non-blended
> ones. Several solutions come to mind:
> 
> 1. The simplest solution is to make all those functions respect the
> transformations, and modify the addon to reset the transformations to
> identity before it draws anything
> 
> 2. Make a subset of those pixel drawing routines ignore transformations
> (e.g. al_put_pixel and al_get_pixel). However, this requires a solution
> for blended primitives (which need an untransformed equivalent to
> al_draw_pixel).
> 
> 3. Avoid the whole issue by making all pixel drawing routines ignore
> transformations.
> 
> In addition to the above considerations, there may be teleological
> concerns. It might not even make sense for al_put_pixel/al_get_pixel to
> be affected by transformations since those are not 'true' graphics
> operations, instead being something that is used to modify textures or
> whatnot.
> 
> Any thoughts?

I thought the last couple times this came up the decision was to transform 
draw_pixel and leave put_pixel untransformed.

> -SiegeLord
> 
> -------------------------------------------------------------------------
> ----- Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> 


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx