Path: chuka.playstation.co.uk!news From: Chris Chadwick Newsgroups: scee.yaroze.freetalk.english Subject: Re: Thanks, but still not sure... Date: Wed, 06 May 1998 13:58:48 -0700 Organization: PlayStation Net Yaroze (SCEE) Lines: 65 Message-ID: <3550CF08.2060@dial.pipex.com> References: <3549FEDD.6D64@writeme.com> <354DEE72.7982@writeme.com> NNTP-Posting-Host: am214.du.pipex.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Win95; I; 16bit) Hi James I believe I've found out why your gradation prog is behaving oddly. Firstly, you aren't setting the .attribute member of the GsGLINES. This in itself doesn't much matter when using static or global variables as you can be sure the memory they occupy is reset (to 0's) when they are created, which happens to be a perfectly valid .attribute value. However, no such reset occurs with automatic/local variables which are created on the stack. This means the unitialized .attribute member could contain garbage values - including values that equate to setting the .attribute to 'display off'! This is indeed what seems to be happening. The first few hundred lines display fine because their variables use 'fresh', zeroed memory (where the stack hasn't previously reached this far down in mem before). However, the later variables (higher up in memory) start hitting old, garbage stack values - hence, the intermittent display of the later lines. Hope this makes sense? By the way, you don't actually need to use an array of GsGLINES anyway. Just use a single GsGLINE variable and initialize it's members each time before sorting it into the OT. I think doing this is OK - it seems to work, anyway! Hope this has helped to shed some light - it had me scratching my head for a time :) Cheers, -Chris James Rutherford wrote: > > Thanks for your help guys - the very prompt response was appreciated > (and the information sorta made sense too!) > > I tried a couple of workarounds according to how I understood the > problem and I'm still a little confused... > > If the problem is to do with the array being destroyed after the local > call has finished (as seems a very plausible explanation) then defining > GLbground[x] as a global/static variable should and does work. However, > so should all of: > > 1) Defining GLbground[x] in main and then calling > DrawGradient(&GLbground[0]) as a pointer to that array. > 2) Inserting the DrawGradient code straight into main(). > 3) Stalling for a number of VSyncs within DrawGradient() after the > DrawOt(...) command has been called. > > I have the same problem when using all three of these work-arounds. > > Any enlightenment would be again, well appreciated - > > Cheers, > > James (~mrfrosty).