|Re: [AD] System bitmap bug (fix)|
[ Thread Index |
| More lists.liballeg.org/allegro-developers Archives
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
The way I see it, we have several options of failing a
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
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