Path: chuka.playstation.co.uk!news From: Jim Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: Perplexing question Date: Wed, 23 Apr 1997 23:57:44 +0100 Organization: PlayStation Net Yaroze (SCEE) Lines: 73 Message-ID: <335E93E8.34DD@micronetics.com> References: <335E7E32.30C9@micronetics.com> <335F32C4.354E@interactive.sony.com> NNTP-Posting-Host: jim.micronetics.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.0b2 (Win95; I) X-Priority: 3 (Normal) SCEE Developer Support wrote: > > Jim wrote: > > > > Here's a strange one fer you all. > > > > I was tweaking my world editor last night can > > came across this. > > > > I though I had introduced a serious bug, but.. > > > > I was drawing around 100 flat textured quads all at identical > > coordinates. Basically 100 poly on top of each other, > > and the frame rate was awful. Really crawling. > > > > But if I lay the polys edge on so I get a 10 x 10 playing > > field, it trotts along at 50 fps no prob. > > > > Now this has me a little perplexed. I have it working as it > > should now, but why did it go soooo slowly when each poly > > was at the same coords? > > > > ` The only thing I can think of is that each poly occupied the > > same slot in the order table. > > > > Does this make sense? Ideas anyone? > > > > Jim > > The reason for the slow down is the repeated screen draws. It all > depends on the size of the polygons you are using. By drawing a large > polygon on the screen many times the frame rate does drop, but with a > small polygon there is no problem. But again this depends on the number > of polygons. > > Stuart Yes, I can understand this. But the polys are identical sizes before perspective is applied, so the vertices & normals should take constant time between the two. So the slow down has to come from the actual rasterizing / filling. What I don't understand is that there was a noticeable slow down after 50 polys all draw on the same spot. When I added about 600 polys edge on the rate didn't even glitch. Just though it was strange, not a problem because you would never really require to do this. Another thing I noticed is this. I am creating a tmd object on the fly. I am avoiding doing a GsLinkObject (what ever it is called) because I am creating it already fixed up. What I want to know is why the olen + ilen fields for first primitive in the tmd are actually combined into a ushort integer rather than the real ilen, olen fields? I can now modify a tmd dynamically without doing a GsLinkObject each time it is changed. You just have to set the ilen/olen for the first primitive to the count of total primitives of that mode that follow the first. < did that sound like a ton of crap?> The upshot of all this is I now have an object editor on the yaroze. So I can change the texture alignment, poly placement directly to objects. All I have to do now is finished off my uuencoded to download the tmd back to the pc. (hay it was a long shot but it works!, just uuencode the block of memory, and echo it to the siocons log, and decode it back on the pc. :-) ) regards Jim