Re: new here, my lang project...

• Previous message: arolsen_at_gmail.com: "Re: Antenna"
• 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, 01 Feb 2005 01:21:06 GMT

"H. S. Lahman" <h.lahman@verizon.net> wrote in message
news:8ewLd.1722$W16.1210@trndny07...
> 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
>
well, I don't have much control over this, and for what it does the map
format works pretty well...

quite often the data is actually split up after loading, eg, entities go one
place, geometry another.

yet another common feature of the map format is embedding some commands in
the map via special texture names. it is not a very great approach imo, but
it works I guess...

likewise, many other things (is water, is lava, is some special effect, ...)
are given via the textures, which luckily at least lie outside the domain of
that directly controllable by map.

>>>>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.
>
these are not so much intended to be "general purpose" tools, just I lack
much better.

a more configurable version of quark would have been nice (eg: one
incorporating many of the customization features from hammer).
oh well...

the current hammer has a problem in that it only supports 16 char texture
names and uses texture wads afaik, which is less useful (quake2 and quake3
use directory based textures, and have a 64 char limit).

>>>>><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.
>
yes, but general purpose binary formats often lead to managing tags and
lengths (sometimes with variable width tag and length encodings).
...

> [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.]
>
err, if you have a direct struct representation, than likely it is not
"general purpose".
the general purpose varieties often involve some amount of parsing and
processing.

on the more basic side, there is IFF and RIFF, which at least don't
discourage use of structs, but are arguable less "general purpose".

> 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.
>
it is possible, except in formats which don't really use structures, or at
least not ones that can be mapped directly (eg: not filled with lots of
variable-width members).

it gets especially bad when trying to deal with a full-semantics (eg:
non-schema based) binary xml variant, which may as well just be text.

it is smaller and possibly faster to parse, but can still be rather
unpleasant to work with.

the work needed for these is much greater than that of text.
at least IFF is easy, so it is ok I guess.

of course, my motivation has not become:
screw general purpose binary formats. I am going to use text formats for
external data, and binary formats for internal data (generally as "caches").

even my special purpose formats have kind of a "general purpose" look
sometimes though, eg, lots of tags and lack of directly mapped structs.

oftentimes the tags are more used to verify something hasn't gone wrong
though, eg: a length was off and I read too much or too little data, eg,
from a compressed buffer.

oh well...

>>>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.).
>
I have had good success with string hashes though.

it might depend though on the variation of the hash algo, eg:
keep computing new keys until an empty/matching slot is found;
or, grouping all keys that have the same hash value under the same slot,
often with linear or lru linear searches...

I more often use the second variety.

>>>>>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-)
>
well, my app generates the bytecode, I am not doing it by hand or
anything...

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

yeah, scripting is nice in my experience.

markup is a little weak though, oftentimes it is somewhat overkill.
preference then leads to plaintext formats.

>>>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).
>
hmm, only some of the data oftentimes is known at the c level, the rest is
kept in entities until needed.
many things are copied from the entity to a struct and back into the entity
when done.

then they are shared between subsystems.

not so great, but quake and friends also used this approach, just in my case
entities are dynamic bags of slots, rather than chunks of memory with
structs and slots mapped onto them.

eg: in quake they would get a total slots-list, figure the size needed for
the entities, and alloc the memory.

accessing a slot would consist of searching for it in the list, and
accessing the appropriate offset in the chunk of memory comprising the
entity.
a lot of more basic fields had static positions and were mapped to a struct.

in mine it is more like:
LBXGL_Entity_GetPropertyFVector(ent, "origin", org, 3);

which is slower, but oh well.
getting and setting entity slots is not presently a major time-killer.

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

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

bboxes have simple checks.

I started doing the checks for solid regions, a much bigger pita...
this notion, however, is needed for the increase in physics abilities, as I
need more accurate collision detection (that can't just answer that it
collided, but where...).

probably for the physics loop I am going to need to statically transform all
region based models for checking efficiency. bboxes can slide, given they
are less accurate and have cheap checks.

• Previous message: arolsen_at_gmail.com: "Re: Antenna"
• 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 ]