I've made some modifications to allegro 4.1.17 sources and I'm posting them here. I've not yet tried it in 4.1.18, but I will do that soon, probably it will work OK.

Just get the Attached file!

If someone wants a example code, I will provide it.

Can you at least explain what you changed and why?

From the ChangeLog, inside the attached file:
*****************************************************

I've made modifications in allegro to eliminate the power-of-two-sized
restriction to patterned drawing modes. I've also created new drawing modes:

DRAW_MODE_SPRITE_PATTERN - It's the fusion of DRAW_MODE_COPY_PATTERN and
DRAW_MODE_MASKED_PATTERN modes, if the pixel of the pattern is the mask, it
will be skiped, like DRAW_MODE_MASKED_PATTERN, but if it isn't, the pixel
from the pattern will be ploted, like DRAW_MODE_COPY_PATTERN.

DRAW_MODE_AND - It's like the DRAW_MODE_XOR drawing mode, but instead of
XOR'ing the pixel, this will AND the pixel.

DRAW_MODE_OR - It's like the DRAW_MODE_XOR drawing mode too, but instead of
XOR'ing the pixel, this will OR the pixel.

Changed files:

\include\draw.h -> Slightly modified (three lines) to define the new drawing
modes.

\src\c\cdefs8.h -> Modified the PATTERN_LINE() and GET_PATTERN_PIXEL()
macros to eliminate the power-of-two-sized restriction.

\src\c\cdefs15.h -> Modified the PATTERN_LINE() and GET_PATTERN_PIXEL()
macros to eliminate the power-of-two-sized restriction.

\src\c\cdefs16.h -> Modified the PATTERN_LINE() and GET_PATTERN_PIXEL()
macros to eliminate the power-of-two-sized restriction.

\src\c\cdefs24.h -> Modified the PATTERN_LINE() and GET_PATTERN_PIXEL()
macros to eliminate the power-of-two-sized restriction.

\src\c\cdefs32.h -> Modified the PATTERN_LINE() and GET_PATTERN_PIXEL()
macros to eliminate the power-of-two-sized restriction.

\src\c\cgfx.h -> Modified the behavior of the FUNC_LINEAR_PUTPIXEL() and
FUNC_LINEAR_HLINE() functions (or maybe macros :-) to understand the new
drawing modes and eliminate the power-of-two-sized restriction.

\src\i386\igfx8.s -> Modified the behavior of _linear_putpixel8() and
_linear_hline8() functions to understand the new drawing modes and
eliminate the power-of-two-sized restriction.

\src\i386\igfx15.s -> Modified the behavior of _linear_putpixel15() and
_linear_hline15() functions to understand the new drawing modes and
eliminate the power-of-two-sized restriction.

\src\i386\igfx16.s -> Modified the behavior of _linear_putpixel16() and
_linear_hline16() functions to understand the new drawing modes and
eliminate the power-of-two-sized restriction.

\src\i386\igfx24.s -> Modified the behavior of _linear_putpixel24() and
_linear_hline24() functions to understand the new drawing modes and
eliminate the power-of-two-sized restriction.

\src\i386\igfx32.s -> Modified the behavior of _linear_putpixel32() and
_linear_hline32() functions to understand the new drawing modes and
eliminate the power-of-two-sized restriction.

\src\misc\modexgfx.s -> Modified the behavior of _x_putpixel() and
_x_hline() functions to understand the new drawing modes and eliminate
the power-of-two-sized restriction.

\src\gfx.c -> Modified the behavior of the drawing_mode() function to
eliminate the power-of-two-sized restriction.

\src\i386\asmdefs.inc -> Modified the LOOKUP_PATTERN_POS() macro to
eliminate the power-of-two-sized restriction. I've needed to create the
DO_PATTERN_MOD() and INC_PATTERN_MOD() macros too for this work.

\src\misc\asmdef.c -> Slightly modified (three lines) to understand the new
drawing modes.

\src\spline.c -> Slightly modified (two lines) the _soft_spline() function
to understand the new DRAW_MODE_OR and DRAW_MODE_AND modes.

\src\scene3d.c -> Slightly modified (one line) the init_poly() function to
understand the DRAW_MODE_SPRITE_PATTERN mode.

I could change the \tests\test.c, but i think that it's still too soon for
that.

Compatibility issues:

The behavior of the drawing_mode() function has changed, it doesn't anymore
round the size of the pattern to a power of two. Maybe this function should
be called drawing_mode_ex() and the old one should be deprecated? Or not?

Performance issues:

Since the code can't just do a simple AND anymore to get the position in a
patterned drawing mode, the code to keep the position inside the pattern is
a bit more complex, but notably slower for putpixels. For hlines it's just a
bit slower. Otimizations would be welcome. (Sorry i'm just a begginer in
assembler :-)

The macro DO_PATTERN_MOD() is used twice by the macro LOOKUP_PATTERN_POS(),
(both in \src\i386\asmdefs.inc), and it is a good target to otimizations.
The macro LOOKUP_PATTERN_POS() is used for each putpixel and hline-like
functions implemented in assembler. So for each one, DO_PATTERN_MOD() is
used twice too. The hline-like functions uses the macro INC_PATTERN_MOD()
for each pixel in patterned modes, so it would be a nice place to otimize,
but i really think that it isn't anymore otimizable.

The macros PATTERN_LINE() and GET_PATTERN_PIXEL() in the \src\c\cdefs*.h
files should be otimized too, if possible.

By Victor Williams Stafusa da Silva - vwss1984 at yahoo dot com dot br

Please send future code changes about allegro to alleg-developers@lists.sourceforge.net, and you should probably also sign up for the mailing list by clicking here and filling out the relevant information.

I will notify the list of this thread.

Please, in the future, create a patch in unified diff format. Google should tell you why, and how it works. If not, just ask here. (Even AJ found out how it works by now )

About the changes - removing the power-of-2 certainly sounds useful - but decreasing performance for it.. not sure what to do. Does OpenGL still have restrictions on texture sizes? If they do not have them anymore, Allegro probably shouldn't need them as well - but the power-of-2 restrictions also are in Bob's gfx api design, so dunno.

The DRAW_MODE_SPRITE_PATTERN, OR and AND modes sound all like they should be there (I actually always believed the DRAW_MODE_MASKED_PATTERN was your DRAW_MODE_SPRITE_PATTERN). I guess they simply are missing because nobody ever needed them.

And then, 4.2.0 sort of is in feature freeze, so Evert must decide what/if can be applied now, or later in the new gfx API

The power-of-two size restriction is probably there for the very reason that it is faster. I'm a bit hesitant to change the original part of the design here. Not that it should give too much of a performance penalty, we can always special-case the situation where we do have power-of-two sizes.
This introduces quite a bit of changes in many different source files and needs a relatively great deal of testing, in particular as it might break things that assume that patterns are a power of two but are not immediately obvious.
I think that's appropriate between WIP releases, but not if the next release is supposed to be a release candidate for a stable version - so I'd want to push the elimination of size restrictions for patterns (with power-of-two sizes as a special case) over to the 4.3 branch.

The drawing modes DRAW_MODE_SPRITE_PATTERN, DRAW_MODE_AND and DRAW_MODE_OR sound like they should indeed have been there already, so I'd be fine adding these for 4.2.

Victor: could you split your modifications in two parts, one for adding these three drawing modes (and documentation, if possible) and one for removing the power-of-two size restriction (if possible with power-of-two as a special case) and create a diff for them? This will make it significantly easier for us to apply it.
It's ok if your second patch prerequires the first one.

Oh, and before I forget, thanks