[ODE] On the meaning of ODE stability (was some quick notes on 0; 6) ...
Jon Watte (ODE)
hplus-ode at mindcontrol.org
Fri Jun 23 10:41:50 MST 2006
Each game will depend on specific bugs and quirks of specific versions
of ODE. A systemwide ODE shared library isn't all THAT useful in general
(other than as a checkmark), and is downright detrimental to software
compatibility moving forward.
Look what they did to D3DX: one new DLL every 2 months. d3dx9_24.dll,
d3dx9_25.dll, d3dx9_26.dll, ... and Microsoft has a LOT more people to
spend on ensuring games compatibility than ODE does. Let's put the
gunpowder where it matters (like collisions, joint types, etc).
Rodrigo Hernandez wrote:
> Terry L. Triplett wrote:
>> On 6/22/06, *Rodrigo Hernandez* <kwizatz at aeongames.com
>> <mailto:kwizatz at aeongames.com>> wrote:
>> Well, there is one single reason I (and others) think ODE should
>> not be
>> Who are these mysterious others? Will they not reveal themselves? :-)
> You alone seem to be the vocal minority who advocates for a system wide
> library, I remember John Watte supporting the
> position that a System Wide library was a bad idea the second to last
> time we discused sonames, (forgive me John if I am mistaken).
>> part of a distribution, and that is the dual library aproach.
>> which one should you distribute? double or single precision? both? if
>> you decide for either, some will require the other, if you go for
>> then we need to decide on how will we be distinguishing them, make
>> changes and so on, this isnt imposible, and maybe not hard, but not
>> exactly easy.
>> Not much in life is easy if worthwhile. Suck it up and make a decision.
>> At the present state of technology? Both, I'd say.
>> Distinguished by name (e.g. ode-single-<version>.<foo> and
>> ode-double-<version>.<foo>, where foo is the designation for shared or
>> static libraries on appropriate platforms). Both produceable by a
>> single build step (ie, building ODE by default gives you both).
>> Having a clear choice of which precision to link to (dynamic linking)
>> or include (static linking) for a C++ library at development time is
>> better than having things blow up in your face because the wrong
>> precision was used against the single ODE library that was available.
> We need to have a consensus, its not just "suck it up and make a
> decision", specialy since I think a single library with precision sufixes is
> better than a library for each precision.
>> Which brings me to a point I wanted to present for a while.
>> I think we should standarize the function names so that there is a
>> single library with single and double precision calls, much
>> like OpenGL "f" and "d" suffixes, just throwing the idea into the
>> air here.
>> And what about quad precision and beyond? (
>> http://en.wikipedia.org/wiki/Quad_precision). As technology
>> advances, notions like precision based on the number of storage
>> locations in memory seem quaint. Pretty soon there will need to be
>> "q" and "whatever" suffixes as well.
>> Ultimately, the answer is likely to be multiprecision, arbitrary
>> precision data types. Until then we have to live with what the
>> language and compiler designers give us.
> Jason answered this one.
>> As for 1.0, I dont see it as just a label, I think once 1.0 is
>> the library would be a full feature library with a stable, standarized
>> API, 1.1 being backward compatible with it and so on, this is just my
>> opinion though.
>> I guess I'd have to see a targeted feature list to be able to
>> interpret what "full feature" would mean. 1.0 *is* just a label, even
>> if it resonates with our human perception of numbers.
>> No matter what the label (ODE-1.0, or
>> ODE-745.453.3452.I_AM_REALLY_STABLE_HONEST_TRUST_ME), it is the agreed
>> upon development objective(s), not the label, that defines stability
>> and full featuredness.
>> Targeting features rather than labels is a better path for this kind
>> of project, IMHO.
> True, I am not going to argue with you here, as this seems to be arguing
> just for the sake of arguing.
> ODE mailing list
> ODE at q12.org
More information about the ODE