Re: new here, my lang project...

From: cr88192 (cr88192_at_NOSPAM.hotmail.com)
Date: 01/29/05 

Date: Sat, 29 Jan 2005 06:56:13 GMT

"H. S. Lahman" <h.lahman@verizon.net> wrote in message
news:3ZwKd.135$g_3.76@trndny08...
> Responding to Cr88192...
>
>>>>>What sorts of tools and what are they generating? (I had the
>>>>>impression you were manually coding C.)
>>>>>
>>>>
>>>>well, primarily modellers (milkshape, ac3d, ...) and programs like quark
>>>>(which do mapping). these tools were generally designed for quake-style
>>>>games (quake 1/2/3, half-life, ...).
>>>
>>>Never heard of them. What sort of models? [I assume you aren't doing
>>>UML models. B-)] I gather these are sort of home-grown modding tools of
>>>some sort?
>>>
>>
>> nope, these do 3d models specific to the game...
>> quark is fairly popular as a multi-game mapper.
>
> Are these pure graphics models (e.g., the equivalent of a GUI builder for
> a graphics pane)? Or are they for the physics of resolving movement,
> extent, etc.
>
both.

the models consist of entities, which are bags of key/value pairs that can
also have geometry attached to them.
the geometry consists of "brushes", which are defined in terms of
intersecting sets of planes (that can also have textures applied to them and
such).

the names, properties, keys, ... of the entity are generally constrained,
and variations lead to inconsistencies with the parent games and with the
editor. I try to keep these inconsistencies low.

>>>>>>nope, quake was single-threaded all the way.
>>>>>>
>>>>>>the main power is a big main loop, that cycles through and calls all
>>>>>>the related subsystems to cause them to do whatever, and the loop
>>>>>>repeats.
>>>>>>
>>>>>>the main power of things is keeping the loop cycling fast (>30Hz is
>>>>>>good,
>>>>>>
>>>>>>>50 is better, ...). 10 or 20Hz, however, is not so good, the game
>>>>>>>lags
>>>>>>
>>>>>>and things start getting jittery.
>>>>>
>>>>>That only works for primitive graphics, a dumb AI, and an RTS format
>>>>>where one doesn't wait for the player. <snip threading issues
>>>>>discussion>
>>>>>
>>>>
>>>>well, but all this is not how the games are done.
>>>
>>>You meant, "... how these games are done", right? I can't imagine the
>>>newer action/shooter games being single threaded.
>>>
>>
>> dunno, but somehow I suspect they are.
>>
>> really, on current pc's what real incentive is there to be
>> multithreaded?...
>> now, I can't really be certsin about games newer than quake2, but somehow
>> I doubt things have changed thst much since then.
>
> The problem is that the OS and low level graphics services (e.g., DirectX)
> are gobbling up an ever increasing fraction of the clock cycles. So when
> you go from 500 MHz to 1 GHz you can actually get a reduction in
> performance when the software is upgraded in lockstep. Note that most of
> today's games would run in slow motion (if they could run at all) on a 200
> MHz PC, which was state of the art not too long ago.
>
nope, not slow motion, rather the game will continue in realtime but only
redraw once in a great while and be quite difficult to control.
one can run quake2 on a 486DX and observe this effect. most newer games are
hw-accel only, and thus can't be run on anything without hw accell.

however, these will not run on a 386, as the 386 lacked a fpu which is
required for quake 1/2. a 386+387 could concievably run quake2, albeit with
terrible performance (quake was bad even on early pentiums, one needed at
least a 133 or 166 pentium to run quake well, pentium 90's ran it poorly,
and a 486DX was worse, but still playable...).

> This is a Catch-22 that has plagued the industry for decades. I can
> remember IBM forcing their 360 mainframe IT users to upgrade their OS/360.
> When they did it would turn out they couldn't get their year-end closing
> of the books done in time without also upgrading the mainframe as well. A
> few years ago Djikstra did a piece on software bloat and inefficiency in
> an IEEE/ACM rag. The designers of X-Windows said that they had designed
> it for a machine that didn't exist yet (and probably still doesn't!). It
> goes on and on; code bloat and inefficiency are epidemic in today's
> software.
>
yes, true, but the net result is not that bad really, apart for the need for
ever faster computers...

