Path: chuka.playstation.co.uk!news From: "SCEE" Newsgroups: scea.yaroze.freetalk Subject: Re: Speed Optimisation Date: Tue, 24 Feb 1998 09:35:51 -0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 86 Message-ID: <6cu42m$as4@chuka.playstation.co.uk> References: <34F1D4C7.6C33@mdx.ac.uk> NNTP-Posting-Host: 194.203.13.10 X-Newsreader: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Hi, General optimisations ( PS ) Don't unroll loops... Group loads and stores together. ( PS can perform multiple loads at 2 cycle per long on same DRAM page, and writes are queued to operate at 2 cycles per long as well ) Always load longs and split in registers... ie. lb cpu cpu cpu lb cpu cpu cpu lb cpu cpu cpu lb cpu cpu cpu is better as lw cpu cpu cpu extract cpu cpu cpu extract etc... Sort primitives in TMD's... Group textures for models together, and try to use texture cache ( 64x64 for 4 bit, 64x32 for 8 bit, 32x32 for 16 bit ) ie. For football pitch or ground plane, render first in seperate OT. For added accuracy in models make bigger and scale... ie. For model with range -256 to +255, scale (X,Y,Z) values by 128, and increase OT shift by 7. ( Screen XY values will still be the same as 128X/128Z is same as X/Z, only Z distance needs changing to fit OT ) If building TMD's on the fly try building the structure into D-cache. I think the compiler generates bit shifts automatically, but FP is definitely bad news. Use higher res ( 512x rather than 320x ) where possible, as GPU drawing hit is negligable. ( For small polygons line set up time is larger than pixel draw time, so increasing X res doesn't impact draw time ) Colin. Peter Passmore wrote in message <34F1D4C7.6C33@mdx.ac.uk>... >Hi, > >I've been mailed about speed optimisation and decided I didn't have a >comprehensive answer. Obviously different games may implement different >game specific optimisation and optimisation for speed will often be at >the cost of space. However there should be a generic set of >optimisations that should apply to the PSX and its libraries. Off the >top of my head I came up with the following, probably wrong in part, and >certainly incomplete suggestions. Can anybody add to it? > > - Set the stack to use the D-cache if possible (set scott evans' >http://www.netyaroze-europe.com/~sevans/tech.htm scee page for a >detailed account on this). > - Reduce the number of polygons in models to the absolute >minimum. > - Make textures as small as possible. > - Only draw the part of the world that is immediately visible >(in 3D games). > - Define small often called functions as macros wherever >possible. > - Use variables which are the same size as the registers (eg >unsigned long) where ever possible. > - Use lookup tables to replace calculations where calculations >are expensive (eg: floating point, trig functions etc) > - Otherwise avoid any floating point arithmetic. > - Avoid texturing and shading models where unneccessary (in 3D >games). > - Clump functions that call each other together in the code in >the hope that they get compiled contiguously in memory and they have >more chance of being loaded into the cache together - (actually this is >supersition, I haven't proved to myself that this works on the PSX). > - Use bit shift operations for maths where possible. > >And its possible that some traditional optimisation techniques may be >inappropriate: > - eg: loop unrolling was a good optimisation on primitive >architectures but not neccessarily more modern ones. > >Peter. >