Re: new here, my lang project...

• Previous message: Shlomy Shivek: "Re: Irrelevant but curious"
• In reply to: cr88192: "Re: new here, my lang project..."
• Next in thread: cr88192: "Re: new here, my lang project..."
• Reply: cr88192: "Re: new here, my lang project..."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Fri, 28 Jan 2005 20:08:31 GMT

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.

>>>>>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.

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.

[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.]

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.

<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!

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>

>
>
>>>>>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?

> 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.

>>>><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-)

<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>

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.

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.

>>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.

>>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?

>>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.

>>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.

>>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.

>>>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?)

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.

>>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?

>>>>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).

>>>>>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?

>>>>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.

>>>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.)

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

• Previous message: Shlomy Shivek: "Re: Irrelevant but curious"
• In reply to: cr88192: "Re: new here, my lang project..."
• Next in thread: cr88192: "Re: new here, my lang project..."
• Reply: cr88192: "Re: new here, my lang project..."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]