So I removed the width and height values from each tile table and hardcoded them in the draw routine. function tile:initialize(img) local theQuad local default = {} local width local height if global.spriteHolder[img] == nil then self.spriteKey = img global.spriteHolder[img] = {} global.spriteHolder...

Two things: First, I want to be able to handle arbitrarily large map sizes. Even ludicrously large maps. For no reason at all than because I said so. There is no specific problem this is causing at the moment. Second, I don't understand what's taking up all the memory, and learning the answer to tha...

The attached game loads up a large map with just two or three small tiles that get repeated over and over again. Ideally the memory used would not be much more than whatever is needed to hold and draw those two or three tiles When a tile is loaded, the code checks the global sprite table to see if t...

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

Okay, so I just messed around with the framebuffer idea. LOVE crashes whenever I try to make a framebuffer larger than 16384 by 16384, which, with 50 by 50 tiles is a 327 by 327 tile map. And there are weird performance issues; it stalls and jumps for what seem like no reason. One of the things I'm ...

So when moving, the framerate would be just as bad as it is now; when standing still, the framerate would fly?

Robin, could you help me out a bit? Maybe some pseudocode or a link? I'm not getting something basic about the idea. If the visible portion of the map changes (which it does every time the character moves), won't I have to redraw the framebuffer every time, making it just as bad as the current metho...

Kadoba: I do use dt. "A" and "S" make the character movement and animation faster/slower. The speed is displayed in the upper left-hand corner. 100 is the "base" speed, but I set it to 500 just to run around the map quicker during testing. I'll give spritebatches a look...

The adventure continues! Thanks to my last question , I got schooled in how to draw a more efficient map. And it worked! I implemented a "spatial hash" and all is right with the world... except for one thing. The framerate craters when I zoom out, I assume because LOVE has to start drawing...

Currently I loop through every tile and check whether or not it's on the screen. If it is, it gets drawn. If not, it doesn't get drawn. Simple enough, and it seems to work okay, but the framerate got cut in half when I tried it with a larger map. Instead of high 200 FPS, I'm getting low 100s. Right ...