Zireael wrote:Are you saying that vrld's libraries are better than yours?
What I am saying is that they are different - not necessarily better or worse.
Last time I checked, gamera does more things than hump.camera. This can be a good or a bad thing, depending on whether you need the extra features or not. Hump.camera (usually) comes bundled inside hump, while gamera is stand-alone. You might want or not want that. It depends on your needs. No one is "better" than the other one.
Zireael wrote:I still can't make the camera behave properly with his library, but
this post isn't clear to me. How do I draw the map so that I can use gamera with my game?
That post is about optimization. Let me try to explain.
Gamera (and hump.camera, as far as I know) assume that your level "doesn't move" in order to make scroll work; There is a constant system of reference which is independent of the camera - this is called "world coordinates" in gamera. These world coordinates are usually in pixels. On this system, the top-left corner of the tile on row 1, column 1 is usually at 0,0. If the tiles are 32x32, then the corner of tile to the left is at 32,0. And so on. The important thing is that, unless these tiles are moving platforms or something like that, these coordinates never change - even if they "seem to move to the right" when the camera moves to the left. No one is doing "tile.x = tile.x + speed * dt".
Instead, the camera moves its position, and then makes transformations to the graphics pipeline before things are drawn. If the camera has moved 100 pixels to the right, the tiles will look as if they have moved 100 pixels to the left (even if they have not moved at all). This way, the camera can be thought of as a rectangle which moves around in the world.
The demo on the first post illustrates this. The world gray tiles never move, even when the cameras move, following the player. It's just that gamera does clever transformations before drawing the rectangles (before entering each camera's :draw method). The "blue rectangle" visible in the demo represents "the part of the world that cam1 can see". It is a rectangle in the "world coordinates".
This means that
you could draw the whole world on each frame. If you make a draw call for every tile and every object on the level inside cam:draw, it will work - but that will be very inefficient (usually, most of the tiles and most levels are not visible, so there would be lots of unnecessary draw calls).
That's what those 4 parameters in camera:draw are for. They give you a "rectangle" in your world coordinates representing the screen (or a rectangle encompassing that, if you are using rotation). You don't need to draw anything outside that rectangle, because it would fall out of the screen anyway. How you reduce the draw calls to accomodate this depends on how you represent stuff in your game. The post you mention explains how to do this "trimming" on tile-based games (I think it applies to yours). It's an ideal scenario because it is relatively easy because changing from "draw all the world" to "draw only a rectangle of the world" is easy.
EDIT: I have attached a modified demo file. On this one, both cameras (cam1 and cam2) draw the same rectangles (the ones visible for cam1). Hopefully this will help you understand how the optimization works - cam1:getVisible() returns a rectangle which can be used to limit the tiles.
. Fixed now.