Re: [AD] Drawing a flipped RLE sprite? |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> > I've thought about this before, and from what I could see, it wouldn't
> > require much more than changing the direction flag.
>
> What do you mean exactly by that ? We probably need to write an entire
> new function.
Yes. What I meant was that AFICS, the difference (to the asm version)
wouldn't consist of much more than a std instruction to change the
direction flag before writing the scanlines, assuming the code looks even
vaguely how I imagine it would look (haven't checked).
Of course, the last time I did anything in assembler was over four years
ago...
> > Are there any objections to adding such a function to the 4.1 series
> > (it breaks ABI compatibility, right?
>
> IMHO a big one: this would be a slippery slope. Why not add all the
> flavours of draw_sprite() then ?
I see your point - my thoughts are as follows:
draw_lit_sprite
draw_sprite
draw_trans_sprite
These have RLE-sprite equivalents.
draw_sprite_*_flip
These do not, but that could easily be added
pivot_*_sprite
rotate_*_sprite
draw_gouraud_sprite
stretch_sprite
These don't either, and they would be very hard to code directly using RLE
sprites (maybe draw_gouraud_sprite wouldn't be too hard).
IMHO, rle-sprites are mainly intended for `static' images, such as
character sprites. You don't ordinarily need to do a lot of fancy stuff
with those: just draw them, light them or flip them. Following that
reasoning, a draw_gouraud_rle_sprite should be a good thing too...
Anyway, I'm not suggesting to lift the limitations of RLE sprites over
plain bitmaps, but to relax them a little: allow the things that can eaily
be done and leave those that cannot. There are already draw_lit_rle_sprite
and draw_trans_rle_sprite functions that have really no more right to be
there than flip_rle_sprite-functions, IMHO of course ;-)
--
Evert Glebbeek
e-mail: eglebbk@xxxxxxxxxx ICQ: 48210348
www: http://www.science.uva.nl/~eglebbk/