Blitting Management

11 posts

Flag Post

Need some advice.

Right now, I blit my entire map onto screen.
I do this in a certain order for depth.
First the entire map is filled with background “tiles”, than clouds are randomly put down, than the interactive map tiles (collisions).

I’m about to move on to enemies and I would like to know what would decrease performance more…

  • Using a for loop to put down a 25×25 background tile in every empty tile space, than moving the clouds, than moving enemies and player.
  • find out which tiles need to be reblitted, reblit them, move clouds, ect.
 
Flag Post
Originally posted by alecz127:

Need some advice.

Right now, I blit my entire map onto screen.
I do this in a certain order for depth.
First the entire map is filled with background “tiles”, than clouds are randomly put down, than the interactive map tiles (collisions).

I’m about to move on to enemies and I would like to know what would decrease performance more…

  • Using a for loop to put down a 25×25 background tile in every empty tile space, than moving the clouds, than moving enemies and player.
  • find out which tiles need to be reblitted, reblit them, move clouds, ect.

If you kept track of all the tiles which would change and how they would change it should be less resource intensive to only change those I think.

 
Flag Post

Ah I forgot to add something…

  • Would it be less resourceful to use two separate “canvas” for blitmaps. One for moving blitmaps, and one for stationary ones. Or stick to using a single one.
    If I were to just reblit “everything”, I.E. everything on the moving back.

Moving canvas would have all interactables (player, enemies, collectables, powerups, whatever, clouds, ect) As well as background “empty” tiles.
So it would reblit all background, than enemies.

OR should I still just search?

 
Flag Post

on my lib i have a spacial hash with blocks of tiles, and i test if that blocks are on screen on render time.
it was slow to do the test for every tile, but it’s very fast using this way.
i’m using blocks of aprox. 10 tiles to do the tests, and it’s much faster than testing everyone.
this is for the tilemap blitting layer, but i do the common test for the characters blitting layer.

 
Flag Post

Don’t reblit everything unless necessary. Try having some form of time measurement so the enemies know where they are, and which frame all the clouds should be on, etc. Only blit the canvas you’re using, or it’s resource intensive.

I suggest blitting all tiles on screen, and from there blitting a couple of tiles outside the screen in case the player moves into them and finds them.

 
Flag Post
Originally posted by jasonjie88:

I suggest blitting all tiles on screen, and from there blitting a couple of tiles outside the screen in case the player moves into them and finds them.

All in one frame!? The player isn’t going to ‘find’ anything off-screen. If it’s off-screen, don’t draw it, you’d be wasting your (computer’s) time.

Background layer: If it’s not too big (the whole level doesn’t exceed the maximum bitmap size allowed (check the specs)), draw it from the tiles once on a separate bitmap. Then copy only the section of that bitmap that the player should see onto your screen. Of course there should only be the completely unchanging stuff on that bitmap, but you could still make it change over time: Add the blast marks from explosions, shell casings, blood stains and corpses on it as they reach their permanent configuration and your background will reflect the state of the battle, for cheap.

Clouds: If you have a few clouds shapes and they end up not moving relative to one another, this layer could also be a separate bitmap from which you copyPixels() every frame onto the screen only the portion needed, so you don’t have to waste time re-composing their configuration every frame. Otherwise blit them on as needed. Make sure to test that they are indeed on screen before drawing them, of course.

Enemies, collectibles, player, effects: Parse through the respective arrays and draw whatever should be drawn, directly on the screen. I do not know any way around that portion. Make sure you get rid of stuff (dead enemies, collected powerups, etc…) when they’re no longer needed.

I’ve heard the idea of keeping track of everything that moves and only redrawing the portions of the screen that need it being floated but:
1) It seems like a logistical nightmare to me.
2) If you have any type of scrolling you’ll end up having to redraw everything more often than not.

 
Flag Post

http://www.alkemi-games.com/alkemi-flash-bitmap-renderer-part-3-blistpool-on-fire/
check that, i’m using it and is the best blitting lib i found.

 
Flag Post

@Ace_Blue: Yes, they’re not going to find anything off-screen. But if the player moves and the camera scrolls to the ‘off-screen’ bit, they will find something. I suggest that’s drawn in advance so there are no surprises.

Also why would you need to draw an entire map? Draw everything that moves and doesn’t move separately. That way you get what is called dirty blitting, which is more efficient that the blitting you’re doing.

 
Flag Post
Originally posted by jasonjie88:

@Ace_Blue: Yes, they’re not going to find anything off-screen. But if the player moves and the camera scrolls to the ‘off-screen’ bit, they will find something. I suggest that’s drawn in advance so there are no surprises.

Also why would you need to draw an entire map? Draw everything that moves and doesn’t move separately. That way you get what is called dirty blitting, which is more efficient that the blitting you’re doing.

If the player moves then a frame has elapsed. If a frame has elapsed then the screen has to be redrawn. If the screen has to be redrawn the current screen is going to to be erased. If the screen gets erased then anything ‘off-screen’ that you previously drew ‘just in case’ is being thrown away as well without having ever been seen. If it hasn’t been seen then you’ve wasted your time.

And the point of drawing the whole map on a separate bitmap if possible is to do it once at the beginning, so you don’t have to loop through the tiles every frame to redraw the same configuration over and over.

No question that dirty blitting is faster than redrawing the whole screen every frame. Whether it’s worth the extra effort (which appears, to me, at first glance, without having tried to implement it so YMMV, to be a lot of effort) is likely to depend on whether or not it is necessary to remove lag.

 
Flag Post

Dirty Blitting??!
HAHA! That is wonderful stuff.
The tutorial that originally taught me about blitting did mention that some people entirely used blitting, and some use a little along with other stuff.
I thought that using ALL blitting would be even more effective, but after hearing what you guys thought…. yeah…. no.
The screen does scroll. Need I say more?

Thank you nineraser for the tutorial.

I think that this complex “blit everything” thing should be saved for when the game is finished, or I have a lot of spare time to make sure I set it up correctly. I attempted it yesterday and I can tell its going to take some.

 
Flag Post

it’s very hard to apply “blit everything” with a completed game that doesn’t do that. at least as i see it.

some people do blitting for the scenario and uses sprites or movieclips for objects, but it works well when there isn’t a lot of them at the same time.