Path: chuka.playstation.co.uk!news From: "Andrew Howe" Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: 3D engines Date: 11 Apr 1997 17:55:50 GMT Organization: Acme Lines: 43 Message-ID: <01bc46a2$06428400$01000080@solabh51.dial.pipex.com> References: <3347dd19.3248416@news.playstation.co.uk> <3348D38C.1DC1@interactive.sony.com> <334A3648.1873@micronetics.com> <3349266B.7BD4@interactive.sony.com> <3349a345.33045335@news.playstation.co.uk> <334A3058.218B@interactive.sony.com> <334b3a68.199522@news.playstation.co.uk> <334B7033.44F8@interactive.sony.com> NNTP-Posting-Host: ak118.du.pipex.com X-Newsreader: Microsoft Internet News 4.70.1155 sceetech wrote in article <334B7033.44F8@interactive.sony.com>... > The vital point here is that the speed of a PlayStation game > is VASTLY more affected by the underlying graphics, game > and AI __algorithms__ than by whether it used Gs or GTE. > The latter is itself going to make a maximum difference > of ~10%; the optimisations available at the level of algorithms, > however, are almost limitless. I optimised the poly output routines for Tomb Raider, and I got in some cases a 200% speed hit. This was going from C+libgte+libgpu to assembler with inline GTE and my own primitive creating code. The difference from libgs is not as big because the gs routines are *fairly* well written, in assembler. They're not optimal, though. The main speed up is overlapping GTE operations like RotTransPers3 with memory fetches. The PSX doesn't read from main RAM very quickly. Another thing is use of the 1K scratchpad at 0x1f800000, which can be accessed in a single cycle. The basic idea is this: say you're drawing an object. If: 1) there are less than 128 vertices in the object 2) the object is fully on-screen (ie none of the vertices will transform incorrectly) 3) you're using monochromatic lighting 4) you have already calculated the lighting then... 1) Rotate all the vertices first, using RotTransPers3 and interleaving GTE with memory fetches for the next set of vertices and sticking the screen coordinates in the scratchpad, 8 bytes per vertex (short x,y,z,intensity) 2) Go through your list of faces, load up the vertices for a face from the scratchpad (fast), do a GTE normal clip while calculating an average Z value in software, if the face isn't back facing then create a primitive connecting up the vertices. I've simplified it a bit but you should get the idea. The conditions are not that restrictive. The point is, you can't do this with libYaroze... Andrew - Core Design