[Lxdream-dev] OSD work in progress

[Nathan Keynes]

> > 6.  I still need to look at the flickering/double buffering.  I also need
>> to make sure my opengl code doesn't cause any bad side-effects in the rest
>> of the opengl drawing functions.
>>
>> Seems to be behaving itself so far. The other rendering functions are
>> pretty paranoid anyway and reset all the state at the start. I might reorg
>> the code to do proper double-buffering and see if there's any actual
>> performance hit (I expect probably not actually).
>>
>
> I'll let you look at the double buffering then, and it seems like I don't
> see any other ill effects.  The only time I noticed something go horribly
> wrong was when I didn't call glLoadIdentity() after I was done drawing the
> text and the whole screen exploded.
>

I've committed some light refactoring (r1076) - there's now a central
function pvr2_draw_frame() in pvr2.c which should do everything involved in
drawing the display, along with a not-yet-configurable flag force_vsync to
switch to double-buffering. I'm thinking this would become something along
the lines of
if( force_vsync || osd_has_text() ) {
    ...
    osd_render();
    ...
}

This is also the hook you'd call from the GUI for redraw when the emu isn't
running.


> Suggestions:
>> * in the OSD setup, it might be a little simpler/more efficient to use a
>> single texture with the full alphabet on it, rather than separate textures
>> per character.
>>
>
> I considered this because it would be a more efficient use of texture
> memory, but I'm not sure about simpler.  I think I'd have to loop through
> all the glyphs once to figure out how big to make the texture, and then loop
> again to do the rendering on the texture.  I believe Freetype only keeps one
> glyph in its slot at a time, which complicates things slightly with 2 loops
> as well.  I'll have to look at some of the other Freetype
> functions/parameters, but I should be able to do this.
>

Hrm. If there's a max_glyph width,
malloc(max_glyph_width*max_glyph_height*MAX_CHAR), build the texture data +
display lists at the same time, and load the tex data right at the end.
Although thinking about it, you're probably right that it's not any simpler,
but it would probably be good to conserve texture slots all the same if it's
not going to be much more complicated.


>
>
>> * It would be really nice if you could stack messages, so that when you
>> get multiple messages at the bottom they're pushed up the screen, and then
>> wink off in order as well (data structure might need some rethinking
>> though).
>>
>
> I was thinking about doing this at some point as well.  I have some of the
> font height stuff already stubbed out for this.
> Now that the OSD is settling in, we may not need the generic 3x3 grid, just
> the specific positions we are using.  This would let me specialize each
> screen location to its purpose.
>

Makes sense to me. Looking good :)

Cheers,
Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lxdream.org/pipermail/lxdream-dev-lxdream.org/attachments/20090803/033bdb5e/attachment-0001.htm>