LÖVE

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).

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

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.

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!

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>