wf-gdk-wfcode

Re: [Wf-gdk-wfcode] lots of changes

[<nl...@nl...>]

On Sat, Dec 07, 2002 at 08:12:59AM -0800, Kevin Seghetti wrote:
> If I convert the new desired orientation to a quaternion (and the old is
> already stored as a quat), then I think I can just subtract the old from
> the new to get the angular delta, which should be the desired Angular
> velocity, right?

I'm afraid my current quaternion knowledge is insufficient to answer
this question... the instantaneous angular motion of a rigid body (with
the classical assumption that the notion of "instantaneous velocity" exists)
can always be expressed as a single rotation about a single vector. The speed
(magnitude) of rotation is expressed by the length of this vector. This is
the "angular velocity" which needs to be derived from previous and current
angular orientations.

> > Appended is a simple example of a kinematically controlled sphere
> 
> Would there be any less error if you had used a force to push on the
> sphere instead of moving it directly?

Yes - there would be far less error, practically zero. The original
test_chain1.c used a force to control the first sphere - run it for
comparison. "Practically zero" error specifically means that (a) new
constraint error is allowed to be introduced by an amount specified
by the CFM (constraint force mixing) parameter, designed to allow
soft or yielding constraints (e.g. soft surfaces that you can push
together slightly, hinges that can be bent slightly past their limits,
etc), and (b) existing error is reduced by an amount specified by
the ERP (error reduction parameter). For a totally stiff system,
ideally, CFM would be zero (constraints can never be violated by any
amount) and ERP would be 1 (constraint error is 100% corrected for
the next frame), but these values cause severe stability problems
in practice (system explodes, etc). Typical global values are CFM=0.00001 and
ERP=0.8. These values can be changed on a per-joint basis to allow
for different material properties (with contact joints) or other
joint properties (e.g. hinge stops).

One of the major benefits of ODE is that with the standard ERP and CFM
values the system is amazingly stable (the integrator is also very
stable), so the system almost never explodes. This is in marked contrast,
for instance, to penalty methods, where artificial springs are used
to enforce constraints, which can easily add energy to the system,
causing unphysical explosions and requiring immense "fine tuning" of
large numbers of non-physical "spring forces". ODE's design specifically
limits the number of parameters you have to tune to get a stable system.
As per the ODE docs, reducing (global) ERP or increasing (global) CFM
are reliable ways to get "misbehaving" systems under control.

> I am not worried about it, I have how gravity affects objects in the
> boxstack demo, so I know that externally applied forces do the right
> thing, so I am confident I will be able to get pathed objects working.
> (and would rather get ODE into the engine and do most of my
> experimenting there :-)

But don't forget that kinematically moving a pathed object is
non-physical and does not involve applying a force at all. It is the
constraints that apply the forces (and a collision between a pathed
object and another object causes creation of a contact joint, which
constrains the relative velocity of the 2 objects to be outgoing, and
fundamentally all constraints are exactly enforced by computing
exactly the required force needed to enforce this and all other constraints
simultaneously in the system). So the force generated by a pathed object
is an implicit one generated by the constraint solver, so I do consider
it as a separate case to test (which is why I made the hacked program
kinematically controlling the chain of spheres). Since the sphere chain
stays together, this proves that point-to-point constraints can deal
with the kinematically driven object state, so collision constraints
should theoretically also work, but I'd want to test it first.

> Ugh, I hadn't thought about timesteps. I would prefer to have it be
> variable so that WF runs well at different frame rates, is the problem
> related to the value of the timestep, or just having it change a lot?

The integration method used in ODE is a time-stepping integration method,
which means that the analytic equations of motion are solved under the
assumption of a particular numerical integration scheme. In particular, the
numerical integration scheme is a fixed-timestep Euler integration scheme.
Changing the timestep, as I understand it, violates one of the fundamental
assumptions underlying the entire solution method. Again, this is a
time stepping integration scheme, so the fundamental equations being
solved (the classical Newton equations of motion) are tightly tied to
a particular numerical integration scheme - in a time stepping scheme, we
solve for the numerical integrals of forces over a particular time
step or time interval, which is in contrast to the other approach, where
we instantaneously compute instantaneous forces needed at the ends of each
time interval. The coupling of the integration scheme (and the fixed timestep)
with the fundamental solution of the fundamental equations makes me very
wary of using a variable timestep. (Incidentally, since we are solving
for integrals of forces over timesteps, instead of instantaneous forces,
we never need to explicitly apply an "impulse", since the effect of an
impulse integrated over a finite timestep can be exactly duplicated with
an equivalent force applied over that timestep. The behavior is identical;
we can declare that "impulsive behavior" occurs if we observe the magnitude
of the force as we scale down the timestep; if the force goes to infinity,
an impulse occurred.)

I'd suggest asking this on the ODE mailing list, though. Unfortunately,
there seems to be some misunderstanding on the ODE list about the
nature of the integrator; some people believe that ODE uses an instantaneous
approach to computing forces. So, critically consider the source and
quality of information you receive on this topic - this includes advice
from me ;-)

In practice, of course, it may be acceptable to use variable timesteps,
but as I said, my understanding is that this is fundamentally a rather
serious violation of one of ODE's basic axioms. I don't like to use
hacks without fully understanding their implications, and I don't fully
understand the implications of using a variable timestep with a
time stepping integration scheme. That said, I think at least one other
person (Nate W., author of the Juice program on the ODE community page)
has been using variable timesteps. 

-Norman

Re: [Wf-gdk-wfcode] lots of changes

[Kevin S. <kt...@te...>]

On Sat, 2002-12-07 at 04:57, nl...@nl... wrote:
> On Fri, Dec 06, 2002 at 10:34:14PM -0800, Kevin Seghetti wrote:
> > At this point I get to ifdef out all of the existing physics and
> > collision code.
>=20
> How do you plan on handling collisions between kinemetically controlled
> (path-controlled) objects and physically-controlled objects?

The way we handled this in the WF physics was to make the pathed objects
have infinite (well as big a Scalar as we can store) mass, which meant
any object it its way got pushed real hard.=20


> I would suggest making an ODE body for the kinematically controlled
> object, initializing its mass and mass distribution to reasonable values,
> manually setting its position each frame, _AND_ (this is the tricky part)
> manually setting its linear and angular velocity each frame. Without
> linear/angular velocity information, the object will, from ODE's point
> of view, simply appear to instantaneously materialize within another
> object, with no information (no velocity information) to understand how
> this situation came about and how to correct it (correction requires
> generation of a contact joint, which prevents further penetration through
> constraining the bodies' relative velocities to be outgoing, and which
> corrects existing penetration through the ERP).

