Re: [AD] System bitmap bug (fix)

[ Thread Index | Date Index | More 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 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

Mail converted by MHonArc 2.6.19+