Re: new here, my lang project...
From: cr88192 (cr88192_at_NOSPAM.hotmail.com)
Date: 01/25/05
- Next message: Dmitry A. Kazakov: "Re: Liskov Substitution Principle and Abstract Factories"
- Previous message: Anders Pedersen: "Re: Use-case driven development - getting to work-tasks ?"
- In reply to: H. S. Lahman: "Re: new here, my lang project..."
- Next in thread: H. S. Lahman: "Re: new here, my lang project..."
- Reply: H. S. Lahman: "Re: new here, my lang project..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 25 Jan 2005 12:22:59 GMT
"H. S. Lahman" <h.lahman@verizon.net> wrote in message
news:DldJd.5459$cx2.2999@trndny03...
> Responding to Cr88192...
>
>>>>ammusing is that the nature of these objects feels pulls even from other
>>>>engines, eg, to match their specific conventions.
>>>>what breaks there have been thus far (eg: calibrating space in meters
>>>>vs. carpentry or standard inches) have resulted in endless annoying
>>>>troubles.
>>>
>>>The old mix & match trick. One can do the same thing with software
>>>construction paradigms with similar results -- which launched this thread
>>>as I recall. B-)
>>>
>>
>> yes, about.
>>
>> albeit, mix and match is more of a direct hassle when dealing with code,
>> as it is not allways clear where and when to convert, and this has led to
>> some annoying kludging.
>
> It is more of an immediate, short-term hassle. But mix & match at the
> construction paradigm level can result in very subtle long-term problems.
> Pay now vs. pay later.
>
well, personally I have not had much in the lines of problems with this.
>>
>> yes, the float/double issue is also a hassle, but at least it is clear
>> where I have to convert, so it is less so.
>> for some things at least I had considered a convention of going to "SI
>> numbers", or essentially '<number><scale><unit>', eg: I could write '3mm'
>> and have it understood as "3 millimeters" and have it autoconverted.
>> however, this does not fix the problem in general (units are not
>> known/retained in many situations).
>
> Descriptors are a hassle to use, they tend to bloat both storage and
> executable statements, and they usually have substantial performance
> penalties. So it is often better to use a consistent units within a
> subsystem and do any conversions in the subsystem interfaces. Of course,
> if the code isn't conveniently modularized into subsystems, you are pretty
> much screwed. B-)
>
well, at the level of parsing or printing, it makes things more convinient.
also, my general designs are not exactly "efficient" anyways.
>>>>however, the monolithic objects aproach is sort of forced by the
>>>>predecessors I have inherited some formats, tools, ... from.
>>>>in some cases, I can do little really wrt fundamental issues.
>>>
>>>Right. That's the classic problem of legacy code. It is generally
>>>regarded as high risk to introduce OO development into a shop with a lot
>>>of legacy code. That's because the legacy code was not constructed with
>>>OO principles so there is no convenient way to partition
>>>responsibilities -- the legacy code has already usurped some of the
>>>responsibilities of the new objects one would like to have. So you
>>>either do a lot of refactoring of the legacy code or you do a kludge.
>>>
>>
>> well, more like legacy data and tools in some ways...
>> I don't control and I can't change the tools, I am stuck with what they
>> generate and understand, and doing something different would be too much
>> work.
>
> 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, ...).
now, I support my stuff presently by overloading quake3, and am thus limited
in the semantics of things.
>>>>oh well, it has been quite a while since I have used (system level)
>>>>threads. on current systems in many cases threads don't have a strong
>>>>justification for the extra work needed to maintain them (eg: avoiding
>>>>race conditions, securing subsystems via locks or such, ...).
>>>
>>>I'm kind of surprised a game like quake didn't have threading. Smooth
>>>graphics usually requires higher priority and I would expect the AI to be
>>>doing something useful while waiting for the next player keystroke.
>>>
>>
>> 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. That approach basically assumes that if
> one divides the program up into small functions and executes them
> serially, everything will be fine because all the processing must be done
> on each cycle regardless of whether it is time sliced or not.
> Unfortunately that does not work well for more complicated games for a
> couple of reasons.
>
> One is that the CPU cycles are not divided equally among activities.
> Probably 80% of the processor cycles go to graphics, even when downloading
> operations to a spiffy graphics card's processor. For smooth processing
> that should not be interrupted very often and then only for short periods.
> (The graphics card provides a buffer for refresh, but it needs data to eat
> that must be loaded fairly regularly in synch with the refresh; otherwise
> images start to overlap.)
>
> The second reason lies in refresh mechanics for the graphics. That is a
> hard real-time constraint in the 50-80Hz area. If the graphics data for a
> loop can't be loaded within 2 periods the odds are good that the display
> will be choppy. Since graphics is eating most of the CPU cycles, that can
> be a problem if one takes a break to do something for the AI or the
> player.
>
> If the AI needs to think or the player initiates some action, the
> resulting computations need to be interwoven with the graphics processing.
> IOW, the graphics needs the highest priority. Perhaps more important,
> there will be times when the player is viewing something that is not not
> very active graphically (e.g., a small scale map or some interactive
> dialogs). Then you need the AI or game mechanics to be making up for lost
> time by doing a lot of computation while they have a good shot at the CPU.
> One can manage that manually, but threads are a lot easier
>
> The third problem lies in differing time scales. Player actions and disk
> I/O are at the millisecond level while everything else is at the
> nanosecond level. It just doesn't make sense for them to get equal
> priority with the graphics on each processing loop. Also, you can queue
> up player events in the UI and poll them from the loop in the game logic,
> but you have to wait for disk I/O. If everyone is held up waiting
> milliseconds for I/O in the single-threaded loop that is a huge waste of
> resources that could be spent one something like a better AI or spiffier
> graphics. (Don't you just hate the older games where the game just stops
> for 5 seconds for an autosave while you are banging on a key to get you
> token out of harm's way?)
>
well, but all this is not how the games are done.
everything is typically done serially and in discreet operations.
avoiding choppyness is a low concern, namely called "lag", and is an
expected consequence of things.
loading and saving delay is also expected. annoying stalling for loading
(sometimes up to several minutes in some games) is common.
in my case, I tolerate bad performance in some areas.
>> 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...
>>>>>Unfortunately this is getting into rendering issues that are well
>>>>>beyond my ken. I haven't paid any attention to graphics techniques for
>>>>>a decade, which makes me pretty obsolete in that venue.
>>>>>
>>>>
>>>>yes.
>>>>
>>>>sprites have gone away. statically deformed meshes have risen and gone
>>>>away. static animations are fading, and may be replaced eventually. ...
>>>>
>>>>always new systems with new data, and old tools that can no longer
>>>>generate new data or have arbitrary limitations. it is sort of like a
>>>>treadmill on this front.
>>>>there also seems to be an ever-increasing amount of ties between the
>>>>subsystems, eg, physics, scripts, and rendering appear to be getting
>>>>integrated at ever finer levels in newer games, ...
>>>
>>>That can be good or bad, depending on the context. It is bad if the ties
>>>represent bleeding cohesion and dependencies between the various subject
>>>matters. OTOH, I think I mentioned that good decoupling interfaces
>>>usually have more, finer-grained message traffic.
>>>
>>>IOW, the quality is more about why the messages are sent and how they are
>>>interpreted than it is about the volume of traffic.
>>>
>>
>> dunno. I am not really that sure how to split them up, even with lots of
>> messages.
>>
>> looser parts are easier, just probably need registration-based interfaces
>> or message passing or such.
>>
>> the main problem is a sort of combinatorial problem, namely, it is
>> unclear how any of the stuff can be done in isolation or reasonably
>> broken up into message traffic.
>
> Unfortunately I can't offer much advice about how to split up the subject
> matters with something more specific. [Especially, when I am beginning to
> have doubts that I know what you are doing at all. B-)] Could you give an
> example of a combinatorial problem? (Not a lot of code; just a
> description of the activities, dependencies, and messages for some
> operation on a single entity.) For example,...
>
>>
>> I guess ways are found by people to manage this and maintain abstraction,
>> just like physics can be largely simplified to discreet
>> timeslices/integration, the use of a set of handlers for every
>> combination of 2 of each type, and a number of passes for each kind of
>> process:
>> setup (preparing the entity for movement);
>> prediction;
>
> Of what? The next waypoint? The best overall path?
>
no, where everything is going to be at the end of the timeslice assuming
nothing gets in the way.
>> detection/compensation (possible multiple passes);
>
> Detection of what? Other entities? Boundaries? Treasure?
>
detection of collision and similar between objects/parts of objects (say,
when I swing my arm it might just hit someone in the face, rather than move
through easily).
> Compensation for what? Obstacles? Windage when aiming? Pay raise?
>
compensation of movement for collision with the objects (eg: bouncing,
excerting force, ...).
>> verification/adjustment (if a movement can't be worked out by here it is
>> just stopped);
>
> So verification is just checking if the target location has been reached?
>
> What adjustment?
>
verification that things haven't gotten into a situation where all movements
would effectively result in other collisions.
consider a pile of boxes. boxes in the middle can't move at all, and trying
to do so will result in other problems. best is to verify that the current
movement is possible, and if not just cause it to not move (the box in the
center is stuck in place until something else happens).
>> finalization (finishing the move and stabilizing the entity state).
>
> Sounds reasonable, but it is short on detail. What's involved in
> 'finishing the move'? What's involved in 'stabilizing'?
>
basically "finishing the move" consists of, after verifying and adjusting
for collisions, adding the final set of movements to the
origin/angles/velocity/...
"stabilizing" basically consists of copying the various data from where it
was being worked on back into entity slots (given the structure of the
entities, slot access is not as fast as it would be, eg, in a struct).
the reason for the pass splits, I have found, is that often the interactions
are non-linear. checking of a subsequent entity can effect a previous one
and thus forth (consider an entity that pushes another entity as it moves).
>>
>> detection is a biggie here. one has to deal with the various pairings of
>> model/solid types.
>
> What models? What solids? Since they are being compared I assume they
> represent views of the same thing, but what is it? (This seems to be
> using a particular technique to detect obstacles, but the details of that
> technique are no clear, such as the nature of the model.)
>
models are collection of geometry, skeletons, ...
or, they are bsp trees and associated faces.
solid types are just a notion of generalizing the type off checking done for
different objects, eg: 2 bounding boxes. checks between bboxes are rather
simple, one can first bound the entire moves and see if the boxes overlap,
then one checks if movements along the various axis will result in a
collision, ...
for nearly every other type, the checks are harder and depend on the types
involved.
>> compensation is a little easier, since one can take shortcuts.
>>
>> this is a hassle not that easily explained, and it requires multiple
>> attempts to get a really usable physics engine.
>
> 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?...
now, for a skeletal model, one needs:
code to check between 2 skeletal models;
code to check between a skeletal model and the map (eg: a bsp tree);
code to check between a skeletal model and a bbox;
code for a skeletal model and a trigger;
...
and also has to deal with the case of multiple simultanious collisions.
now, one can state that if I have a check for A->B, I also have one for
B->A, but this just serves to halve the number of checks.
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.
> 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.
>> 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).
> 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.
> While I am sure that once the next <incremental> entity move is
> determined, several subsystems (e.g., Rendering, Game Logic, AI, etc.)
> might have a need to know about that. So multiple announcements are
> generated when the move is determined. But whoever is managing the
> movement probably only needs information from the owner of the map
> information to select the optimal path and move along it incrementally.
>
no, path finding is different, and afaik probably simpler, issue.
path finding is a tracing activity, and not so much a dealing with possibly
n-way collisions problem.
or maybe I am just stupid.
I don't know.
there is probably at least some reason why a lot of recent game developers
are outsourcing the game physics to other companies...
- Next message: Dmitry A. Kazakov: "Re: Liskov Substitution Principle and Abstract Factories"
- Previous message: Anders Pedersen: "Re: Use-case driven development - getting to work-tasks ?"
- In reply to: H. S. Lahman: "Re: new here, my lang project..."
- Next in thread: H. S. Lahman: "Re: new here, my lang project..."
- Reply: H. S. Lahman: "Re: new here, my lang project..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