That makes sense, we did something similar in the WF physics, but all
inside of the current frame. We would ask each object to calculate its
predicted position (where it would end up at the end of the frame if it
didn't hit anything). Then predcitedPosition-currentPosition IS its
linear velocity (we store it as then new position, but it could have
just as easily been stored as a motion vector). So it should be pretty
easy to change things to work that way.


=20
> A linear velocity approximation is easy to get (current_pos - last_pos).
> Angular velocity is more difficult, but you could possibly ignore the ang=
ular
> component (resulting in less "correct" behavior, of course).

If I convert the new desired orientation to a quaternion (and the old is
already stored as a quat), then I think I can just subtract the old from
the new to get the angular delta, which should be the desired Angular
velocity, right?

> Appended is a simple example of a kinematically controlled sphere
> (position is controlled by a hard-coded path) dragging along a number
> of other spheres, all of which are physically controlled and constrained
> to be connected in a chain. Note that the discontinuous "forcing" of
> the position of the kinematically controlled sphere introduces joint
> error into the system (I didn't update the position of the sphere
> connected to the kinematically controlled sphere), so the rest of the
> chain is visibly separated from the kinematically controlled sphere.
> ODE's ERP reduces this error, but it can only reduce it a certain amount
> each frame, and I am constantly artificially increasing the error by
> kinematically "forcing" the sphere position.

Would there be any less error if you had used a force to push on the
sphere instead of moving it directly?

> This is probably mostly an issue for articulated systems. For a single
> box or sphere controlled to move on a path, designed to knock away
> other single spheres or boxes (not connected together), this would probab=
ly
> work okay. A simple test would be to make an unordered stack of boxes,
> then to kinematically move a sphere along a path through the boxes in
> a manner similar to that shown below, then to see if the boxes get
> realistically knocked away by the kinematically controlled sphere.

I am not worried about it, I have how gravity affects objects in the
boxstack demo, so I know that externally applied forces do the right
thing, so I am confident I will be able to get pathed objects working.
(and would rather get ODE into the engine and do most of my
experimenting there :-)

> Oh, also, something else, you probably want to be using a fixed timestep
> for ODE, due to properties of the integrator and the error reduction
> mechanism.

Ugh, I hadn't thought about timesteps. I would prefer to have it be
variable so that WF runs well at different frame rates, is the problem
related to the value of the timestep, or just having it change a lot? In
the existing system the time delta is always behind by a frame (since I
don't actually know how long the current frame is going to take), so it
looks bad with wildly changing framerates anyway, I could low-pass
filter the timestep (wrong paradigm, I should say "dampen or slew limit"
:-) so that never changed very fast from ODE's point of view, do you
think that would be good enough? This might be one for the ODE mailing
list (which I will now subscribe to).

--=20
Kevin Seghetti: E-Mail: kt...@te..., HTTP: www.tenetti.org
GPG public key: http://tenetti.org/phpwiki/index.php/KevinSeghettiGPGKey
Check out www.worldfoundry.org for my GPL'ed 3D video game engine

Re: [Wf-gdk-wfcode] lots of changes

[<nl...@nl...>]

On Fri, Dec 06, 2002 at 10:34:14PM -0800, Kevin Seghetti wrote:
> At this point I get to ifdef out all of the existing physics and
> collision code.

How do you plan on handling collisions between kinemetically controlled
(path-controlled) objects and physically-controlled objects?

I would suggest making an ODE body for the kinematically controlled
object, initializing its mass and mass distribution to reasonable values,
manually setting its position each frame, _AND_ (this is the tricky part)
manually setting its linear and angular velocity each frame. Without
linear/angular velocity information, the object will, from ODE's point
of view, simply appear to instantaneously materialize within another
object, with no information (no velocity information) to understand how
this situation came about and how to correct it (correction requires
generation of a contact joint, which prevents further penetration through
constraining the bodies' relative velocities to be outgoing, and which
corrects existing penetration through the ERP).

A linear velocity approximation is easy to get (current_pos - last_pos).
Angular velocity is more difficult, but you could possibly ignore the angular
component (resulting in less "correct" behavior, of course).

Appended is a simple example of a kinematically controlled sphere
(position is controlled by a hard-coded path) dragging along a number
of other spheres, all of which are physically controlled and constrained
to be connected in a chain. Note that the discontinuous "forcing" of
the position of the kinematically controlled sphere introduces joint
error into the system (I didn't update the position of the sphere
connected to the kinematically controlled sphere), so the rest of the
chain is visibly separated from the kinematically controlled sphere.
ODE's ERP reduces this error, but it can only reduce it a certain amount
each frame, and I am constantly artificially increasing the error by
kinematically "forcing" the sphere position.

This is probably mostly an issue for articulated systems. For a single
box or sphere controlled to move on a path, designed to knock away
other single spheres or boxes (not connected together), this would probably
work okay. A simple test would be to make an unordered stack of boxes,
then to kinematically move a sphere along a path through the boxes in
a manner similar to that shown below, then to see if the boxes get
realistically knocked away by the kinematically controlled sphere.

Oh, also, something else, you probably want to be using a fixed timestep
for ODE, due to properties of the integrator and the error reduction
mechanism.

-Norman

------

/* this is a hacked version of test_chain1.c which kinematically drives the first sphere */

/* exercise the C interface */

#include <stdio.h>
#include "ode/ode.h"
#include "drawstuff/drawstuff.h"

#ifdef MSVC
#pragma warning(disable:4244 4305)  // for VC++, no precision loss complaints
#endif

/* select correct drawing functions */

#ifdef dDOUBLE
#define dsDrawBox dsDrawBoxD
#define dsDrawSphere dsDrawSphereD
#define dsDrawCylinder dsDrawCylinderD
#define dsDrawCappedCylinder dsDrawCappedCylinderD
#endif


/* some constants */

#define NUM 10			/* number of boxes */
#define SIDE (0.2)		/* side length of a box */
#define MASS (1.0)		/* mass of a box */
#define RADIUS (0.1732f)	/* sphere radius */


/* dynamics and collision objects */

static dWorldID world;
static dSpaceID space;
static dBodyID body[NUM];
static dJointID joint[NUM-1];
static dJointGroupID contactgroup;
static dGeomID sphere[NUM];


/* this is called by dSpaceCollide when two objects in space are
 * potentially colliding.
 */

static void nearCallback (void *data, dGeomID o1, dGeomID o2)
{
  /* exit without doing anything if the two bodies are connected by a joint */
  dBodyID b1,b2;
  dContact contact;

  b1 = dGeomGetBody(o1);
  b2 = dGeomGetBody(o2);
  if (b2 && b2 && dAreConnected (b1,b2)) return;

  contact.surface.mode = 0;
  contact.surface.mu = 0.1;
  contact.surface.mu2 = 0;
  if (dCollide (o1,o2,0,&contact.geom,sizeof(dContactGeom))) {
    dJointID c = dJointCreateContact (world,contactgroup,&contact);
    dJointAttach (c,b1,b2);
  }
}


/* start simulation - set viewpoint */

static void start()
{
  static float xyz[3] = {2.1640f,-1.3079f,1.7600f};
  static float hpr[3] = {125.5000f,-17.0000f,0.0000f};
  dsSetViewpoint (xyz,hpr);
}


/* simulation loop */

static void simLoop (int pause)
{
  static dReal xx=0.,yy=0.,zz=2.,delta=0.1;

  int i;
  if (!pause) {
    static double angle = 0;
    angle += 0.05;
/*    dBodyAddForce (body[NUM-1],0,0,1.5*(sin(angle)+1.0)); */

    dSpaceCollide (space,0,&nearCallback);
    dWorldStep (world,0.05);

    yy+= delta;
    xx+= delta;
    dBodySetPosition (body[NUM-1],xx,yy,zz);
    dBodySetLinearVel(body[NUM-1],delta,delta,0);
    dBodySetAngularVel(body[NUM-1],0,0,0);
    if(yy>1.0) {
      delta = -delta;
    } else if(yy<-1.0) {
      delta = -delta;
    }

    /* remove all contact joints */
    dJointGroupEmpty (contactgroup);
  }

  dsSetColor (1,1,0);
  dsSetTexture (DS_WOOD);
  for (i=0; i<NUM; i++) dsDrawSphere (dBodyGetPosition(body[i]),
				      dBodyGetRotation(body[i]),RADIUS);
}


int main (int argc, char **argv)
{
  int i;
  dReal k;
  dMass m;

  /* setup pointers to drawstuff callback functions */
  dsFunctions fn;
  fn.version = DS_VERSION;
  fn.start = &start;
  fn.step = &simLoop;
  fn.command = 0;
  fn.stop = 0;
  fn.path_to_textures = "../../drawstuff/textures";

  /* create world */

  world = dWorldCreate();
  space = dHashSpaceCreate();
  contactgroup = dJointGroupCreate (1000000);
  dWorldSetGravity (world,0,0,-2.5);
  dWorldSetERP(world,0.8);
  dCreatePlane (space,0,0,1,0);

  for (i=0; i<NUM; i++) {
    body[i] = dBodyCreate (world);
    k = i*SIDE;
    dBodySetPosition (body[i],k,k,k+0.4);
    dMassSetBox (&m,1,SIDE,SIDE,SIDE);
    dMassAdjust (&m,MASS);
    dBodySetMass (body[i],&m);
    sphere[i] = dCreateSphere (space,RADIUS);
    dGeomSetBody (sphere[i],body[i]);
  }
  for (i=0; i<(NUM-1); i++) {
    joint[i] = dJointCreateBall (world,0);
    dJointAttach (joint[i],body[i],body[i+1]);
    k = (i+0.5)*SIDE;
    dJointSetBallAnchor (joint[i],k,k,k+0.4);
  }

  /* run simulation */
  dsSimulationLoop (argc,argv,352,288,&fn);

  dJointGroupDestroy (contactgroup);
  dSpaceDestroy (space);
  dWorldDestroy (world);

  return 0;
}

Re: [Wf-gdk-wfcode] lots of changes

[Kevin S. <kt...@te...>]

On Fri, 2002-12-06 at 12:53, nl...@nl... wrote:
> Actually as I understand it, ODE uses quaternions internally; the matrix
> is, I believe, computed from the quaternion. So, for instance, if you wan=
t
> to dump the entire physical world state to a file and restore it later an=
d
> be guaranteed reproducible behavior, you should dump the world state usin=
g
> the quaternions, not the matrices, since there is some tiny precision
> loss in converting. There was a thread in the ODE mailing list recently
> (November 2002) about this.

That's what I get for using the test program and not reading the
documentation. Oh well, I will revisit that if/when I need to (I was
considering using quaternions in the WF engine anyway). Currently I have
the Euler matrix conversion working well enough in both directions to
run with either Matrix or Vector/Euler internally (with the old physics
system in the game and in physicstest using ODE), it only seems to have
problems with code that iteratively increments an Euler angle (like the
cube menu animation).

At this point I get to ifdef out all of the existing physics and
collision code.

--=20
Kevin Seghetti: E-Mail: kt...@te..., HTTP: www.tenetti.org
GPG public key: http://tenetti.org/phpwiki/index.php/KevinSeghettiGPGKey
Check out www.worldfoundry.org for my GPL'ed 3D video game engine

Re: [Wf-gdk-wfcode] lots of changes

[<nl...@nl...>]

> I also have started
> on a compile time switch which changes PhysicalAttributes to use a
> Matrix34 internally instead of Eulers & Vector3 (since ODE uses matrixes
> internally).

Actually as I understand it, ODE uses quaternions internally; the matrix
is, I believe, computed from the quaternion. So, for instance, if you want
to dump the entire physical world state to a file and restore it later and
be guaranteed reproducible behavior, you should dump the world state using
the quaternions, not the matrices, since there is some tiny precision
loss in converting. There was a thread in the ODE mailing list recently
(November 2002) about this.

-Norman

[Wf-gdk-wfcode] lots of changes

[Kevin S. <kt...@te...>]

I have just checked in a huge # of changes, all were to move the
codebase closer to being able to use ODE. I added float & double support
to Scalar (set with SCALAR_TYPE=3Dfixed|float|double). I also have started
on a compile time switch which changes PhysicalAttributes to use a
Matrix34 internally instead of Eulers & Vector3 (since ODE uses matrixes
internally). Doesn't fully work yet. The problem is there are places in=20
the engine where we want to read the Eulers back from the
PhysicalAttributes class. I found and implemented a function which is
supposed to convert a 3x3 matrix back into Eulers, but it doesn't seem
to always work (see mathtest for an example of it failing). Even if I
get the Matrix->:Euler conversion working it is not an optimal solution,
since Euler->Matrix conversion is lossy, so the same data doesn't always
come back (for example, the cubemenu, which reads and adds to the Eulers
in a loop to spin gets stuck because the axis it is incrementing is
coming back out as a different axis). Anyhow, I am going to look at
quaternions to see if they might be a better solution for this problem.

Unfortunately some things have broken which I need to go back and debug:
The lights don't animation any more, and the 3D text level doesn't=20
spin the object any more, probably both related to the PhyiscalAttribute
Euler changes.

For a preview of ODE in the engine, run physics/physicstest (make test
in physics), then press the 1 key a few times. This is basically gfxtest
with ODE crammed in, so the other joystick buttons and the cursor keys
move the camera around.

--=20
Kevin Seghetti: E-Mail: kt...@te..., HTTP: www.tenetti.org
GPG public key: http://tenetti.org/phpwiki/index.php/KevinSeghettiGPGKey
Check out www.worldfoundry.org for my GPL'ed 3D video game engine

[Wf-gdk-wfcode] windows GL interface redone

[Kevin S. <kt...@te...>]

I was having trouble with WF under windows, so I went out and found a
modern example of GL under windows and integrated it. WF can now run
full screen or in a window, and switch between the 2 (although more work
is needed there, the textures get lost since GL is re-initialized, so
all of the PixelMaps need to re-register themselves).

I also re-enabled the ability to set the window size on the command line
(also sets the resolution in full screen mode), but some work needs to
be done on glOrtho to make it look correct.

But anyhow, the latest in cvs works under windows again.

--=20
Kevin Seghetti: E-Mail: kt...@te..., HTTP: www.tenetti.org
GPG public key: http://tenetti.org/phpwiki/index.php/KevinSeghettiGPGKey
Check out www.worldfoundry.org for my GPL'ed 3D video game engine

[Wf-gdk-wfcode] possible game...

[Karel R. <kar...@vo...>]

 Well, I am afraid it won't be really simple, because such type of game would need
in my opinion a lot of add-ons into engine.
 As I see it, the concept should be something like jump and run and maybe few obstacles
to think about :)K
 It is the present state of World Foundry If I understand it right, of course there are
lot of variations because it is so open, but without some system with bones and mainly
incorporating such system into some kind of oas composed into some tree of it, where
you refer to every part of body as a single object, you can't do it nowadays.

>	My idea was a simple 1-on-1 fighting game (think virtua fighter or 
>tekken). One level, two characters, some effects, interface, input, 
>sound and physics (can these be connected to the IK-bones, so if I 
>"hit" the chest only the chest gets partially "thrown back"?). Two 
>characters and a level (not big) plus some ingame art should be 
>reasonable for me to handle and we get the result fast enough as to 
>not get de-motivated because it takes too long. And it also has much 
>of what all games need so it could be interesting for the coders...

 cheerio

 Karel

Re: [Wf-gdk-wfcode] engine cleanup

[Kevin S. <kt...@te...>]

On Sat, 2002-11-02 at 06:21, nl...@nl... wrote:
> I haven't looked at the WF code in a while, so my comments are of a gener=
al
> nature, but hopefully still relevant.
>=20
> The Actor needs to write to "a list of mailboxes", NOT to "the level's li=
st
> of mailboxes". Thus the Actor only needs to know about a "MailboxList"
> and not a "Level". Either in the Actor constructor you can initialize its
> MailboxList, or in the specific functions which need to write to mailboxe=
s,
> you can explicitly pass in a MailboxList. The first option is easier, but
> the second option is more explicit (forces you to find all locations wher=
e
> the Actor tries to do anything with a MailboxList and to explicitly pass
> the MailboxList as a parameter).

I don't like either of these answers because #1 uses more memory (each
instance of a Actor now has an additional 4 byte reference to a
MailboxList in it), and #2 uses more time/stack space (actually if this
was the only case I could probably live with it, but as listed below,
there are a dozen or more cases like this).

