[openbeos] Re: 3d engine

/lurk disable

Let me clarify what Crystalspace is:

    It is a 3d rendering engine, capable of doing just about any type of
game.  It is a massive set of abstraction layers such that it can run on
just about ANY operating system platform.  It provides keyboard, mouse,
joystick, 3d rendering, iso rendering, audio, networking, etc. (though some
components depend on whether the OS driver provides the proper abstraction
layer/api, but still.)  It, presently, has little to no applications
available using it, unlike other libraries of the same nature (Allegro, SDL,
etc)

*Could* it be included with OBOS?   Yes. There is no real-world reason
preventing it from being included, just as there is no reason not to include
the SDL gaming libraries or a MUSCLE library..

*Should* it be included with OBOS?   Not at the present state it is in.
There is still alot of work to be done to it and we are busting our arses to
get out a v1.0 soon.  Maybe the v1.0 release would be a better choice, but I
wouldn't suggest shipping with the current state (nightly changes to the
cvs).

I have already stated many times in this mailing list and in irc, I will be
updating the BeOS code in Crystalspace to work with OBOS when OBOS is able
to support it.  I currently maintain the current BeOS port (and saved it
from removal) and will maintain the OBOS port once it's finished.

You wanna help me?  Tell me whether OBOS will use Mesa or OpenGL?  Will SDL
be available?  Will OpenAL be available?  What codecs are planned to be
written?  What changes from the BeOS GameKit, MediaKit, and NetworkKit will
there be?  (or anything sound, video, 3d api, or networking related.)  Give
me api layouts (completed ones, not partial ones.)

Whether or not CS makes it to a 'wow look at these neato extra things for
OBOS' package, it doesn't matter nor should it.  I will be porting it to
OBOS.  I will post it up on BeBits.  It will be in the main CS package (of
which there are plans for a CS CD sometime after v1.0).  If it's deemed neat
enough to include, kewl.  If not, kewl.

/lurk enable.

-jtarbox

----- Original Message -----
From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
To: <openbeos@xxxxxxxxxxxxx>
Sent: Thursday, February 28, 2002 8:26 PM
Subject: [openbeos] Re: 3d engine


> Of course, Nathan is right in saying that code is required for an API to
do something.
> What do you define as an "engine"? The definitions that I infer from what
is written would
> imply that any significant code is an engine. App_server, I think, could
be called an "engine".
> To say that we should have no "engines" would imply that the OS does
nothing, literally.
>
> What to include and not include is almost a philosophical question.
> Certainly, no one would argue that we should not include the kernel. After
that, I think that
> few people will agree on what an "optimal" package would include. Most
people want
> networking. Most people want a GUI. Most people want printing. That stuff
is all pretty simple.
> Every OS out there includes those things. But what about gaming APIs? On a
pure business machine,
> they may well be wasted. Or ODBC, on a gamer's machine. Or MIDI on a
kiosk?
>
> The way that I (personally) see it, the "cost" of including the package
should be outweighed by its
> usefulness. Most people will use networking. So the fact that it takes up
(with all of the tools and all)
> N megabytes of the install are worthwhile. If we did not include
networking, a majority of people would
> need to install it. On one side of the equation (the DON'T include side),
you have size of the package,
> CPU cycles when unused and making the package bigger. On the other side
(the DO include side) you have
> convenience, utility out of the box, the ability for standardization and
increasing the popularity of the API.
>
> So, generally, I would think that packages that are fairly small, fairly
good quality and fairly useful should
> be installed by default. The bigger, the more unstable, and the more
obscure, the less likely that they should
> be installed.
>
> >In my dictionnary (ok, ok ... we can go far with that :-)  I think a game
> >engine is too specialized for a "basic" OS package. We have to
concentrate
> >on more generic services that can be used for. Like DirectX is a generic
API
> >for games development, but not an engine itself.
> >
> >But if we plan for a huge packaging (like Linux distros), sure we can
bundle
> >anything else, including this engine...
> >
> >I just want for those "extra" to remain extra and not be considered as
> >"native" in the heart of the OS...
> >
> >----- Original Message -----
> >From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
> >Sent: Wednesday, February 27, 2002 7:02 PM
> >Subject: [openbeos] Re: 3d engine
> >
> >> > I think it's a bad idea to include any "engine". In my book an OS
> >> > provide APIs. Period.
> >>
> >> And in my book those APIs are tied to a system that *does* something.
> >> What are the media_server, the app_server, or the net_server if not
> >> 'engines' for media, graphics, and networking, repsectively?
> >> -Nathan
>
>
>

Other related posts: