Second day: scroll

reidrac on 2011/09/12 21:50 of usebox.net
— edited on 2011/09/13 16:21

I've improved the tiles, just a little bit, to fix some awkward cases I didn't like.

And then started with the scroll... :(

Worth reading: a newbie guide to pygame, or TL;DR: among lots of interesting stuff, I learnt today that there are some kinds of scroll you can't implement with pygame because of performance.

Nevermind. I think I've got a reasonable scroll with 30 FPS (sic). And that's all for today.

Tomorrow I'll try to add the main character and start playing with physics for the red blood cells (oh, please... don't take it too seriously!).

Update: read the comments!

(log in to comment)

Comments

Cosmologicon on 2011/09/12 22:25:

Over time the advice about performance on that page will become less and less true. I've never used the dirty rect animation they give in Rule #5 and I always find a way to make things work in pygame. Granted I'm not as demanding as most players; I think that 30fps is just fine. But still I think it's a bit much to say that there are some kinds of scroll you can't implement in pygame because of performance. Your graphics don't look any more complicated than what we did in Fractured Soul, and the engine we used for that game (gummworld2) just calls pygame.display.flip.

reidrac on 2011/09/12 22:46:

I think this hw is capable of more than 30 FPS.

The scroll I've implemented looks OK to me, even at 30 FPS, but I wouldn't call it smooth. After trying Fractured Soul, and I must be doing something wrong!

bitcraft on 2011/09/12 23:24:

when i do scrolling, i blit the background over itself, leaving the area when new tiles need to be drawn, then redraw the areas that are being scrolled into view. this breaks everything down into 1 big blit and a just a few smaller blits in the "new" areas. manually locking your surfaces before blitting your tiles will help, too. with this i can get into the 100's of fps even without dirty rect animation. good luck!

reidrac on 2011/09/13 07:23:

Thanks, I'll try with surface locking.

I've tried different approaches, and right know I'm just bliting from from a big surface with ALL the scenario already drawn (can I have your memory?). So I can lock the surface and I don't need to unlock it again!

dotteri on 2011/09/13 09:32:

Why not draw just the tiles that will be seen in screen? I think that doing this can help you improve performance.

reidrac on 2011/09/13 09:40:

@dotteri: That was my first version, but after getting a choppy (non-smooth) scroll, I moved to the other approach that is supposed to be faster (instead of blitting X x Y tiles every loop interation, I do that for all the map BEFORE entering the game loop so I have a static background to get the area I want to show).

I'm looking forward to go try the locking thing this evening!

saluk on 2011/09/13 10:28:

It probably doesn't matter, but make sure you are calling .convert() on graphics you load in pygame. If you just pygame.image.load() instead of pygame.image.load.convert() it is not quite as optimized.

Hugoagogo on 2011/09/13 10:33:

I ran into similar problems with pygame trying to make an large scale rts where you could do alot of zooming in and out, then i found pyglet :)

bitcraft on 2011/09/13 16:07:

ok, this message board keeps eating my posts with 500 errors! such a pain!

reidrac on 2011/09/13 16:20:

Yes, mystery solved! The problem is in self.clock.tick(fps) -- I don't know how to fix it :)

You can't blit a locked surface (probably I got bitcraft comment wrong).

reidrac on 2011/09/13 16:50:

I don't know, it doesn't look right. I've tried this:

http://pygame.org/wiki/ConstantGameSpeed

and it really works better, but I don't understand why. I better keep working in other things before I get out of time!

bitcraft on 2011/09/13 17:09:

i noticed i made a huge speedup when locking a surface before lots of *draw* calls, not blit. sorry if i lead you astray there. tried it myself, can't lock before a blit. =(

i don't know if you are doing this or not, but i've seen some people do a load(image).convert() every time they blit an image. if you are doing this, it could be so much faster if you pre-load (and convert!) all the tiles into a list or dictionary, then when you are blitting them, just get the image from the list or dictionary. Most computers these days should have no problem with this using simple pygame surfaces.

reidrac, although constant game speed sounds cool, i tend to design games where the speed is as fast as possible, then just cap the framerate. its so much easier that way.

also, i have a pet peeve with frames dropping, especially in action style games. i'd rather the game slow down if the action is too much, rather that it dropping frames and putting me in a situation where i die or do something stupid because the game locked up and i couldn't control it.

Python Jedi on 2011/09/13 19:08:

I'm making a platformer and I actually have all my tiles as sprites, for collision and images in one. Then I just have my camera class grab the sprites that collide with it's rect, then draw those on the surface (the camera is a sprite as well, I move the tile's rects back the amount that the camera's rect is forward, then pass the translated rect to the blit and it works fine. the same thing applies to up and down, but I'm not going to scroll vertically in mine.) hope this helps!