I want to have my cake and eat it to. One of the original design
constraints for WF was low memory usage (the Playstation has 2MB of
memory, which all code, data and stacks must fit into), so we did as
much as we could to reduce memory overhead. One of the ways we
accomplished this was by having a global pointer to the level (called
theLevel), which objects can ask for things like Memory context, Actor
lists, Room lists, asset slots, common block,etc. Level has become a
catch all for all data associated with a running level.

In the classes where the # of class instances is low (like Rooms or
script interpreters), and the dependence on the level data is low (like
only needing a Memory context to allocate from), I have now added a
local reference which is initialized at construction time (since I am
much less worried about memory usage than I used to be).

But for the Actor class, it uses level for the following:
Rooms
actor list
template object construction
object destruction
asset manager
 sound effect slots
 gfx slots
memory context
leveldata (oad data)
  path data
wall clock (this one I plan to move to a lower level library, although I
still might need to know what time the level started for level timers)
mailboxes (level and game wide)

Clearly I don't want to have every actor have references to all of this
stuff. The level is basically acting as a huge "ListManager" object.=20

If I made a separate ListManager object I think it would have most of
what is currently in the Level class in it, thus not gaining me much
(although I might try it and see). But it wouldn't really help with what
I am trying to do, which is to make some classes not know about some
other classes (the ListManager would have to include the headers for all
of the components it manages lists for, so anything including the list
manager header will know about all of the pieces).=20

Just making this list I can see some areas for improvement, like I
should break out actor list management into a separate class (it is
tricky because the level contains the Actor array, but each Room
contains a list of Actors in that room, most processing is done Room by
Room).=20

