Norman Vine wrote:
FWIW I would be much more excited about this if we were switching
to a library designed for highend simulations such as OpenProducer
which by the way also has a portable threading library OpenThreads
this aims at OpenSceneGraph - doesn't it ? ;-)
Martin.
--
Unix
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Martin
Spott
Sent: Wednesday, April 14, 2004 8:11 AM
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote:
FWIW I would be much more excited
Martin Spott writes:
Norman Vine wrote:
FWIW I would be much more excited about this if we were switching
to a library designed for highend simulations such as OpenProducer
which by the way also has a portable threading library OpenThreads
this aims at OpenSceneGraph - doesn't
Norman Vine wrote:
OpenProducer was written to support OpenSceneGraph but, it
doesn't need OpenSceneGraph and more importantly it was
designed to be used in 'multi-pipe' OpenGL systems as well as
more conventional OpenGL configurations from the ground up.
STLport, OpenThreads,
On Wed, 14 Apr 2004 09:11:08 -0400, Norman wrote in message
[EMAIL PROTECTED]:
One thing I would like todo is use DirectX
..this too is Microsoft's IP, no?
rather then the normal WIN32 API for the event loop but what is there
works well enough and was a lot less work when porting from the
Bernie Bright wrote:
Just updated cvs. Your fix looks for GL/glut.h when --enable-sdl is
specified. I thought it was supposed to be either or.
Not at this time, there are too many side projects/utilities that depend
on glut (for example the tests subdirectory which gets build by default).
Bernie Bright wrote:
On Tue, 06 Apr 2004 13:52:28 -0700
Andy Ross wrote:
Sure. This should work right now. The only bits missing are the
autotools magic to do the detection and set up the makefiles
appropriately. I fear autoconf, I really do... Does someone with a
more solid handle on these
On Wed, 07 Apr 2004 17:20:47 +0200
Erik Hofman [EMAIL PROTECTED] wrote:
Bernie Bright wrote:
On Tue, 06 Apr 2004 13:52:28 -0700
Andy Ross wrote:
Sure. This should work right now. The only bits missing are the
autotools magic to do the detection and set up the makefiles
appropriately.
Andy Ross writes:
Is SDL something we want to commit to?
FWIW - I don't see what this gets us but .
since we are now agnostic as pertains to the lowlevel
OpenGL initialization routines I don't see why the choice
of OpenGL toolkit used couldn't just be an option
i.e. since all of the
Norman Vine wrote:
since we are now agnostic as pertains to the lowlevel OpenGL
initialization routines I don't see why the choice of OpenGL toolkit
used couldn't just be an option
Uh, that's the whole point. What would you prefer, if not SDL? If
you want to write a windows-only
Andy Ross writes:
Norman Vine wrote:
since we are now agnostic as pertains to the lowlevel OpenGL
initialization routines I don't see why the choice of OpenGL toolkit
used couldn't just be an option
Uh, that's the whole point. What would you prefer, if not SDL? If
you want to write
Norman Vine wrote:
Out of curiosity what can't you do today that would make FlightGear
better because we are using GLUT that you would do differently today
if we were using SDL and what exactly is it that would make FGFS better.
One big issue is that out of the box, glut is either broken, or
Norman wrote:
Out of curiosity what can't you do today that would make FlightGear
better because we are using GLUT that you would do differently today
if we were using SDL and what exactly is it that would make FGFS
better.
Off the top of my head:
+ Build out of the box on Fedora, which no
Norman Vine wrote:
Out of curiosity what can't you do today that would make FlightGear
better because we are using GLUT that you would do differently today
if we were using SDL and what exactly is it that would make FGFS better.
Under Linux, resolution switching (i.e. go fullscreen at 1024x768
Curtis L. Olson wrote:
I understand that there are (or at least were) issues between SDL
and cygwin, but perhaps it would be more productive to address that
problem directly ...
Ah. I honestly didn't know this. I just assumed that cygwin was one
of their native platforms. I just checked,
Andy Ross wrote:
Ah. I honestly didn't know this. I just assumed that cygwin was one
of their native platforms. I just checked, and it's true that cygwin
doesn't ship an SDL library as part of the distribution. I did find
the following README on the SDL website which seems to imply that the
On Tuesday 06 April 2004 20:16, Norman Vine wrote:
Out of curiosity what can't you do today that would make FlightGear
better because we are using GLUT that you would do differently today
if we were using SDL and what exactly is it that would make FGFS better.
Using SDL has many positive
Curtis L. Olson wrote:
Probably the best short term solution is to make sure we can build
with both SDL and glut and let the builder decide?
Sure. This should work right now. The only bits missing are the
autotools magic to do the detection and set up the makefiles
appropriately. I fear
Andy Ross wrote:
Sure. This should work right now. The only bits missing are the
autotools magic to do the detection and set up the makefiles
appropriately. I fear autoconf, I really do... Does someone with a
more solid handle on these things want to help out? :)
Be a man and dive in. I
Curtis L. Olson writes:
I understand that there are (or at least were) issues between SDL and
cygwin, but perhaps it would be more productive to address that problem
directly ...
I haven't heard of any one not being able to compile CVS FGFS because
of GLUT but this is not the point I am
Andy Ross writes:
Norman wrote:
Out of curiosity what can't you do today that would make FlightGear
better because we are using GLUT that you would do differently today
if we were using SDL and what exactly is it that would make FGFS
better.
Off the top of my head:
+ Build out of
Andy Ross writes:
Curtis L. Olson wrote:
I understand that there are (or at least were) issues between SDL
and cygwin, but perhaps it would be more productive to address that
problem directly ...
Ah. I honestly didn't know this.
short memory :-)
Norman Vine wrote:
FWIW I would be much more excited about this if we were switching to
a library designed for highend simulations such as OpenProducer
which by the way also has a portable threading library OpenThreads
The argument is still open. Sell us on OpenProducer. I've never
heard of
On Tue, 06 Apr 2004 13:52:28 -0700
Andy Ross [EMAIL PROTECTED] wrote:
Curtis L. Olson wrote:
Probably the best short term solution is to make sure we can build
with both SDL and glut and let the builder decide?
Sure. This should work right now. The only bits missing are the
autotools
For those interested, I just checked an SDL implementation of
fg_os.cxx (fg_os_sdl.cxx) into the source tree. It isn't quite
ready for prime time yet, but does seem to work if anyone is
interested in testing it.
It obviously isn't integrated into the build process, though. The
easiest way to
I wrote:
The one thing that is missing is support for changing the mouse
cursor image.
Melchior pointed me at a font editor (http://fontforge.sf.net) that
can read .pcf files, so I've thrown together a set of bitmaps based on
the X11 cursor font and checked them in.
This basically makes the
26 matches
Mail list logo
