Rotation and Mirror code in the tilemap?

[TradeMark]

Is there some good reason why the map format doesnt support rotating and mirroring settings for the tiles? so you dont need to create a new tile if you just want to rotate it.

This would allow you to rotate the tile in any angle and also mirror/flip it in every possible way.

ATM the tilemap is using (int), we could add there space for rotation code (2 bits) and mirror code (1 bit)

And still, theres 29 bits for the tile indexes, so we cant run out of indexes, biggest maps take 512*512 tiles, or maybe 1024*1024, and thats just a million tiles, while 2^29 = 536870912, so it would only make the map size limits into (sqrt(2^29)*32)/512 = 1448x1448 size Spring map, which is ridiculously large and nobody will ever make that big maps with this shitty map format anyways.

Those rotated or / and mirrored tiles could be rendered into the memory correctly, so you dont need to rotate them while you render the tiles (unless its very fast operation...).

So basically this hack would just allow you to make smaller filesize in maps if you have tiled them in that way.

This wouldnt need any changes in the map format, since we could just change the way how spring reads the current map format (SMF and SMT files).

DDS format shouldnt be a problem either, since the format doesnt care about the pixel positions, so you could even rotate the DDS DXT1 compressed tiles without recalculating it completely (i heard its very CPU heavy thing to do).

I like this idea.

[Pxtl]

It would be nice to see those DSD 4way and X and whatever maps implemented in a sane way.

[TradeMark]

Exactly.

There are other mirrored maps too, and its a shame they take two or four times of that space, even though they are just mirrored and/or flipped...

Edit: actually the zip/7zip compression makes them about the same size anyways, but still, it would also make map editing easier / faster, since you dont need to recompress those mirrored and/or rotated tiles again.

[TradeMark]

I made C code to mirror the DDS and all its mipmap levels! Hurray!
This code should be pretty optimized already, so it wont eat CPU so much...

Code: Select all

void mirror_dxt1(unsigned char *DDS){
	int miplevel, pos, dpos, texels, half_texels;
	int p1d, p2d, p1, p2;
	int x, y, u;
	unsigned char c1a, c1b, c2a, c2b;
	unsigned char val1, val2;
	pos = 0;
	dpos = 512;
	texels = 8;
	for(miplevel = 0; miplevel < 4; miplevel++){
		half_texels = texels>>1;
		p1d = half_texels<<3;
		p2d = p1d+(texels<<3);
		p1 = pos;
		p2 = pos+(texels<<3)-4;
		for(y = 0; y < texels; y++){
			for(x = 0; x < half_texels; x++){
				c1a = DDS[p1+0];
				c1b = DDS[p1+1];
				c2a = DDS[p1+2];
				c2b = DDS[p1+3];
				DDS[p1+0] = DDS[p2-4];
				DDS[p1+1] = DDS[p2-3];
				DDS[p1+2] = DDS[p2-2];
				DDS[p1+3] = DDS[p2-1];
				DDS[p2-4] = c1a;
				DDS[p2-3] = c1b;
				DDS[p2-2] = c2a;
				DDS[p2-1] = c2b;
				p1 += 4;
				for(u = 0; u < 4; u++){
					val1 = DDS[p1];
					val2 = DDS[p2];
					DDS[p1++] = (val2<<6)|((val2&12)<<2)|((val2&48)>>2)|(val2>>6);
					DDS[p2++] = (val1<<6)|((val1&12)<<2)|((val1&48)>>2)|(val1>>6);
				}
				p2 -= 12;
			}
			p1 += p1d;
			p2 += p2d;
		}
		pos += dpos;
		dpos >>= 2;
		texels >>= 1;
	}
}

Havent tested it in C though, but in PHP format it worked perfectly.

Note: This function only works properly with DDS DXT1 images which both dimensions are power of 2.
Note: This function uses the given DDS block data, and replaces the data with the mirrored data.

I will make more code later since this was fun (rotation and its combinations with mirror)

[manolo_]

there was the same suggestion in the past and im still vote +1

[KDR_11k]

Isn't it easier to simply modify the UV coords based on the flag bits at render time?

[jcnossen]

Isn't it easier to simply modify the UV coords based on the flag bits at render time?

That won't fit in the current smf map rendering.
The tiles are collected into a larger big tile (128x128 tiles iirc), and those is used to render the map (So there are less texture state changes).

[TradeMark]

Yeah so its just better to mirror or/and rotate the DDS data

[KDR_11k]

Isn't it easier to simply modify the UV coords based on the flag bits at render time?

That won't fit in the current smf map rendering.
The tiles are collected into a larger big tile (128x128 tiles iirc), and those is used to render the map (So there are less texture state changes).

Yeah but that big tilemap is a texture whose components get selected with UV coords, no?

[TradeMark]

i think he means that the DDS data is collected into 128x128 size blocks, so they arent drawed there with openGL functions or anything, so you cant just draw them in different angles etc... so the only way to rotate the tiles is to rotate the DDS data as i already made some code for it... which sounds good, since then it would be very fast operation as well.

[Tobi]

However KDR means those 128x128 blocks are still used as texture for a bunch of small triangles, so by rendering that part of the map with modified texture coordinate generation you can also flip/rotate the smaller tiles.

Whether it's really easier depends a lot on whether texture coordinates are shared between triangles and whether the rendered triangles align with the tiles and are never bigger then half a tile.

I think coordinates are shared and I also think the rendered triangles can be bigger then the tiles, making changing texture coordinates to mirror/rotate tiles hard / impossible without redoing a lot of the map renderer.

[lurker]

And it's probably slower to add in the extra code to change the uvs than to alter the texture once.

[TradeMark]

thats what i also thought...

so can i make the rest of the code now then?

[KDR_11k]

Whether it's really easier depends a lot on whether texture coordinates are shared between triangles and whether the rendered triangles align with the tiles and are never bigger then half a tile.

Did he really mean free rotations or just in 90┬░ steps?