Nearest neighbor filtering
by Hans Sjunnesson · in Torque Game Builder · 04/11/2005 (3:05 am) · 27 replies
Anyone who wants to make a retro 2d-game wants blocky sprites, right? So I made a small hack so you can enable nearest neighbor filtering on a fxImageMap2D datablock.
Patch for fxImageMapDatablock2D.h:
And for fxImageMapDatablock2D.cc:
Blocky sprites makes a world of difference, don't they?

There are a few problems with this approach, first if you are going to use the same texture image for both nearest neighbor filtered sprites and linear filtered ones, you need to copy the image, making at duplicate, otherwize T2D would bind the same GL reference to both datablocks. My above example then is:
The second problem is that the nearest neighbor filtered sprite looks really weird when it moves slowly. You can minimize that problem by moving it rapidly and stopping it instantly, at which you really can't see the artifacts.
Patch for fxImageMapDatablock2D.h:
97d96 < bool mNearestNeighbor;
And for fxImageMapDatablock2D.cc:
73,74c73
< mCellCountY(-1),
< mNearestNeighbor(false)
---
> mCellCountY(-1)
100d98
< addField("nearestNeighbor", TypeBool, Offset(mNearestNeighbor, fxImageMapDatablock2D));
157,160d154
< // Set nearest neighbor filtering
< if (mNearestNeighbor)
< mImageMapTextureHandle.setFilterNearest();
<Blocky sprites makes a world of difference, don't they?

