A Question for Melv re: New Plan

#1 Chris,

I'm still working on the new imageMap system so that you've got lots of control on how T2D uploads your frames (in this case tiles) to the GPU. I can't "fix" the filtering "problem" as such but I can give you control over the frames themselves with respect to their neighbours.

In the end, the only way to stop standard bilinear filtering from sampling neighbours is to have either identical texel colours surrounding the tile in question, use the "inset" parameter in the imageMapDatablock or the best way would be to use nearest neighbour sampling, something which the new system provides although you probably won't want to use the camera zoom when using nearest-neighbour sampling. You can use nearest neighbour sampling in v1.0.2 and I believe there's a T2D resource showing how to do this.

Hope this helps!

- Melv.

#2 Thanks for the info Melv!

#3 Ok here's a question from me, if you've got time. In a couple of the demos, the objects were scaling in size... does that mean animatable properties have been added or did you simply do that with script for those particular demos?

Needless to say, scaling and fading are two things I use a huge amount of the time, and doing them in the engine instead of script will be way more efficient. I'm planning to write something like this myself if it won't appear in the next update. So that's why I'm asking. Don't wanna spend time on it if you've already done the heavy lifting for me. ;)

#4

Quote:In the end, the only way to stop standard bilinear filtering from sampling neighbours is to have either identical texel colours surrounding the tile in question

This sounds suspiciously like something that T2D should be able to do for us. That is, adjusting the image at load time to add the appropriate texels to the edges of the tiles/sprites (as scaled sprites would have the same problem). Sure, it would expand the size of the image map (thus probably taking up more memory. And potentially splitting something from being one texture per image map to being multiple textures per image map), but it would make things much easier from our perspective. And if you have chunked image maps working just fine in all cases (meaning that you don't need to ask specifically for chunked image maps; it's the default behavior of image maps), then it doesn't take too much more work to make loading and processing work this way.

#5

Quote:...adjusting the image at load time to add the appropriate texels to the edges of the tiles/sprites...

I don't want the engine mucking around with my art, so I would only like this if it was optional.

#6 @Smaug: Agreed, this is an option for us to look at.

@Jason: It does this @ runtime internally only, it won't change your underlying art. Essentially just reorganising it (as specified by the user) into a format that removes artifacts or potentially alter either performance/compatibility with older cards. The primary goal here is to provide compatibility options for a broader range of hardware. You can choose to design your art for the range of hardware or be lazy and allow T2D to reorganise it into a compatible format and live with any potential performance hits associated with that. Again, you're getting more control here, you're not getting less.

On your previous question; I'm not sure which demos showed scaling as I don't recall doing that but to answer your question directly, we've not yet added animated props yet. If you were referring to the GUI demo then you'll find that the underlying object is just rotating which causes it's clipping-size to vary as this is what the GUI sizes to when in locked-size mode because they cannot currently be rendered rotated and still work with mouse-events correctly.

- Melv.

#7 Sorry to keep repeating this and I'm not sure if it's relevant, but when my writing my 2D tile code I removed border seams by passing GL_CLAMP_TO_EDGE to glTexParameter. It won't work on some (very) old cards, but it's an easy fix.

#8 Joe,

This is the default for texturing under T2D unless the texture is used in the t2dScroller. Unfortunately, this only works if each tile is in its own texture (and is therefore very expensive to render) as it tells OpenGL not to sample the neighbour texel from the opposite border but rather to clamp it to the edge texel. Rendering sub-regions of a texture are not affected by this apart from any region edges that are on the edge of the texture.

Spacing/padding tiles or using nearest-neighbour are the best alternatives.

If this worked for you and you were using a texture full of tiles then I'd love to know why! :)

- Melv.

#9 Thanks Melv. You're right, it's not exactly a tilemap per-se because the "tiles" are screen-sized... No sub-regions, each image is it's own texture so maybe that's why clamping works. It looks ok and scrolls but it runs like a dog on old hardware. I was trying to make a fighting game (was!) so I thought it would work for 2D fighter backgrounds that need lots of detail and don't have to be huge. Anyway, it's good to know you've already considered it. ;)

#10 Posted this on another thread, but this does work for me. (i.e, was seeing the same issues all over the place until I added these lines) The tiles in question are in a single texture, arranged as a strip of 4 tiles (128x128x4).

glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);