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/ |