Re: new here, my lang project...
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/31/05
- Next message: H. S. Lahman: "Re: new here, my lang project... PT2"
- Previous message: Ilja Preuß: "Re: OCP and Java"
- 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: Mon, 31 Jan 2005 20:07:32 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.
>>>>
>>>
>>>both.
>>
>>In the same model? Or are there separate models for display and movement
>>physics?
>>
>
> same model.
Not good. Entirely different subject matters with very different paradigms
>>>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.
>>
>>So you need a tool like quark to ferret out inconsistencies?
>>
>
> no, quark is the tool that makes the models, however, it was designed to
> target different games.
> to a lesser extent my engine has to emulate the other games to retain
> compatibility with the tools.
Kind of the tail wagging the dog. Tools should facilitate development,
not drive it.
>>>><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.
>>
>>I have to disagree. Messing with ASCII for anything other than external
>>configuration data usually means writing extra code and it is hugely
>>inefficient, especially in a computationally intensive application like a
>>computer game.
>>
>
> well, yes, but the issue is "general" vs "specific". a specific purpose
> binary format is easy. a general purpose text format is easy.
>
> general purpose binary formats, are, however, often a horribly complex pita.
> likewise, special purpose text formats are just ugly and don't gain much
> over a binary format.
I don't see that. I have to store the number 16 somewhere. I can use
the machine's binary format or I can use the string "16". Either way
the number 16 is buried somewhere in the complex structure and I have to
be able to find it to use it. So finding it is a wash.
[Though not even the navigation is a wash if one uses something like XML
for navigation because the navigation is via parsing and ASCII
comparisons, which are slow. But if the structure is all binary it is a
matter of a couple of offset operations and in a language like C the
compiler will do it for you through the struct mapping most of the time.]
The difference lies in using it once I have found it. If it is binary,
I use it directly as-is; if it is ASCII I have to decode it first and
that will take orders of magnitude more machine cycles than the
arithmetic operation where I use it.
The only time ASCII can be a win is when the structure is dynamic (i.e.,
the actual elements present are a subset of the possible elements and
the subset changes between navigations). However, even then one can
almost always employ binary identity to "walk" the structure buffer much
faster and the structure will be smaller, especially in a language like
C where one can easily dynamically map structs onto the buffer.
>>Worse, it leads to bad practices. Look at the overuse of hash tables.
>>Hashing is a form of distribution sorting where performance depends on
>>/each/ bit in the key being randomly set over all stored values, which is
>>never true for ASCII.
>>
>
> I have had lots of success with hashes though, in all sorts of usages.
>
> hashes are an almost magical structure sometimes, simple but with great
> optimization powers...
Just don't use them for ASCII keys. There will always be a more
efficient way to do it and in worst case a hash table can drag an
application to its knees. There are even pitfalls for numeric keys when
most of the values don't use all the bits in the key (e.g.., the high
order bits are 0, all the values are even, etc.).
>>>>Are you saying you produce bytecodes directly?
>>>>
>>>
>>>
>>>yes.
>>
>>Yech. That's why god invented 3GLs. B-)
>>
>
> hmm...
That's like writing Assembly or encoding HTML directly as embedded
markup codes. Life is way to short for that. B-)
[Apocryphal aside. A few years ago I read an article in a refereed
journal where the author asserted that the first markup language was
invented in 1986. The guy was totally unaware that markup and scripting
languages were very heavily used in the '50s and '60s. He was obviously
a product of the Net Generation. So the guy was also totally unaware
that there was a reason why scripting and markup languages disappeared
during the '70s. The poor scalability, fragility, and poor
maintainability made them only slightly less odious for large scale
development than Assembly. Or bytecodes.]
>>If one synchronizes data like position in a systematic way, such as the
>>end of a time slice, then the interactions between subject matters should
>>be pretty minimal.
>>
>
> dunno really.
I should have been clearer. Each subject matter eats data in its own
unique way. If the subject matter is abstracted in terms of invariant
behaviors and the results for particular situations are dealt with
parametrically through the data, then two things happen. First, the
subsystem tends to be invoked at a high level of abstraction (e.g., for
collision detection the invocation might be, "It's the end of a time
slice. Do your thing and see if there are any collisions.") So the
interactions to invoke the behaviors tend to be high level.
OTOH, the results are purely dependent on the position data for a gaggle
of entities. At least some of that data will be shared, though each
subsystem will have its own <optimized> view of it. So that has to be
synchronized so that all changes anywhere before the time slice end are
made known the the collision detection subsystem. That may involve a
very large number of data synchronization messages (e.g., "Bbox ABC is
now at {x,y,z}"). However, those messages are trivial in nature and
they are easy to implement (e.g., in a OO application one would just
have the attribute setter send the synchronization message, which
guarantees integrity).
So you tend to have more interactions in the sense of the volume of
messages. However, the vast majority of the messages are essentially
the same, they are trivially generated, and they affect only state
variables. The small remainder of messages deal with behavioral
interactions that actually define the overall solution flow of control.
Those flow-of-control interactions are the important ones.
>>>>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).
>>
>>Aha! An abstraction disconnect. My OO abstraction bias is showing
>>through; I never even thought of such a restriction. B-) Who says a bbox
>>has to be rectangular? Why can't it be any regular polyhedron or else
>>some reasonably sized set of geometric shapes?
>>
>
> then it is a "bounding region", and no longer a "bounding box".
>
> bounding boxes are defined by sets of 6 numbers, and can easily be checked
> (6 checks if I am thinking right).
>
> using solid regions, however, would require other checks.
This is strictly a nomenclature disconnect (region vs. box). I am
abstracting at a higher level. The difference between a region and a
box would be a reflection of the view of particular subject matter. So
I might expect one to use boxes in one subsystem and regions in another
to model the same entity. IOW, they represent difference views of what
a Skeletal Model is.
*************
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
- Next message: H. S. Lahman: "Re: new here, my lang project... PT2"
- Previous message: Ilja Preuß: "Re: OCP and Java"
- 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 ]
Relevant Pages
|
