Fast way to draw large number of quads?

[slime]

With framebuffers I recommend creating one just a little bit larger than the screen size (or the next biggest power-of-two), there's no need to draw tiles that aren't currently on the screen. You would then re-draw to the framebuffer if the tiles have changed (which won't happen very often, relatively speaking).

[adrix89]

Drawing sprite batches is just as fast as frame buffers as long you don't initialize them every frame(clear, addq).

[Ensayia]

It might be worthwhile to note that not all computers can do framebuffers, particularly old hardware or on board graphics chipsets it seems.

Ultimately your compatibly is up to you.

[jeremiahs]

Further experimentation with the framebuffer idea has made me decide it won't work the way I might hope it to work.

I think I'll table the idea, because it's a "want" not "need" thing, and look at spritebatches/multiple spatial hashes for rendering when I decide it needs to be implemented for realz. Thanks for the advice!

[tentus]

A couple things that you should do post-haste:
1) move images and sounds into folders. This will prevent future headache. I personally recommend making a 'media' folder and then making subfolders for images and sounds, but that's just me.
2) Make your images PO2. I had to run this in the most recent nightly build in order to be able to see anything.
3) Snap your renderings to the grid. Right now as I move around I see thin black lines constantly, where things are a percent-of-a-pixel over.

Good start though! Feel free to read through the source of my game, Kurosuke, I see that you do several things very similar to how I did them: feel free to lift any code that may help you out. </blatant plug>