On 18.Jan.2002 23:46 Arnt Karlsen wrote:
On Fri, 18 Jan 2002 10:50:44 +0100
Erik Hofman <[EMAIL PROTECTED]> wrote:
> Just my 2 Euro ct. (Sorry Arnt ;) )
.as a coding member in an itzy bitzy wee part of our great
continent, the cradle of mankind, spanning from Cape Town well
past Vladivostok, y
> >3. it uses a single audio buffer, instead of the commonly accepted
> >dubbel buffering principle.
The PLIB itself is single buffered, but that's ok because the sound
driver itself on Linux and Windows (dunno about irix) is multi-buffered.
___
Flight
Erik Hofman writes:
>
>Well, since plib is claiming Irix compatibility but obviously, but
>doesn't apply my patch I drew my own conclusions.
>I concider including my patch just as a way to have more time
>to work on
>SDL because the audio part of plib breakes about every rule of
>computer controll
Norman Vine wrote:
> Erik Hofman writes;
>
>>I've twice committed a patch wich gets audio (sort of) working
>>for Irix
>>(audio realy is crap in plib anyway) but it didn't get
>>included, without
>>a reason, without any notice.
>>
>
> Erik
>
> Apologies for not checking up on your patch
>
Erik Hofman writes;
>
>I've twice committed a patch wich gets audio (sort of) working
>for Irix
>(audio realy is crap in plib anyway) but it didn't get
>included, without
>a reason, without any notice.
Erik
Apologies for not checking up on your patch
I just assumed that it got included by o
> I've twice committed a patch wich gets audio (sort of) working for Irix
> (audio realy is crap in plib anyway) but it didn't get included, without
> a reason, without any notice.
It took me some consistent hassling, too.
> So plib devlopers can do their own business, but I'm moving on.
Don'
Christian Mayer wrote:
> Erik Hofman wrote:
>
>>Curtis L. Olson wrote:
>>
>>
>>>FlightGear and plib have had a very good cooperative relationship and
>>>both projects have greatly benefited because of that.
>>>
>>If bug-fixes don't get applied we have to move on.
>>
>
> Did I miss something? I
David Megginson <[EMAIL PROTECTED]> said:
> Norman Vine writes:
>
> > Again I don't see any compelling reason to move to SDL
>
> As an outsider, I'll mention that one advantage is the fact that so
> many other high-end games seem to be using SDL now. I like PLib, but
> it hasn't seemed to cat
Erik Hofman wrote:
>
> Curtis L. Olson wrote:
>
> > FlightGear and plib have had a very good cooperative relationship and
> > both projects have greatly benefited because of that.
>
> If bug-fixes don't get applied we have to move on.
Did I miss something? I can't remember any bugfixes for PLI
Curtis L. Olson wrote:
> FlightGear and plib have had a very good cooperative relationship and
> both projects have greatly benefited because of that.
If bug-fixes don't get applied we have to move on.
Erik
___
Flightgear-devel mailing list
[EMAIL
Christian Mayer wrote:
> Erik Hofman wrote:
>
>>I don't say why should move to SDL, but I like it and *if* we move away
>>from GLUT (which in my opinion would be a good idea) then SDL would be
>>my favorite alternative.
> Well, there are thoughts to make PLIB 2.0 GLUT independant as it whould
Erik Hofman wrote:
>
> I don't say why should move to SDL, but I like it and *if* we move away
> from GLUT (which in my opinion would be a good idea) then SDL would be
> my favorite alternative.
Well, there are thoughts to make PLIB 2.0 GLUT independant as it whould
ship directly with FreeGLUT (
Norman Vine writes:
> SDL certainly has been made into the 'poster boy' for Linux Gaming
> but except for audio PLib is IMHO comparable. Also don't forget that
> PLib was in many ways, if not a direct spin off of FlightGear, written
> for FlightGear or at least to be VERY FlightGear friendly.
Norman Vine wrote:
> David Megginson writes:
>
>>Norman Vine writes:
>>
>>
>>>Again I don't see any compelling reason to move to SDL
>>>
>>As an outsider, I'll mention that one advantage is the fact that so
>>many other high-end games seem to be using SDL now. I like PLib, but
>>it hasn't seeme
David Megginson writes:
>
>Norman Vine writes:
>
> > Again I don't see any compelling reason to move to SDL
>
>As an outsider, I'll mention that one advantage is the fact that so
>many other high-end games seem to be using SDL now. I like PLib, but
>it hasn't seemed to catch on in the same way.
Norman Vine writes:
> Again I don't see any compelling reason to move to SDL
As an outsider, I'll mention that one advantage is the fact that so
many other high-end games seem to be using SDL now. I like PLib, but
it hasn't seemed to catch on in the same way.
All the best,
David
--
David
Erik Hofman
>
>Andy Ross wrote:
>
>> this. Frankly, if we really want to move away from GLUT,
>for whatever reason, I'd suggest SDL instead.
>
>Me too, I have threads/timing working for SDL (which basically means
>threading for windows/MacOS is supported then) and I am working on the
>sound code.
Andy Ross wrote:
> this. Frankly, if we really want to move away from GLUT, for whatever
> reason, I'd suggest SDL instead.
Me too, I have threads/timing working for SDL (which basically means
threading for windows/MacOS is supported then) and I am working on the
sound code.
It actually pre
Julian Foad writes:
> In my experience, debugging FG (single-stepping, run-to-here, etc.)
> is almost impossible under GDB
It is very difficult.
> and I believe the OpenGL "I'm in charge of the main loop"
> philosophy is the main cause.
No, the problem is the heavy use of inline functions
Julian Foad wrote:
> In my experience, debugging FG (single-stepping, run-to-here, etc.) is
> almost impossible under GDB and I believe the OpenGL "I'm in charge of
> the main loop" philosophy is the main cause.
I've successfully and productively run fgfs under gdb just fine. I'm
not sure the
Julian Foad writes:
>
>In my experience, debugging FG (single-stepping, run-to-here,
>etc.) is almost impossible under GDB and I believe the OpenGL
>"I'm in charge of the main loop" philosophy is the main cause.
This is GLUT not OpenGL
> Could we abuse OpenGL by making the idle function alway
In my experience, debugging FG (single-stepping, run-to-here, etc.) is almost
impossible under GDB and I believe the OpenGL "I'm in charge of the main loop"
philosophy is the main cause. Could we abuse OpenGL by making the idle function
always request OpenGL to terminate its loop? If we can d
22 matches
Mail list logo
