Ways to improve sprite performance with tile-based games? (exo)

[danShumway]

Hi everyone, I'm coming over from https://github.com/danShumway/python_math, I just wanted to ask some quick questions about performance on the XO laptop.

We're running into some delays with keyboard events registering, which we believe is related to the number of sprites we have on-screen at a time. Because our game is tile-based, and mostly static, we could theoretically leave those regions of the screen completely un-drawn, and leave those sprite un-updated.

Are there any ways within spyral to do this?

[rdeaton]

Spyral is actually doing its best to do this automatically for you. I'll look a bit this evening to see if that stuff is working well in your game, or if the detection for what is static is failing.

[rdeaton]

(As a note, we've had games with 2500 sprites on the screen drawn at full FPS without much trouble, so when it works, it works well)

[danShumway]

Huh. I'll dig through the code again and see what bottlenecks might be happening on our end. It's quite possible that one of our algorithms for moving or even just for registering input might have been coded really inefficiently.

Thanks for the quick reply!

[acbart]

Event registration has a big potential speed-up: passing in the scene explicitly to spyral.event.register [1]. Detecting it automatically is surprisingly costly - I've considered forcing users to always pass it in.

class MyScene(Scene):
     def __init_(self):
           ...
           spyral.event.register("input.mouse.down", self.do, scene=self)

So try adding that scene parameter and see what happens.

[1] http://platipy.readthedocs.org/en/latest/spyral_docs.html#spyral.event.register

[danShumway]

After fiddling around with a lot of stuff, what eventually ended up fixing the problem was making sure sprite positions were stored as int values (ie, 1 over .96).

I don't know if this is intended behavior or not, but the rest of my team is confirming that the game is running smoothly again. Thanks so much for your help!

[rdeaton]

Definitely not intended behavior that I'd really thought about, but it makes sense. Equality checks with floats are not reliable, and so internally it's hard to tell that it hasn't actually moved. We may be able to do some work to check rounded values though. I'll leave this open as a reminder to do just that.

[danShumway]

Thanks a ton.

[icarito]

Hi, I'm wondering if this is the issue I'm observing in my own games: "Detecting it automatically is surprisingly costly - I've considered forcing users to always pass it in."

If considering making this mandatory, perhaps it would be an option to make the event registration a method of the Scene class? I think it would make for nicer syntax:

class MyScene(Scene): def _init(self): ... self.event.register("input.mouse.down", self.do)

[icarito]

I've updated my latest game to include the explicit scene reference on event registration. Slight performance improvement, only with a few events registered. Probably bigger gains when using more events.

[icarito]

Btw latest game working at https://github.com/icarito/peru-learns-english (look into Games/ dir) I have a tweaked spyral included in that repo, that I use on XO because I removed parsley, because it is such a performance hog on the XO.

[icarito]

I'd close this one though, too broad.

[acbart]

Ooh, I'd love a pull request on the removal of Parsley. I think that @rdeaton and I agreed that parsley was hurting way more than it added. If I have free time to hack on Spyral anytime soon, then I'll be working hard to remove that component. If you can do it instead... Well, that would be excellent.