> [I can recall running a Visicalc spread*** on an Apple II with 256 K of
> memory and a clock that was measured in KHz. That spread*** ran just as
> fast as the same content today in Excel on a 3 GHz machine with 3 Mb of
> memory. But Excel wouldn't even be able to load on an Apple II's
> resources and, if it could, one could have children in the time it would
> have taken to calculate the subtotals.]
>
yes.

> For the past couple of decades developers have been lulled by Moore's Law
> into believing that performance doesn't matter because by the time the
> product is ready there will be a machine around fast enough to run it.
> The problem is that everyone has the same attitude so all the
> applications, including OS and other services, are pigs.
>
moore's law is levelling off now for the time being.

still, I am not that compelled to go multithreaded, as current cpu's
wouldn't be able to make much use of it anyways. this will change if and
when cpus specialized in multithreading start getting more popular.

> <soapbox>
> Today we deal with interoperability by converting everything to ASCII,
> shipping it, and converting it back to something computable when it gets
> there. That is a horrendous performance penalty to pay for
> interoperability. Worse, it has crept into everything in the service
> infrastructures so one is saddled with the overhead even if one's
> application doesn't need interoperability. And it is all because the
> hardware vendors can't agree on a standard for endian or where the lsb
> goes after seven decades of building hardware!
>
this is just one issue.

in general it is easier to come up with general purpose textual formats than
binary ones, and people are a little more able to agree on textual ones as
well.

> Similarly, we have interoperability infrastructures that allow us to pass
> objects around routinely. That's very convenient for lazy developers and
> looks really good in demos when there is mainframe power in the hardware
> behind the scenes. But compared to a pure data transfer interface the
> overhead is orders of magnitude greater and it can be even more verbose in
> total when one includes stuff like peripheral IDL to define things. (The
> commercial infrastructures hide the IDL, but in doing so they lock you
> into the overhead of remote objects.) Worse yet, it is very poor OOA/D
> practice because it trashes cohesion and encapsulation.
> </soapbox>
>
it can be nice and convinient, but yes, it is slow, and it can make
interoperability a major pita.

>>
>>
>>>>>>I don't really get it, however:
>>>>>>my inheritence model is also outside the app code.
>>>>>>
>>>>>>it is basically just files and directories in the resources directory
>>>>>>which define "classes", which serve to specify the search path for
>>>>>>resources, specify scoping for the scripts, ...
>>>>>>
>>>>>>all this is dynamic, eg, no compiled code involved, and even fairly
>>>>>>minor impact on the scripting. "classes as an abstraction for data"
>>>>>>really. the masses of game resources are becomming large and difficult
>>>>>>to manage or navigate, possibly eventually serving as an impediment to
>>>>>>modders or such...
>>>>>
>>>>>OK, then I am thoroughly confused about what you were doing. B-) I
>>>>>thought you were updating a Quake engine that was written in C.
>>>>>
>>>>
>>>>
>>>>no, I have had experience working with the quake engine.
>>>>
>>>>I have just written my own engine, which has mysteriously ended up
>>>>looking a lot like quake, but is otherwise clean source and internally
>>>>works somewhat different in many ways...
>>>
>>>What I am asking about is how there can be no compiled code. I thought
>>>the engine you were working on was in C.
>>>
>>>You will also have to put some more words around the notion of an
>>>inheritance model outside the app code in terms of files and directories.
>>>
>>
>> I am not getting what you are akking (possibly due to beers count).
>> but, anyways, are you fammilair with bytecode?...
>
> Yes; basically an intermediate code between 3GLs and Assembly often used
> by interpreter run time engines. (It was pioneered in R-T/E for things
> like DSP, usually burned into ROM.) Also used as a common output for
> multiple 3GLs so that one can apply back-end optimization one way for all
> the languages. Also used for portability by substituting the run time
> engine for local environments, as in Java.
>
> But one doesn't write bytecodes directly; they are compiled from the 3GL
> code that the developer creates by the compiler's lexical analysis and
> preprocessor functions. (The difference between a compiler and
> interpreter in the bytecode context is simply whether the bytecodes are
> subsequently interpreted or converted directly to machine language at run
> time; the 3GL code is still compiled to produce the bytecodes in both
> cases.) So I still don't no what you mean by "no compiled code". Are you
> saying you produce bytecodes directly?
>

