Graphic layers?

[Jasoco]

I notice there doesn't seem to be a way to create pre-drawn layers, also called "Canvases" (Called layers on old game consoles like the NES and SNES) where you would draw complex backgrounds onto a hidden canvas, then just copy that to the main screen each frame so you don't have to draw all the tiles and stuff each frame.

Does LOVE not need this to be done?

I have wanted to create a top-down game that uses maps for each screen and the character walks around on it. The screen would be 640x480 which would amount to 20 x 15 tiles of 32x32 pixels each frame. That's 300 tiles for one layer each frame.

Am I supposed to be doing it that way? Or is there a way to draw all those tiles onto another screen, then copy it over.

In QBASIC this would use the SCREEN and PCOPY commands. In JavaScript (Which is what I had been developing my game in) you just use <CANVAS> elements and layer them with Z-indexes then draw stuff onto them and they'd remain unchanged until you needed to change them. But it doesn't look to be a way to do layered pre-drawn canvases in LOVE yet.

Or did I miss it? Or do I not need to do it? How fast can LOVE even go? Because at the worst, my game would need to draw a map (300 draws), two or four object layers (300 times 2 or 4) and a layer with the player, NPC's and any enemies as well as all projectiles. That seems like a lot to draw every frame. Of course I haven't gotten to the point where I can test how fast it will go yet. I'm still learning.

BTW, LOVE looks awesome. I just hope it doesn't leave me like TNTBasic did.

[Robin]

More people have brought this up. You are right, buffers/canvases/layers are incredibly useful, and are not supported by LÖVE at the moment. (rude/mike: were you planning on giving some love to buffers? I forget.)

[Zorbatron]

I would really like to see this feature in love. However, I believe what you want can be achieved by the screenshot function (love.graphics.screenshot()), however, I'm not sure if you have to resize the window in order to get the correct size, I do know that transparency cannot be achieved with this, but maybe for what you need.

Just draw everything you need onto the screen, and screen shot it, then create a new image from the screen shot and render it ingame.

[Jasoco]

Well, I'd have to do that every time a map is loaded. (When you change screens which would happen thousands of times over the course of the game.)

I'll do some playing around for a while and hope that LOVE matures into something awesome.

So, are there any limitations to the size of the game you can make?

[Zorbatron]

Well when the game loads, just go through every level at the beginning of the game and write their image files (though they really should be automatically created in your level editor or something)

[Jasoco]

The way I do maps is the way everyone does maps. Files with numbers representing tiles in a grid. My maps would have 5 layout layers plus one object/player layer. My game might end up with hundreds of maps when its done. Keeping all that data in plain ASCII text files would be a lot less space hogging than using images. But I could probably create a way of "caching" all the maps on first run then just loading the pre-generated map when the game is launched each time from then on.

But I'd still love to have layers. So hopefully at some point they'll be implemented.

In the meantime, I've just gone through all the sample examples from the site and am impressed at what a lot of them had done. Some manipulating hundreds of objects on the screen at once. (That one with the emoticons falling from the sky and piling up on each other was impressive. And I got a kick out of the SHMUP with the cat shooting at hearts with the J-pop song playing in the background and stars flying by. Makes me want to create a clone of Pop'N'Twinbee because it would probably be very possible and very fast.)

[Zorbatron]

A good, full game, would not use a grid based numeratical layout for their maps, everyone does not, and should not use this method. Regardless you could load them when the game loads even if you don't have them precompiled. You should really consider making a basic tilemap editor for yourself if you want to make a decent game.

[rude]

Relevant planned stuff:

1. Vertex Buffer Objects. Allows you to render lots of geometry with one call to love.graphics.draw.
2. Frame Buffer Objects. Render to texture. Suitable for real-time use (in theory).
3. Pixel data access. Allows you to cut-and paste pixels between images. NOT suitable for real-time use.

1 and 3 are almost ready (99% complete). Haven't started on 2.

[Robin]

Pixel data access.

Yay!

Haven't started on 2.

Aw...

[Jasoco]

A good, full game, would not use a grid based numeratical layout for their maps, everyone does not, and should not use this method. Regardless you could load them when the game loads even if you don't have them precompiled. You should really consider making a basic tilemap editor for yourself if you want to make a decent game.

Explain what you mean. A map in a tile based game is basically a grid of numbers or letters representing objects to draw. Whether its stored in ASCII or binary.

I already have a tilemap editor I made actually.

I should show you guys what I've done with JavaScript, CSS and HTML5. If I can replicate it in LÖVE, I'd be impressed extremely. Especially if it kept a steady 60FPS.

Here's a curious question, at any point is LÖVE going to consider doing basic 3D? I know it's "LÖVE2D" but simple 3D would be awesome. Even if it was just plain old SNES SuperFX style 3D. (Think StarFox) Maybe for the future. Since the program uses OpenGL and stuff and is able to do it very fast.