There are a few problems with this approach, first if you are going to use the same texture image for both nearest neighbor filtered sprites and linear filtered ones, you need to copy the image, making at duplicate, otherwize T2D would bind the same GL reference to both datablocks. My above example then is:
datablock fxImageMapDatablock2D(megamanImageMap) {
mode = cell;
cellwidth = 35;
cellheight = 35;
textureName = "~/client/images/megaman";
nearestNeighbor = false;
};
datablock fxImageMapDatablock2D(megamanFilteredImageMap) {
mode = cell;
cellwidth = 35;
cellheight = 35;
textureName = "~/client/images/megaman1";
nearestNeighbor = true;
};The second problem is that the nearest neighbor filtered sprite looks really weird when it moves slowly. You can minimize that problem by moving it rapidly and stopping it instantly, at which you really can't see the artifacts.
#22
1) Make your point by phrasing things more constructively
2) Else, be quiet and actually *do* something. If you want to see a feature, code it. If you'd design something some way, actually design it and do it. Then you'll have what you're looking for. If you want to, submit your work to the community and/or privately to me, and hey, if it's cool, it'll go in T2D and you'll have your nice design in there.
I wouldn't normally say "if you want to see something in T2D, do it yourself". Melv and I both want to help people get their work done in T2D, and want to listen to feedback and incorporate good ideas. But you just don't help the process along.. plus, you present yourself as being capable of making design decisions and doing an implementation, so I have no problem saying the above to you. Even so, you are still welcome to make posts about what you'd like to see, you just need to phrase them in a helpful manner. Again, if you don't want to do that with your posts, no problem... just be quiet then, and if you want to see something done, do it yourself and feel free to share your results.
We are very, very open to feedback, as is obvious from all the feedback given on this forum, and how we take it. For example, Ray "Noolness" has made some excellent suggestions pointing out some things we wanted to change in the T2D physics. He phrased things well and constructively, and everything went great. There are many, many, many such examples.
Your posts are rarely so helpful or worthwhile. If you truly want to get stuff done and truly want your opinions to be heard and considered, start thinking about how to get your points across in a more helpful fashion. And even better than talking about how you might want things to work, since you claim expertise, just make it work the way you want it to and then we can talk about the implementation, whether it's good and whether it'd make sense for T2D in general.
This place would fall apart if every piece of feedback was phrased as a hostile attack. I'm not saying you do that every time, but you certainly could be smarter about the way you post. Phrase your feedback constructively. We will not let anyone hijack the excellent community and vibe here.
I don't have a problem with you sharing your opinion at all. I have a problem with the way you present it. For example, after the initial flurry of posts you made on the C++ main loop stuff, where you mostly complained and moaned... you ended up doing a good job when you actually bore down and started figuring stuff out.
Next time, skip the first part where you make a bunch of unhelpful posts. Rather than spending a couple days spouting off about how T2D should be structured or how you'd do something... just figure things out, ask questions (don't make hostile statements) if you need to, and get the work you're trying to get done, done. Then, if you want to, please feel free to post about your work and any changes you make. Such posts are very informative for people, and would be much more appreciated by everyone here than your current interactions. Keep them constructive, and make them helpful to other readers.
If a post is not going to help people here, then there's no point in having it around. The only reason you are still allowed to post here is because I'm hoping you will turn into a constructive and helpful member of the community. I will be deleting all your posts from now on that aren't serving some useful purpose and written constructively. If you want to have a voice from now on, you'll have to make it one that is constructive and is going to help the rest of the community.
You don't always make aggressive or poorly worded posts. I've seen some reasonable and helpful posts. So, I'm not trying to come down and you say that all your posts are bad or anything. I am saying though that we'll no longer be tolerating invective posts from you.
04/15/2005 (10:21 am)
Smaug, rather than making strongly worded posts about what should or shouldn't be in T2D, from now on you have two options:1) Make your point by phrasing things more constructively
2) Else, be quiet and actually *do* something. If you want to see a feature, code it. If you'd design something some way, actually design it and do it. Then you'll have what you're looking for. If you want to, submit your work to the community and/or privately to me, and hey, if it's cool, it'll go in T2D and you'll have your nice design in there.
I wouldn't normally say "if you want to see something in T2D, do it yourself". Melv and I both want to help people get their work done in T2D, and want to listen to feedback and incorporate good ideas. But you just don't help the process along.. plus, you present yourself as being capable of making design decisions and doing an implementation, so I have no problem saying the above to you. Even so, you are still welcome to make posts about what you'd like to see, you just need to phrase them in a helpful manner. Again, if you don't want to do that with your posts, no problem... just be quiet then, and if you want to see something done, do it yourself and feel free to share your results.
We are very, very open to feedback, as is obvious from all the feedback given on this forum, and how we take it. For example, Ray "Noolness" has made some excellent suggestions pointing out some things we wanted to change in the T2D physics. He phrased things well and constructively, and everything went great. There are many, many, many such examples.
Your posts are rarely so helpful or worthwhile. If you truly want to get stuff done and truly want your opinions to be heard and considered, start thinking about how to get your points across in a more helpful fashion. And even better than talking about how you might want things to work, since you claim expertise, just make it work the way you want it to and then we can talk about the implementation, whether it's good and whether it'd make sense for T2D in general.
This place would fall apart if every piece of feedback was phrased as a hostile attack. I'm not saying you do that every time, but you certainly could be smarter about the way you post. Phrase your feedback constructively. We will not let anyone hijack the excellent community and vibe here.
I don't have a problem with you sharing your opinion at all. I have a problem with the way you present it. For example, after the initial flurry of posts you made on the C++ main loop stuff, where you mostly complained and moaned... you ended up doing a good job when you actually bore down and started figuring stuff out.
Next time, skip the first part where you make a bunch of unhelpful posts. Rather than spending a couple days spouting off about how T2D should be structured or how you'd do something... just figure things out, ask questions (don't make hostile statements) if you need to, and get the work you're trying to get done, done. Then, if you want to, please feel free to post about your work and any changes you make. Such posts are very informative for people, and would be much more appreciated by everyone here than your current interactions. Keep them constructive, and make them helpful to other readers.
If a post is not going to help people here, then there's no point in having it around. The only reason you are still allowed to post here is because I'm hoping you will turn into a constructive and helpful member of the community. I will be deleting all your posts from now on that aren't serving some useful purpose and written constructively. If you want to have a voice from now on, you'll have to make it one that is constructive and is going to help the rest of the community.
You don't always make aggressive or poorly worded posts. I've seen some reasonable and helpful posts. So, I'm not trying to come down and you say that all your posts are bad or anything. I am saying though that we'll no longer be tolerating invective posts from you.
#23
Thanks
04/17/2005 (11:12 pm)
I just want to know if there has been any bad things from this hack. It really is something I want to add to my game since it uses a lot of pixelated images. Thanks
#24
- Melv.
04/18/2005 (12:44 am)
There's no good reason why you can't add this patch into T2D. It'll work fine. :)- Melv.
#25
Btw: The issue with seams between tiles is related to using linear filtering, correct?
08/17/2005 (8:33 pm)
If you want to have all of your graphics use nearest neighbor instead of linear filtering, you can simply do a search and replace GL_LINEAR with GL_NEAREST and GL_LINEAR_MIPMAP_LINEAR with GL_LINEAR_MIPMAP_NEAREST in TextureManager::createGLName (dgl/gTexManager.cc).Btw: The issue with seams between tiles is related to using linear filtering, correct?
#26
I had a problem like this in my 2D OpenGL code once and the way I fixed the seams was by using GL_CLAMP_TO_EDGE for tile images. So if all else fails, we might want to try that.
08/17/2005 (10:44 pm)
Hi I just posted about this in another thread, but it seems on topic (or it was, back in April!:o) I had a problem like this in my 2D OpenGL code once and the way I fixed the seams was by using GL_CLAMP_TO_EDGE for tile images. So if all else fails, we might want to try that.
#27
08/23/2005 (7:27 pm)
Thanks to Hans for such a simple and elegant solution! I just changed all my sprites and tiles to use Nearest Neighbor, and it worked like a charm!
Torque Owner Josh Williams
Default Studio Name
-----------