yes.
a good portion of my code is dynamically loaded, bytecode compiled, and is
then interpreted at runtime.

the rest is plain c, and often consists a lot of infrastructure and such.

>> in the case of the second part, it is a combination of an abstraction,
>> and some amount of code to do something along those lines.
>
> Alas, not a lot of information content here. B-) I still don't see the
> connection between OO inheritance and a file system directory structure,
> other than they are both represented by trees.
>
well, with the use of files, one can build a class-based inheritence tree on
top of the filesystem, effectively inheriting files and code from other
directories into a kind of conceptual "this" directory.

one can also have links between the code and data as well (data can invoke
functions, and code can use data).
similarly, the directory-inheritence system can create objects that match
the inheritence graph and load code into them based on commands given in
files and such.

all the code here is, however, necissarily interpreted, or at least rather
dynamically compiled.

imo, I view it as "data oriented coding", others have called the idea
"ramming code down data's throat", but whatever really...

>>>>><snip answers to my questions>
>>>
>>>>>What do you mean by 'physics engine'? Can you provide a couple of
>>>>>sentences to describe what you think the subject matter and
>>>>>responsibilities are? (I have my own vision, but that may be the
>>>>>communication problem here.) Some of my questions above are a tad on
>>>>>the facetious side, but the basic push-back isn't. I don't have a good
>>>>>picture of what /you/ think is going on here and that stands in the way
>>>>>of speculating on how to partition things.
>>>>>
>>>>
>>>>well, it is difficult to explain.
>>>>
>>>>consider 2 skeletal models:
>>>>each has a number of bones and each bone has a bbox. the positions and
>>>>sizes of these bboxes depends on the model animation, and collisions can
>>>>further effect the subsequent state of the model (excerting force or
>>>>bending the model, telling the script what part of the model was hit and
>>>>with what, ...).
>>>>now, what if these bboxes interact in different ways with different
>>>>objects simultaniously?...
>>>
>>>OK, that's pretty much what I would have pictured but without any mention
>>>of animation, scripts, subsequent state. If I swing a two-handed sword
>>>at Fred's head, is it going to get stuck in an overhead tree limb on the
>>>way? But I wouldn't expect the Physics subsystem to know what Fred's
>>>head, a tree limb, or a two-handed sword were. Nor would I expect it to
>>>understand the reason a particular bbox was scheduled to move in a
>>>particular way. IOW, Physics would just understand the positions for
>>>bboxes and their parent skeletal models.
>>>
>>>I also think I understand why you are having problems with interactions.
>>>I think that is rooted in the time slicing. If I understand this
>>>properly, Physics is handling an entire action, like swinging a
>>>two-handed sword at Fred's head, until it is completed one way or another
>>>(e.g., Fred's head is split or the sword gets stuck in a tree limb, or
>>>Fred gets his shield up to block the move). If that is the case, then
>>>Physics has too much to think about at once because too much is happening
>>>in a full move like a sword swing when other objects are moving as well.
>>>It is also making decisions about what to do after there is a collision.
>>>
>>
>> sorry, beers count too high to understand.
>
> I gather that sobering up an re-reading is not an option? B-)
>
well, I went to sleep, and started responding, then my dad demanded use of
my computer a good way though, and crashed my computer (and as a result then
demanded my dvd-rw drive and continues to interrupt me rather frequently).

as a result I had to start over, which annoys me...

