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.
#2
04/11/2005 (5:27 pm)
Melv, is it possible to make it an option for both? If I had to choose between the two, I'd go for setting it in the imageMap itself. It'd save work, as every image map would have at least one object using it (maybe hundreds, who knows). So it'd cut down on lines of code in a normal project (but then again, I'm a beginner, so I don't know how many image maps would be needed in a single complex object). Also, in a game, you usually either go all out with that style of art, or not at all. And if you do a mix, usually the art that you would want to look like clear pixel art wouldn't be used as filtered pixel art.
#3
I think it would be better if it was defined on the sprite itself.
The imagemap datablock is used to load an image into the engine, it should not have anything to do with how it it rendered. It would be alot more flexable that way, and why would anyone want to waste space loading 2 identical images.
04/11/2005 (5:59 pm)
@MelvI think it would be better if it was defined on the sprite itself.
The imagemap datablock is used to load an image into the engine, it should not have anything to do with how it it rendered. It would be alot more flexable that way, and why would anyone want to waste space loading 2 identical images.
#4
04/11/2005 (6:15 pm)
I can't imagine a real-world use where you want to use bilinear filtering on some sprites with the same image and on other sprites with that image you don't. If you want the filtered look, then you always want it on magnified objects. If you don't want the filtered look, then you never use it. This tends to be an either/or decision.
#5
04/11/2005 (6:34 pm)
Neither can I.
#6
Yeah, same here.
@Chris
If you can't imagine that situation, why did you say this?:
But I think the ability to use both styles in a single game is important. I can think of many ways that would be used. I just don't think that it will be an issue if you have to create the setting per imageMap. It would be nice if you could create a global setting, however. And detailed settings if you wish (maybe that went against the global setting, so you could have nice smooth particles in a pixelly game for instance).
04/11/2005 (10:12 pm)
@SmaugYeah, same here.
@Chris
If you can't imagine that situation, why did you say this?:
Quote:They wouldn't. The art they want sharp, they won't want to show again as a blurry object. But maybe I'm not thinking creatively enough :).
and why would anyone want to waste space loading 2 identical images.
But I think the ability to use both styles in a single game is important. I can think of many ways that would be used. I just don't think that it will be an issue if you have to create the setting per imageMap. It would be nice if you could create a global setting, however. And detailed settings if you wish (maybe that went against the global setting, so you could have nice smooth particles in a pixelly game for instance).
#7
There are cases where you may want to reuse art and have different effects. This isn't typical for main game characters or background art but for things like particles and special-fx art, the user may be interested. It could be just for performance when used as particles for a specific effect where the particle count is high, who knows? I'm not going to make the decision, I'll try to let the user decide.
The ability to choose, as long as that doesn't come at a too big a price is a non-decision really.
- Melv.
04/12/2005 (1:51 am)
I'm trying not to write T2D based upon my perception of how people will use T2D or how others perceive wouldn't be useful. That's not to say I'm not listening to peoples opinions but quite often this experience is with a certain type of application and T2D has people interested in non-gaming and other general visualisation apps.There are cases where you may want to reuse art and have different effects. This isn't typical for main game characters or background art but for things like particles and special-fx art, the user may be interested. It could be just for performance when used as particles for a specific effect where the particle count is high, who knows? I'm not going to make the decision, I'll try to let the user decide.
The ability to choose, as long as that doesn't come at a too big a price is a non-decision really.
- Melv.
#8
Really? Since the earliest days of texture filtering, I've never heard of a 3D game that ever took the same image and used bilinear in one instance and nearest in another.
If nobody uses it, it can't be that important.
This... this does not bode well.
T2D must serve the needs of game developers first. If others find T2D useful for their needs, this is all well and good, but its design must cater to our needs above all others. If there is a design choice, one that favors game development and one that favors general use, we win. There's no need for T2D to become "Generic Script-Based 2D Simulation System". You're working for GarageGames for a reason.
Since the days of the TNT, bilinear filtering has always, always run at the same speed as nearest filtering.
04/12/2005 (2:46 am)
Quote:But I think the ability to use both styles in a single game is important.
Really? Since the earliest days of texture filtering, I've never heard of a 3D game that ever took the same image and used bilinear in one instance and nearest in another.
If nobody uses it, it can't be that important.
Quote:That's not to say I'm not listening to peoples opinions but quite often this experience is with a certain type of application and T2D has people interested in non-gaming and other general visualisation apps.
This... this does not bode well.
T2D must serve the needs of game developers first. If others find T2D useful for their needs, this is all well and good, but its design must cater to our needs above all others. If there is a design choice, one that favors game development and one that favors general use, we win. There's no need for T2D to become "Generic Script-Based 2D Simulation System". You're working for GarageGames for a reason.
Quote:It could be just for performance
Since the days of the TNT, bilinear filtering has always, always run at the same speed as nearest filtering.
#9
04/12/2005 (3:07 am)
If you ask me, you should ask for your money back Smaug. You seem to find something wrong with everything
#10
04/12/2005 (3:09 am)
Yeah, I really can't understand why you oughtn't to have an option for using all kinds of filtering for different objects, at the same time. Why is that such a bad thing? And how does that turn T2D into a "generic script-based 2d simulation system"?
#11
I used that as an example because it was the first thing to pop into my head after seeing the above images. I do agree it may have been a poor example to support my point. Even not using it as an example it does not take away my point that loading an image into mem and displaying it should have nothing to do with each other.
Thinking about this even more, its a hard issue to decide on what's better, keeping things seperate or ease of use ( not defining it for each sprite but for the image itself )
Perhaps as said above to have a global rendering option and if you need each sprite to render differentaly, set it in the sprite itself.
But I'm sure Melv will come up with a good solution.
04/12/2005 (6:01 am)
@DavidI used that as an example because it was the first thing to pop into my head after seeing the above images. I do agree it may have been a poor example to support my point. Even not using it as an example it does not take away my point that loading an image into mem and displaying it should have nothing to do with each other.
Thinking about this even more, its a hard issue to decide on what's better, keeping things seperate or ease of use ( not defining it for each sprite but for the image itself )
Perhaps as said above to have a global rendering option and if you need each sprite to render differentaly, set it in the sprite itself.
But I'm sure Melv will come up with a good solution.
#12
I do not work for GarageGames, they are my publisher, writing T2D is part-time for me. I would not have added half the features if I wasn't primarily considering games developers so I don't need you to preach to me (yes you are being patronising and preaching even if you don't realise it). You only seem to complain and I can't remember anything positive you've posted. If you'd lightned up a little (serious man, lighten-up) you'd read it as also taking other aspects of T2D usage into account and as I said, "as long as that doesn't come at a too big a price" so please don't try to make out that I said anything like "making games doesn't come first". If taking other very important usages of T2D doesn't sit well in your books then I can live with that.
The occasional light hearted post would prove that you are a human being and not a robot from the future.
- Melv.
04/12/2005 (7:38 am)
@Smaug:I do not work for GarageGames, they are my publisher, writing T2D is part-time for me. I would not have added half the features if I wasn't primarily considering games developers so I don't need you to preach to me (yes you are being patronising and preaching even if you don't realise it). You only seem to complain and I can't remember anything positive you've posted. If you'd lightned up a little (serious man, lighten-up) you'd read it as also taking other aspects of T2D usage into account and as I said, "as long as that doesn't come at a too big a price" so please don't try to make out that I said anything like "making games doesn't come first". If taking other very important usages of T2D doesn't sit well in your books then I can live with that.
The occasional light hearted post would prove that you are a human being and not a robot from the future.
- Melv.
#13
Sorry your sharing of a new feature for T2D has turned into this debate. I'm sure many people appreciate this very much, like I do. Thank you, once again!
04/12/2005 (8:08 am)
@HansSorry your sharing of a new feature for T2D has turned into this debate. I'm sure many people appreciate this very much, like I do. Thank you, once again!
#14
Can't say it better... Smaug, you have some very good and informative posts some times, but you just need to lighten up... Don't respond to everything so dramatic. Its like your trying to prove some point here but I'm not sure what point your trying to prove, that you can take any side of a debate and win ?
If you knew any thing about GarageGames you would know they support a lot of flexibility... they are aiming Torque as a Platform now and not just a bunch of game engines.... platform... Like the Torque Show Tool Pro... a 3D app done in Torque... the Torque Constructor (that they are working on)... a 3D interior modeller done in TAP...
Whats wrong with options ? Its not like Melv is dropping some game critical feature and spending months on some feature that won't have a use in games... Hes simply leaving it open so you (as well as all of us) can choose what you want to use...
Relax a bit and remember we aren't your enemy. lol... if anything we should be your allies... you don't treat your allies like inferiors, like you are doing right now... Theirs constructive cristism and then there is BS criticism, your starting to do the later... relax a bit and remember making games are supposed to be fun! Not a dramatic critique of every little detail... Everyone else here is helping eachother and having fun, if they have a suggestion they post it constructively... I'd be nice to have you with the rest of us here
04/12/2005 (8:18 am)
Quote:If you'd lightned up a little (serious man, lighten-up)
Can't say it better... Smaug, you have some very good and informative posts some times, but you just need to lighten up... Don't respond to everything so dramatic. Its like your trying to prove some point here but I'm not sure what point your trying to prove, that you can take any side of a debate and win ?
If you knew any thing about GarageGames you would know they support a lot of flexibility... they are aiming Torque as a Platform now and not just a bunch of game engines.... platform... Like the Torque Show Tool Pro... a 3D app done in Torque... the Torque Constructor (that they are working on)... a 3D interior modeller done in TAP...
Whats wrong with options ? Its not like Melv is dropping some game critical feature and spending months on some feature that won't have a use in games... Hes simply leaving it open so you (as well as all of us) can choose what you want to use...
Relax a bit and remember we aren't your enemy. lol... if anything we should be your allies... you don't treat your allies like inferiors, like you are doing right now... Theirs constructive cristism and then there is BS criticism, your starting to do the later... relax a bit and remember making games are supposed to be fun! Not a dramatic critique of every little detail... Everyone else here is helping eachother and having fun, if they have a suggestion they post it constructively... I'd be nice to have you with the rest of us here
#15
04/12/2005 (8:42 am)
On a lighter note... Hans, that pic is a great example!
#16
04/12/2005 (9:14 am)
Megaman X! Hans didn't draw it :). But yes, Mega Man is a great example to all, in all things.
#17
04/12/2005 (9:43 am)
Yup... I love (and have played just about) all of the Mega man games... just when trying to picture it I couldn't get the clearest picture in my head (though I knew what it was) and that reference pic is great, even if he didn't do it
#19
@Melv: Hey, it's allright. It's still an important issue to debate. My opinion is that the added cost of storing duplicate images on disc outweights the cost of duplicate memory for these sprites. However, having to store two identical images on disc isn't a particularly intuitive approach and might be confusing for some.
As an addendum, and a bit off topic, this thread on gamedev.net was a great resources for finding sprites, for those of us who suck at pixel-art.
04/12/2005 (10:05 am)
@David: I needed to find some good sprites I could use as a "hero sprite" in my tests. Megaman was the perfect choice, and his animations are really well done.@Melv: Hey, it's allright. It's still an important issue to debate. My opinion is that the added cost of storing duplicate images on disc outweights the cost of duplicate memory for these sprites. However, having to store two identical images on disc isn't a particularly intuitive approach and might be confusing for some.
As an addendum, and a bit off topic, this thread on gamedev.net was a great resources for finding sprites, for those of us who suck at pixel-art.
#20
04/12/2005 (10:16 am)
@Hans: sorry for hijacking your thread =/ 
Associate Melv May
Something similar to this will go in when the new file-format is in.
Thanks for the patch in the meantime though. :)
It's good that you raise the issue of sharing imageMaps. It is a good question whether this should be an option of the sprite or the imagemap itself.
You'll definately see more precise control in the near future.
- Melv.