Re: [AD] Allegro 5's new graphics core

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


In reply to Bob <ohannessian@xxxxxxxxxx>:
[snip]
>http://pages.infinit.net/voidstar/new_gfx.c

With the create_video_bitmap function you are proposing, why not create
the video bitmap directly from a normal memory BITMAP? That way, the cvb
function could return a different type (eg. AL_VID_BITMAP), which would
be more restricted than a BITMAP (ie. you can't read/write pixels, just
blit it to the screen; like RLE sprites).

Advantages:
 - BITMAP doesn't need to support video bitmaps, just memory bitmaps
 - AL_VID_BITMAP doesn't need to support getpixel(), putpixel(), etc.
 - distinction between BITMAP and AL_VID_BITMAP will create simpler code

but disadvantages:
 - getpixel() and putpixel() don't work on AL_VID_BITMAP at all
 - can't make minor changes to AL_VID_BITMAP; need to recreate
 - can't convert AL_VID_BITMAP back to BITMAP

I don't have enough experience with graphics to give a fair opinion
about which is better, though. :-(

>I also disagree with Shawn about not having a GL driver in Allegro. Although 
>I do agree that 3D is beyond the scope of Allegro, I'd still like to use 
>OpenGL's 2D abilities (and acceleration!).
[snip]

I don't think this is what Shawn was getting at. He was saying don't
reimplement OpenGL in Allegro; you are saying writing an Allegro video
driver that can map onto OpenGL calls. I think I can safely say that
both ideas are great, and would like to see them happen :-)

Bye for now,
-- 
Laurence Withers, lwithers@xxxxxxxxxx
                http://www.lwithers.demon.co.uk/

Attachment: signature.asc
Description: PGP signature



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/