Re: [Vxl-maintainers] vgui and efficient rendering

[Matt L. <mat...@gm...>]

Gehua,
   I don't know how to fix the "X11 menu hack" to work with FreeGlut.=20
However, I have just added the following to the vgui CMakeList.txt
file:

      IF(EXISTS ${GLUT_INCLUDE_DIR}/GL/freeglut.h)
        SET(vgui_glut_sources ${vgui_glut_sources}
          impl/glut/menu_hack_none.cxx
        )
      ELSE(EXISTS ${GLUT_INCLUDE_DIR}/GL/freeglut.h)
        SET(vgui_glut_sources ${vgui_glut_sources}
          impl/glut/menu_hack_X11.cxx
        )
      ENDIF(EXISTS ${GLUT_INCLUDE_DIR}/GL/freeglut.h)

This gives the same result as using GLUT in Windows.  GLUT will work
but with no menu support.  This allows FreeGLUT users to compile
without errors and use the vgui_text_tableau and other GLUT dependent
features.

Does anyone actually use GLUT as a primary GUI toolkit for VGUI?  If
so we will need to fix menu support at some point.  I know at least
FreeBSD and Debian GNU/Linux have switched to FreeGLUT.  I am sure
others will follow.

-- Matt Leotta
=20

On 5/5/05, Gehua Yang <ya...@rp...> wrote:
> I would also like to bring up issues with GLUT. Currently on our FreeBSD
> machines, only FreeGLUT package is installed, which provides with the
> same functionality and almost-identical interface. However, because VGUI
> access some internal state variables of GLUT directly,  it is not
> hassle-free to replace GLUT with FreeGLUT.
>=20
> see the following link for details about FreeGLUT project:
> http://freeglut.sourceforge.net/
>=20
> I am not familiar with GL/GLUT. Maybe someone can take a quick look and
> give an evaluation.
>=20
> Thanks.
> Gehua
>=20
>=20
> Amitha Perera wrote:
>=20
> >Folks,
> >
> >I'd like to revisit the whole image rendering framework in
> >vgui. Currently, vgui will take an image and convert it to a "best"
> >format, and keep a cached image of that format. Often, however, this
> >"best" is arbitrarily chosen to be GL_RGBA or GL_RGB byte
> >pixels. However, OpenGL itself has mechanisms for rendering images
> >stored in memory as bitmap, unsigned and signed char, floats,
> >etc. With OpenGL hardware being so common, I'd like to begin to
> >update the rendering interface to let OpenGL deal with the conversion
> >issues where possible.
> >
> >This implies, at the first stage, removing the support for Mesa
> >and Hermes acceleration. I don't believe they are really used, so I
> >don't consider that a problem.
> >
> >Any comments?
> >
> >Thanks,
> >Amitha.
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: NEC IT Guy Games.
> >Get your fingers limbered up and give it your best shot. 4 great events,=
 4
> >opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> >win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20
> >_______________________________________________
> >Vxl-maintainers mailing list
> >Vxl...@li...
> >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
> >
> >
> >
> >
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, =
4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>