Path: chuka.playstation.co.uk!news From: Robert Swan Newsgroups: scee.yaroze.programming.3d_graphics Subject: ordering table cheat Date: Thu, 13 Aug 1998 15:00:02 +0100 Organization: I wish! Lines: 53 Message-ID: <35D2F162.7FA9@mdx.ac.uk> NNTP-Posting-Host: nova.mdx.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4u) Been messing around with otables to try to reduce overlap. usual solution = gssortobject4( &ground, &otable[], 16-otablelength); gssortobject4( &player, &otable[], 16-otablelength+1); which means the player gets put in the otable with the apparent depth that is half o what it really is. +ve points = you can control what gets put in front to some degree -ve points = messes up badly in a lot of cases. What i always wanted was a way of doing more suble things than that, ie, placing the player in the otable a few priorities ahead of what it should be, and i think i found the solution (see other post asking why it doesnt cock up though!) for example, you want to sort the ground as normal, but the player 5 priorities closer than the ground this is also only for one frame (cant be bothered to copy everything else out twice for double buffering!) #define otable_length (10) #define player_offset (5) GsOT otable_header[2]; GsOT_TAG otable_array[(1<