| Re: [AD] DO_PARALLELOGRAM_MAP again |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2010-09-11, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> On 2010-09-10, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> > As can be seen in the failing [test scaled rotate 5][sw] unit
test,
> > parallelogram_map cannot draw things which exceed the range of an
> > al_fixed, which is 32768. I suggested a few times already to move
> > al_draw_bitmap et al. into the primitives addon and then use the
polygon
> > rasterizer in there for drawing rotated bitmaps, which has no such
> > limitations. It is slower though.
>
> If we're going to do that then I'd rather move more of the
primitives
> into the core.
BTW, there's no reason we couldn't use the faster parallelogram_map
implementation when possible, but fallback to the primitives
implementation if necessary.
Peter
One reason to avoid that is that the output of the parallelogram_map
and the primitives addon is noticeably different (the primitives
version is nearly indistinguishable from hardware, so you can just look
at ex_transform for the illustration of this) If we make it size
dependent, there probably will be a noticeable "change" once the bitmap
becomes big enough.
Anyway, it's not like the drawer from the primitives addon is fatally
slower... it is slow for two reasons: it uses function pointers instead
of macro inlining; it uses al_put_pixel calls instead of direct memory
writes. Both can be fixed in short order, but as you can imagine they
make the development of those functions harder... (which is the very
problem of parallelogram_map) so I did not do them. If that drawer
becomes used for all bitmap drawing, it won't be a problem to speed it
up via some macro work.
Lastly... I am not 100% sure that that drawer can handle giant bitmaps
either, so its something to test first too.
-SiegeLord