> If it is too cumbersome to initialize each object manually with reference=
s
> to all the lists it uses, you could have one or more "ListManager" object=
s
> which the Actor then queries to get a pointer/reference to the correct
> list. This allows the same functionality (one/multiple global authorities
> for returning pointers/references to globally used lists) while breaking
> out this list-management or global-object-management responsibility from
> the level. E.g. the Actor might ask the ListManager for the MailboxList
> or the RoomList. Or, at a finer-grained level, you could have the Actor
> ask a MailboxListManager for the MailboxList and a RoomListManager for th=
e
> RoomList.

I am focusing on physical dependencies (what headers need to get
included), a single ListManager won't really help since it would need to
include the headers for all of the sub-systems it managed. I view the
libraries in WF as a linear list each only depending on libraries below
it, game is at the top, I am trying to move things out of game to other
libraries, but the list of Actors is in game, most everything that is
left in game wants access to the Actor list in some form.
Having multiple ListManagers might work, but then we are back to adding
a lot of memory overhead to each Actor to keep references to all of
them.

> With respect to the level, I think it seems OK to let the level know abou=
t
> actors, because it contains them. However, it only needs to know about
> those PARTS of the actors that it actually uses.
>=20
> I would say that is the general rule. Any class X that only references
> methods or attributes Y::a, Y::b and Y::c from class Y, only knows
> Y::a, Y::b, and Y::c about class Y, nothing more. To reduce the
> dependency, encapsulate the known subset of methods/attributes into
> an separate class Z, create an instance of Z at some point
> in time, link this new Z instance with an instance of Y, and pass this
> new Z instance (instead of a Y instance) to X.

In this context I don't know that it would gain me anything to do this.
I have never done this sort of thing, so maybe it is just my lack of
experience. Maybe it depends on why dependency reduction is being done.
In this case I am trying to break functionality out into separate
libraries, with each library only depending on libraries (meaning
including headers from) below it in the hierarchy (gfx knows nothing
about anim or game, but does use pigsys, math and memory, for example).
I want to move all physics and collision detection out of the game
directory so that it will be easy to replace with ODE, but currently the
list of objects in the world is in the Level and Room classes, and the
collision code needs to iterate that list to check for collisions. So
what I am thinking is I want an 'ActorList' class which is in a separate
library which the physics code can use. But to do that I pretty much
need Actor (or a base of Actor) to be move out of the game directory as
well. So I thought I would see how much I could disconnect the pieces
first.

Another way I could do this would be to break the Actor into a bunch of
classes and multiply inherit them all back together, then different
sub-systems could only know about sections of it and maintain separate
lists. (but the current coding standards prohibit MI, and I am not sure
I want to introduce it). Also I am not sure it would be a good idea to
have several separate lists, when an object is destroyed it will require
some effort to keep it all synced up (the current method is all lists
contain indexes into the master list, so it is possible to tell if one
is accessing a deleted object).

Ok, writing this has helped me figure out what I really want. The actual
issue is I want to have lists of objects where I only know about a
sub-set of the object (in this case, the PhysicalAttributes class). In
this case I don't mind it being a base class, since all Actors have a
PhysicalAttributes instance in them anyway. So I can just keep lists of
the base class (I will probably call it ActorBase), and the libraries
will only need to know about that. The reason I didn't want to do this
before was because I didn't want to have to add reinterpret_cast to all
higher level accesses to entries in the list. I just figured out how to
avoid that: I will write a separate iterator/list wrapper which does the
reinterpret_cast for me. This iterator will be in the game directory and
know all about the full fledged Actor.=20


> Without digging out my book, this sounds like a "refactoring" problem.
> OK, I dug out the book ("Refactoring: Improving the Design of Existing
> Code", Martin Fowler et al.).=20
Maybe I should get that book, sounds interesting.

> This sounds like it could be an instance
> of the "Extract Interface" refactoring pattern: "Several clients use the
> same subset of a class's interface, or two classes have part of their
> interfaces in common. Extract the subset into an interface." The book
> also has scores of other refactorings.

I commonly try to do that particular refactor (2 classes have part of
their interfaces in common), always attempting to push common
functionality down toward the base of a class tree (of course a side
effect of this is the Actor class is huge and does everything).
=20
I haven't tried looking for the first case (several clients use the same
subset), I can imagine places where that would be useful.

> As a practical way of realizing this I would=20
>=20
> a) Edit actor.h to remove all other #includes
> b) Create a test program which does nothing but instantiate an Actor clas=
s.
> c) It will fail because of all the dependencies Actor has on other
>    classes.
> d) For each such other class, declare a dummy stub class in actor.h with
>    the needed methods and attributes
> e) These dummy stub classes are exactly the dependencies that actor has o=
n
>    all other classes (its "environment"). Analyze and refactor these
>    environmental dependencies to come from the environment, not from
>    an assumed run-time object-hierarchy (this means having global
>    Manager objects returning environmental information, or initializing
>    environmental information into objects when they are instantiated, or
>    passing environmental information explicitly into each method that
>    requires it).

Interesting, I am able to evaluate this pretty well without resorting to
these means using slickedit and doxygen.

> And as a final test I would use the criteria:
>=20
> Can the actor be created in a separate test.cpp program, without the usin=
g
> the level class, instead only using the required environmental classes?
> (i.e. is the actor independent of the level)
>=20
> Can the level instantiate interface-compatible actor replacements without
> using actors? (i.e. is the level indepedent of the actor - this independe=
nce
> might not be required however)
--=20
Kevin Seghetti: E-Mail: kt...@te..., HTTP: www.tenetti.org
GPG public key: http://tenetti.org/phpwiki/index.php/KevinSeghettiGPGKey
Check out www.worldfoundry.org for my GPL'ed 3D video game engine

Re: [Wf-gdk-wfcode] engine cleanup

[<nl...@nl...>]

On Sat, Nov 02, 2002 at 12:30:30AM -0800, Kevin Seghetti wrote:
> Each class goes to level to find things, like actor lists and room
> lists, so the collision code asks level for a room list. 
> But since level contains these things (room lists, actor lists), it
> needs to know about them. 
> 
> A specific example: the Actor class needs to be able to write to level
> wide mailboxes occasionally, so it needs to know about the Level class, 
> and since the Level keeps a list of Actors the Level class needs to know
> about Actors. 
> 
> I want to figure out how to break this cyclic dependency. My motivation
> for this is to make it possible to easily replace the physics and
> collision system.

I haven't looked at the WF code in a while, so my comments are of a general
nature, but hopefully still relevant.

The Actor needs to write to "a list of mailboxes", NOT to "the level's list
of mailboxes". Thus the Actor only needs to know about a "MailboxList"
and not a "Level". Either in the Actor constructor you can initialize its
MailboxList, or in the specific functions which need to write to mailboxes,
you can explicitly pass in a MailboxList. The first option is easier, but
the second option is more explicit (forces you to find all locations where
the Actor tries to do anything with a MailboxList and to explicitly pass
the MailboxList as a parameter).

If it is too cumbersome to initialize each object manually with references
to all the lists it uses, you could have one or more "ListManager" objects
which the Actor then queries to get a pointer/reference to the correct
list. This allows the same functionality (one/multiple global authorities
for returning pointers/references to globally used lists) while breaking
out this list-management or global-object-management responsibility from
the level. E.g. the Actor might ask the ListManager for the MailboxList
or the RoomList. Or, at a finer-grained level, you could have the Actor
ask a MailboxListManager for the MailboxList and a RoomListManager for the
RoomList.

With respect to the level, I think it seems OK to let the level know about
actors, because it contains them. However, it only needs to know about
those PARTS of the actors that it actually uses.

I would say that is the general rule. Any class X that only references
methods or attributes Y::a, Y::b and Y::c from class Y, only knows
Y::a, Y::b, and Y::c about class Y, nothing more. To reduce the
dependency, encapsulate the known subset of methods/attributes into
an separate class Z, create an instance of Z at some point
in time, link this new Z instance with an instance of Y, and pass this
new Z instance (instead of a Y instance) to X.

Without digging out my book, this sounds like a "refactoring" problem.
OK, I dug out the book ("Refactoring: Improving the Design of Existing
Code", Martin Fowler et al.). This sounds like it could be an instance
of the "Extract Interface" refactoring pattern: "Several clients use the
same subset of a class's interface, or two classes have part of their
interfaces in common. Extract the subset into an interface." The book
also has scores of other refactorings.

As a practical way of realizing this I would 

a) Edit actor.h to remove all other #includes
b) Create a test program which does nothing but instantiate an Actor class.
c) It will fail because of all the dependencies Actor has on other
   classes.
