Path: chuka.playstation.co.uk!news
From: "Jon Prestidge (alias Moose)" <zmoose@premier.co.uk>
Newsgroups: scee.yaroze.programming.3d_graphics
Subject: TMD info: varying and sharing prims between objects
Date: 24 Mar 1999 17:49:15 GMT
Organization: PlayStation Net Yaroze (SCEE)
Lines: 54
Message-ID: <01be761f$21ed0dc0$988a93c3@default>
NNTP-Posting-Host: p97s10a01.client.global.net.uk
X-Newsreader: Microsoft Internet News 4.70.1155

Here's some info for anyone dabbling directly with TMDS...


Great difficuties can be experienced when both:-

   trying to share primitives between objects...

   and at the same time varying the number of primitives
   in those objects that have shared primitives.

Here's the cautionary tale:-

I use objects where I vary the number of primitives by
changing the value of 'n_prim' in the object header to
a value between one and the total number of primitives I've
defined and then re-calling GsLinkObject4.
I've found this quite successful and useful.
(If you're wondering why I do this see the last paragraph!).

But just lately I've been trying to save some space in my
game by making objects which are separate instances of the same
thing use the same set of primitives, normals and vertices.
This also worked fine until I got to do this to those objects
with varying numbers of primitives... the GsLinkObject4s
and GsSortObject4s started spewing loads of errors.. I just could
not fathum why.
... it turns-out that it's to do with the fact that GsLinkObject4
changes the ilen and olen of the first primitive in the object
to the value set in the 'n_prim'.  Now, I know that the Yaroze O/S
must also refer to those changed values in the primitive at later
stages.... and if that primitive is shared by more than one object
then all those objects must have the same number of primitives
at the same time -- or else it's error time!

There is a way round it, but it's a bit of a pain.... if
you define all your primitives in reverse order and when you
vary the number of primitives ('n_prim') you will also have to
vary the 'prim_top' field before calling GsLinkObject4... this works
because the Yaroze O/S only seems to look at that modified
ilen and olen field in the first primitive it's pointed to i.e.
the one at the address of 'prim_top'

You may ask, "Why would he want to vary the number of primitives
in an object?"
... well think of this simplistic example... suppose you made an
object of a house, and you wanted to show the house being built
brick by brick: if every brick was a primitive (in the appropriate
order) then you could simpy implement that by initially setting
'n_prim' to 1 when the object was initially created, then
incrementing 'n_prim' and recalling GsLiknObject4 every few frames
 --- easy huh?


Jon Prestidge