openglean-devel — Development (plans, problems, status...)

Re: [openglean-devel]Font support.

[varol k. <var...@gm...>]

Dear Richard,

Sorry for the late reply. I had to go to a place (conference) with no
email access and stuff like that.

On 9/30/05, Richard Rauch <sf...@ol...> wrote:
> Varol:
>
> I've been looking at your code a little more this morning.  It
> looks like you only read characters in the range 0..255.
>
> Have you given much thought yet to supporting large character sets?

Well, one of the reasons that the current bdf subsystem is a hack is
because supporting unicode/etc the right way is difficult. If you want
to support unicode then you have to be much more careful.

> I'm inclined towards the idea of reading font glyphs more or less
> on-demand, rather than reading the entire font at once.  The
> difficulties are in finding where as-yet-unread glyphs begin and
> in rapidly finding glyphs in memory after loading.  (Allocating
> pointers to all possible glyphs in a big array and filling unloaded
> ones with NULL is probably not a very good solution; even for 16-bit
> Unicode, on a 32-bit system, that's a quarter of a MB of pointers
> for every font...)

I completely agree with the "not reading the whole font at once". Some
fonts out there are huge! As you noticed, the current bdf subsystem
design is not adequate at all (on purpose, to make things simple).
There are other things that are not working properly, like kerning or
calculations for proper string dimensions/extents which I plan to fix
when everything else is more settled down.

> I'm thinking of some kind of hash approach.  Take a sequence of
> primes, where the Nth prime is approximately 2^N.  Take the glyph
> number mod by the prime table size  That would be the primary
> location for already-loaded glyphs.  As the table fills, reallocate
> and re-hash.

hmm ... I am not sure about the hash thing. Unless carefully done, the
hash may turn out to be bad. We'll have to look at the occupation
characteristics of unicode planes ... there may be a better (easier)
approach. Special attention should be taken to make sure that the
common cases run fast.

