Path: chuka.playstation.co.uk!tjs From: tjs@cs.monash.edu.au (Toby Sargeant) Newsgroups: scee.yaroze.beginners Subject: Re: Plotting 2D Boxes in a 3D World (+ faster code hint!) Date: 15 May 1998 05:58:35 GMT Organization: PlayStation Net Yaroze (SCEE) Lines: 28 Message-ID: References: <355a3dc2.2999054@news.playstation.co.uk> <355A67EA.137C@mdx.ac.uk> <355B0CD4.2A85@writeme.com> <355B86AD.3C0@manc.u-net.com> <6jg24u$f4o3@chuka.playstation.co.uk> <01bca867$ef75bda0$1eb6e9cd@lausauvege> NNTP-Posting-Host: indy16.cs.monash.edu.au X-Newsreader: slrn (0.9.5.1 UNIX) On 15 May 1998 04:04:48 GMT, dr Z wrote: >This is a little off topic but now on Pentium and on Power PC processors, >using Y*320 instead of Y<<8 + Y<<6 is faster because of the cost of >stalling the processor and the less cycles used by the multiplication >instruction. And I agree that there is a lot of room for optimisation these >days. > >Now, on a more related topic, could it be more faster and memory efficient >to use GsLines instead of sprites or GsBOXFs. A line uses less packets in >the WorkBase and the GPU doesn't have to do a look-up in VRAM. You could >use a GsGLINE with the semi-transparency rate set to 1xback + 1xforward and >a width of 2 to 4 to simulate the blur of a fast moving stars. The blur is a definite bonus, but: 1) There's a special sprite primitive for 1x1 sprites, which is both smaller in terms of GPU packets, and which _should_ be faster for the GPU to draw. 2) The GPU texture cache should mean that there's only 1 read from VRAM. The fastest way, i think, would be to build an OT with a length of 1 (or several, if you want many priorities). render MAX_STARS lines (or sprites) into it, and then update the packet data to change the coordinates and the num element of the GsOT_TAG structure to change the number of stars drawn. then, sort the OT into the master OT, and just draw it. toby.