Sprite Fragments, The 2nd

[Quiest]

Once again, this has to be asked:

How can you get rid of these sprite fragments, that stay on the screen?

I used Moogles solution:

restore_type=complete_restore;
dump_type=complete_dump;

for the time being, until I found out that it causes major slowdowns in menu and games (maybe you notice the slowdown at the menu at the minigame project after playing a minigame?)


I also tried using

map_clear(0,0,0);

in a loop, which just erases the background picture and make the background black . So, no good.


So, I want to know if there is a solution that is easy and that does not cause slowdowns.

Thanks.

 

[Bampt]

sprite fragments?? Never had that...
But if you want to clear your screen use clear_screen(); and if you want to kill all processes use let_me_alone();

 

[Quiest]

Sprite fragments are just some pixels that moving sprites left on the screen randomly. As soon as something moves over them they disappear.

They just look ugly
You maybe never encountered them, because you have a scrolling background in your games.

What exactly does the clear_screen(); do?
Does sound like it removes the background picture set with the put_screen command. So it wouldn`t help, either...

 

[skeezix]

Is it a bug in the engine that fenix is, or is it just your script?

ie: If you have a non-moving background, and a sprite moving left acrosds it, then of course you'll leave junk behind on the right (behind the moving object). Thats your own problem to fix

In that case its easy -- draw something behind the sprite.

ie: One of the easier optimizations is to always 'attempt' to redraw the entire playing surface, skipping things not altered since last update.

So in the idea when you've got a playfield, and a sprite moving left.. if thats all thats going on, then attempt to redraw everything but skipping unchanged stuff. When the sprite moves left, set a 'change' flag on things in the area (tiles under the sprite, for instance) so that your next sweep you'll redraw the stuff where the sprite was, and draw the sprite, and voila.. nice and clean and still fast.

You could also 'undraw' the sprite, then redraw the sprite..

jeff

 

[Quiest]

Seems rather complicated to do (in Fenix atleast).
Doing this for every moving object in every minigame is quite a lot work...

Of course I leave junk behind? So that does not only happen in Fenix?

I always thought it`s not my fault, since every Fenix game with still background (look at Devlkore`s shoot or that new Fenix Pang game for example).


I also tried to run the put_screen command in every frame, but that causes much more slowdowns...

 

[reaper79]

Is there a way to create a function that draws a transparent sprite behind all moving sprites?

 

[Quiest]

There is sure away to make that function yourself... But will a transparent sprite do the job?

Besides that, visible or transparent, for Squares32 for example that means not 6-7 moving processes at once on screen, it means there are 12-14, which would cause a slowdown also.


Hmm, maybe one big, transparent sprite in the background, rotating all the time? But that is just so... stupid...

 

[Steve-O]

I had something like this but when I had LOTS of Scrolling Text on the screen. (Lines would be left untill writing went over it)

 

[trooper]

I`m not a coder, As everyone probably already knows. But back in the day, I used to have a SAM Coupe, Which had Basic built-in. Well this version of basic used a PUT command to place sprites on the screen (Like so, PUT x,y,a$). It also had the option to create a MASK for the sprite (Like so, PUT x,y,a$,m$ (m$ is the MASK) which was a predefined (using the sprite co`ords)transparent version of the sprite so as not to interrupt the background.

Is there such an predefined option in Fenix that could be used ?

Trooper

 

[Quiest]

I don`t know, if so would be great. Anyone knows?

 

[Blah]

If the fenix port allowed for double buffering, we wouldn't have this problem

 

[WhiteFalcon]

On the PC I used to store the background where the sprite was going to be drawn, drew the sprite, show the screen (flip it) and then restore the background. This is fast for a small amount of sprites.

On the GP32 I usually simply redraw the whole screen, I know it is a waste of the processing power but the GP32 has been handling it well for me

 

[Quiest]

I tried redrawing the screen, Fenix needs much more power for that.

If only the map_clear(0,0,0); wouldn`t erase the background image, it would be fine.


EDIT: Okay, tried the invisible/transparent square rotating in the background. It does the job, but everything is going in slowmotion again, so that way is a NO, too