Path: chuka.playstation.co.uk!news
From: Robert Swan <rs108@mdx.ac.uk>
Newsgroups: scee.yaroze.programming.3d_graphics
Subject: Re: the cutting edge! :)
Date: Thu, 13 Aug 1998 14:46:25 +0100
Organization: I wish!
Lines: 30
Message-ID: <35D2EE31.201D@mdx.ac.uk>
References: <35D1BCF7.72328388@hi.is> <35D1F0A9.B85A662D@scee.sony.co.uk> <6qsvtd$n7i3@chuka.playstation.co.uk> <01bdc691$46c030c0$230b0a0a@Angela1.intelligent-group.com>
NNTP-Posting-Host: nova.mdx.ac.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4u)

Craig Graham wrote:
> Of course, you could decipher them from the GPU packet buffer and ordering
> tables
> by sorting single primitives (eg. sort a sprite, check what the prim was,
> sort a TMD
> with a single poly of a type, check what the result was, etc). Then you can
> do your
> own low-level primitive drivers and roll a 3D engine to avoid the problems
> in the
> Gs renderer.

This is something Ive always wanted to do, and it shouldnt be too hard.
What is worrying me is that there must be some external pointer that we
never see that controls where the next primitive is placed in the packet
area, and which gets reset when you clear the oredering table. (thinking
about it, there must be a pointer like this for every otable). Now this
obviously seems like the GsOT_tag *tag in the GsOT struct, but owing to
my messing around, im not so sure...

reason is that im using one packet area for one frame, but two GsOTs
that both reference the same GsOT_TAG array AND packet area. Lets assume
that i place a polygon into otable 1, then its *tag gets incremented but
the *tag for otable 2 doesnt (which should point to the same place in
memory that otable1*tag used to. I now sort something using otable 2,
and lo and behold, it hasnt wiped over the previous primitive... how can
this be? Its nice and useful that it doesnt, but kind of leaves me
astounded.

Robert Swan
rs108@mdx.ac.uk