Path: chuka.playstation.co.uk!news From: SCEE TECH Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: OT buffer puzzle Date: Thu, 19 Jun 1997 15:28:06 +0100 Organization: Sony Computer Entertainment Europe Lines: 75 Message-ID: <33A941F6.39CD@interactive.sony.com> References: <01bc7ca1$2688a700$LocalHost@default> Reply-To: N/A-Use-Newsgroups 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) Jon Prestidge (alias Moose) wrote: > > Hello, this (as many things do) is perplexing me...... > > I'm sure this next section of code where stuff for the ordering tables are > set-up will look familiar - it seems to be in many yaroze demos on the web > site.... > > #define OT_LENGTH 9 > static GsOT Wot[2]; /* Handler of OT */ > static GsOT_TAG wtags[2][1< . > . > . > Wot[0].length = OT_LENGTH; > Wot[0].org = wtags[0]; > Wot[1].length = OT_LENGTH; > Wot[1].org = wtags[1]; > > GsClearOt(0, 0, &Wot[0]); > GsClearOt(0, 0, &Wot[1]); > > It just did not look right to me -- ie I would have thought the Wot[n].org > would have had to have been set using a "&" before the wtags[n] to get it's > address -- but there again I'm not a C guru and so I assumed that there > must be some C-weirdness where arrays are automatically by reference... and > after all that bit of code seems to be widely used -- so it must work... > mustn't it?!?! Anyway I included it in a program I was starting to write. > When going throught the program on the debugger (MetroWerks debugger > V1.6) I noticed that the address that the pointer Wot[n].org was being set > to was 9, which just so happend to be the constant OT_LENGTH! Obviously > address 9 can't be right can it? It certainally was not even remotely like > the address of the wtags array. So anyway I amended the code to be as > follows... > > #define OT_LENGTH 9 > static GsOT Wot[2]; /* Handler of OT */ > static GsOT_TAG wtags[2][1< static GsOT_TAG *temp_GsOT_TAG_pointer; > . > . > . > Wot[0].length = OT_LENGTH; > temp_GsOT_TAG_pointer = &wtags[0][0]; > Wot[0].org = temp_GsOT_TAG_pointer; > > Wot[1].length = OT_LENGTH; > temp_GsOT_TAG_pointer = &wtags[1][0]; > Wot[1].org = temp_GsOT_TAG_pointer; > > GsClearOt(0, 0, &Wot[0]); > GsClearOt(0, 0, &Wot[1]); > > ... and this looked much better under the debugger... the pointer > Wot[n].org now pointed to the same address as wtags[n]. I probably could > have gotten away with just putting Wot[n].org = &wtags[n][0] but I wanted > to see things happen in the debugger. > > My program works OK with my amended version of theOT set-up. > I can't say whether or not it would have worked with the code the normal > way because the program didn't work then anyway for other reasons. > > I'd be very interested on people's comments... could it be the debuger > giving-out wrong data, or have I got the wrong idea about pointers and > stuff, or have I lost my marbles... or .... other? > > Jon There are no true arrays in C, just offsets. This is why so many people get so many problems, over writing memory and the like. The top piece of code works just fine, no need for the &. I've no idea what the debugger is doing, maybe someone else can help you (you could post this in the codewarrior section). Stuart