> For unloaded font glyphs, some kind of sparse array could be
> used to locate known places in a font.  For example, after reading
> the font glyph for 'a', you would know the location of 'b'.  (Well,
> maybe not.  I am not sure if BDF files are necessarily presented
> in the order of the glyph encoding.  But in most, if not all, cases
> you will probably be better off to start searching for 'b' right
> after 'a', I suspect.  (^&)

I don't think that this is a good idea (too complicated). I would go
with something like this: make an API to let the library know which
parts do you want supported (latin1 + latin2 + latin5, or even a UTF-8
encoded string with all the characters that you will be using) and
then when you load a font, it will load only those characters. After
all, it will be the user who knows best. I can see, though, that your
approach is more transparent.

> Additionally, perhaps loading up to 8 or 16 glyphs at a time
> might be good.  If you need the Latin 'a', the chances are pretty
> good that you'll need 'b' before too long.

Incremental loading? I am not sure it is a good idea. The BDF format
is not designed for random access. You will have to scan through most
of the BDF each time to get to what you want. The BDF specification
does not seem to require that the characters are presented in order.
Not to mention that the encoding can be different too. While it is
true that 'b' follows 'a' is true for english, it is not necessarily
true for other languages (in turkish, 'c' is followed by '=E7' which is
nowhere near 'c' in the encoding, for example).

> (But for languages like Chinese, I don't think the odds are so favorable.=
)

I'll have to check with my chinese friends :-)

Varol

Re: [openglean-devel]Font support.

[Richard R. <sf...@ol...>]

Varol:

I've been looking at your code a little more this morning.  It
looks like you only read characters in the range 0..255.

Have you given much thought yet to supporting large character sets?
I'm inclined towards the idea of reading font glyphs more or less
on-demand, rather than reading the entire font at once.  The
difficulties are in finding where as-yet-unread glyphs begin and
in rapidly finding glyphs in memory after loading.  (Allocating
pointers to all possible glyphs in a big array and filling unloaded
ones with NULL is probably not a very good solution; even for 16-bit
Unicode, on a 32-bit system, that's a quarter of a MB of pointers
for every font...)

I'm thinking of some kind of hash approach.  Take a sequence of
primes, where the Nth prime is approximately 2^N.  Take the glyph
number mod by the prime table size  That would be the primary
location for already-loaded glyphs.  As the table fills, reallocate
and re-hash.

For unloaded font glyphs, some kind of sparse array could be
used to locate known places in a font.  For example, after reading
the font glyph for 'a', you would know the location of 'b'.  (Well,
maybe not.  I am not sure if BDF files are necessarily presented
in the order of the glyph encoding.  But in most, if not all, cases
you will probably be better off to start searching for 'b' right
after 'a', I suspect.  (^&)

Additionally, perhaps loading up to 8 or 16 glyphs at a time
might be good.  If you need the Latin 'a', the chances are pretty
good that you'll need 'b' before too long.  (But for languages
like Chinese, I don't think the odds are so favorable.)


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [openglean-devel]Hurricane Rita.

[Richard R. <sf...@ol...>]

On Wed, Sep 21, 2005 at 02:16:52PM -0500, Richard Rauch wrote:
> I'm living in Houston, which is a little off-center from Hurricane
> Rita.  From the way that things look now, I expect to stay in

In the end, I stayed, and didn't see much of a storm here in
Houston.

I must say that I think that the evacuation would have been a
terrible disaster if the hurricane had hit Houston and the surrounding
(clogged-with-people) roadways with the kind of power that people
were forecasting.  So many people were trapped on the roads (as
far as I could tell), or started out then either stopped before
going far or came back.  And still others, such as myself, heard
how bad the roads were and just hunkered down in Houston hoping
for the best.


Okay, just my little soapbox.  Not really OpenGLEAN-related.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

[openglean-devel]Hurricane Rita.

[Richard R. <sf...@ol...>]

I'm living in Houston, which is a little off-center from Hurricane
Rita.  From the way that things look now, I expect to stay in
Houston through the hurrican, but there's a fair chance that
my access to the Internet will shut down.  Current projections are
for Rita to make landfall Friday or Saturday.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

[openglean-devel]gleanfonts: Unicode and client font support.

[Richard R. <sf...@ol...>]

In order to ensure that unicode either works or is "easy" to
add, I've temporarily modified the gleanfonts core to, if it
can't identify the bitmapped font pointer you've handed it,
assume that you've handed it a pointer to an object that
is arranged like the internal OpenGLEAN font data.

This has advantages and disadvantages.  I will probably keep
the core library "close" to working with Unicode, without
including Unicode support (and probably will remove the
current mechanism for client-supplied fonts).  But it will
remain relatively trivial for a client to run genfonts for
themselves and alter the gleanfonts library to support
new fonts.


Of course, if someone really wants to have a GLUT-like
bitmapped font API that includes Unicode (or support for
client-supplied) fonts, now is a good time to speak up.
(^&


Any thoughts?  Or does anyone much care about the old
bitmapped font API enough to comment?  Ultimately, as
discussed elsewhere, I think that raster fonts will work
better as textures, but don't know when that will happen.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

[openglean-devel]gleanfonts 0.7 released.

[Richard R. <sf...@ol...>]

I've moved ahead with a 0.7 gleanfonts release.  This chiefly adds Courier &
Symbol fonts from Adobe, with more uniform sizes and styles available.

Some groundwork was laid for supporting Unicode, though no Unicode fonts
are embedded in the library and I'm not sure about the idea of putting a
Unicode font in the library.  (But client-supplied data may be allowed in
time, and Unicode might then be possible.)

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [openglean-devel]Font support.

[Richard R. <sf...@ol...>]

Sorry for the length of this.  I've batted around font ideas for
a while, so this is kind of a core-dump of everything that is
currently in my head.


On Sat, Sep 17, 2005 at 02:19:37AM -0500, Richard Rauch wrote:
 [...]
> The upshot is that adding new fonts to the library should be
> difficult, but making a good API for using the fonts properly

...err, should NOT be difficult.  (^&


Varol: I can't reply directly.  Your initial email had the appearance
of an administrative request, to SourceForge (I'm not sure why).
After I approved it, it was marked with an invalid tag by SourceForge's
own spam-filter, because of the way SourceForge handled the email,
so it got rejected at olib.org.  So I can't directly see, or reply
to, it---I can only read it on the SourceForge list archive.

Nor can I see the screenshot that you attached, since the archive doesn't
include those.  Maybe you can put it up somewhere on the web and post
a URL?


To answer your specific questions:


1. I think that some more embedded fonts are a plus, so that the library
can guarantee certain fonts will be there, without the application having
to burden itself with font files, etc.  Whether the font data is physically
in the main library or is in a well-known file that is shipped with the
library is not so crucial.  But as I think that the number of fonts that
should be guaranteed makes a small set, I don't think that it hurts so
much to have them in the core library.  But I also think that the ability
to access extended fonts is essential (more than just whatever is included
with the library).  More on that below.  (^&

2. I want to avoid hard dependencies such as on freetype.  I think that an
interface to something like freetype would be nice.  And to TeX fonts, etc.

3. Yes, Unicode support and right-to-left rendering are desirable.  I do
not know these areas well, but I want to permit it.


Font support has been discussed before in other forums for extending a
GLUT like library.  Here are my thoughts:

 * A relatively small number of guaranteed fonts that are always with
   us is useful.  The past couple of days, I implemented part of an
   old API proposal, cowritten with others, which called (among other
   things) for the 14 Adobe PDF fonts to be added in certain common
   sizes.  I was unable to readily get three aspects covered:
   The fonts are all ISO-8859-1.  The "ZapfDingbats" font is not
   available.  The size 36 version of the fonts was not available in
   a way that I could extract with the current tool.

 * No pre-defined set is going to be sufficient for everyone.  There
   needs to be a way to access both "system" fonts and application-
   specific fonts.

   I do not intend to put all of the thousands of fonts from XFree86
   or X.Org into the library, much less to start harvesting other
   font libraries.  But clients should have access to whatever
   fonts the user has on their system.

 * I think that switching to a string-based font identification scheme
   is best.  The string should encode some basic things about the font
   (size/resolution if bitmapped; character set; whether bitmapped or
   stroked; ...).  The basic things may not uniquely identify the
   font, but should allow one to determine some characteristics about
   the font.  The string name would also encode a source of the font,
   and a unique id within that source (e.g., a "system" font on X11
   could have the X11 font specification string).

   One virtue of the naming scheme is that it would let you search
   for a font such as "helvetica" and see if any font in the system
   had such a name.  "The" Helvetica may not come in the size that
   you want, but there may be another Helvetica that is better
   suited to your needs.

   Perhaps more importantly, it provides a way for a user to guide
   a program to find fonts that may only exist on their computer,
   and which in any case the core library has no reason to know about.

 * I'm currently leaning towards the idea that a "font" would be
   handled as a collection of functions (or function-pointers---think
   callbacks for client fonts; (^&) that are tied together under some
   identifier.  Something vaguely like this, perhaps:

    my_font = gleanfontCreate ("whatever my font is called");
    gleanfontDrawFunc (cb_my_font_draw);
    gleanfontDrawStrFunc (cb_my_font_draw_str);
    gleanfontWidthFunc (cb_my_font_width);
    gleanfontWidthStrFunc (cb_my_font_width_str);
     /* ... */

   The core library could be smart enough to say "To draw a string,
   if there's a string-drawing function, call it directly; if there
   isn't, then call the single-character function in a loop.  So it
   would not be necessary to provide all callbacks for every font."

 * Extending this idea a little, a font repository could be another
   collection of functions that manage an interface to multiple fonts
   organized and accessed in a particular way.  This lets us define
   a library with old-style fonts, then wrap a font-repository layer
   around it that uses the same callbacks for every font in the library.
   Then another (very different) wrapper could be put around freetype.
   And another around TeX.  Etc.  The wrappers themselves would have
   a standard interface.

   These "layers" can be separate shared libraries that are explicitly
   loaded.  This way we avoid building knowledge about TrueType (for
   example) into the library, avoid forcing one to have (for example)
   freetype installed to compile/use the basic library, and still allow
   one to use (for exaple) freetype to access (for example) TrueType
   fonts.



As you can see, I've thought about it a bit.  I hope that some of
my thinking has been productive.  (^&

I would welcome: Ideas, critiques of any of the above ideas, and
actual code.  In code, I'd like to avoid hard dependencies on
external libraries such as freetype.

What I've done up to this point has been an incremental extension
of the basic fonts to a couple more typefaces and more sizes (and
more uniformly populating the available sizes).

I have not at this time put Unicode support into the library, but
I suspect that if I changed the X font identifier name that I pass
to specify the ISO-10646 character set for some of the fonts, we'd
have unicode.  I haven't done that partly because I didn't want to
embed *that*much* data into the library.

And, too, I think that proper Unicode support will mean modifying
the core API (right-to-left, top-down support).


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [openglean-devel]Font support.

[varol k. <var...@gm...>]

Nice coincidence! As part of looking into using OpenGLEAN as a basis
for a GUI I was also looking at way to use nice looking (antialiased +
kerning) fonts. I think that everybody agrees that textured fonts are
the way to go. Right now I have a way to automatically generate
textured fonts from freetype2 (on the fly, precompute and embed into C
source or save in a specialty format (subset of BDF + extensions)).

  Some questions that come to my mind are:

1. Do you want all the fonts to be embedded into OpenGLEAN (as they
were in GLUT) or do you want to be able to provide external fonts as
separate files? (I have mixed feelings about this, maybe a
well-defined set of embedded fonts + ability to load extra)

2. Do you want any dependencies like freetype or do you prefer an all
home-cooked solution with the minimal amount of external dependencies?
(I assume you don't want external dependencies, right?)

3. Do you want to support stuff like Unicode, left-to-right or
top-to-bottom scripts like chinese, arabic and japanese? (I would not,
it is just too complicated to do right. But the API or internals can
be designed to make it easy to implement later)

Varol Kaptan

P.S. I attached a test screenshot for amusement and the generated
texture. The font is Vera at 16 pixel height.

On 9/17/05, Richard Rauch <sf...@ol...> wrote:
> I've been fiddling a bit with the gleanfonts genfonts program and
> compile.sh which runs genfonts.
>=20
> One thing that I've more or less decided, for the near term, is
> to try to fill out a a fairly useful set of basic fonts at various
> uniform sizes, with bold, italic, and bold-italic versions at
> each resolution.
>=20
> There are a few things on my mind:
>=20
>  * Eventually, I want to redo the font API to work in model
>    space for all fonts.  (Bitmapped fonts will then become
>    textures.)  At that point, only a few actual font sizes
>    would be built into the library (probably about 3 sizes),
>    with mipmapping.  Since the bitmapped fonts are presently
>    blitted into the graphics area, however, I think that
>    a large set of sizes is presently called for.
>=20
>    This is just a heads-up both about the addition of new
>    sizes coming soon and that those sizes will likely
>    be replaced by textures.
>=20
>  * It turns out that using the genfonts program, some
>    fonts (e.g., TimesRoman) are available in "italic" form but not
>    "oblique", while others (Helvetica) are in an "oblique" form
>    but have no italicized version.  The difference between italics
>    and obliques is that obliques are just slanted, while italics
>    tend to be a little curly.
>=20
>    I am undecided if I should try to retain the two different
>    modes.  Opinions?  I'm inclined, for simplicity's sake,
>    to use italicized typefaces where I can, and where no italics
>    exist, use obliqued typefaces and just call them "italics".
>=20
>  * Italics and obliques, by virtue of slanting, bring a new
>    aspect into issue.  In most fonts, you have an origin
>    of the letter and a distance to advance the origin (cursor)
>    after rendering---but the character is permitted to use some
>    space to the left of the letter.  Basically, italics and slanting
>    can mess up horizontal spacing.
>=20
>=20
> The upshot is that adding new fonts to the library should be
> difficult, but making a good API for using the fonts properly
> will bring some new issues.
>=20
> For today, I am content to expand the font set, and I already
> planned to overhaul the API anyway.  But I thought that I'd
> toss this out for anyone to discuss.
>=20
> --
>   "I probably don't know what I'm talking about."  http://www.olib.org/~r=
kr/
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your ver=
y
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> openglean-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openglean-devel
>

[openglean-devel]Font support.

[Richard R. <sf...@ol...>]

I've been fiddling a bit with the gleanfonts genfonts program and
compile.sh which runs genfonts.

One thing that I've more or less decided, for the near term, is
to try to fill out a a fairly useful set of basic fonts at various
uniform sizes, with bold, italic, and bold-italic versions at
each resolution.

There are a few things on my mind:

 * Eventually, I want to redo the font API to work in model
   space for all fonts.  (Bitmapped fonts will then become
   textures.)  At that point, only a few actual font sizes
   would be built into the library (probably about 3 sizes),
   with mipmapping.  Since the bitmapped fonts are presently
   blitted into the graphics area, however, I think that
   a large set of sizes is presently called for.

   This is just a heads-up both about the addition of new
   sizes coming soon and that those sizes will likely
   be replaced by textures.

 * It turns out that using the genfonts program, some
   fonts (e.g., TimesRoman) are available in "italic" form but not
   "oblique", while others (Helvetica) are in an "oblique" form
   but have no italicized version.  The difference between italics
   and obliques is that obliques are just slanted, while italics
   tend to be a little curly.

   I am undecided if I should try to retain the two different
   modes.  Opinions?  I'm inclined, for simplicity's sake,
   to use italicized typefaces where I can, and where no italics
   exist, use obliqued typefaces and just call them "italics".

 * Italics and obliques, by virtue of slanting, bring a new
   aspect into issue.  In most fonts, you have an origin
   of the letter and a distance to advance the origin (cursor)
   after rendering---but the character is permitted to use some
   space to the left of the letter.  Basically, italics and slanting
   can mess up horizontal spacing.


The upshot is that adding new fonts to the library should be
difficult, but making a good API for using the fonts properly
will bring some new issues.

For today, I am content to expand the font set, and I already
planned to overhaul the API anyway.  But I thought that I'd
toss this out for anyone to discuss.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [openglean-devel]Re: A question about menu windows

[Richard R. <sf...@ol...>]

On Thu, Sep 15, 2005 at 12:04:03PM -0500, Richard Rauch wrote:
 [...]
> window system level.  WIN32 behaves one way, and the UNIX_X11 branch
> of OpenGLEAN varies it behavior with your window manager.

Um, just to pick at nits, this isn't quite clear:

OpenGLEAN tries (fairly well, I think) to give the same behavior
on all WIN32 and UNIX_X11 systems.  In the case of menu windows,
the current behavior seemed to be the strongest common behavior.
There may be consistency problems, though, and there may be a
better way to address this.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

[openglean-devel]Re: A question about menu windows

[Richard R. <sf...@ol...>]

> Is there a good reason not to allow input callbacks for menu windows
> and delegate everything to the parent window?

I'm not sure that I understand your question, Varol.

Possibly I'm just not fully awake this morning.  However, I'll try to
answer it:

Mouse and keyboard events should already be delegated to the parent
window.  Those events cannot be meaningfully registered directly on
the menu window because the parent must handle them.

The reason that the events get pushed from the menu window to the parent
is because in some cases it seems to be *forced* to be that way, at the
window system level.  WIN32 behaves one way, and the UNIX_X11 branch
of OpenGLEAN varies it behavior with your window manager.

I would prefer to see the individual windows handle the callbacks
just like non-menu top-level windows.  I don't know when I might
get around to trying to address this, but patches for it would
be appreciated.  (^&

(If you're at all interested: The stay-on-top window support has
code for determining the current window manager.  See near the
bottom of .../src/window.c in the main OpenGLEAN library.)

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

[openglean-devel]A question about menu windows

[varol k. <var...@gm...>]

Is there a good reason not to allow input callbacks for menu windows
and delegate everything to the parent window?

Varol Kaptan

[openglean-devel]OpenGLEAN news.

[Richard R. <sf...@ol...>]

Well, all of the sub-projects now build the libraries under:
NetBSD, CygWIN (MS-Windows XP), and MSVC (".net 2003", XP).
I'll make sure that the GNU/LINUX (Fedora Core test system)
support is running, and then call it a 0.6.


I'm leaning towards putting the demos in their own sub-project as
well, as the demos generally require the core library and often at
least one other besides what they are demonstrating.  (E.g., the
shapes demo requires the core and fonts, in addition to gleanshapes.)

The core is not to the point where I want to call it 1.0, but I will
probably not add any features to non-core componnents of the core
library.  (To be concrete: I *may* add a new font to gleanfonts,
but would not put the new font into the core OpenGLEAN library.)
There will be improvements to the core library, however, in areas
that are truly core to its function---especially in areas that will
move us closer to 1.0 (e.g., fleshing out the videomode support).

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [openglean-devel]Empty window query

[Richard R. <sf...@ol...>]

On Tue, Aug 30, 2005 at 12:44:30AM +0100, Matt Jones wrote:
> > In this case, I see a couple of workarounds.  One is to use a GLUT
> > timer to delay the time-consuming initialization.  (Or even spread
> > out the initialization in chunks over time, if there are other
> > things that you can do during that setup.)
> >
> > Will these ideas work for you?
> 
> Of course, great ideas! thanks for that.

Good news.  (^&


> It must be quite a load on your mind being the sole developer.
> I'm not in any position to help out either, but hope you don't ever feel
> pressured to bust any guts coding away.  The font stuff would be cool
> whenever it decides to make its way to the top of that list!

It's good to have criticism of one's ideas.  I don't have that as
the sole developer.  And when I stop, there's no one to keep the
forward momentum going.

Oh well.  It's moving at its own pace.  (^&


> By the way, I have openGLEAN working nicely with GLOW, kind of using it
> as a c++ wrapper plus its nice custom widget classes.  Just in case
> anybody might be interested whether they worked together...

That's good news.  I remember looking at GLOW a couple of years ago.
I can't remember why I didn't start using it, but I remember thinking
that it looked like it provided some nice GUIs.


> Best of luck with the proj.  Appreciate your efforts,

Thanks.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [openglean-devel]Empty window query

[Matt J. <mat...@fa...>]

> In this case, I see a couple of workarounds.  One is to use a GLUT
> timer to delay the time-consuming initialization.  (Or even spread
> out the initialization in chunks over time, if there are other
> things that you can do during that setup.)
>
> Will these ideas work for you?

Of course, great ideas! thanks for that.

It must be quite a load on your mind being the sole developer.
I'm not in any position to help out either, but hope you don't ever feel
pressured to bust any guts coding away.  The font stuff would be cool
whenever it decides to make its way to the top of that list!

By the way, I have openGLEAN working nicely with GLOW, kind of using it
as a c++ wrapper plus its nice custom widget classes.  Just in case
anybody might be interested whether they worked together...

Best of luck with the proj.  Appreciate your efforts,

Matt

-- 
http://www.fastmail.fm - Or how I learned to stop worrying and
                          love email again

[openglean-devel]Next Step.

[Richard R. <sf...@ol...>]

The past couple of weeks have seen a few sub-project, or satellite,
libraries being spun off.  They appear to be self-contained.  With a
few changes the core OpenGLEAN is able to play nicely with them on a
single system.

I think that as far as migrating core library APIs to satellites is
concerned, the library structure is about where it should be for now.

So I'm taking a little rest and letting the dust settle.  The next step
is probably going to be a 0.6 (or 0.6.x) release of the all of the
libraries to ensure:

 * The libraries play nicely together in their leading-edge releases.
 * Nothing was broken relative to OpenGLEAN 0.5.x
 * Documentation is coherent and less redundant between the
   projects.

So, 0.6[.x] will be an important time for checking and refining the
way that the library core has been split.


After that, 0.7 will probably see some new features.  Especially
I am interested in getting the features in place so that gamemode
has a complete alternative.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [openglean-devel]Empty window query

[Richard R. <sf...@ol...>]

On Mon, Aug 29, 2005 at 01:40:20PM +0100, Matt Jones wrote:
> Hi, I hope this is a good place to ask.
> A very minor comment that I didn't feel I could submit as a bug or a
> feature request.

Probably this is the best place for this discussion.


> When using the old GLUT library in my project, I created a window,
> reserved lots of memory and then went into the glutmainloop.  Now in
> between the time the window was created and the mainloop entered
> (initialisation finished) the window was just filled with black - which
> I guess was not updated, just initialised on creation to be black.

I can see how that can be desirable.


> However, with the openGLEAN library the difference is this window,
> although it has the frame and bar at the top, the contents is empty -
> that is, the contents of the window are the same as the background so in
> effect it looks completely transparent until the mainloop is reached,
> where the background is finally filled in.
> 
> I'm not entirely sure this is a bug or a feature, but I would much
> prefer the black initialisation because there is a long pause while
> reserving memory in my prog and it looks very ugly during this time.  As

I understand.  I'm mixed on whether to change the behavior.

Keeping the library simple never outranks important functionality.
In this case, I see a couple of workarounds.  One is to use a GLUT
timer to delay the time-consuming initialization.  (Or even spread
out the initialization in chunks over time, if there are other
things that you can do during that setup.)

The other workaround is along these lines:

    void redisplay_normal (void)
    {
        // ...
    }
    void redisplay_init (void)
    {
        blank_window ();
        do_initialization ();
        glutDisplayFunc (redisplay_normal);
        glutPostRedisplay ();
    }

    int main (int argc, char **argv)
    {
        // ...
        glutDisplayFunc (redisplay_init);

Will these ideas work for you?

I realize that these are just workarounds.


> you can tell, it's not the most important query of all time..... just
> aesthetics.

It's pretty important that the library allow for aesthetics.  (^&
I'll even go so far as to say: It is important to OpenGLEAN that
there be away around this issue.


> By the way, thanks a lot for developing openGLEAN, it has been great to
> use so far, and I'm looking forward to using the new fonts!

Of course, much is owed to those who came before:

 * Mark for the original GLUT.  Clean, simple, and pretty bug-free,
   really.
 * Pawel for the open-source implementation in freeglut.
 * The rest of the freeglut developers for fixes and enhancements.
 * Nigel for lots of work on the Doxygen documentation as well as
   misc. features and fixes, in OpenGLUT.

Without them, OpenGLEAN probably wouldn't exist.  (To say nothing of
the people who made the tools, and SourceForge for site support...)

And, I'm always looking for people willing and able to help OpenGLEAN
go in new directions.  Input, documentation, code, porting to new
build environments or window systems, testing, ...


Re. fonts: So far, there are no new fonts, but the GLUT font
selection was very restricted.  That's an area I want to address.
Right now, I'm the sole developer working on OpenGLEAN and new
fonts are a little ways back in the queue.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

[openglean-devel]Empty window query

[Matt J. <mat...@fa...>]

Hi, I hope this is a good place to ask.
A very minor comment that I didn't feel I could submit as a bug or a
feature request.

When using the old GLUT library in my project, I created a window,
reserved lots of memory and then went into the glutmainloop.  Now in
between the time the window was created and the mainloop entered
(initialisation finished) the window was just filled with black - which
I guess was not updated, just initialised on creation to be black.

However, with the openGLEAN library the difference is this window,
although it has the frame and bar at the top, the contents is empty -
that is, the contents of the window are the same as the background so in
effect it looks completely transparent until the mainloop is reached,
where the background is finally filled in.

I'm not entirely sure this is a bug or a feature, but I would much
prefer the black initialisation because there is a long pause while
reserving memory in my prog and it looks very ugly during this time.  As
you can tell, it's not the most important query of all time..... just
aesthetics.

I am using openGLEAN 0.5.0 for windows, XP.  Development environment is
visual .net 2003.

By the way, thanks a lot for developing openGLEAN, it has been great to
use so far, and I'm looking forward to using the new fonts!

Best regards,

Matt

-- 
http://www.fastmail.fm - A fast, anti-spam email service.

[openglean-devel]Joystick support in gleandev.

[Richard R. <sf...@ol...>]

On further reflection, as I create the split gleandev project, I
am inclined to remove support for callbacks.  They complicate
the library in ways that don't help most applications significantly,
and create a pseudo-event API where the low level code does not do
events.  So as the core library prepares to remove the obsolete
functions, gleandev will provide explicit-poll joystick support
for C programs.

The proper way for you to do joystick events is to use a GLUT
timer.  I can come up with covoluted examples where that is
slightly more trouble than the GLUT joystick API, but do not
see how those examples would be an impediment to applications in
practice.  So the traditional GLUT joystick API will be unmourned.

Of course, as with the rest of the OpenGLEAN API that is currently
available but marked "deprecated", the GLUT joystick API will remain
available through OpenGLEAN 1.0.  But this is one area where I am
now disinclined to support a verbatim API clone via satellites, at
this time.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

[openglean-devel]New joystick support in the GLUT family (OpenGLEAN 0.5)

[Richard R. <sf...@ol...>]

Well, I released OpenGLEAN 0.5 around 6am on the 19th.  Around
5 or 6 hours later, the freeglut project owner made it clear that
he would not, after all, want those same features in freeglut.  I'm
puzzled why he took so long to speak about it.

In any case, this is both bad and good.

It's bad that he didn't speak up earlier.  In a desire to keep
abreast of other GLUT family features, I added the new joystick
API support to OpenGLEAN because it had been discussed on the
freeglut lists and the developers seemed to be set on retaining
the features.  I did not think that the freeglut project owner
would care for the features, but as he remained silent for...1
month? 2?...I began to accept that this would be another case of
ill-conceived features being added to freeglut.  Unlike the
glutMouseWheelFunc() callback registration, however, this at least
seemed to extend the API functionality.  I just would rather have
seen some people think about the API rather than exposing something
that one freeglut developer had sloppily defined and another had
opportunistically implemented.

However, this is good for OpenGLEAN.  While the OpenGLEAN project
is happy to see freeglut flourish, and the API in question seems
hasty, it is nice to have one more advantage over freeglut.
freeglut's goal as a GLUT drop-in is inherently limiting.  The
OpenGLEAN project is founded on the idea that the essence or core
of the GLUT API is worthy of advancement, and that freeglut is
ultimately and willfully slating itself for obsolescence.  So,
changes that relegate freeglut to the closet and OpenGLEAN to active
use are better than those that make no distinction between the
libraries or, worse, promote freeglut in some people's eyes.

Ultimately, I believe that the added functionality to OpenGLEAN
will be an inducement to use OpenGLEAN.


In other news:

 * As splitting the satellites from the core continues, I found it
   desirable to create another gleanshapes "release" (though I see
   no immediate need to post a file release).  As it is expected
   to remain relatively stable until OpenGLEAN 1.0, at which point
   I'd like to create 1.0 releases of all sub-projects, I thought
   to call it 0.2, release candidate 1.  Due to a little bit of
   sloppiness, it became 0.2.1, instead.  (There never was, nor
   now will be, a 0.2 gleanshapes.)

 * OpenGLEAN 0.5 has some font prototypes that should have
     #ifndef GLEANFONTS_H
   around them.  This will be fixed in the next release of OpenGLEAN,
   but will cause some pain if you try to build the gleanfonts
   demos from CVS.  I expect that the first real gleanfonts release
   will come at about the same time as the next OpenGLEAN update,
   though, so no worries if you're waiting on a file release.

 * The joystick support (possibly with other devices glommed into
   the same release) is next on the list, as gleanfonts appears to
   be shaping up nicely.  When that is completed, the biggest thing
   to do before OpenGLEAN 1.0 will probably be splitting out the
   gamemode support into component features.

OpenGLEAN 1.0 is getting closer.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

[openglean-devel]OpenGLEAN 0.5 released.

[Richard R. <sf...@ol...>]

OpenGLEAN 0.5 has been released.  The WIN32 and RPM distribution files
are not yet up, but the primary sources, pre-processed documentation,
and the tiny pkgsrc module are all up, along with fingerprints.

The primary source tarball is available for download (tested and
verified; there's always a delay before SourceForge mirrors get
these things).  The others should be available, as well.


Some general notes about 0.5:

 * This marks the point where satellite libraries are now
   being added.  Some things are being changed to accomodate
   building the satellites on a system already carrying the
   regular OpenGLEAN---without quite removing anything from
   OpenGLEAN's implementation just yet.  (Until OpenGLEAN 1.0,
   the library functionality should be unimpaired.)

   In particular, the OpenGLEAN header is modified to allow
   features to be exclusively prototyped in the satellites;
   but if not in the satellites, OpenGLEAN will provide
   prototypes for its own features.  (Useful if you have
   some rather picky compiler warnings turned on.  This
   is temporary and will not be needed once the obsolete
   APIs are removed from OpenGLEAN.)

   Additionally, OpenGLEAN no longer generates man-pages for the
   functions that duplicate functions in gleanshapes.

 * New joystick API.  This has been silently exported by
   freeglut for a long time on most UNIX_X11 systems.  It
   appears that freeglut intends to include it fully in the
   next release, and I had always intended to split off and
   expose this (or a comparable) API in OpenGLEAN.  So...the
   freeglut API is exposed and documented in OpenGLEAN.

   I am not too pleased with the new joystick API as it stands,
   but I ca evolve it in OpenGLEAN, or after it is split into
   its own library.

 * Documentation should be substantially upgraded.

 * OpenGLEAN is now officially in Beta release.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

[openglean-devel]OpenGLEAN 0.5 release cycle started.

[Richard R. <sf...@ol...>]

To ease some issues between OpenGLEAN 0.4.3 and gleanshapes 0.1, I
am getting out a 0.5 OpenGLEAN release.  The headers and man-pages
should no longer conflict with gleanshapes, letting you install both
cleanly.  (Part of this phase means that the man-pages for certain
OpenGLEAN API features are no longer to be generated.  The man-pages
can be had from gleanshapes, which will be where those functions and
their documentation will be maintained, henceforth.  When OpenGLEAN
gets to 1.0, those features will be excised from OpenGLEAN, and the
satellite library will be their only source within the OpenGLEAN
project.)

In addition to providing some resolution to conflicts with gleanshapes,
OpenGLEAN 0.5 will feature improved documentation and new features.

Just a heads-up.  No downloadables yet.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

[openglean-devel]gleanshapes CVS repository launched.

[Richard R. <sf...@ol...>]

I have created the "shapes" repository under the OpenGLEAN project,
on the SourceForge CVS server.  This holds the first portion of
OpenGLEAN to be isolated from the core API.  There are numerous
logical fault-lines in the GLUT API along which the library can
be very cleanly separated.  This is one of them.

Further, the shapes API has been backwards-compatible for a very long
time, aside from some freeglut bugs about the winding of surfaces.
If it does not evolve much or at all, and if any application only uses
the shapes code, the application should not need to upgrade when bugs
are found and fixed in the core library.  However, I look forward to
making some simplifications to the API around the time that I have
OpenGLEAN break backwards compatibility in a major way.


I will probably  make some kind of gleanshapes release soon.  After
testing a bit, I will likely make a new release of OpenGLEAN's core
(and perhaps another release of gleanshapes), with some coordination
so that OpenGLEAN and gleanshapes can coexist a bit more nicely.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

[openglean-devel]redbook demos updated (0.9.2)

[Richard R. <sf...@ol...>]

As noted elsewhere, the redbook demos, as modified to use OpenGLEAN,
were updated.  The raw C code is unmodified (one wants to minimize
the changes to that!), but some cruft was cleaned up and a newer
version of Doxygen was used to generate the output.

Also, LaTeX and PDF output is included.

For a high qualit printed reference, you can print the
.../doc/latex/refman.pdf file.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [openglean-devel]New release coming.

[Richard R. <sf...@ol...>]

On Sun, Jul 31, 2005 at 07:33:10PM -0500, Richard Rauch wrote:
 [...]
> Just a heads-up that I expect a new release in a day or so.

Oh, by the way: Said release was cut. 


 [...]
> again, this is simply maintaining the 0.4 release so it is expected
> to be 0.4.2.

A 0.4.2 was tagged.

However, owing to problems, 0.4.2 had to be skipped.  0.4.3 was
then cut and properly released.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/