Re: [AD] offscreen sub bitmaps revisited |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: "Coordination of admins/developers of the game programming library Allegro" <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] offscreen sub bitmaps revisited
- From: Matthew Leverton <meffer@xxxxxxxxxx>
- Date: Sat, 26 Jun 2010 13:04:55 -0500
On Sat, Jun 26, 2010 at 7:52 AM, Elias Pschernig
<elias.pschernig@xxxxxxxxxx> wrote:
> On Sat, 2010-06-26 at 02:00 -0500, Matthew Leverton wrote:
>> Attached is a half-implemented patch for memory bitmaps. Maybe there
>> is an easier way to implement this at a lower level...
>>
>
> Could be. Or maybe this is the right place and we just should move
> applying the transformations up to the driver-independent level.
>
Again, I know very little about how Allegro's coordinate system works,
but I expected that clipping (with subbitmap consideration) would be
done first in a central location, and then original and clipped box
coordinates for both source and dest would be sent along. Or something
different than copy/pasted code everywhere. ;)
> Also, looking at the code, shouldn't the scaled and rotated drawing
> functions just apply an additional transformation?
>
I don't know, I didn't really look. But all of that code gets called
before the regular clipping happens. It looks like they implement
their own type of clipping.
> Shouldn't be hard to fix, just tedious because of all the duplicated
> code we have in there - removing the scaled/rotated versions should make
> it easier. You can apply the patch as is I'd say, will be more
> motivation to fix things properly.
>
I want to at least get blitting into out-of-bounds sub-bitmaps working first.
>> It also doesn't work with bitmap flipping, but that's already screwed
>> up (IMO) with sub-bitmaps as is.
>
> We really need a test app showing all the problems.
>
The main problem with bitmap flipping into a memory sub-bitmap is that
it's cropped first and then flipped. This problem happens with or
without my patch. OpenGL is correct. It flips and then crops.
There is a problem with OpenGL blitting from an out-of-bounds bitmap.
(Try switching the ex_subbitmap to OpenGL and running it against my
patch.) It looks like the edge pixel is stretched out. So if there
should be, say, a 10 pixel padding on the left because the source was
(-10,0), the first row of 10 pixels will be duplicates of (0,0), and
so forth.
What we need are a bunch of automated unit tests that get triggered
every time code is committed...
--
Matthew Leverton