Since the introduction of large maps, I think there's one feature missing that would help many pico-8 games: the ability to flip and rotate individual tiles in the map. Games often use up a lot of their sprite space just for the map data, duplicating tiles for the different boundaries needed, or using manual spr() calls to get the necessary x_flip and y_flip needed. Since there's no visible editor to worry about anymore, this could be a quick patch (via a poke value to an alternate map() drawing mode), and would make map() much more useful.

Flip map mode, option one: 0x8000+ is used for map data (same format used now), 0x2000 is the flip data for that map data, using 2 bits per tile (x_flip, y_flip).

Flip map mode, option two: the 1 byte of map data stored anywhere now references a cell # in the first 16 sprites (n 0-15, 4 bits), x flip (1 bit), y flip (1 bit), and 90 degree clockwise rotations (2 bits). Like so:

map data: 1 byte per tile (same as now)
nnnnxyrr
nnnn = sprite number, 0 to 15
x = flip horizontally?
y = flip vertically?
rr = clockwise rotation, in 90 degree increments (00: no rotation, 01: 90deg, 10: 180deg, 11: 270deg)

This limits you to 16 tiles for map() calls, but those tiles are also much more useful now, with hundreds of drawable combinations.

Either of these two options would be very helpful for reducing the sprite cost and token cost of nice looking maps. It would be great to have an option for easy rotations that doesn't involve tline calls, too.

I personally think, that rotate is a little bit too much, but for example the NES supported a flip bit.

The C64 had a "screen"-buffer (like the current map-data) and an Color-Buffer.

My suggestion would be a optional "color/style"-Buffer in the high-memory (the normal map must then in the lower memory).
8 Bits:
xyit pfff

X=Flip x
y=Flip y
i= inverted color
t= Color 0 is transparent or solid
p= Use Palette (main palette 0) or (second palette 2)
fff = flags (0-7)

The flags should can be used in Map-Layer-Parameter (after the point. for example 0b0.001 would only draw tiles, where the map-flag 1 is set)

With this not only flip is possible also other things like the cloud/bush-tile in Super Mario Bro. for the nes. They are the same tile, only different color.

@GPI The NES can't flip tilemap tiles. Only sprite objects can be flipped.

I agree that at least having a function to flip x and y would be really useful. Palette changes per-tile could open up a lot of interesting possibilities, too.

By coincidence I just wrote my own x flip function before seeing this post.

function tile_flip(sprite_index)

	local spr_tbl = {}
	local spr_offset = 512 * (sprite_index \ 16) + 4 * (sprite_index % 16) - 1
	local byte_index = 0
	local rows_passed = 0

	while(rows_passed < 8) do

		byte_index += 1
		spr_offset += 1
		local byte = peek(spr_offset)
		add(spr_tbl, shl(band(byte, 15), 4) + shr(band(byte, 240), 4))

		if byte_index == 4 then
				poke(spr_offset-3, spr_tbl[4], spr_tbl[3], spr_tbl[2], spr_tbl[1])
			spr_offset += 60
			spr_tbl = {}
			byte_index = 0
			rows_passed += 1
		end

	end

end

I'm sure someone's already written functions to do everything listed in this thread, but it's the kind of thing where if you're already trying to save space by using tile flips, the extra tokens from the custom functions might end up defeating the purpose.

You could get a little performance improvement by replacing the bitwise function calls by the corresponding operators (band → &, etc).

poke and peek also have operators.

I did try that with the bitwise operators but I had some trouble nesting the shorthand versions, so I just left it that way for now. I forgot there are shorthand peeks/pokes. I think my implementation probably isn't very good anyway, but I learned a lot working it out.

I think you could add tables within the main table for the remaining rows instead of doing them one at a time, and that way it would be easy to add vertical flips, but I'll leave that for someone else to try.