noobifull BitBlt Clipping

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
Shito
Posts: 21
Joined: Wed May 11, 2005 1:38 am

noobifull BitBlt Clipping

Post by Shito »

Ok, first of all I'm not really used to hardcore coding and all, I'm more used to nice graphical APIs, so sorry in advance for any noobiness that could emerge from this topic. ^^

Sooo, since we're accessing the video memory to blit an image on screen, I can easily understand how some things could go wrong if we try to blit something *outside* the screen.
In facts, with nem's function, only negative y's seem to be the problem and lead to a crash.
x's just seem to loop from one side of the screen to the other, and SCREENHEIGHT+ y's go weirdy weirdo after a certain value.
Hence this quick fix to nem's function :

Code: Select all

void pgBitBlt(unsigned long x,long y,unsigned long w,unsigned long h,unsigned long mag,const unsigned short *d)
{
	unsigned char *vptr0;		//pointer to vram
	unsigned char *vptr;		//pointer to vram
	unsigned long xx,yy,mx,my,sy,ry;
	const unsigned short *dd;
	
	////////////////////////////////
	// [Shito] Clip negative y's 
	ry = y ;
	sy = 0 ;
	
	if &#40;y < 0&#41;
	&#123;
		ry = 0 ;
		sy = -y ;
		d+=w*sy ;
	&#125;
	////////////////////////////////

	vptr0=pgGetVramAddr&#40;x,ry&#41;;
	for &#40;yy=sy; yy<h; yy++&#41; &#123;
		for &#40;my=0; my<mag; my++&#41; &#123;
			vptr=vptr0;
			dd=d;
			for &#40;xx=0; xx<w; xx++&#41; &#123;
					for &#40;mx=0; mx<mag; mx++&#41; &#123;
						if &#40;*dd != KEYCOLOR&#41;				// &#91;Shito&#93; discard keycolor pixels
							*&#40;unsigned short *&#41;vptr=*dd;
						vptr+=PIXELSIZE*2;
					&#125;
				dd++;
			&#125;
			vptr0+=LINESIZE*2;
		&#125;
		d+=w;
	&#125;	
&#125;
(Plus as an added bonus, the extra difficult transparent keycolor handling ^^)

Works fine on pspe, have yet to test it on my psp, but I just wanted to know : do you think I should also check the other edges, or since it doesn't seem to crash let's just leave at that and save us a little (*little*) cpu time ?
If you have an even easier solution, I'm begging of you, please go ahead and show me. :)
Smiths
Posts: 30
Joined: Sun May 15, 2005 10:01 am

Post by Smiths »

Am trying to import this function into RIN's source, but there's an error because there's no definition of KEYCOLOR.

What should it be defined as?
User avatar
alonetrio
Posts: 34
Joined: Sun May 15, 2005 12:10 am
Contact:

Post by alonetrio »

just assign to it the color you want to be transparent ;)

it's seem the "the extra difficult" joke was too much ;)
Shito
Posts: 21
Joined: Wed May 11, 2005 1:38 am

Post by Shito »

:)

Smiths, here's the one I use, "full green" being the transparent color :

Code: Select all

#define		KEYCOLOR	0x03E0			//transparent color &#40;full green&#41;
Smiths
Posts: 30
Joined: Sun May 15, 2005 10:01 am

Post by Smiths »

i threw it in RIN, setting white as a transparent color. it all compiled fine and ran without any noticable glitches, so I guess the routine works :)
Didn't notice much in the way of changes/speedups but I didn't really test it insanely.

Still, when it works, it works.
Shito
Posts: 21
Joined: Wed May 11, 2005 1:38 am

Post by Shito »

If you want to see what it changes, try to blit an image at (0,-10) with and without this little fix. ;)
subbie
Posts: 122
Joined: Thu May 05, 2005 4:14 am

Post by subbie »

-Y results in a write to a location before the Screen Address. Hense the crash. -X just wraps back into current space (unless Y is 0, in witch it writes outside of screen address).
Grover
Posts: 50
Joined: Wed Feb 23, 2005 3:13 am

Post by Grover »

Hi.. I added a similar thing to nems PG library. Source here:
http://forums.ps2dev.org/viewtopic.php?t=1752

it adds a clip flag to the function - there are times you will want to bitblt to an offscreen buffer (esp for things like the panorama sky map used in my terrain src) and they wont necessarily be a screens dimension size.
Bye.
Post Reply