> <trip down Memory Lane>
> My first 2-1/2 years of college were the most fun years of my life. In
> the last term of that period I was taking Advanced Calculus for Engineers.
> Four quizzes and a final. Through the first three quizzes I never went to
> class and never opened the text book. I went to see the Prof to find out
> my grades...
>
> Me: "Sir, I haven't been to many classes and..."
>
> He, interrupting: "I did have the distinct impression I had never seen you
> before in my life." Not a good start. It turned out my average was 44
> points below the class average and grading was on a curve.
>
> So I brought out the A material and gave him a heart-rending story about
> having a conflict with another class that didn't have a text so I had to
> attend it to take notes. (Back in the '50s that stuff wasn't computerized
> so there was no easy way for him to check.) However, he had been around
> students long enough to be seriously skeptical. Nonetheless he said if I
> passed the last quiz and the final, he would pass me in the course.
>
> Of course I found myself the night before the final opening the book for
> the first time. By 6 AM I had read the material but had done none of the
> homework problems. Being a realistic sort, I decided that I had no chance
> in hell of passing the 9 AM final. Fortunately my room mate had half of
> fifth of bourbon on his desk, so I decided to go out with a glow.
>
> I started looking at the final with the last few shots from the bottle in
> a tumbler beside me. It was open book. I looked at the first question
> and it seemed vaguely familiar. I fumbled through the book and --
> voila! -- there was an example problem that was almost identical except
> for the numbers. I dutifully copied out the solution, substituting the
> exam stuff. Rather than risk blowing a good thing by actually doing
> something, I left it as "solve for x".
>
> I looked to the next question. Again, vaguely familiar. Again, an
> example problem with slight changes. And so it went for the whole final.
> I finished the 3 hr final and the last of the bourbon in an hour or so. I
> got a C; it was the highest grade I got that term. I still have no idea
> how I reached that level of blissful acumen, but my speculation is that my
> subconscious was somehow released since consciousness was pretty relative
> by that point anyway.
>
> Alas, that was the term was when my cum caught up with me and no amount of
> banter could persuade them not to flunk me out. When I went back I had to
> make Dean's List each term just to get my cum up to graduation level
> because there were so many 0s weighting it down. (MIT required 2.50 out
> of 5.00 back then and I graduated with 2.495.) During that time I was
> tempted to unleash my subconscious again in a similar manner but, sadly, I
> couldn't take the chance. [Back then they only gave you one chance to
> come back. If you screwed that up, you went to a different school that
> had no Brass Rat ring.]
> </trip down Memory Lane>
>
yes, I had an experience of failing calculus fairly hard...
and then a year went by of not having any classes, and now starting again,
and being blamed for the resultant time loss (it was my parents who decided
to move, and who wanted to wait until they no longer had to pay non-resident
tuition).

in both cases they have not been very prestigous, more like community
colleges...

> My basic point here is that, as described, your Physics has to do several
> distinct things:
>
> (1) Figure out how the bboxes get from the set of locations {A} to the set
> of locations {B}. That is, predict desired trajectories.
>
> (2) Figure out if bboxes ever occupy the same space when following their
> trajectories. That is, identify collisions.
>
> (3) Do (2) in real time for multiple entities.
>
> (4) If there is a collision, then figure out a new movement based upon the
> nature of the collision. That is, revise the trajectories from (1).
> However, this is a different problem because it involves additional
> physical properties of the entities and different laws of physics.
>
5. do 3 and 4 until either things stabilize or a timeout is exeeded, in
which case the involved objects are just stopped.

1 and 4 are based on movetype.
2 and 3 depend on solidtype.

in some cases movetype and solidtype are interrelated, eg: one can only use
certain combinations.

not all solidtypes are based on bboxes, eg, some are based on bsp trees or
collections of planar halfspaces, and thus the need to understand their
various behaviors, and that of the other types they are checking against.

so it is a grid:
various pairs of movetypes:
    sometimes with only some valid movetypes for a given solidtype
    sometimes with only some valid solidtypes for a given movetype
    for the various pairs of solidtypes for differing entities:
        detecting collision
    if collided, handling for the various pairs of movetypes

