Re: [AD] Miscelaneous issues

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


On Wed, 2005-03-30 at 10:01 +0200, Evert Glebbeek wrote:
> > Well, with the old code, it made not much sense. Fonts were read from
> > the datafile as 256 color paletted image, and there was no other way to
> > read in a font - so fonts always stayed paletted, even when Allegro
> > later got the ability to handle truecolor modes.
> 
> Good point. In other words, no real reason not to fix this. :)

Well, now that it's possible to load from a bitmap, I actually think we
could allow truecolor fonts. I didn't think about the implications
though - some places maybe assume fonts have only 256 colors?

> > So, while the timer draws into canvas, canvas is blit to the screen. But
> > there's no synchronization whatsoever for this under windows. The
> > proposed fix probably just makes some race condition less likely to
> > occur (didn't really investigate it though..).
> 
> Good point. So basically, we can just tell people to draw the mouse
> themselves if they insist on drawing it to the backbuffer.

I guess, in 4.3.x, we can safely draw the cursor from within
al_flip_display() or similiar for non-direct-updating.

> > Yes, can do it after the beta if trivially enough. I may have a look at
> > it in any case..
> 
> The cursor is only changed in a few places. Just replacing show_mouse(...)
> with something like if (!select_os_cursor(...)) show_mouse(...); does the
> trick. I had it working with the API I originally proposed.

No, the show_mouse API should work in grabber. So basically,
enable_hardware_cursor at the beginning and done. Do you still have your
patch?

> > > Volunteers?
> >
> > Waiting first for Peter..
> 
> Guess that means you're next in line? ;)

Well.. :) Hm, maybe in future, we should keep a list of "jobs" on
allegro.cc, simple things like this which can be done by everyone in an
hour or two.

> This reminds me, should we change the examples that load fonts from a
> datafile to use load_font(...) instead of the old method? The new one may
> be preferable now if the font is all we're interested in.

I think not, datafiles still make sense. For 4.3.x, we probably should
try to unify datafile access with something like the zip reader addon
(i.e. a virtual file system) - so a .dat can be replaces by a .zip
without modifying the code.

-- 
Elias Pschernig





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