Re: new here, my lang project... PT2

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

Date: Mon, 31 Jan 2005 10:43:51 GMT

"H. S. Lahman" <h.lahman@verizon.net> wrote in message
news:ElSKd.737$AY3.268@trndny05...
> Responding to Cr88192...
>

<big ass snip>

>> 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.
>
> I don't see that argument in a joy stick game. The player isn't
> calculating to mm tolerances. The scale is limited by the resolution of
> the graphics pane and what the player can actually see at the game display
> scale. At that scale one can be pretty loose with the tolerances of
> collision.
>
> IOW, I see this as a precision vs. accuracy issue. When I take my
> temperature I want it to be pretty accurate about whether I am sick, but I
> don't care about six decimal places; one decimal is more than enough.
> Similarly one doesn't want to get into fractal tolerances in computing
> whether there is a collision or not.
>

usually, however, for many things fairly precise detection is needed.
is the player on the ground, above the ground, touching a wall, ... ?

to answer these requires a lot of checking, and at least reasonably precise
checks.

the possibility of multiple simultaneous collisions also, and one can't have
due to precision errors the player sliding and managing to fuse into the
floor or the object.

>>>>>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.
>
> That is the point of synchronizing around fixed time slices. The
> collision is detected at the end of the time slice by simply looking for
> overlap in positions of bboxes. So all collision detection needs is the
> positions of the bboxes at the end of each time slice. There is no
> dynamics involved at all.
>
> If the time slice is small enough the player will never see the messy
> overlap of bboxes at the end of the time slice where the collision is
> detected even if it is rendering in the display. For the next time slice
> the collision will be resolved and new movements will have <hopefully>
> corrected the problem.
>
ok.

>> I have spent a fair amount of time staring at the code to try to figure
>> ways to clean it up.
>
> You probably can't. B-) The scheme I suggested is architectural. I
> would bet it could not be implemented without effectively rewriting most
> of the code. I think the same would be true of any other clean up
> alternative. IOW, the design you are working with sounds like it is
> architecturally flawed because the application is not well modularized.
>
yes, fixing would probably require rewrites.

my existing design was basically created on the grounds of patching over my
old system and at the same time ripping off quake.

doing something cleaner, yes, would probably require starting fresh and also
with a design in hand, planning out the general capabilities and features up
front, rather than adding them on later, or splitting up passes to try to
deal with interdependencies in operations, ...

>>>>>>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...
>
> That's because it was initially the biggest problem and because it is very
> nicely defined in a mathematical sense. Also, one is basically dealing
> with well organized hardware (nowadays standardized OS graphics services).
> That sort of well-defined problem tends to get solved first.
>
ok.

> The physics issues are also well defined in the algorithmic sense.
> However, it sits between the game semantics, which are not mathematically
> defined, and the standardized rendering solutions. That presents the
> temptation to bleed game space into rendering space over the body of
> physical laws.
>
> Even if the rendering is highly modularized, one can still be victimized
> by the API. If the API reflects the internal rendering structures, the
> the rest of the application is exposed to those internals and must be
> built around them. That alone can create unnecessary dependencies.
>
> bottom line: the physics stuff will tend to be less well formed than the
> rendering stuff.
>
yes, agreed.

>> sometimes I wonder if and how all these problems have been approached by
>> newer commercial games...
>
> I have no solid information. However, from various snippets from online
> forums like this one over the years my impression is Not Very Well Yet.
> That's hardly surprising because most of the code in the entire software
> industry is pretty bad. To paraphrase G. B. Shaw on Christianity, the
> only problem with good software development is that it has never been
> tried.
>
ok.

it almost makes sense to drive hard walls between the subsystems.
eg, everything could be split into several parts:
mathematics and interface core (lots of shared math functionality and
similar, basic entity and message passing stuff, ...);
render core (everything related to rendering, and possibly also sound,
input, and the gui);
physics core (physics functionality, little else);
formats core (manages file formats);
glue and misc (a library for gluing together the previous, and misc crap
that doesn't belong in the others).

this is would be similar to the division within the more basic libs:
pdbase (mm/fileio/vars/... also includes data compression);
pdnet (networking code);
pdvfs (handles filesystem abstractions/emulation);
pdscript (manages language interpreters);
pdglue (meant to handle gluing the previous together, but is little used).

just I am not sure how necessary the partitioning is at present.
I had started partitioning the systems before, but stuff changed around a
lot. the centralized rendering tended to disolve, physics rose up and began
dominating a lot of other things, ...

Relevant Pages

  • Re: new here, my lang project... PT2
    ... sent prior to triggering the collision checking. ... information that was different between the current time slice and the ... > mostly used now) are easy (an aabb is just an obb with the positions set to ... > cylinders may be a little more work. ...
    (comp.object)
  • Re: Question about ID3DXMesh
    ... >> also in a separate array which I use for collision tests and ... >> than rendering. ... > to be reading back from it on a regular basis, such as for collision ... > vertex format used by the GPU, so access could also mean translation to ...
    (microsoft.public.win32.programmer.directx.graphics)