RE: [AD] No more video/system bitmaps

["Robert Ohannessian" <ROhannessian@xxxxxxxxxx>]

> Not sure. If Bob or some other OpenGL expert isn't going to implement
> this whole idea, then it probably won't be done anyway. At least for
me,
> the proposal so far has not enough details so I could implement it.

I'd need to experiment with AllegroGL and a hacked version of Allegro.

Now if only I had the free time to do it...



> -----Original Message-----
> From: alleg-developers-admin@xxxxxxxxxx [mailto:alleg-
> developers-admin@xxxxxxxxxx] On Behalf Of Elias Pschernig
> Sent: Thursday, June 16, 2005 11:33 AM
> To: alleg-developers@xxxxxxxxxx
> Subject: RE: [AD] No more video/system bitmaps
> 
> On Thu, 2005-06-16 at 10:48 -0700, Dustin Dettmer wrote:
> >
> > I say let AUTO be the default.  Make the function
> > AL_BITMAP *create_al_bitmap(int width, int height,
> > AL_DISPLAY *env);  If a user wants more control on
> > where the bitmap goes, there could be another
> > function, create_hinted_al_bitmap(int width, int
> > height, int hint, AL_DISPLAY *env);
> >
> > I could see noobs and experianced programmers alike
> > having to sit and think "Now what kind of bitmap is
> > this going to be?"  I say make it easy for those who
> > don't care, yet leave the optimized option open.
> 
> Yes, that's just what I meant. You should be able to give hints, but
not
> required to.
> 
> > A question I had about this whole thing, is what does
> > the flip function do?  I couldn't tell from this
> > description, and I think new users will have the same
> > problem.  If its a function to replace the current
> > request_video_bitmap / show_video_bitmap functions,
> > then maybe it should be named someting less vague like
> > set_al_display(AL_DISPLAY *env, AL_BITMAP *bmp).
> 
> I find "flip" describes it very good. I guess it would be:
> 
> al_flip_display
> 
> >From what I remember, other suggested names were "show" and
"present".
> "set" is a bit too vague I think. And OpenGL also uses "flip". Not
sure
> what SDL uses.
> 
> >
> > On another note, I'm not sure how much I like this
> > idea.  It would involve (or at least its begining to
> > sound so) putting in counters / checks in every
> > function that affects and / or reads bitmaps,
> > potentialy taking a long time to swap where the
> > bitmaps live in memory.  What if I as a user need to
> > do a quick getpixel or something, and all of a sudden
> > my game freezes for a second or two.
> 
> That should never happen. Normally, a bitmap will have its type
decided
> initially very fast, and then won't change. And the time traversing
the
> bitmaps and checking the counters probably also is insignificant. If
it
> is not, then we cannot do this, of course.
> 
> > Putting hooks into functions has two issues that I
> > see.
> >
> > 1) Performance hits.  I think allegro should be very
> > carefull here.  Reputations are gained extremely
> > easily, and hard to shake.  If there are more games
> > out there that pause randomly with an Allegro logo on
> > it, then SDL will completely take over.  Also the
> > developers of those games wont like such uncontrolable
> > delays.
> 
> Well, there definitely would be no arbitrary pausing. And as I see it,
> the time spent by al_flip to check the bitmap counters would be much
> less than whatever else it needs to do (at the worst, sending a whole
> screenfull of pixels to the video card..).
> 
> >
> > 2) Messiness.  Its just plain messy to be putting a
> > hook into tons of differen't functions.  And what
> > happens when one of the drawing functions calls
> > another one?  Its fixable but its still just a really
> > messy idea.
> 
> Heh, did you ever see the current Allegro code? Or SDL code? And I
don't
> want to what the DirectX source looks like, or how OpenGL drivers are
> implemented. But then, I agree, having clean, well documented code
> should be one of the top priorities for 4.3.x. It's just always easier
> to hack something in, with not enough cleaning and not enough testing,
> than doing it properly :|
> 
> >
> > Having a seperate function to handle moving bitmaps
> > around in memory could work, but I still think the
> > approach is a little tacky / unintuitive.
> >
> > Isn't there a better approach to smart bitmaps?
> >
> 
> Not sure. If Bob or some other OpenGL expert isn't going to implement
> this whole idea, then it probably won't be done anyway. At least for
me,
> the proposal so far has not enough details so I could implement it.
> 
> --
> Elias Pschernig
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers