Path: chuka.playstation.co.uk!news
From: rs108@mdx.ac.uk (Robert Swan)
Newsgroups: scee.yaroze.programming.2d_graphics
Subject: Re: buggged
Date: Mon, 16 Mar 1998 18:31:50 GMT
Organization: PlayStation Net Yaroze (SCEE)
Lines: 57
Message-ID: <350d6fd1.5899277@news.playstation.co.uk>
References: <350C8EA6.555A@which.net>
NNTP-Posting-Host: stu-dialup3.mdx.ac.uk
X-Newsreader: Forte Free Agent 1.11/32.235

Darn it, Id already written the post and now everything is stated
twice. Oh well... here's the same thing again :) (plus theres a
download at the end)

There's a few problems. some of which I'm sure cause trouble, others
Im not so sure on, and there are other areas that might be a problem,
but I can't tell from the code supplied.

>> #define SCREEN_WIDTH (512)
there are problems with your screen size. 512 is a valid vertical
resolution, but your setup for GsDefDispBuffis wrong. 512 is
interlaced, meaning that instead of having two buffers side by side or
on top of each other in video ram, they actually occupy the same space
(usually (0,0) to (SCREEN_WIDTH, 512)). Buffer 0 only draws on even
numbered rows of pixels, and buffer 1 on odd numbered rows of pixels.
The correct calling for GsDefDispBuffwould be GsDefDispBuff(0, 0, 0,
0). Also, the video ram itself is only 512 pixels high, so even if you
wanted to set two interlaced buffers, they would need to be at
locations (0,0) and (SCREEN_WIDTH,0) rather than (0,0) and (0, 512),
which is what you called.

>> #define SpriteAdd (0x80010000)//address of tim
not sure about this one. All examples Ive seen start placing tims,
tmds, and sound data in memory at 0x80090000. Im assuming that this
because anything before that gets used by the system and therefore is
likely to mess up big time. Somewhere on one of these newsgroups it
gives the limits for memory use, but I can't remember where, sorry.

>> TestSprite.u = 0;
>> TestSprite.v = 0;
Im not sure you can always assume that these are zero (unless of
course you made sure the sprite's location in vram was on the boundary
of a texture page, but t might not be a problem here.

The other problems are to do with when you converted your .bmp or .gif
images or whatever into a .tim. If you position your sprite in vram
where a buffer will be, then it will get overwritten and you won't see
anything. Also, if your location means that the sprite covers more
than one texture page then it messes up (how, Im not sure). Also if
your CLUT has the same problems, your sprite will come out with dodgy
colours.

One last thing (unlikely though) is that the auto file should load the
.tim into the same area of memory as specified by SpriteAdd.

For some strange reason, when I tried to get your code to run I came
up with an error I'd never seen before, so I started again, trying to
match your program which worked. The complete files can be got from

http://www.netyaroze-europe.com/~middex2/ftp/sprite1.zip

In my programs Ive edited the screen res to a more orthodox 320x240,
but Ive altered it and it works in any of the stranger combinations
(including interlace).

Robert Swan
rs108@mdx.ac.uk