[no subject]

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


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





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