Path: chuka.playstation.co.uk!news From: SCEE Developer Support Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: Various things Date: Fri, 18 Apr 1997 21:52:11 +0100 Organization: Sony Computer Entertainment Europe Lines: 82 Message-ID: <3357DEFA.4C73@interactive.sony.com> References: <3355D64F.4E6D@geocities.com> <3357626c.1625559@news.playstation.co.uk> <3357E789.6E82@reptile.no> <3358724a.548445@news.playstation.co.uk> NNTP-Posting-Host: 194.203.13.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (Win95; I) Alex Amsel wrote: > > On Fri, 18 Apr 1997 23:28:41 +0200, Rune Solberg > did quoth at me: > > >Did you just load a regular TMD and then set the double-side flag? I > > I convert the TMD data to a new set of primitives (goraud tmapped). > The program wasn't meant for misc objects, but I tried them anyway. > When the normals were all screwed I set bit 1 in flag to make them > double sided. Again, it was after a loooong night and by that time by > vision is giving out! Yet another night with 3 hours kip... > > >thought you'd need to have all the primitives for the extra polys in the > >TMD as well, but I might be wrong. Or does GsLIB handle this internally > >when the flag is set? > > I thought the later, but perhaps I'm wrong. Maybe you have to have the > 2 equivalent polys next to each other? > > >How I wish we knew more about what GsLIB actually does... > > Now I have spent a couple of days working with it I REALLY wish I knew > much more about the internals. I'm also discovering a pissload of > restrictions (esp. lighting & memory restictions due to the structures > used). However, I'm using a 1.7k polygon object with 16 bit colour > goraud tmapping and I'm still at 50 frames so it ain't slow. I wonder > how much you could do with custom code then :) > > Testing 16 bit colour I found it still ran 50 frames! I thought the > ps-x was slow at this? Anyone done any speed tests? > > Also, I did a routine that wraps a texture onto an arbitary object in > a couple of hours the other night - the only problem is at corners of > my texture the u,v coordinates wrap, something the ps-x doesn't like. > I can pretty much find where this has occured, but solving it is > another problem. I think the best way is to just have approx 20% (if > that, my polys are small) repeated texture at the bottom and right. > > Currently I modify the u,v coords a little to correct them and it > looks fine, but I'd like to make it less hacky since all this stuff is > pre-calced anyway. > > * Alex Amsel * Into Beyond Web Design & JAVA Programming * > * http://www.intobeyond.com * WWFC Utter Rubbish 1996-7* > MM - "Steve Corica is every bit as good as that Kinkladze" Minor hardware points, ( I don't know if they are in the manual, as my main job is R&D ) The PS renders polys using a scan line algorithm, optimised for triangles. Therefore QUADs are drawn as two triangles by the GPU, ( hence the famous texture map distortion found on many games ). When textures are drawn, the right hand and bottom coords are not drawn ( used as limits for the draw algorithm ) - This can bugger up your texture mapping, and effectively means that the bottom line and right line of a tpage can not be drawn to screen. This is not a problem with GS/PS, it is how the hardware (GPU) renders 2D triangles/quads. Colin. PS: A minor aside: For some reason today I had to trawl through the SCEA developer BBS message list, and one of the things I noticed was that most of the messages would go on about LibGS, not because of it being slow, but because we wouldn't release the source code to the development community!!! Plus I had an indignant Email this week from a Norwegian developer complaining that we always recommended LibGte inline/LibGPu for better performance, when he had converted his code from LibGs to use the inline ( low level ) functions, only to experience a drop in rendering speed. The way GS/PS works uses the hardware tightly, and most developers only really change the code to use different data structures for their 3D models. If you have any questions/problems that you think are caused by the GS system, tell us: We will try to answer ( as long as you don't expect access to the hardware......)