this results in annoying difficult to split code, since none of the types
can really be dealt with in isolation.

> I am arguing that 1, 2, and 4 are three different subject matters that
> should be separated. In order to do 3, you need some sort of time slicing
> to move through the trajectories incrementally. You also need that for
> loading the data for the Rendering. So my basic suggestion is to combine
> that with 1; compute the trajectories in an incremental fashion where each
> increment for each skeletal model's movement has the same slice boundaries
> in time.
>
> If the subsystem that does 1 splits up the trajectories for common time
> slices, then it is easy to separate that from 2 and 4. In 2 you do one
> time slice at a time and the computation of collisions is <relatively>
> trivial from the end position. Similarly, once a collision if detected,
> one terminates the original trajectory motions and computes new ones in
> for the remaining time slices and feeds those back to 2.
>
dunno.

>>>Now suppose you subdivide simulation time into time slices that are
>>>roughly the graphics refresh period and let Physics only worry about one
>>>such slice at a time. So a move like swinging a sword is broken up into
>>>increments based on time slices. In that case a move increment /always/
>>>goes to full completion but that increment is only the frame-to-frame
>>>distance that would appear smooth in the display.
>>>
>>
>> well, it is in small time slices, but a lot can happen in that time. a
>> small time slice does not necissarily fix things.
>
> The only thing it fixes is the modularity of the application by providing
> a basis for synchronization between the various subject matter processing.
>
> Note that once the trajectory is computed (which you have to do anyway),
> nothing happens if there is no collision -- it is just a pass-through to
> Rendering. If is only when there is a collision that one has to make
> adjustments (i.e., compute new trajectories, which you have to do anyway).
> By separating that incremental analysis and collision detection, both get
> easier to implement because they can be highly optimized to their rather
> narrowly defined tasks. For example, collision detection is no longer
> dynamic in any way; one simple compares coordinates. That reduces the
> overall checking overhead for all unimpeded trajectories.
>
similar is done allready, but movetype and solidtype play into the checking
as well...

>>>In that case there are only two possibilities for any given bbox
>>>incremental move: there is nothing in the way (i.e., no other bbox
>>>occupies the same end space) or there is something in the way (i.e.,
>>>another bbox occupies some part of its space). All the Physics subsystem
>>>needs to do is report when the bboxes collide to whoever is managing
>>>their skeletal models. IOW, Physics basically does nothing except check
>>>for collisions at the end of an incremental move.
>>>
>>
>> not so simple, or at least this is where "movetype" comes in.
>
> movetype?
>
yeah.

there is a system of "movetypes" and "solidtypes", which define respectively
how to go about moving from point to point or dealing with physical
properties, and how to go about dealing with the different ways of which to
represent a model that can be collided with.

this is another one of those design features that was inherited from quake.
a single view of how to detect collision doesn't allow much variation in
model representation, and only a single way to represent object behavior
leads to the need for a lot of special cases and checks.

movetypes basically allow one to specify various sets of physics features an
object responds to, and how it goes about interacting with other objects.

eg:
a character will move on impulses, and fall when being pulled by gravity and
when falling has little control over movement;
a door or platform will move in a specified direction a specified distance
and stop, it will excert force on any characters or objects in the way, but
otherwise it does not care about gravity or colliding with objects (quite
frequently doors or such will open or close in such a way that they pass
through other solid objects);
a missle will just fly through the air in a straight line and stop when it
hits something, meanwhile ignoring gravity;
a grenade will fly through the air while being effected by gravity, and will
bounce off any objects it collides with eventually comming to rest or such;
...

each is assigned a name and checks are added for it.

