| Re: [AD] DO_PARALLELOGRAM_MAP again |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2010-09-15, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> On 2010-09-12, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > On 2010-09-11, Pavel Sountsov <slabode@xxxxxxxxxx> wrote:
> > >
> > > 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.
> >
> > Yes, I see. With this quick hack `ex_blend_bench 3' is nearly as
fast
> > as `ex_blend_bench 2' on my machine. Restoring the commented out
lines
> > in fix_var makes it about twice as slow.
>
> al_draw_prim should be acceptably fast now. So do we move
al_draw_prim
> (and other "Low level drawing routines") to the core, or the whole
of
> the primitives addon?
Answering myself again: once you move al_draw_prim and all the files
required to implement it, only high_primitives.c remains. So there is
not much reason to keep a separate primitives addon.
I will wait for an okay to make this change.
Peter
Well, color and memfile addons also consist of one relatively small
file each, so I don't think size alone should decide this. Many high
primitives functions seem to me to be somewhat esoteric utility
functions... you could say that they are to allegro core as libGLU is
to libGL.
I don't feel too strongly about that, however.
Incidentally, do these recent changes make that scaled bitmap test that
Elias originally complained about pass? It'd be kind of silly if it
still fails...
-SiegeLord