I mean, it looks like they’ve got multiple versions done. Is it possible to just upload the various ones and let people choose which they like best?
to be perfectly honest, since there is only normal car (redish) and armored, I would just use a darker green without any pattern. Like here:
1 Like
Love this tileset. But I’m noticing in the newer experimentals there are ugly white borders showing up around the sprites… I’ve seen weird borders showing up in other tilesets recently but it is most pronounced with this one. This was not an issue when I last played around September last year. Any idea what change could have caused this? Seems especially bad when Hardware Acceleration is turned on in the graphics options.
This might be a bit of a late reply, but this looks like a case of texture bleed on the sprite sheet.
Typically in a game like this, all the tile images are saved in one large image called a sprite sheet (or texture atlas if the sizes are different) and then texture coordinates are used to pick out what specific sprite to use. This both saves memory and is much, much faster than having a bunch of different images in memory and switching between them programmatically.
Unfortunately, there’s a side effect in how 3D hardware deals with textures in memory in that, due to rounding errors, there can sometimes be a bit of “bleed” from the next texture over on the sprite sheet.
There are several ways to fix the problem. The “easiest” (though perhaps most time consuming) is to add padding to each of the tiles in the sprite sheet which mimics the pixels of the tile directly adjacent to it. This ensures that if a texel gets misaligned slightly, then it will still get the correct data. The amount of padding needed is a bit of a dark art related to the implementation specifics of the texture code and how large the texture atlas texture is. The larger the texture atlas, the more padding is needed between each sprite.
A more difficult solution that requires changes to the C++ texture code would be to programmatically add padding to every tile when the texture atlas is created.
Another solution that would work is to have the texture code do it’s own texture sampling. Again, requiring C++ code and likely some shader programs.
A further solution would use OGL texture arrays, but this might require a complete rewrite of the texture code as well as require OGL 3.0 at a minimum (I actually don’t know what versions of OGL DDA supports). It would also necessitate an appropriate shader program.
As it is, perhaps the easiest thing you can do is simply play the game at a specific zoom level where the artifacts disappear. Typically, this problem happens with mip-mapping and I’m guessing that DDA implements zooming up and down through mip maps.
1 Like
Those lines are because of linear filtering. Turning it off removes them.
I’ve also worked on my own fix to this tileset to cover everything in vanilla that has been missed. I’ve merged Arkenstone1’s fixes with the version included with the experimentals (as of april 2018) and also added other missing tiles. I will upload it to github later when I’ve covered all the missing tiles in vanilla.
1 Like
I made new thread here.
My account was lost when forum moved.