Well, I think for a camera, you'd keep track of the camera position and only draw the bits of your level/game that fit in the current screen area. You can use transforms to store your camera position, but its probably easier to just use some regular old variables^[1] to track the position.

I'm imagining you have a 2d map, maybe a side scroller or a tile map. In these cases you don't really want to do any bitmap region magic or transforms to move the drawing around because you can just take the camera position and figure out the current bits of the map to draw from that (from the camera origin minus half the screen, to camera origin plus half the screen, or something similar).

Yikes. Yea, that'll cost ya.

I much prefer to use the transforms.

It can be kinda tricky, but once your camera is setup it's not difficult to translate both to and from world and camera coordinates. You get the advantage of having zoom and rotation which is nice to have in your pocket, and you won't have pos-camera_x, pos-camer_y cluttering all your drawing code. Overall, you get more control, simplicity, and power if you choose to use transforms, but there is a learning curve.

Which I didn't , and it was naaaysty

But even with bitmap holding and sprite sheets, I've run into (extremer) cases where performance took a hit, (probably because you're still sending a lot of drawing calls, and allegro is building transforms for each al_draw_bitmap call on the backend). I think the ultimate optimization is making the tilemap one large ALLEGRO_VERTEX tile_map_prim[], every tile being 2 triangles, and the texture is the tile atlas. That's my next pet project, really looking forward to trying that out.

Not separately, you can extract them from the transform. If your camera has a camera_width and camera_height, you can al_transform_coordinates() on camera_x, camera_y, camera_x+camera_width, and camera_y+camera_hight. That'll give you your clipping rectangle in world coordinates. If you then divide each coordinate by 16 (or whatever your tile size is), then you get the row/column of the tilemap.

Yeah, your best bet is to draw the geometry in one go. Bitmap holding is supposed to do that, as long as you only use the same actual texture for ALL calls. Of course using a single batch for all of the map is going to need to use the same texture regardless.

Though I've been experimenting with setting up multiple texture atlases, and having the geometry data send in the texture id to pick the correct one. If more things supported Texture Arrays, this would be so much simpler, but its not a 100% supported thing yet.

You could but I'm not sure how that's simpler or better

What are you using it for? Isn't it normally for doing lighting and stuff like that?

Yeah, thats more or less what I have.

ALLEGRO_VERTEX_ELEMENT elements[] = {
    { ALLEGRO_PRIM_POSITION, ALLEGRO_PRIM_FLOAT_3, offsetof(CustomVertex, pos) },
    { ALLEGRO_PRIM_TEX_COORD, ALLEGRO_PRIM_FLOAT_2, offsetof(CustomVertex, txcoord) },
    { ALLEGRO_PRIM_USER_ATTR, ALLEGRO_PRIM_FLOAT_1, offsetof(CustomVertex, tx_page) },
    { ALLEGRO_PRIM_COLOR_ATTR, ALLEGRO_PRIM_FLOAT_4, offsetof(CustomVertex, color) },
    { 0, 0, 0 }
  };