Crystal Space 3D SDK

Hi. I subscribed to the mailing list, but I am not receiving any =
messages like the 50-a-day that was described. So, Can anyone see =
this???

Thanks, Marc.

DX3 is the highest version of DX that runs on NT. It's installed as part of
sp3 and beyond. Some games can fall back to using this version of DX, as
long as they don't use D3d interfaces (some just use DDraw and their own 3d
engine.. TA comes to mind).

There are ways to hack DX5 and 6 to get some parts of it working under NT
(like DirectPlay.. but not d3d), but it's not worth it.

-frank
----- Original Message -----
From: BrainBoy <brainboy@...>
To: <crystal-main@...>
Sent: Saturday, March 25, 2000 1:49 PM
Subject: Re: [CsMain] Followup: COM again...?


> I'm perty sure I've installed Dx5 on my NT based Laptop so that I can play
> games when my employer sends me out of town.
>
> It seems to me in the past that NT was one ver behind Win9x.  So, Dx6
might
> be working now.
>
> All from a user's perspective and not programmer's.
>
> ----- Original Message -----
> From: "Paul Garceau" <pgarceau@...>
> To: <crystal-main@...>
> Cc: "Eric Sunshine" <sunshine@...>
> Sent: Tuesday, March 21, 2000 1:35 PM
> Subject: Re: [CsMain] Followup: COM again...?
>
>
> >
> >
> > On 21 Mar 00, at 21:37, the Illustrious Thomas Hieber wrote:
> >
> > > From: Paul Garceau <pgarceau@...>
> > > >
> > > > Is there any reason why "#include <objbase.h>" needs to be
> > > > called for OS_WIN32 if COM is no longer being used?
> > > >
> > >
> > > Maybe it is not needed any more, but you should be aware, that
> > > COM is (of course) still used in the Win32 specifiv stuff. (Like
> > > Direct Input, Direct Draw, Direct Sound and so on.)
> >
> > That is what I was afraid of...
> >
> > Well, since the Mingw port for NT4 can't use Dx or any of the
> > "Direct"x stuff (Mingw/gcc does not include Dx that works for
> > NT4 & Dx5/6/7 are incompatible with NT4.  Dx3 headers are not
> > available for Mingw/Gcc).  I will be using the OpenGL/MesaGL
> > stuff depending on the need.
> > It appears that at least the OpenGL related stuff does _not_
> > depend on Dx for anything, which is ideal when it comes to NT4
> > ports (ie. non-dependency on Dx).
> >
> > Thanks for letting me know, Thomas.
> >
> > Peace,
> >
> > Paul G.
> >
> > >
> > > Thomas
> > >
> > >
> > > _______________________________________________
> > > Crystal-main mailing list
> > > Crystal-main@...
> > > http://lists.sourceforge.net/mailman/listinfo/crystal-main
> > >
> >
> >
> >
> >
> > Nothing real can be threatened.
> >     Nothing unreal exists.
> >
> > _______________________________________________
> > Crystal-main mailing list
> > Crystal-main@...
> > http://lists.sourceforge.net/mailman/listinfo/crystal-main
> >
>
>
> _______________________________________________
> Crystal-main mailing list
> Crystal-main@...
> http://lists.sourceforge.net/mailman/listinfo/crystal-main

I forgot to mention this:

The VFS is intended to keep the user away from the real filesystem. So we
need a function to create a new directory through the VFS (which creates a
real diectory for this and mounts it afterwards). This function would do the
following:
- arguments : virtual base path, real name, mount name, type (real directory
or archive)
- expand virtual base path to real path (fails if it does not exist or is
inside an archive, because the VFS cannot handle archives inside archives as
virtual directories, or if this virtual directory is mapped to several real
directories).
- change to this real path
- create the directory or archive (real name)
- mount (real name) as (mount name)

Martin Geisse

1. Why do you think the RefCount stuff will avoid searches? The objects do
not
know their position in the 'vectors for everything', e.g. csWorld::sectors.
So they cannot delete themselves. This has to be done by a flush function,
which finally has to loop through all objects (that's what I mean with
'search'). BTW this flush function has to be called immediatly after the
world or a
library is unloaded.
I see that this flush function need not be that fast because it is called at
startup (e.g. when a new level is loaded). So the RefCount could be the
solution if you don't want multiple inheritance. But maybe it conflicts with
the rest (see 4.)

2. I know that csEngine does not know about csLoader. Adding the mentioned
feature does not create such a dependency. It is rather a feature to group
several world objects and give this group a name, and to make deleting the
whole group possible. csLoader only uses this feature.

3. Why should one need to unload a library? Don't know, but I see a purpose
in unloading everything BUT the libraries, e.g. when loading a new world.
But if you can unload everything that does NOT belong to a library, the
possibility to unload a library is probably only a small change.

4. Jorrit, you said the engine does a lot of initialization with loaded
objects, which invalidates them. This is not a real problem, because nobody
would want to access the original data. But this initialization creates new
data (otherwise it would be useless). So this new data is what should be
kept when the rest is deleted.
This could however be a problem with the RefCount.

Until we find a good solution the todo is the right place for this.

Martin Geisse