Alternative tile implementation

[T-Bone]

Hi lövers! I've been thinking about an alternative way of implementing fine tile-scrolling, that basically works like this:

At start of a level in a game, the entire level's tiles are drawn to a framebuffer (which will be larger than the screen) which is then saved and kept untouched for the rest of that level. Then, the world can be scrolled by simply moving where on the screen the framebuffer is drawn.

As I see it, there are both good and bad aspects of this approach.

Good:
Easy to implement
Fast, since picking tiles and stuff is only done once

Bad:
Uses more memory (since the entire level is graphically loaded at all times)
Inflexible, since changing any tiles in the middle of the game would require the world to be redrawn, which would be slow.

Are there any probllems with this approach that I've overlooked? If not, do you think it would work well, if I make a game designed to work this way (like not having too large maps and not chaning the tiles in the middle of gameplay)?

[Robin]

Framebuffer support is the big question mark here. Some people don't support very large framebuffers, or even no framebuffers at all.

Also, if you want to use FBs, you will probably need to make them both square and PO2 to maximize your audience.

[kikito]

I would go with an intermediate solution and render the world in "patches"; maybe 512x512 pixels. This would be minimally slower than having everything rendered on a single call, but less taxing on the graphics memory (If I remember correctly, it's easier to allocate 4 patches of 512x512 px than 1 area of 1024x1024).

What about spritebatches?

[T-Bone]

Framebuffer support is the big question mark here. Some people don't support very large framebuffers, or even no framebuffers at all.

Also, if you want to use FBs, you will probably need to make them both square and PO2 to maximize your audience.

Really? My computer can't handle SpriteBatches at all, but all Framebuffer's I've thrown at it has worked just fine, and it's just a netbook. Perhaps my computer is different from the norm?

I would go with an intermediate solution and render the world in "patches"; maybe 512x512 pixels. This would be minimally slower than having everything rendered on a single call, but less taxing on the graphics memory (If I remember correctly, it's easier to allocate 4 patches of 512x512 px than 1 area of 1024x1024).

What about spritebatches?

I was thinking about using a single 512*1024 framebuffer (the game window is 320*240, upscaled), do you think it would be too large? And is not having square framebuffers really an issue?

Maybe using multiple 512*512 is better though. Still very easy to implement but much more flexible. I'll try that.

[slime]

There is a bug in the current version of LÖVE which prevents spritebatches from working on integrated intel cards. Perhaps you'll be able to use SB's in 0.8.0, if you have an Intel card.

[T-Bone]

There is a bug in the current version of LÖVE which prevents spritebatches from working on integrated intel cards. Perhaps you'll be able to use SB's in 0.8.0, if you have an Intel card.

Indeed I do. Good to know, thanks!

[Taehl]

From my experiences with Isome, spritebatches proved to be better for this situation in every way (faster, less memory, more compatible). Just keep in mind that this works best for static stuff (remaking a huge spritebatch can be slow) - anything that moves or interacts are better with regular draws. Also, last time I checked, Love had positioning issues with huge spritebatches (more than 63,000 sprites on one sheet, if I recall), so there's another reason to break your map into chunks.

[T-Bone]

From my experiences with Isome, spritebatches proved to be better for this situation in every way (faster, less memory, more compatible). Just keep in mind that this works best for static stuff (remaking a huge spritebatch can be slow) - anything that moves or interacts are better with regular draws. Also, last time I checked, Love had positioning issues with huge spritebatches (more than 63,000 sprites on one sheet, if I recall), so there's another reason to break your map into chunks.

Obviously, I had planned to use regular drawing for all game objects, destructable blocks etc.

The idea of spritebatches being more compatible than framebuffers seem really wierd to me for obvious reasons Integrated Intel graphics aren't excactly uncommon. Are Framebuffers really that incompatible?

[BlackBulletIV]

If you're worried about framebuffer support and are using images for your tiles, you could always use ImageData. Just load the tile images as ImageData objects, paste them into bigger ImageData objects (say, 256x256), then convert them into Image objects.

[Taehl]

The idea of spritebatches being more compatible than framebuffers seem really wierd to me for obvious reasons Integrated Intel graphics aren't excactly uncommon. Are Framebuffers really that incompatible?

Aside from this one specific bug, spritebatches should be compatible with everything. Framebuffers, on the other hand, aren't supported by a wide range of old and/or cheap graphics hardware. You can think of a spritebatch as simply an optimized list of things to draw. But framebuffers require hardware support and decent drivers.