Sprite Tearing At The Top Of Screen...


pithy

Still Fresh
Joined
Apr 12, 2007
Messages
8
EDIT:

Problem still isn't solved... four days and still nothing even remotely close to fixing this. I am really starting to get disheartened.

No other fenix games display this behavoir so I know there must be a way to fix it.

Please, won't anyone help me?

I've simplified the code to be as basic as it can. The tearing only occurs when at 90 or 180 degrees.

In addition to the things below, I've gotten rid of the background, implemented a resolution of 100, and tried changing the framerate to 24, 30, and 60.

I've tried using different graphics. I even used the FPGs from games that didn't exhibit the issue like protozoa (which totally rocks Ruckage).

I've also tried altering the "angle" to be double and negative valued (e.g. instead of 180000, 540000 || -180000).

Angle is such an important property for dealing with sprite processes I can't really see working around this by having different facing sprite sets.

I've made it so that only the problem angles are used so it's easy to find the spot at the top of the screen.
Oh! and it only happens on the GP2X, the windows interpreter doesn't show the error at all.

Here's my code...
CODE

PROGRAM Gravity;

Global
CtDir=0;
XRes=10000;
YRes=10000;

//Let's start over

PROCESS Control()
PRIVATE xdim,ydim;
BEGIN

xdim=400;
ydim=400;
CtDir=0;
x=10000;
y=10000;

LOOP

SWITCH (CtDir)

CASE 0:
YRes=(y+=ydim);
FRAME;
END

CASE 1:
XRes=(x-=xdim);
FRAME;
END

CASE 2:
YRes=(y-=ydim);
FRAME;
END

CASE 3:
XRes=(x+=xdim);
FRAME;
END

END
if (x<0):x=32000;END
if (x>32000):x=0;END
if (y<0):y=24000;END
if (y>24000):y=0;END
if (key(_alt)): xdim = 0; ydim=0;END


END
END

PROCESS Crit(graph, angle)
BEGIN
resolution=100;

LOOP
graph=(graph+1)%8;
if (graph==0):graph=1;END
x=XRes;
y=YRes;
FRAME;
//Left on the thumbstick: gravity=left, Gravit butts to the left
if (key(_left)): CtDir = 1; angle = 90000;END
//Down on the thumbstick: gravity=down, Gravit butts to the ground
if (key(_down)): CtDir = 0; angle = 180000;END
//Up on the thumbstick: gravity=up, Gravit butts to the sky
if (key(_up)): CtDir = 2; angle = 180000;END
//Right on the thumbstick: gravity=right, Gravit butts to the right
if (key(_right)): CtDir = 3; angle = 90000;END
if (key(_space)): Chkqt();END

END

END

PROCESS ChkQt()
BEGIN
//Dramatically fade to black
fade_off();
//Kill all the other processes but this one
let_me_alone();
//Erase the screen
clear_screen();
//Delete the text written by the Header() process
delete_text(0);
//Exit this last remaining thread
exit("",0);
END

PRIVATE n;
BEGIN
//Set the screen size and pallette (x(width), y(height), Pallette(8bit, 16bit)
//SET_FPS(24,0);
set_mode (320, 240, 16);

//Load the graphics library for the game
load_fpg ("falling.fpg");

Control();
Crit(001, 180000);


END
 
Found something that might be related by searching "Flickering". The one adjective I don't use... :p

http://www.gp32x.de/board/index.php?showt...p;hl=flickering

Problem isn't solved though.

-I'm not using mode 7
-I tried not using the size command
-I tried not using put_screen
-I tried not having a backgorund at all
-I even tried moving FRAME to different places within the process

In the above link Goity says that he was able to resolve the issue. Does anyone know how?

~Pithy
 
Last edited by a moderator:
Okay, finally narrowed down the issue (still not fixed)...

I was using "angle" to rotate my sprites so that they'd be facing the right direction. For some reason, an angle value of anything other than 0 (I presume - not fully tested) will cause the sprite to flicker and tear if it is within the range of ~ y=0 to y=20.

So now my question is... Is there a less taxing/buggy way to rotate sprites other than the angle property?

I'm off to flip the sprites manually until then.

CODE


//Left on the thumbstick: gravity=left, Gravit butts to the left
if (key(_left)): GravDir = 2; angle = (270000);END




~Pithy

EDIT: Removed previous question and lengthy code snippet.
 
The sprite leaves garbage on the screen? (I`m too lazy to read the whole thread now).

You can try a put_screen(0,nr) if you use a background image, a clearscreen() if you use a black background or map_clear(0,0,rgb(r,g,B)) if you use a single color background, one of these every frame, this should simple overwrite that pixel garbage.
But it will also make your game slower.
 
First, thank you so much for posting. I really appreciate your response.

Unfortunately those solutions didn't work.

I did happen to find a livable work around however thanks to the tinkering that your suggestion resulted in.

The problem is, that whenever the sprite(s) are close to the top of the screen, if they have been rotated to a specific angle pieces of them disappear. At the moment my sprites are circles with eyes, so it looks like someone ate most of the pie and left me the last piece. The problem angles in this case were 90 and 180 degrees. When the sprite isn't rotated or rotated to 270 degrees they remain completely visible when passing through that portion of the screen. It's the angle that does it. I don't know why but if I rotate my sprite to 89 or 179 degrees it doesn't occur either.

So I used the FLAGS property to flip horizontal at angle=0 for down and horizontal and vertical while rotated to 270 degrees for left. This fixes the issue for now. But I'm worried that it'll pop up again when I need a bit more range.

Thanks again for your response, and please do let me know if you have any other ideas.

~Pithy
 
Very strange. I haven't noticed that problem before but I normally tend to avoid rotating sprites as it causes slowdown - Instead I create the rotated frames myself. It's time consuming but it does look nicer and helps keep everything fast. Infact as much as possible I avoid the angle command all together as It's is a hog if you are using lots of sprites, instead I use pre-calculated angles. (ask sam how much of a speed increase he got when he stopped using them in his boomshine game he's making)
If you want to use built in angle though (which for a few sprites should be fine) there is a local variable called xgraph which you can use instead of standard graph. It works like this:

Instead of rotating the sprite it picks the appropriate graphic from a set of pre defined images of different rotation. So the first task is to create the different directions in a graphic editor - can be as many or as few as you like. Eight would be a good number to start with for testing.

Next you need to create a table in the global section of your program like this

ship_graphic[]8,1,2,3,4,5,6,7,8

The first number in the table is the number of frames used for the directions and the folowing numbers are the graph numbers in the fpg which will correspond to various angles starting at 0 (facing right). With eight images the angles will be in 45 degree increments.

Next you need to tell the process to use these images by setting the xgraph variable in the process. This would be xgraph=offset ship_graphic;

From then on the process will pick the frame most appropriate to the angle.

Hope this helps a little.
 
Ah sprite rotation, missing pieces of the sprites! Yes, that is a Fenix bug you discovered, that appears at certain angles, due to some (wrong?) calculations.
This has been fixed in the newer versions of Fenix (0.92 is the newest) but unfortunately the GP2X only supports the 0.84 versions...

And thanks for that, ruckage, haven`t heard or xgraph yet :)
 
Back
Top