Alternative tile implementation

[BlackBulletIV]

You can think of a spritebatch as simply an optimized list of things to draw.

As far as I know, much of this speed comes from the drawing loops being in C++, meaning that no Lua to C calls (rather expensive) are required for all the drawing (and the loops are faster too).

[T-Bone]

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.

Well, the only problem is that if this bug truly effects all integrated Intel chips, then that's pretty serious, because the way I look at it, it's like this: either the computer is good, or it's bad.

If it's good, then it's no issue either way.

If it's bad, the chance of it being an integrated Intel chip is pretty high (using Core2Duo with no external graphics card is very common, and Atom is also fairly common these days).

Also, I have proof that framebuffers work fine on at least some crappy hardware with crappy drivers (an Atom with linux drivers, and believe me, these drivers are pretty crappy).

I'm not saying that you're wrong, but what you're saying contradicts my own experiences... Maybe the best solution is to ship multiple tile implementations, that can be chosen from an Options menu.

[tentus]

I'm not saying that you're wrong, but what you're saying contradicts my own experiences... Maybe the best solution is to ship multiple tile implementations, that can be chosen from an Options menu.

That will produce the highest compatibility, yes: but it's also by far the most work, and also the most prone to human error.

I have an Intel GX620 for work. It's a great machine, it can handle most anything I throw at it (I play Spiral Knights during my lunch break at 1920x1080) but it has no support for LOVE Framebuffers. In my LOVE projects I use newImageData to completely avoid the problem.

[T-Bone]

What is the difference between newImageData and framebuffers? And wouldn't an imageData approach require the creation of new objects every time you draw? Can the garbage collector handle that?

[BlackBulletIV]

What is the difference between newImageData and framebuffers? And wouldn't an imageData approach require the creation of new objects every time you draw? Can the garbage collector handle that?

ImageData is supported everywhere (as long as you use a Po2 compliant width and height) while framebuffers aren't supported on machines with certain (usually older) hardware and drivers.

No, you only need to create the Image object from the ImageData object once, just like other images.

[T-Bone]

What is the difference between newImageData and framebuffers? And wouldn't an imageData approach require the creation of new objects every time you draw? Can the garbage collector handle that?

ImageData is supported everywhere (as long as you use a Po2 compliant width and height) while framebuffers aren't supported on machines with certain (usually older) hardware and drivers.

No, you only need to create the Image object from the ImageData object once, just like other images.

Is that really all the difference there is? If so, how do i draw text on ImageData? I don't see any easy way to do that on the wiki.

And also, are you saying that you don't have to create a new Image even when you change the ImageData? That sounds wierd.

[BlackBulletIV]

No, you can only get/set pixels and paste in other ImageData objects with ImageData; that's its big limitation. But for tiles it shouldn't be a problem if you're just using images.

In that case you would have to create a new Image; but if you're changing it every frame, that defeats the purpose of caching.

[vrld]

What is the difference between newImageData and framebuffers?

An ImageData object is exactly that: Image data, i.e. the raw pixels. When you want to draw an image or even text to the image data, you have to do that using setting and getting pixels (ImageData:paste() can help you here).

A framebuffer on the other hand is a virtual screen (or a canvas). You can draw to it using the regular love.graphics.* functions and then show the virtual screen on the real screen. This requires a little effort of the graphics card, so with really, really old ones (which are often found in laptops), framebuffers might not work.

[slime]

You can think of a spritebatch as simply an optimized list of things to draw.

As far as I know, much of this speed comes from the drawing loops being in C++, meaning that no Lua to C calls (rather expensive) are required for all the drawing (and the loops are faster too).

Actually, a lot of the speed increase from spritebatches/VBOs comes from the fact that it stores all the information on VRAM rather than transferring everything to the GPU each frame. This tends to be the huge bottleneck in GPU-accelerated rendering, and much of the changes to OpenGL over the past decade have been aimed at making things require less transfer from the CPU/RAM to the GPU/VRAM.

[T-Bone]

What I mean is that my game requires framebuffers, as they're the only way to scale up text in LÖVE. Because of this, computers incompatible with framebuffers are already excluded from playing my game. So then I might as well use framebuffers.