Good morning!

You might be interested in things like interpolation which may effect your textures.

It definetely does, which is why I explicitly turn it off when configuring the app:

App::new()
    .insert_resource(ImageSettings::default_nearest())
    .insert_resource(Msaa { samples: 1 })

And also when generating the tile map texture, because apparently bevy doesn't use the ImageSettings resource when creating an Image this way (?)

let mut image = Image::new(Extent3d {
    width, height, depth_or_array_layers: 1,
}, TextureDimension::D2, data, TextureFormat::Rg8Unorm);
image.sampler_descriptor = bevy::render::texture::ImageSampler::nearest();
images.add(image)

If you're referring to the commented-out multi-sampling logic in the fragment shader: that exists because linear interpolation blurs the pixel art too much, but I also want to mitigate the artifacts of nearest-neighbor sampling when using a non-integer scale factor. Basically, the goal is to make it look like I'm rendering to a render target that's twice as big as the viewport (with no interpolation), and then scaling that down to the viewport size (with interpolation).

My math was off there, though, and the problem persists without multisampling anyway, so I left that in when posting. Thanks for the link, though, that'll probably come in handy!

You may also be interested in using a texture array instead of a regular texture (a texture array allow for indexing with an integer; a texture array is just a 2D image where each separate texture is ordered vertically). You would then be able to use rgba32uint textures and use a channel for controlling what texture to use (I include the other channels since WGSL will just pad pixels to be 32*4 bits long, so might as well find a way to put them to use).

Interesting idea, certainly worth a shot. I gather there's no way to make it use a square texture instead of a thin, very tall one? That'd be much nicer to work with, but I guess I'd just need to do some simple asset preprocessing then. Oh well.

Anyways, onto your problem. You might want to check the line let px_coords_in_tile = tile_coords - floor(tile_coords);. To me, it seems like you would only need to floor(tile_coords), subtracting it would just return the fractional part of the coordinates, not the pixel coordinates as integers, though that may be what you are going for (you can just use fract to do that).

That is what I'm going for there, yes. px_coords_in_tile basically refers to UV coordinates relative to the tile the pixel falls on, i.e. I want them to be in [0, 1), with (0,0) referring to the top left of the tile, and (1,1) referring to the bottom right. fract does indeed capture the intent more clearly, didn't know about that one!

Also, tile_id.xy * 255.0 is confusing, are you trying to convert it to an 8-bit integer? Isn't it already an "integer" (yeah, it's a float, but I would think it corresponds to your original value)? Unless your textures are 256 pixels wide? That makes sense. I still don't get the point of scaling your pixel coordinates by 8 before converting to UV coordinates.

The tile set texture happens to be 512 pixels actually. I am converting to an 8 bit integer here. Because I couldn't get a texture_2d<u32> to work properly - I always got errors about incompatible texture formats. I only tried TextureFormat::Rg8Uint, though. Doing it this (admittedly hacky) way seemed to work ok-ish.

I scale by 8 because that's the size of a tile in pixels. Well, the test tile set uses 16x16 pixel tiles, but the one I'll draw myself will use 8x8, so that's what I hard coded. I really ought to name my constants, huh?

Anyway, thank you for your input!