Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: Elliott Lee <tenchi@netmagic.net>
Newsgroups: scea.yaroze.programming.2d_graphics
Subject: Re: Invisible 256x256 TIM limit?
Date: Tue, 10 Feb 1998 10:01:18 -0800
Organization: .
Lines: 64
Message-ID: <34E095EE.99BA51E@netmagic.net>
References: <6bp6mn$3jg1@emeka.playstation.co.uk>
Reply-To: tenchi@netmagic.net
NNTP-Posting-Host: dhcp-e-39-245.cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.03 [en] (Win95; U)

*nod*

That what was what I was going to try next.  This will prove useful
when saving the contents of the screen.  E.g. using sprites to
compose a background image and saving the background into memory.

- e!
  tenchi@netmagic.net
  http://www.netmagic.net/~tenchi/yaroze/

Lewis_Evans@Playstation.sony.com wrote:
> 
> From: Lewis_Evans@Playstation.sony.com
> To: news@playstation.co.uk
> 
> You _can_ display TIMs with a width greater than 256, but need to be a
> little devious.
> 
> All polygons, sprites, etc have uvs for texture mapping; these are type
> unsigned char,
> hence the 0-255 limit. The timv.bat viewer probably assumes this, as do
> most programs.
> (The main reason for this is that texturing with such large TIMs carries a
> heavy price
> if you texture many polys, due to severe texture cache missing and
> reloading each time).
> 
> However, if you use MoveImage or LoadImage, you can get a 320x240
> image onto screen without any need for chopping it into bits.
> Eg MoveImage: just directly copy the texture from off-screen to the
> double-buffer area of VRAM.
> 
>      Lewis
> 
> To:       Lewis Evans
> cc:
> From:     news @ playstation.co.uk
> Subject:  Invisible 256x256 TIM limit?:scea.yaroze.programming.2d_graphics
> 
> From: dblee <dblee@netmagic.net>
> Newsgroups: scea.yaroze.programming.2d_graphics
> Subject: Invisible 256x256 TIM limit?
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Hello,
> I played around with the sprite functions over the weekend and ran
> into a problem with a 320x240 TIM.  Apparently the width was clipped
> to 256 pixels.  I don't remember reading about this limitation in the
> documentation or in any message in this newsgroup.
> When displaying the image back (I tried 8-bit CLUT and 15-bit
> direct versions of it), I got about 3/4 of it.  Coordinates
> (0,0)-(255,239) seemed to be fine, but (256,0)-(319,239) seemed to
> be just a wrap-around of the first 64 pixels.
> I eventually gave up and chopped the image in half (two 160x240x8
> TIMs) and that filled out the screen.  :P  If anyone knows why this
> happens, please let me know if I'm doing something wrong.
> p.s.: the TimUtil.exe viewer converted it fine.  The preview showed
> a full 320x240 image just fine.  However the timv.bat viewer only
> ended up showing a 64x240 window of the image stretched out over the
> entire screen.  Odd.
> Puzzled,
> - e!
>   tenchi@netmagic.net
>   http://www.netmagic.net/~tenchi/yaroze/