>>>That means that someone else has to manage movement at the level of full
>>>sword swings. That someone -- let's call it the Move Manager
>>>subsystem -- understands what bboxes are involved in a sword swing.
>>>Using that knowledge they are responsible for the prediction portion
>>>above where they define the set of incremental moves for each relevant
>>>bbox to get the sword from its present position to the desired position
>>>after the full swing. Then for each time slice they are triggered to
>>>send the next set of incremental bbox moves to the Physics subsystem.
>>>
>>
>> bboxes are only one of the solid types.
>
> Why? The skeletal model composed of connected bboxes seems like a very
> general representation. Why wouldn't all game entities be represented
> that way? Immobile entities would just be simpler. IOW, it seems to me
> that articulation is just a property of the skeletal model.
>
it is because, insufficient info exists to represent everything with bboxes
effectively.

bsp trees are a clear issue here, namely you have a mass of faces that
organize themselves into a tree, and one can work by descending down one
side or the other of the tree checking for collisions, and ignoring sides
where a collision is impossible.

other exceptions exist as well (eg: completely nonsolid objects, non-solid
objects that respond to collisions, ...).

>>>Once Move Manager has figured out the sword trajectory, it has nothing
>>>else to do except pump out incremental moves to Physics. If there is
>>>nothing in the way, the whole move will complete with the sword in Fred's
>>>skull. When that happens Physics will report the collision. If
>>>something like the tree limb or shield gets in the way prematurely, the
>>>overall move is simply halted. Move Manager reports back to whoever is
>>>managing the sword swinging entity that the blow was delivered or halted
>>
>>
>> it is not so simple, and the concept of "fred swinging sword" is a bit
>> below physics anyways.
>
> Actually, I would expect it to be substantially above the physics issues
> in the levels of game abstraction. Things like skeletal models are what
> lower level services need to implement notions like Fred swinging a sword
> for proper display rendering. They don't even exist in the game
> semantics; just Fred and the sword do. Conversely, those services don't
> care at all whether a particular skeletal model represents Fred or an
> Ogre. They only care about how skeletal model interact.
>
mind you, I was drunk, and "above" and "below" wrt levels of abstraction is
not allways firmly grasped or presented correctly...

