A simple scrolling game, and some issues I'm having

[Jason]

Attached is a screenshot of it.

Basically you control a cloud, that flies over the randomly generated large (infinite?) land. WASD controls, strafe across the world, mouse up down increases or lowers the size (height, visually) of the cloud, and alters the over all speed.

That's the gist.

I would like to draw everything in game, which would be (which is what I'm using ColorLayer for, can't find a better solution):

Cities (those brown rectangle things you see)
Cloud (a bunch of alphaed ColorLayers distributed by using random.triangle)
River (draw line)
Forests (to be drawn, I guess using ColorLayers like pixels?)

Problem is, obviously, it's it a bit of a hog and gets slow. A city will have, say, 20-50 ColorLayers of varying sizes and colours. A City is a Sprite with ColorLayers added to it.A Sprite is a BatchableNode, so I guess that's as optimized as it could be?

I have the cloud on the main layer, and the Land Layer (cities + river +land +whatever else) that I move based on the user input. So really the user is moving the land layer and staying still.

I looked at ScrollableLayer, but didn't find enough examples, and looks like it wanted one of those tile.xml map things, which I'm not using.

So, my questions are:

1) Is there a better way to draw the stuff I want to draw in game?
2) Is there something I should be looking at to speed things up?
3) Is it basically just unfeasible to draw anything in game and hope for decent performance?
4) If I add and remove things to the LandLayer as they become viewable, will that get me better performance?
5) Any other way to write this (I'm sure there is) that'll result in faster code?

Thanks!
J

[Jason]

 I'm going to reply to my own question, in case someone else has the same questions, or in the more likely event that I dont' remember what I did, and need to look it up.

1) There is a better way to draw stuff in game. That's to use the Python Imaging Library to dynamically create a PNG on the fly, then write that to disk, then use that for the sprite. This gives you both better drawing tools and better performance.

For example, a city has many buildings, lets say 20. Before I would draw out  the building with ColorLayers and add them all to the City sprite. The problem is now you have 20 images for one sprite. With the new method you draw the buildings out in PIL, write it to disk, and add THAT to the City sprite. Allows for flexibility and performance.

2, 4) Obviously, you cannot have an infinite layer of infinite objects. I think (I still have to implment this) you can have a primitive type of frustrum culling where you pop the sprite onto the scrolling layer as it becomes visible (using the relative distances (point_to_world method) between the Cities and the Cloud). Having an object in memory and NOT adding it to a node or layer makes a huge performance difference. This should have been obvious to me.

Other Notes:
I couldn't just keep the Cloud on one layer, and the scrolling layer on the other, I was having trouble with getting collisions right. So I just put them on the same layer, and scrolled the land one way, and the cloud the other, making the cloud look like it was staying still, and making it easier to find the coordinates of the City/Forests/Whatever and the cloud.


A Bug I Couldn't Figure Out:
I wanted to rotate the world around the cloud. The problem is that I'm rotating the entire world, but the rotation point stays still. So as I move away from the initial starting point, the rotation angle becomes larger, and just doesn't behave as it would if the rotation point was centered on the middle of the screen.

Hope this helps someone in the future.