[Lxdream-dev] OSD work in progress

[Jon Ring]

On Fri, Jul 31, 2009 at 12:12 AM, Nathan Keynes <nkeynes at lxdream.org> wrote:

> On Jul 29, 2009 1:31pm, Jon Ring <jonnyring at gmail.com> wrote:
> > Here is a new patch with some changes.  This is what's changed (and what
> hasn't):
> >
> > 1.  Fonts are now rendered with Freetype 2.  Hopefully this works out
> better as a cross-platform high-quality option.  It automatically
> anti-aliases the text which makes it look nicer than the X/GLX version.
> Both ways generate display lists, so I could use your X code as a fallback
> if necessary.  Even if we don't do this, I may refactor the
> freetype-specific code to a separate file just to make it easier to read.
>
> Hey... that looks really awesome. I like the approach of constructing a
> font texture too, hadn't thought of doing it that way, but makes sense and
> is even portable :). I don't have any problem with a freetype dependency
> since it's practically always installed anyway.
>
> > 2.  The code still uses fontconfig at the moment, but I plan to bundle a
> font so that fontconfig doesn't get a chance to make any weird font choices
> for anyone.
>
> Ok. For now though fontconfig isn't a problem.
>
> > 3.  I added the GTK configuration dialog for video settings (nothing is
> hooked up to configuration values yet). I added an option for font size
> because on a PC a smaller font would be readable, whereas on a TV you'd want
> a bigger font.
>
> If you're going to do that, I'm thinking you might as well go all the way
> and use a GtkFontSelectionDialog, let the user pick any (truetype) font -
> probably actually about the same amount of work or less.
>


Hmm... I kind of like that.  Maybe I'll keep fontconfig around after all to
choose a default font on first load, and then a user can pick a different
one using the dialog if they don't like the default.



>
>
> > 4.  I didn't realize just how many INFO messages there were until I
> started showing them on the OSD!  These and probably the warnings as well
> are going to need to be cleaned up, many should probably be switched to
> DEBUG.
>
> I've just pushed a patch to nuke those - most of them are pretty old and
> have just hung around through inertia.
>
> > 5.  The OSD functions are now top-level and initialized in main.c,
> instead of tied to the driver.
>
> Nice. I'd probably move it out of the driver directory too since it seems
> to be generic and stick it in the (increasingly inaccurately named) pvr2
> directory where all the other generic GL code lives.
>

Will do.


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



>
> Nits:
> * log_message should ignore the global log level for errors + osd/status
> messages (ie log level only applies to actual logging output)
>

I meant to ask you about that specifically, rather than just leaving the
TODO in the code.  Thanks for bringing it up.



>
> * messages don't disappear if the emu is stopped (I tend to think they
> should)
>

I agree.  They also currently appear before the emu starts, if any were to
pop up immediately (like when you uncomment the test code in osd_init).  It
shouldn't be a hard fix.



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



>
> * It's probably also easier if you use GL_TEXTURE_RECTANGLE_ARB instead of
> GL_TEXTURE_2D. Rectangle textures have two useful features - they're
> arbitrary sized (don't have to be power of 2), and the tex coords aren't
> normalized (ie they're 0..size of texture rather than 0..1)
> * Could probably also get away with a pure alpha texture in this case since
> you're just setting the luminance to 1.0 anyway.
>

Good to know, thanks.  I originally tried using luminance to put an outline
around the text, but it didn't work very well and I went with the drop
shadow instead.



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


Thanks again for the feedback.  I should be a little sooner with the next
update ;-)


Jon





>
>
> Cheers,
> Nathan
>
>
> _______________________________________________
> Lxdream-dev mailing list
> Lxdream-dev at lists.lxdream.org
> http://lists.lxdream.org/listinfo.cgi/lxdream-dev-lxdream.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lxdream.org/pipermail/lxdream-dev-lxdream.org/attachments/20090731/2be8869f/attachment-0002.htm>