Norman,
(Sorry this message got so long)
Let me try to get this discussion back on track and address some of
your specific comments. The way my mind works [1] I like to think
before I leap. That involves thinking through the process (or design)
as far as possible before taking any "irreversable" action. Depending
on the complexity and importance of the issue I like to give it
several days, maybe even weeks. Certainly I could think of something
on Day 5 that I would have overlooked on Day 1. You could think of
this as building a "virtual prototype" in my mind. I can construct
it, test it, debug it, and work out issues, all before I lay down a
single line of code. Obviously it is a bit of a shakey/incomplete
process, but at least I hit the ground running with a plan and a
purposeful direction.[2]
[1] I'm sure not everyone's mind works the same; I *hope* not
everyone's mind works the same! :-)
[2] That way when I run into a brick wall, knock myself out, come to,
and find myself painted into the corner, I can at least build a
case for why I took the best course of action. :-)
I don't know about every one else, but this is the phase that I am
currently in ... thinking, planning, investigating, talking. You have
been sharply critical in the past of people not discussion major
issues in advance, now you are belittling our efforts to do just
that?!?
Personally, I have done some tests of SDL. I have downloaded and
installed it. I have built some of the demo apps. And I have also
built my own plib/SimGear app for a work project so I can get some
real world experience. However, I don't have the time/resources to
personally investigate the intricacies of SDL on every conceivable
platform/compiler. That is why we are having an open discussion here
on the developers list. We are looking to identify potential serious
issues, and also look to see if we can find solutions/work arounds in
advance.
>From the discussions it is clear that some of the other developers
also have experience (mostly positive) with SDL and have opinions that
contribute to this discussion, so I am glad we are doing this.
In the FlightGear project we don't have any official rules of
governance. We don't really have a constitution or any official way
to resolve disagreements other than trying to talk them through and
hopefully reach a consensus or a set of conditions that make everyone
reasonably happy. Barring a violent uprising, I still have the root
passwords to the flightgear servers so I guess if worse comes to
worse, I can act as the "benevolent dictator" but I try to use that
power only as a *very* last resort when all other avenues are
exhausted.
So what do we do when we can't make every one happy? In this case
I've only heard one voice (yours) expressing concern or opposition to
the idea of switching to SDL. You are our primary Cygwin expert, and
most of your SDL concerns center around cygwin support and cygwin
interoperability. Those are valid concerns and I hope you don't feel
we are skipping over those lightly.
You and I have had some discussions offline where I've tried to get an
understanding of the nature of the problems and tried to see if any of
the obvious [to a unix guy] work arounds are feasible for the cygwin
platform. I hope you interpret those questions as a search for
solutions, not as a search for a way to ignore your concerns.
A couple more comments are interspersed below ...
Norman Vine writes:
> Haven't seen many reports from FlightGear developers
> doing any beta testing.... guess they are all to busy beta
> testing OSG and SDL integration
If this was marriage counseling, the above statement would be call
"not fighting fair." :-)
> Speaking of which any reports on the OSG front ? Anyone write a OSG
> FGFS Terrain loader module yet ??
That is one of the many issues that would need to be discussed and
considered at the point when we take up a discussion about plib/ssg
vs. OSG. But right now we should stay focussed on SDL if we want to
get any where with this discussion.
> Anyone got FGFS running on a SDL OpenGL surface instead
> of a GLUT OpenGL surface yet ??
>
> or is this all idle speak or do folks want to make a decision
> about moving to a different library without trying it out first.
Again, it's helpful if everyone keeps to fair comments. I have a
plib/SimGear based app running nicely on an SDL OpenGL surface for a
work project. There are additional issues with FlightGear because it
depends heavily on glut's mouse and keyboard routines, but I haven't
seen anything that I would consider a show stopper ... with the
possible exception of cygwin incompatibilities. SDL lists cygwin as a
supported platform, but cygwin is often a moving target. I'd like to
get these issues figured out in advance if possible.
How about this for a suggestion. There are quite a few developers
using cygwin. Could a few people go grab SDL and compile and install
it on your systems? Could a few people try building a few SDL and SDL
opengl demos. If we can verify this works (or find a way to make it
work) I think this would go a long ways towards alleviating Norman's
concerns.
> FWIW I just did my part towards making experimentation easier by
> removing a bunch of GLUT dependencies.
I do greatly appreciate those efforts.
> and have been trying unsuccessfully to get stderr and stdout working
> with a WIN32 compiled SDL and have OSG running on my machine.
And those efforts as well.
> FWIW2
>
> I might be *much* more favorably inclined to make a switch
> to something other then PLIB when I see reports of what folks
> have experimented with and how it has improved things rather
> then speculation what it will do based on 'hype'
This discussion is a process ... we are trying to identify potential
issues so that we can take a closer look at them. Many of our
developers have used SDL in other projects (or have used other SDL
based software) so my sense is that we are able to have a good
discussion based on real world experience, and not just "hype".
Best regards,
Curt.
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities curt 'at' me.umn.edu curt 'at' flightgear.org
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
