RE: [AD] acquire_bitmap weirdness

> Ah, that's bad. I was assuming you could use gfx_capabilities to know if
a function needs locking or not.

You can't - that's the trouble. Otherwise, it we could just fix it by updating the docs :)

> Would that API also work for putpixel?

There are basically three ways of drawing a single pixel on screen: 1) Locking the bitmap, writing 1 to 4 bytes, then unlocking the bitmap. 2) Creating a 1x1 bitmap containing the color you want, and then BltFast() it. 3) Use a rectangle clear. All of the above are pitifully slow, but at least, #3 is the least sucky of all of those (if we can avoid locking).

If locking can't be avoided, we could have putpixel select to either copy the bytes itself (if the bitmap is already locked), or use a clear rectangle (if the bitmap is unlocked).

> Otherwise, we still need to update
> those docs and state how it works, I guess it would be my proposed a)
> then, simply state how it works under DX and does auto-unlocking, and
> also list all the affected functions.

Ok, then how do you write portable Allegro code that also performs descently on the big 2 platforms?

On Sun, 2006-01-01 at 12:06 -0800, Robert Ohannessian wrote:
> This will likely have very negative performance repercussions if all
> functions between acquire/release are hardware accelerated.

Yes, but in that case, acquire_bitmap simply is used wrong.

> Allegro apps can't know if the functions they'll call will be
> accelerated or not, and they certainly can't know it for all platforms
> that Allegro can and might support. In addition, some operations may not
> be hardware accelerated yet require the bitmap to be unlocked (DDraw's
> BltFast is one of them).

Ah, that's bad. I was assuming you could use gfx_capabilities to know if
a function needs locking or not.

> The real solution is d): deprecate acquire/release_bitmap, make them do
> nothing in Windows (what about on X11?), then implement all the Allegro
> functions using the DDraw portion of the API that does not require
> locking.

Would that API also work for putpixel? I mean, right now, if I fill the
screen with putpixel() without acquire_bitmap, it will take much much
longer.. and you say we simply are using the wrong way to place a pixel
with DX?

Also, do you mean we should completely deprecate acquire_bitmap for
4.2.1 - i.e. remove it from the docs? Otherwise, we still need to update
those docs and state how it works, I guess it would be my proposed a)
then, simply state how it works under DX and does auto-unlocking, and
also list all the affected functions.

--
Elias Pschernig

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
--
https://lists.sourceforge.net/lists/listinfo/alleg-developers