Path: chuka.playstation.co.uk!news
From: sceetech <ps_yaroze@interactive.sony.com>
Newsgroups: scee.yaroze.programming.2d_graphics
Subject: Re: GsIMAGE pmode 8 - another red herring
Date: Fri, 04 Apr 1997 15:19:25 +0100
Organization: SCEE
Lines: 124
Message-ID: <33450DEC.7AE5@interactive.sony.com>
References: <01bc289b$f6314fc0$c793989e@fourny.demon.co.uk> <33422052.4C18@interactive.sony.com> <01bc28b3$29e10100$c793989e@fourny.demon.co.uk>
Reply-To: ps_yaroze@interactive.sony.com
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)

grim wrote:
> 
> OK you asked for it :)
> 
> Sorry if it's a bit C++. I'm not ashamed. Picture if you will an
> object-oriented fishing game.
> 
> main()
> {
>         SetVideoMode(MODE_PAL);
>         GsInitGraph(320, 256, 4, 0, 0);
>         GsDefDispBuff(0, 0, 0, 256);
>         CSea sea(0, 0, 0, 0);
> 
> calls contructor for CSea
> 
> CSea::CSea(int player1, int player2, int player3, int player4)
> {
>         mOT[0].length=OT_LENGTH;                //ordering tables, copied
>         mOT[1].length=OT_LENGTH;                //from the balls demo
>         mOT[0].org=mTags[0];                    //but irrelevant I think
>         mOT[1].org=mTags[1];                    //given I only get where I do
>         CFish *firstfish=new CFish(30, 30);
> 
> calls constructor for CFish
> 
> CFish::CFish(unsigned int x, unsigned int y)
> {
>         mSprite = new CSprite(1);
>         mX=x;
>         mY=y;
> }
> 
> calls constructor for CSprite
> 
> CSprite::CSprite(int frames)
> {
>         mFrames=frames;
>         mTPages=new unsigned short[mFrames];
> }
> 
> finishes, drops back to CSea constructor again
> 
>         firstfish->LoadSprite();
> 
> calls LoadSprite in CFish
> 
> void CFish::LoadSprite()
> {
>         mSprite->Load(0, "small.tim", 576);
> }
> 
> calls load in CSprite
> 
> void CSprite::Load(int frame, char *filename, int filesize)
> {
>         GsIMAGE image;
>         RECT pixRect;
>         RECT colRect;
>         unsigned short tPage;
> 
>         MWRedirectIO(__MWIO_CDROM);
>         void *location=malloc(filesize);
>         long bytes=MWbload(filename, location);
>         GsGetTimInfo((u_long *)(((char *)location)+4), &image);
>         pixRect.x=image.px;
>         pixRect.y=image.py;
>         pixRect.w=image.pw;
>         pixRect.h=image.ph;
>         LoadImage(&pixRect, image.pixel);
>         DrawSync(0);
>         tPage=GetTPage(0, 0, pixRect.x, pixRect.y);
> 
> Single step the debugger through that lot and it always crashes on
> LoadImage. Likewise put a breakpoint on GetTPage it will always crash
> before the breakpoint.
> 
> image.pixel points 40 bytes after location, on the heap (initialised by
> codewarrior
> between the end of the program and the start of the stack, both in default
> positions). I believe there is a CLUT just before the pixel data.
> 
> 576 bytes are actually read by MWbload, and this is also the DOS size of
> the TIM.
> 
> I downloaded the textutil file as was suggested, but it looked just like I
> expected it to, pretty much just like the code above. I wouldnt normally
> pester people with my stupid bugs but this has been annoying me for 3 days
> and I'm just not getting anywhere with it. Please let there be a simple
> oversight on my part.
> 
> yours in hope
> 
> Grim


Firstly: code generated should be independent of the difference
between siocons and CodeWarrior, so that people using either
can run it easily. Hence, ALL CodeWarrior-specific functions
should go in special procedures, only to be called
(eg) ifdef CODEWARRIOR. Failure to make a clean separation
will prevent people without Codewarrior from using your
code.

Secondly: multiple actions next to declarations, and
no check for malloc;
but my real suspicion is the combination of 
memory loading only just before its use,
and dubious casting for GetTimInfo; the memory loading
MAY be implemented as non-blocking process,
in which case the loading won't finish until
DrawSync(0), with clearly disaatrous consequences.

Remedy: do loading into main memory way before anything else
and make certain in finishes before using anything;
and for debugging, it is usually Much quicker to use
printf to find the values of all things (and the
point at which crash occurs) than it is to use the debugger.
Print out all things and you're usually bound to find it;
stepping through the debugger, it's very easy to not check
all variables.


	Lewis