Re: [AD] System bitmap bug (fix)

[Robert Jr Ohannessian <rohannessian@xxxxxxxxxx>]

Eric Botcazou wrote:
> > But Allegro already provides a fallback path in create_system_bitmap!
>
>
> Yes, but it sets the BMP_ID_SYSTEM anyway so you must supply the 
> corresponding method in the current scheme. Every other driver provides it.

Which doesn't really make sense. The driver doesn't support system 
bitmaps but must still expose a look-alike functionality, which isn't 
fully interchangeable with memory bitmaps? This strikes me as 
unorthogonal, not to mention extra work.


> > My vote is for making create_system_bitmap() return NULL if they're not
> > supported or can't be created, instead of this
> > memory-bitmap-that-looks-like-a-system-bitmap-but-not-really. This seems
> > rather kludgy to me.
>
>
> I'm not convinced. This has worked until now and I don't see any incentive to 
> modify it.


The way I see it, we have several options of failing a 
create_system_bitmap() call:

1. Return NULL, like video bitmaps. Let the app figure it out. Not 
backward compatible though.

2. Return a Real Memory Bitmap (tm). The app can't tell the difference 
anyway (appart from blitting speed). Drivers which don't support system 
bitmaps don't need to expose any system-bitmap-related functions. This 
means that they don't need to support pass-through calls for 
fake-system-bitmaps. This also makes it consistent with the way Allegro 
handles drivers (unsupported calls just don't do anything, except for 
create_system_bitmap).

3. Return a memory bitmap with the system-bitmap flag set. Frankly, I 
really don't see any advantage of using this method.

Other valid points were raised in other posts on this thread.


--
- Robert Jr Ohannessian
http://bob.allegronetwork.com/