d) For each such other class, declare a dummy stub class in actor.h with
   the needed methods and attributes
e) These dummy stub classes are exactly the dependencies that actor has on
   all other classes (its "environment"). Analyze and refactor these
   environmental dependencies to come from the environment, not from
   an assumed run-time object-hierarchy (this means having global
   Manager objects returning environmental information, or initializing
   environmental information into objects when they are instantiated, or
   passing environmental information explicitly into each method that
   requires it).

And as a final test I would use the criteria:

Can the actor be created in a separate test.cpp program, without the using
the level class, instead only using the required environmental classes?
(i.e. is the actor independent of the level)

Can the level instantiate interface-compatible actor replacements without
using actors? (i.e. is the level indepedent of the actor - this independence
might not be required however)

-Norman

[Wf-gdk-wfcode] engine cleanup

[Kevin S. <kt...@te...>]

I have been reorganizing and doing some cleanup in the game directory of
the engine and trying to reduce interdependencies this past week. The
game directory is the worst for this since it is the topmost layer it
ended up being where people naturally added things. Anyhow, I have made
some progress (like it should now be easy to drop in a new scripting
language), but there is still a tangled mess of cross dependent
classes/files:

actor, level, game, room, rooms, assets, actrooms, the movement code,
and collision code all refer to each other.=20
Each class goes to level to find things, like actor lists and room
lists, so the collision code asks level for a room list.=20
But since level contains these things (room lists, actor lists), it
needs to know about them.=20

A specific example: the Actor class needs to be able to write to level
wide mailboxes occasionally, so it needs to know about the Level class,=20
and since the Level keeps a list of Actors the Level class needs to know
about Actors.=20

I want to figure out how to break this cyclic dependency. My motivation
for this is to make it possible to easily replace the physics and
collision system.

Any ideas/suggestions? What idioms/patterns are used to avoid this sort
of thing?

--=20
Kevin Seghetti: E-Mail: kt...@te..., HTTP: www.tenetti.org
GPG public key: http://tenetti.org/phpwiki/index.php/KevinSeghettiGPGKey
Check out www.worldfoundry.org for my GPL'ed 3D video game engine

Re: [Wf-gdk-wfcode] Ideas for next steps....

[Kevin S. <kt...@te...>]

On Thu, 2002-10-24 at 23:31, Karel Rous wrote:
>     My personal opinion is also to set basic functionality in=20
> innovation. If it helps,
> I could look more into code and try to solve it in case you don't have=20
> time. But it
> would take me at least one week.
I will work toward working on that again (I recently upgraded my laptop
to Mandrake 9.0, and neither I3D or WF want to build on it, need to get
them going first).=20

>     To someone who was talking about game concept. It personally recommen=
d
> to make some small game concept and finish it (10-20) rooms to see what a=
re
> we missing and what is buggy and what isn't.

I completely agree. At this point even a 3-4 room level using all Linux
tools would be a step in the right direction.=20


> >Sorry it isn't more clear, the code base has been through a lot, in some
> >places it is better than others. (and there is quite a bit of code to
> >solve problems than no longer exist, like dealing with very limited
> >memory on the Playstation).
> >
>     That's fine I like such code, a lot of assertion sounds good to me.=20

A lot of assertions is awesome. The engine almost never crashes, I
attribute much of this to the assertions noticing problems early on. I
recently ran BoundsChecker on WF for the first time, no out of bound
references at all.=20

The goal is to have every function validate all inputs, validate all
outputs, and in the case of member functions, to validate the state of
the class on entry and exit. Unfortunately, since there have been many
contributors to this code base it doesn't always happen.

I recently learned that what I do is called design by contract, see my
programming page:
http://tenetti.org/phpwiki/index.php/KevinSeghettiProgramming for links
to DBC sites.

Another goal was to break functionality down into smaller manageable
pieces, which is why there are so many directories under source. In most
cases each directory/.library can be built and tested in isolation (in
layers, the gfx library uses the math library, for example). To test a
particular library, cd to that directory and do 'make test'. The math
library is a good example of what I want all of them to have, a decent
test suite. Whenever a bug is found first I update the test code to
reveal the bug, then I work on the code until the bug goes away. This
way if the bug comes back later I will notice (it also makes it easy to
test when porting to a new OS, I did the initial Linux port in about a
week (only because we were already using OpenGL)).

> And personally
> I would still solve memory problems as well, then we could port it=20
> anywhere or
> make it work anywhere (even on slower hardware and so). We just need to=20
> document
> it in Programmers Documentation more properly and divide it some way=20
> then (don't
> know how, I have never been doing code for more than one OS at time).

I have done a lot of that, and think I am getting pretty good at it :-)
What we tried to do in WorldFoundry was to provide low level libraries
which abstracted the OS and the hardware, so that the main game code
doesn't know what platform it runs on. Then where it can't be helped we
use #if defined(__LINUX__) (and other platform names) to switch the
code. Doesn't happen much, if you search wfsource/source/game (where the
main game code is), there are only a few references to linux. (looking
at the ones that are there, they just need to be moved elsewhere).=20
The math library is a good example of this, most of the code is
portable, but where we need to do assembly there are separate
sub-directories for each OS. (although one thing it is missing is a
software version of the low level calls which could be used to validate
the assembly implementation).

>     Anyway I will look at code and try to start to work on Documentation=20
> which
> could help us in future to make an extension to it.
Great, that is why the World Foundry site is on a wiki, so that everyone
can contribute.=20

Do you have a sourceforge account? If you get one and tell me your
username I will make you a member of the WorldFoundry project, then you
can check in source code changes.

>     maybe it would be cool to know more about assertion (for example=20
> what is tested). I've seen
> ranges and pointers, but what else?

I try to test everything. :-)
It depends on the circumstance, I try to verify everything early and
often, on the theory that the closer to the bug the assertion is, the
easier it is to find the bug, so I try to validate everything I can.
Inconsistent state would be another one I check for.