>>>by a collision. Physics will also report to whoever is managing the Fred
>>>entity that there is now a sword buried in his head so that hit points,
>>>etc. can be adjusted.
>>>
>>>Note that things like bouncing the sword off a shield or separating
>>>Fred's head from his body are not relevant to the actions so far. Those
>>>will trigger the appropriate /next/ full move by Move Manager when it is
>>>notified of the collision. That is, the bounce or whatever is a move in
>>>itself triggered by the <premature> completion of the previous move.
>>>Since the time slice is at the scale of the refresh rate, having both
>>>bboxes occupying the same display space is not going to be noticed.
>>>
>>>[You will also note that Move Manager as described here does things
>>>(i.e., compute 3D trajectories) that are very close to the sort of stuff
>>>Rendering may do. But that is not quite so. Move Manager is an excise
>>>in analytic geometry for individual movements without regard to context.
>>
>>
>> ok.
>> again "sword embedded in fred's skull" is a concept for the script layer,
>> physics is more concerned with the movements and collisions involves just
>> stopping an action has sohwm itself to be an unreasonable approach.
>
> I understand that. My point is that Physics is doing too many different
> sorts of physics things. As I indicated above, I think there at least
> four different subject matters involved whose concerns need to be
> separated.
>
ok.

it is still an ugly system though, eg: how do I fully seperate movetype from
solidtype, or the different solidtypes?...

the necessity of nested switch statements and lots of ugly interdependencies
doesn't seem easy to escape...

yes, maybe movetype could be replaced by a mass of options and heavier (but
closer to "complete") physics, but this would somewhat increase
computational costs or difficulty in working with it (a grenade, for
example, would go from being "move_bounce" to "object with low mass, highly
elastic, with zero acceleration" or such).

likewise, all models would need to have a consistent notion of "collision",
and a way to seperate it from the model.

>>>>now it is a hassle because one can't check for one without knowing the
>>>>details of the other, eg:
>>>>
>>>>map and bones, both the map and skeletal code are involved, each bone is
>>>>checked against the map, or vice versa.
>>>>one could, say, split it up into a mass of bbox checks, or choose a more
>>>>abstract structure (say, an obb-tree), but these are likely to hurt
>>>>performance, and still the need for them itself hurts abstraction.
>>>
>>>I am not sure what you mean by 'map' here, but I'll assume you mean
>>>something like terrain obstacles (trees, walls, etc.).
>>>
>>
>> vaguely, yes.
>> it is more a mass collection of polyhedra.
>
> Relative to my point above about different representations, isn't a
> polyhedron just a special case of a skeletal model that has one bbox with
> a specific regular geometric shape? (Or, if you need to sometimes break
> up the obstacles in an explosion, a single skeletal model with lots of
> identical bboxes that don't articulate?)
>
not really, a bbox is allways rectangular, but a polyhedron may not be (it
can be a rough sphere or cylinder for example, or many other shapes).

similarly, it is not possible to make the same optimizations as polyhedra
with bboxes and vice versa.

however, the cost of efficiency is arguably great, but imo dealing with a
system where all object types are unified is worse (a lot slower, more
cumbersome, ...). this is what my previous ones were.

> It seems like having to drag in a separate set of algorithms to deal with
> a different representation would just complicate things. Especially if one
> had to provide special code for all the possible combinations of
> interactions with entities being represented differently.
>
yes, I do actually, and that is part of the mess...

>>>The answer here is to provide the map entities as exactly the same sort
>>>of skeletal models with bboxes as the non-map entities within the Physics
>>>subsystem. They just don't move a lot.
>>>
>>
>> problematic and unreasonable.
>
> Why?
>
it would involve a lot of math that would be unneeded and unreasonable.
it would be difficult to optimize.
bboxes can't fully represent polyhedra, or make use of overlaps between
them.
...

however, often bboxes are used at least as a "first pass" in many cases,
because a bbox can be checked quicker, and can be used to quickly rule out a
lot of impossible collisions. in this sense, all objects do have bboxes,
just a loose fit one to rule out impossible collisions, rather than to
reliably detect the collisions themselves.

>>>>>As an example of where my preconceptions may be getting in the way, in
>>>>>this of list of process steps the only one that I might regard as
>>>>>physics is the detection of obstacles. Even that I would expect to be
>>>>>owned by a Map or Terrain subsystem rather than by Physics.
>>>>>
>>>>
>>>>well, collision detection is a major one, but increasingly compensation
>>>>is also important.
>>>
>>>Note that in the proposal above, compensation is handled outside Physics.
>>>That's because the nature of the compensation (bouncing off a shield vs.
>>>splitting a skull) depend upon the semantics of the colliding bboxes in
>>>the game logic sense. That is, to decide the appropriate response to a
>>>collision you have to know what sort of things collided.
>>>
>>
>> and in typical approaches, things are spilt into layers.
>> one does not know much about what is above or below, only that the
>> contents of a layer are sometimes a scary mess.
>
> Layering is a good start but it is inadequate for complex problems --
> precisely because it leads to layers that are scary messes. One needs to
> partition via subsystems in 2D (i.e., a layer is a special case of having
> a single subsystem at a particular level of abstraction).
>
ok.

>>>>>>now, if one looks at it enough, it might also become apparent why
>>>>>>things like ik/"ragdoll" are scary-looking. they have both
>>>>>>combinatorial and integration related problems. not only that, but the
>>>>>>renderer gets involved, the current state of a model/entity
>>>>>>(positions, bounds, ...) are needed both by physics and rendering, and
>>>>>>don't go well with the typical abstractions (eg: frames, state
>>>>>>variables, ...). actually, it could probably be said physics is doing
>>>>>>the heavy lifting and rendering is just along for the ride.
>>>>>
>>>>>Let the renderer have its own view of the entity. Some aspects of that
>>>>>view, like position, will change as a result of game logic changes
>>>>>while others, like bounds, are likely to be quite stable. Use messages
>>>>>to synchronize things like position data with activities elsewhere.
>>>>>
>>>>
>>>>maybe.
>>>>
>>>>position is at least easy, "state" would require a bit more (eg: the
>>>>current positions and forces on the various bones for each model).
>>>
>>>In the suggestions above one idea was that Physics was limited to /only/
>>>thinking about position. The state was handled elsewhere. So one didn't
>>>need to think about forces because of the time slice granularity. (One
>>>probably would have to think about forces in determining the trajectory
>>>of the new move, but that would be Move Manager's union.)
>>>
>>>[In reality, I think my solution is an oversimplification. I would be
>>>inclined to separate out things like impact analysis into a different
>>>flavor of Physics as a subsystem. It would be limited to dealing with
>>>the "new moves" resulting from collisions. It would understand rebounds,
>>>slicing, etc. to create the resulting trajectories for all the bboxes
>>>involved in the collision based upon their properties and would ripple
>>>outwards through the connected bboxes. In effect it would replace Move
>>>Manager in the special situation of collisions for all the involved
>>>entities.]
>>>
>>
>> dunno.
>
> Don't know what? That is would be a better organization? That is could
> be done? That the code you already have could be modified to partition
> this way?
>
pretty much.

I don't really understand how the movement can really be seperated from the
collision detection in any really reasonable way.

I have spent a fair amount of time staring at the code to try to figure ways
to clean it up.

>>>>>Let's say the Physics subsystem does detect obstacles to movement. The
>>>>>presence of an obstacle in the path would be important to whoever is
>>>>>managing the entity's movement, but I don't see why Rendering would
>>>>>care. Rendering displays the obstacle but it isn't involved in
>>>>>movement. It just renders the result of moving the entity to a new
>>>>><probably incremental on a path> position /after/ the path is adjusted
>>>>>around the obstacle.
>>>>>
>>>>
>>>>well, the rendering gets involved as often there is overlap in the
>>>>representation of the model. the physics needs to look at the model in
>>>>various details, and so does the rendering.
>>>
>>>But to do that all Rendering needs to know is the new position of all the
>>>bboxes and how they are displayed. It understands the display viewpoint
>>>and deals with what's hidden and what's not, not Physics. The
>>>algorithmic content may be physics of a sort, but it is quite different
>>>than the physics that determines when moving entities collide.
>>>
>>
>> there is overlap in the data and structs.
>
> True. That's why one needs to share and synchronize data. But long
> before OO development Nicolas Wirth wrote a famous book titled, "Data
> Structures + Algorithms = Programs". IOW, even without OO combining
> related knowledge and behavior in classes, one had to look at the Big
> Picture of how and when they interact. Corollary: one isolates and
> encapsulates the concerns of each interaction (i.e., How & When). As a
> practical matter that generally maps to sharing the data but keeping the
> behaviors separate.
>
maybe.

I guess eventually the code and data may decouple some, but for now (given
that a lot of the code is newer and still shows many kludgemarks) this is
unlikely...

>>>>there is probably at least some reason why a lot of recent game
>>>>developers are outsourcing the game physics to other companies...
>>>
>>>The algorithms for determining something like how a shadow should look
>>>from and arbitrary light source are nontrivial. So are algorithms for
>>>determining what's hidden from view, trajectories for multiple bboxes
>>>when swinging a sword, and a bunch of other stuff. Perhaps more
>>>important is that the algorithms are computation intensive and they all
>>>need the same CPU, so optimization is very important. IOW, that requires
>>>a special skill set so it pays to specialize.
>>>
>>
>> no, shadows are a rendering concern.
>
> It is just a different suite of algorithms to apply physics of a
> <somewhat> different sort. Skeletal models, trajectories, collisions,
> rebounds, ray tracing, whatever -- it's all basically the same science
> whose flavors need to be partitioned more than just Physics vs. Rendering.
> (I would argue that the Rendering needs to be partitioned in the same
> manner as we have been talking about Physics.)
>
yes.

luckily at least rendering is at least a lot more partitioned normally, I
just have to try to keep it from being assimilated entirely into physics and
the code for dealing with fileformats...

sometimes I wonder if and how all these problems have been approached by
newer commercial games...