| Re: [AD] Miscelaneous issues |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> 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. :)
> This is hard to fix for 4.2.0. As far as I see, DirectX doesn't always
> like to blit video pages inside a flipping chain. Which makes sense
> somehow. For 4.3.x, we should specify the flipping method already with
> create_display or whatever, and then only create a DirectX flipping
> chain if it is needed (i.e. PAGE_FLIPPING or TRIPLE_BUFERING is
> selected).
al_create_display() already contains a parameter for the update method.
This actually already works, but lives on top of the old drivers, so it
doesn't currently fix anything.
> Not sure. But generally, show_mouse() should only be used with a direct
> update method, never with double buffering (as in the above case), or a
> flipping chain.
>
> Just look what he is doing:
>
> show_mouse(canvas);
> blit(canvas, screen, 0, 0, 0, 0, canvas->w, canvas->h);
>
> 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.
> 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.
> > Volunteers?
>
> Waiting first for Peter..
Guess that means you're next in line? ;)
> The memory packfile example that came with Peter's original patch should
> go in, I think. Whoever does the documentation can do that as well..
Sounds good.
> Well, an exfont certainly wouldn't hurt.
The example I have loads two fonts from a datafile, extracts the capital
characters from the second one and the other characters from the first and
then merges the two fonts to create a font with fancy capitals (which
reminds me, the font ranges remain seperate even if they can be merged...
maybe we should fix that at some point since it makes the font internal
structure a bit cleaner). It then says `Hello World!'.
The main problem with it is that the code is ugly and doesn't properly free
temporary font objects that are no longer needed, and it might need a new
datafile added to the examples directory, although I should check if I can
get away with using one of the existing fonts.
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.
Evert