before i go on, i'll reiterate on a bug that i may or may not have posted a bug report on: as seen in the above image, even when an entire tileset is fully replaced, many (if not all) maps still show the original tileset for some tiles, and the new tileset for all others... does anyone know why this occurs?
back on topic:
first tileset:
example tile:
filtered
unfiltered (after per's code reversion)
as seen from the filtered render, the colorized border is only displayed with something like 1/5th of a texel (what should have taken 5 pixels to render on screen took only 1 or two). as some of us know, the reason for only a sliver of that border being rendered is because each tile is being rendered as a 62x62 tile, and the texture filtering algorithm makes every immediately adjacent pixel to that 62x62 square "bleed" in to the tile during rendering; the same problem exists with pie modelling, and warzone's 3d artists learned to inset each texture coordinate by one texel for filtered polygons -- some examples of unadjusted texture mapping can be seen on the default propulsion pies: in-game, a green set of half-tracks might have a magenta (or some other color) edge on most polys because of this bleed-through.
the effect is small enough that pixel padding operations may work, most preferrably those initiated and cached by the engine (as opposed to having to manually pad the original tiles). If we can agree to N-2 texture dimensions (62x62, 126x126, etc) as a standard, than it may be a good solution, however, many artists have worked on tilesets that are N-dimensioned, and one cannot maintain rotational seamlessness by cropping the tiles down, and they would lose substantial quality and most likely would end up non-rotationally seamless if scaled down by two pixels. therefore, if we were to choose a pixel padding approach, i believe that N+2 textures are far more effective because they would retain compatibility, at the expense of either texture access speed (devurandom confirmed that non-power-of-two textures take longer for a gfx card to access) or stored texture size (padding the memcached texpage in both directions with blank pixels until the texpage is power-of-two -- good texture sorting algorithms could minimize the ill effects of this). in the next few days, if i remember, i'll make and test a 62x62 rotationally seamless tileset with a 1-pixel pad, and see how that works: if it displays as intended, than a 66x66 solution (unchanged 64x64 tiles with an engine-calculated 1-pixel pad) may be the path to least resistance for all people involved.
better yet is if we can find an gl texture clamping method that prevents bleed -- it seems likely that one exists, as this is no small issue.
the possible solution of blending tiles obviously has the compatibility/performance drawbacks, but also there's a good chance that doing so simply won't look good at all, and in many cases, such as blending water and sand, would certainly look too cartoonish and artificial.
one issue i'm also seeing: on the corners of many tiles in both screenshots, an extra brightly colored texel appears where it does not exist in the original tile. are the tiles compressed using a lossy algorithm before loading them into memory, or is this some kind of rendering/loading bug?
second tileset:
example tile:
filtered
unfiltered (after per's code reversion)
as seen, after per's change, tiles are once again rendered correctly, though more pixelated.