If you mean what macros are defined, see wfsource/source/pigsys/assert.h=20
(near the bottom is a short list (the null versions for release build).

RangeCheck and ValidPtr are the most useful (actually, AssertMsg is the
most useful and is used everywhere). I don't think ValidateObject is
used (we just call the class Validate function directly). What I really
want is to have a way to automatically print the values of every
variable in the assertion expression when the assertion fails (that is
why I have RangeCheck, etc so that at least in those common cases the
printing is automated. I tried having an AssertEq which took 2
parameters and asserted they were equal, but it didn't catch on.

BTW, you and anyone else who is contributing) might want to add your
email address to
http://worldfoundry.org/wfwiki/index.php/EmailNotification so that you
will be notified when wiki updates occur.

--=20
Kevin Seghetti: E-Mail: kt...@te..., HTTP: www.tenetti.org
GPG public key: http://tenetti.org/phpwiki/index.php/KevinSeghettiGPGKey
Check out www.worldfoundry.org for my GPL'ed 3D video game engine

Re: [Wf-gdk-wfcode] Streaming geometry

[Kevin S. <kt...@te...>]

On Fri, 2002-10-25 at 10:13, nl...@nl... wrote:
> On Fri, Oct 25, 2002 at 08:25:33AM -0700, Kevin Seghetti wrote:
> > Mesh, animations, sounds, textures are all assets, and get loaded per
> > room (except for those which are flagged as permanent, the designer can
> > flag objects as permanent, anything which can move from room to room
> > needs this, like the superhero (otherwise it would loose its textures
> > when the room it started in was unloaded).
>=20
> However an object moving from room1 to room2 could have its assets
> "attached" to the room it is currently in, so if for instance a moving
> enemy moves into room1 and the player moves out of room1 far away
> such that room1 gets unloaded, all of the enemy's assets could get
> unloaded as well.

The current assets per room are pre-bundled into single chunks of data.
When the asset system loads a room it is a single binary load, which it
then parses into the various assets (pointing back into the binary
chunk). When a room is unloaded it is freed with a single free (actually
I don't think we use the memory manager at all at that point, all room
asset storage slots are the same size and they just load over each
other). So the current system can't keep some of the assets from a room
that is going away (and even if it could it would lead to memory
fragmentation). To avoid this we made another slot called Permanent
which contains assets which are needed level-wide (it is OK for the same
asset to get used in many rooms without being permanent, it will just
get repeated in each of them).=20
So something like what you are proposing is possible, but not under the
current system.
=20
> I am speaking in general terms here - basically trying to define a system
> (or adapt the WF model) such that arbitrary rooms or objects can announce
> their presence and get loaded/rendered correctly.
>=20
> > > I was thinking more along the lines of simultaneous cooperative
> > > exploration of networked 3D spaces, not necessarily a real-time 3D
> > > gaming experience. In other words more like a 3D MUD.
> >=20
> > That would require quite a bit more than just streaming rooms on the
> > fly, if there is more than one person in the same room they ought to be
> > able to see each other and interact, which goes back to network gaming.=
=20
>=20
> Exactly, which is why I wrote so much on this topic on the wiki ;-)
>=20
> I recently found the cube engine (http://wouter.fov120.com/cube/) which
> is an open source (zlib license) networked deathmatch quake-style engine
> for Linux and Windows. Very minimal game state, but functioning networkin=
g
> code.
>=20
> As another thought, how feasible would it be to impose a client/server
> networked positioning sytem to WF? In other words, ALL
> objects which can move in a level get their positions from the server.
> The server saves all game state (mailboxes, scripts, etc), and merely
> transmits positions/orientations/animation-frame-number of all objects
> (statplats, enemies, particles, player) to all clients. This would requir=
e
> massive bandwidth, but is it feasible for WF or would this mean a total
> rewrite?
I think it could be done, the physics and rendering are pretty well
separated now, so it would mean having the engine build 2 ways: client
and server. The server's rendering function would copy the game state
into a download buffer, and the client would download the world state as
fast as it could and render it. The server would need to run all rooms
all of the time, but I think that is just a matter of changing the
execute loop. So I would say it is a medium sized project, probably take
a bit longer than switching to the new physics is going to take).

--=20
Kevin Seghetti: E-Mail: kt...@te..., HTTP: www.tenetti.org
GPG public key: http://tenetti.org/phpwiki/index.php/KevinSeghettiGPGKey
Check out www.worldfoundry.org for my GPL'ed 3D video game engine

Re: [Wf-gdk-wfcode] Streaming geometry

[<nl...@nl...>]

On Fri, Oct 25, 2002 at 08:25:33AM -0700, Kevin Seghetti wrote:
> Mesh, animations, sounds, textures are all assets, and get loaded per
> room (except for those which are flagged as permanent, the designer can
> flag objects as permanent, anything which can move from room to room
> needs this, like the superhero (otherwise it would loose its textures
> when the room it started in was unloaded).

However an object moving from room1 to room2 could have its assets
"attached" to the room it is currently in, so if for instance a moving
enemy moves into room1 and the player moves out of room1 far away
such that room1 gets unloaded, all of the enemy's assets could get
unloaded as well.

I am speaking in general terms here - basically trying to define a system
(or adapt the WF model) such that arbitrary rooms or objects can announce
their presence and get loaded/rendered correctly.

> > I was thinking more along the lines of simultaneous cooperative
> > exploration of networked 3D spaces, not necessarily a real-time 3D
> > gaming experience. In other words more like a 3D MUD.
> 
> That would require quite a bit more than just streaming rooms on the
> fly, if there is more than one person in the same room they ought to be
> able to see each other and interact, which goes back to network gaming. 

Exactly, which is why I wrote so much on this topic on the wiki ;-)

I recently found the cube engine (http://wouter.fov120.com/cube/) which
is an open source (zlib license) networked deathmatch quake-style engine
for Linux and Windows. Very minimal game state, but functioning networking
code.

As another thought, how feasible would it be to impose a client/server
networked positioning sytem to WF? In other words, ALL
objects which can move in a level get their positions from the server.
The server saves all game state (mailboxes, scripts, etc), and merely
transmits positions/orientations/animation-frame-number of all objects
(statplats, enemies, particles, player) to all clients. This would require
massive bandwidth, but is it feasible for WF or would this mean a total
rewrite? Again this is in the context of VR, not necessarily twitch-style
gaming, so a bit of latency is OK.

There is a system VOS at http://interreality.org which aims to be a
networked VR platform using portals for loading new worlds as the user
passes from one area into another. It seems to have a lot of promise.

But your earlier comment about "everyone wanting to go in a different
direction" with WF is right - these are just some speculations about
possible long-term future uses.

-Norman

Re: [Wf-gdk-wfcode] Streaming geometry

[Kevin S. <kt...@te...>]

On Fri, 2002-10-25 at 09:15, nl...@nl... wrote:
> On Fri, Oct 25, 2002 at 07:08:12AM -0700, Kevin Seghetti wrote:
> > On Tue, 2002-10-22 at 13:18, nl...@nl... wrote:
> > > What sort of data does World Foundry stream from CD-ROM?
> > >=20
> > > I am thinking about Internet streaming of data where a level is truly
> > > loaded incrementally. I think WF loads some global level stuff first,=
 and
> > > only limited data (e.g. textures) are streamed.=20
> >=20
> > That is correct, only assets are demand loaded.
>=20
> What does "assets" include - models and animations as well? If an object
> with an animation is located in room 10, does the object's mesh and
> animation get loaded at level start, or when I pass into that room?

Mesh, animations, sounds, textures are all assets, and get loaded per
room (except for those which are flagged as permanent, the designer can
flag objects as permanent, anything which can move from room to room
needs this, like the superhero (otherwise it would loose its textures
when the room it started in was unloaded). Put another way, the entire
.lvl file is loaded at level load time, as are all of the "permanent"
assets, the rest of them per room. Build the superhero level and look at
wfsource/assets/linux/superhero/superhero.iff.txt you will see what is
loaded into each room ('PERM' are the permanent assets, 'RM0' is the
assets for room 0, etc.) The ASMP chunk is the asset map, it makes
filenames to asset IDs (eventually this was supposed to happen at level
construction time), and 'TOC' is a Table of contents, just contains
offsets in the file to the other chunks so that the engine doesn't have
to parse the entire file to find a room (same thing occurs one level up
in cd.iff.txt).
=20
> I was thinking more along the lines of simultaneous cooperative
> exploration of networked 3D spaces, not necessarily a real-time 3D
> gaming experience. In other words more like a 3D MUD.

That would require quite a bit more than just streaming rooms on the
fly, if there is more than one person in the same room they ought to be
able to see each other and interact, which goes back to network gaming.=20

--=20
Kevin Seghetti: E-Mail: kt...@te..., HTTP: www.tenetti.org
GPG public key: http://tenetti.org/phpwiki/index.php/KevinSeghettiGPGKey
Check out www.worldfoundry.org for my GPL'ed 3D video game engine

Re: [Wf-gdk-wfcode] Streaming geometry

[<nl...@nl...>]

On Fri, Oct 25, 2002 at 07:08:12AM -0700, Kevin Seghetti wrote:
> On Tue, 2002-10-22 at 13:18, nl...@nl... wrote:
> > What sort of data does World Foundry stream from CD-ROM?
> > 
> > I am thinking about Internet streaming of data where a level is truly
> > loaded incrementally. I think WF loads some global level stuff first, and
> > only limited data (e.g. textures) are streamed. 
> 
> That is correct, only assets are demand loaded.

What does "assets" include - models and animations as well? If an object
with an animation is located in room 10, does the object's mesh and
animation get loaded at level start, or when I pass into that room?

> I don't think streaming rooms over the internet at run time would make
> for a very pleasant gaming experience, however. I would much prefer to
> wait beforehand while a level downloads then have my gaming experience
> interrupted during play due to net congestion. I think background
> downloading of the NEXT level while playing the current one would be a
> better way to accomplish the same thing.

I was thinking more along the lines of simultaneous cooperative
exploration of networked 3D spaces, not necessarily a real-time 3D
gaming experience. In other words more like a 3D MUD.
 
-Norman

Re: [Wf-gdk-wfcode] Streaming geometry

[Kevin S. <kt...@te...>]

On Tue, 2002-10-22 at 13:18, nl...@nl... wrote:
> What sort of data does World Foundry stream from CD-ROM?
>=20
> I am thinking about Internet streaming of data where a level is truly
> loaded incrementally. I think WF loads some global level stuff first, and
> only limited data (e.g. textures) are streamed.=20

That is correct, only assets are demand loaded.

>What would be interesting
> is to rewrite the streaming so that no global level data is loaded,
> and so that the entire world is dynamically streamed. In other words,
> you pass into the next room, and the level, knowing nothing about the
> next room, loads the next room's geometry, textures, objects, etc.
> (Actually the room would be loaded as soon as you pass into the room
> before it, since the engine always has 3 rooms in memory at once.)
>=20
> Is this already possible? If not, is it a difficult change? Again, the
> goal is to be able to load the next room via the Internet (or other
> stream), with absolutely zero a priori knowledge of what that room might
> contain.=20

The problem (and the reason it doesn't already work this way) is that we
want rooms to maintain state if we leave and come back (if you move some
objects around in room 1, then go to room 4 and back to room 1 they
should still be where you moved them).=20

It would probably be moderate work to break out more of the
initialization of the level so it could occur at room load time. One big
difference would be under the current implementation the engine can run
the room without the assets loaded, just can't render it. (since the
object itself always exists, just doesn't know how it looks, sounds, and
animates).=20

I don't think streaming rooms over the internet at run time would make
for a very pleasant gaming experience, however. I would much prefer to
wait beforehand while a level downloads then have my gaming experience
interrupted during play due to net congestion. I think background
downloading of the NEXT level while playing the current one would be a
better way to accomplish the same thing.

I am starting to think that WF's biggest problem is it's flexibility,
everyone wants to go in a different direction with it. What it needs is
for someone to make some levels which show off what it was designed for
and can already do: a 3D version of Super Mario World (that was the
short version of the design criteria). (note: NOT Mario 64, which is a
very different way to go, small reusable world instead of long linear
world).
I would like to see someone design some levels which require running,
jumping, timing, avoiding baddies, solving simple puzzles, with power
ups and special abilities. Heck, ripping off ideas from Super Mario
World would be a great place to start (SMW is the only one of the Mario
series I played to near the end (although I did get 70 stars in M64)).

Hmm, guess I should make a game ideas section in the wiki.

--=20
Kevin Seghetti: E-Mail: kt...@te..., HTTP: www.tenetti.org
GPG public key: http://tenetti.org/phpwiki/index.php/KevinSeghettiGPGKey
Check out www.worldfoundry.org for my GPL'ed 3D video game engine

Re: [Wf-gdk-wfcode] Ideas for next steps....

[Samo K. <sa...@xy...>]

Karel Rous wrote:
> Kevin Seghetti wrote --- napísal::
> 
>> Do you think I should work on the I3D geometry exporter, or should we
>> move on to Blender? 

I don't know how difficult it would be to write built-in xport code 
for Blender, but as soon as the bring out a stable build to play with 
(without having to figure out why the makefiles wont work) it would 
certainly be worth a look - it has character animation tools which 
would mean one could do both - levels and ingame characters.

>    To someone who was talking about game concept. It personally recommend
> to make some small game concept and finish it (10-20) rooms to see what are
> we missing and what is buggy and what isn't. 

My idea was a simple 1-on-1 fighting game (think virtua fighter or 
tekken). One level, two characters, some effects, interface, input, 
sound and physics (can these be connected to the IK-bones, so if I 
"hit" the chest only the chest gets partially "thrown back"?). Two 
characters and a level (not big) plus some ingame art should be 
reasonable for me to handle and we get the result fast enough as to 
not get de-motivated because it takes too long. And it also has much 
of what all games need so it could be interesting for the coders...

If we get a lot of positive response on it, we can still make it 
bigger :o)

have a nice day,
Samo

[Wf-gdk-wfcode] Re: Streaming geometry

[Karel R. <kar...@vo...>]

Good point. Anyway in my opinion we would need something more than just
geometry later. So it would need to divide it into global part of AI and
the local one. I would suggest to solve at first the problems which are
breaking the possibility to finish any game. For example camera
movements which are irrational from time to time. Or I still can't
understand that when the camera is in my eyes I could see trough
objects... Streaming or global AI would be the next extension. But if we
aren't able to show it works sufficiently there won't be much interest.

Karel

[Wf-gdk-wfcode] Ideas for next steps....

[Karel R. <kar...@vo...>]

Kevin Seghetti wrote --- nap=EDsal::

>The geometry exporter was the last thing I wrote, and I wasn't finished
>with it (and certainly hadn't tested it much), so it is quite likely
>that it doesn't export the textures properly.
>
>I haven't been working on World Foundry lately, looks like I need to get
>back into it.
>=20
>Do you think I should work on the I3D geometry exporter, or should we
>move on to Blender?
>
    My personal opinion is also to set basic functionality in=20
innovation. If it helps,
I could look more into code and try to solve it in case you don't have=20
time. But it
would take me at least one week.
    To someone who was talking about game concept. It personally recommen=
d
to make some small game concept and finish it (10-20) rooms to see what a=
re
we missing and what is buggy and what isn't.

>>Unfortunately the code is of course too difficult to be understanadable=
=20
>>at once. So the only thing I can tell you is, that inside cd.iff is tha=
t=20
>>TGA in some way as well, but after running the level (nearly the same a=
s=20
>>the test, only one pratform and texture is added), it doesn't work and=20
>>the output is following.... It has probably something in common with=20
>>asset slot and Load Texture, but I am not quite sure about the internal=
s=20
>>to tell from such debugging info and stepping through code without=20
>>bigger knowledge of it.
>>
>>   =20
>>
>Sorry it isn't more clear, the code base has been through a lot, in some
>places it is better than others. (and there is quite a bit of code to
>solve problems than no longer exist, like dealing with very limited
>memory on the Playstation).
>
    That's fine I like such code, a lot of assertion sounds good to me.=20
And personally
I would still solve memory problems as well, then we could port it=20
anywhere or
make it work anywhere (even on slower hardware and so). We just need to=20
document
it in Programmers Documentation more properly and divide it some way=20
then (don't
know how, I have never been doing code for more than one OS at time).
    Anyway I will look at code and try to start to work on Documentation=20
which
could help us in future to make an extension to it.

>>+- ASSERTION MESSAGE --------------------------------------------------=
-------+
>>AssertMsg:Asset Type: 1; Room: 0; Index: 1 not found, map contains:
>>AssetMap:
>>Type: 1; Room: 0; Index: 4094, memory =3D (nil), size =3D 0
>>Type: 1; Room: 0; Index: 4095, memory =3D (nil), size =3D 0
>>Type: 5; Room: 0; Index: 4095, memory =3D 0x406b250c, size =3D 60
>>Type: 7; Room: 0; Index: 4095, memory =3D 0x406b2548, size =3D 12
>>
>>+- ASSERTION FAILED ---------------------------------------------------=
-------+
>>|0                                                                     =
       |
>>|in file "assslot.hpi" on line 102                                     =
       |
>>+----------------------------------------------------------------------=
-------+
>>sys_exit: game quit
>>sys_exit(-1) called
>>Calling sys_call_atexit function
>>sys_call_atexit function called, num_atFuns =3D 0
>>calling exit with return code of -1
>>   =20
>>
>Wow, I haven't seen that assertion in a while. It is most likely the
>geometry exporter just isn't working right. What this basically says is
>that a request was made for an asset which doesn't exist. Most likely
>there is an asset index in the model which is invalid.
>
> =20
>
    maybe it would be cool to know more about assertion (for example=20
what is tested). I've seen
ranges and pointers, but what else?

> =20
>

Re: [Wf-gdk-wfcode] still problem with TGA texture

[<nl...@nl...>]

On Thu, Oct 24, 2002 at 04:05:23PM -0700, Kevin Seghetti wrote:
> On Thu, 2002-10-24 at 07:05, Karel Rous wrote:
> Do you think I should work on the I3D geometry exporter, or should we
> move on to Blender?

For now my suggestion is to continue work on I3D. My feeling is that the I3D
exporter is almost finished, and that it is less work in the short term to
get the I3D work in a usable state.

As for Blender, I'd estimate 2 months before a stable build will emerge.
The build process is kind of shaky right now, as is the Python scripting
API. It is not yet clear exactly how extensibility in Blender should be
handled in the future (it already has 2 incompatible Python API's, both
somewhat incomplete, and there is talk of a new plugin system), and this
will take a bit of time to settle down. In 2 months, I expect the GPL
version of Blender to be stable and with the same functionality as the
last official release of Blender (2.25). At that point, even with any
quirks or warts, Blender should build smoothly and the Python API should be
back to the same functional level it was in Blender 2.25, which would
enable writing the necessary export functions as a Blender Python script.

-Norman

Re: [Wf-gdk-wfcode] still problem with TGA texture

[Kevin S. <kt...@te...>]

On Thu, 2002-10-24 at 07:05, Karel Rous wrote:
> I was looking through the code to find out, why the TGA texture added to=20
> one platform doesn't work on linux after building from Innovation 3d.=20
The geometry exporter was the last thing I wrote, and I wasn't finished
with it (and certainly hadn't tested it much), so it is quite likely
that it doesn't export the textures properly.

I haven't been working on World Foundry lately, looks like I need to get
back into it.
=20
Do you think I should work on the I3D geometry exporter, or should we
move on to Blender?

> Unfortunately the code is of course too difficult to be understanadable=20
> at once. So the only thing I can tell you is, that inside cd.iff is that=20
> TGA in some way as well, but after running the level (nearly the same as=20
> the test, only one pratform and texture is added), it doesn't work and=20
> the output is following.... It has probably something in common with=20
> asset slot and Load Texture, but I am not quite sure about the internals=20
> to tell from such debugging info and stepping through code without=20
> bigger knowledge of it.
>=20
Sorry it isn't more clear, the code base has been through a lot, in some
places it is better than others. (and there is quite a bit of code to
solve problems than no longer exist, like dealing with very limited
memory on the Playstation).

> lookup up asset stream for asset id Type: 1; Room: 0; Index: 1
> +- ASSERTION MESSAGE ----------------------------------------------------=
-----+
> AssertMsg:Asset Type: 1; Room: 0; Index: 1 not found, map contains:
> AssetMap:
> Type: 1; Room: 0; Index: 4094, memory =3D (nil), size =3D 0
> Type: 1; Room: 0; Index: 4095, memory =3D (nil), size =3D 0
> Type: 5; Room: 0; Index: 4095, memory =3D 0x406b250c, size =3D 60
> Type: 7; Room: 0; Index: 4095, memory =3D 0x406b2548, size =3D 12
>=20
> +- ASSERTION FAILED -----------------------------------------------------=
-----+
> |0                                                                       =
     |
> |in file "assslot.hpi" on line 102                                       =
     |
> +------------------------------------------------------------------------=
-----+
> sys_exit: game quit
> sys_exit(-1) called
> Calling sys_call_atexit function
> sys_call_atexit function called, num_atFuns =3D 0
> calling exit with return code of -1
Wow, I haven't seen that assertion in a while. It is most likely the
geometry exporter just isn't working right. What this basically says is
that a request was made for an asset which doesn't exist. Most likely
there is an asset index in the model which is invalid.

(ignore the rest of this, there is a known problem with failing to exit
properly)
> ValidPtr( (nil) ) failed
> ValidPtr( (nil) ) failed
> +- ASSERTION FAILED -----------------------------------------------------=
-----+
> |ValidPtr(_oadData)                                                      =
     |
> |in file "actor.hpi" on line 117                                         =
     |
> +------------------------------------------------------------------------=
-----+
> sys_exit: game quit
> sys_exit(-1) called
> sys_exit called recursively, retcode =3D -1, calling exit directly.
>=20

--=20
Kevin Seghetti: E-Mail: kt...@te..., HTTP: www.tenetti.org
GPG public key: http://tenetti.org/phpwiki/index.php/KevinSeghettiGPGKey
Check out www.worldfoundry.org for my GPL'ed 3D video game engine

[Wf-gdk-wfcode] still problem with TGA texture

[Karel R. <kar...@vo...>]

I was looking through the code to find out, why the TGA texture added to 
one platform doesn't work on linux after building from Innovation 3d. 
Unfortunately the code is of course too difficult to be understanadable 
at once. So the only thing I can tell you is, that inside cd.iff is that 
TGA in some way as well, but after running the level (nearly the same as 
the test, only one pratform and texture is added), it doesn't work and 
the output is following.... It has probably something in common with 
asset slot and Load Texture, but I am not quite sure about the internals 
to tell from such debugging info and stepping through code without 
bigger knowledge of it.

DEBUG = 1,
DO_ASSERTIONS = 1, NO_ASSERT_EXPR = 0, USE_INLINE_DEFS = 1, WF_BIG_ENDIAN = 0
pigsys_version = "pigsys.h: v1.0.6d3"
argc = 1, argv: ../../source/objdebugglsoftwarexss.linux/game/game 
cbHalLmalloc = 3500000, cbHalScratchLmalloc = 180000
WorldFoundryEngine v0.4.1, Built:Oct 22 2002,13:12:12 by kts
argc = 1, commandIndex = 1
Level=-1
cerror:
cwarn:
cstats:
WorldFoundryEngine Ver 0.4.1, Built:Oct 22 2002,13:12:12 by kts
DBSTREAMS Opening cd.iff
LMalloc of 353 not long word aligned
LMalloc of 1 not long word aligned
Level::Level: leveldata= 0x4078e0a4, object count  = 17
101 mailboxes specified in levelobj object
15 scratch mailboxes specified in levelobj object
ASS closed without all data read (bytesLeft = 4118)
ASS closed without all data read (bytesLeft = 150)
ASS closed without all data read (bytesLeft = 16)
ASS closed without all data read (bytesLeft = 16)
PixelMap::Load: this = 0x4063cd54
PixelMap::Load: this = 0x4063cd74
DMalloc of 414 not long word aligned
DMalloc of 426 not long word aligned
DMalloc of 426 not long word aligned
DMalloc of 402 not long word aligned
Walking from 0
0->0
0->0
ASS closed without all data read (bytesLeft = 4118)
ASS closed without all data read (bytesLeft = 8214)
ASS closed without all data read (bytesLeft = 64)
ASS closed without all data read (bytesLeft = 16)
PixelMap::Load: this = 0x4063cd94
PixelMap::Load: this = 0x4063cdb4
lookup up asset stream for asset id Type: 1; Room: 0; Index: 1
+- ASSERTION MESSAGE ---------------------------------------------------------+
AssertMsg:Asset Type: 1; Room: 0; Index: 1 not found, map contains:
AssetMap:
Type: 1; Room: 0; Index: 4094, memory = (nil), size = 0
Type: 1; Room: 0; Index: 4095, memory = (nil), size = 0
Type: 5; Room: 0; Index: 4095, memory = 0x406b250c, size = 60
Type: 7; Room: 0; Index: 4095, memory = 0x406b2548, size = 12

+- ASSERTION FAILED ----------------------------------------------------------+
|0                                                                            |
|in file "assslot.hpi" on line 102                                            |
+-----------------------------------------------------------------------------+
sys_exit: game quit
sys_exit(-1) called
Calling sys_call_atexit function
sys_call_atexit function called, num_atFuns = 0
calling exit with return code of -1
ValidPtr( (nil) ) failed
ValidPtr( (nil) ) failed
+- ASSERTION FAILED ----------------------------------------------------------+
|ValidPtr(_oadData)                                                           |
|in file "actor.hpi" on line 117                                              |
+-----------------------------------------------------------------------------+
sys_exit: game quit
sys_exit(-1) called
sys_exit called recursively, retcode = -1, calling exit directly.

[Wf-gdk-wfcode] Re: Linux cd.iff

[Karel R. <kar...@vo...>]

well it works some way, but I was talking mainly about the I3D export
which behaves strangely time to time. We will see as soon as I get time
to look at the code, today I am not able to tell what is the real problem.

Karel

Re: [Wf-gdk-wfcode] Linux:problem with TGA or any other texture mesh through atrribedit...

[Karel R. <kar...@vo...>]

Kevin Seghetti wrote --- nap=EDsal::

    Well, sorry I forgot to mention when there is a TGA texture on mash,=20
then it doesn't work. That
is the feature I am talking about. Anyway the distribution I am using is=20
Debian ustable..... I really
don't understand why it doesn't work, but as soon as I have to I'll look=20
at it more precisely...

>On Tue, 2002-10-22 at 06:53, Karel Rous wrote:
> =20
>
>>on Linux, cd.iff is created, but after that the level doesn't work. Was=
=20
>>this feature tested or not?
>>   =20
>>
>
>Yes, I commonly run cd.iff built on linux. However, there is a problem
>with iffcomp, if it encounters an error and aborts it leaves the output
>file in a broken state. Subsequent builds will then be broken. To be
>sure delete the entire fwssource/assets/linux directory and build again.
>Just curious, which Linux distribution are you running?
>
> =20
>