[Code submission] High quality resize filters

[Gez]

Skulltag now has those filters in OpenGL mode. Apparently, Torr managed to make a deal with the author to include the HQ filters in Skulltag in exchange for keeping that tiny part of the code open. So there is a GZDoom patch that puts those in, but it is, of course, for r127.

Therefore, I made the minimal work of adapting those changes to r278. It compiles and it works.

The patch is attached here:

[Graf Zahl]

I have to admit that I like this even less than ZDoomGL's HQ filters. Those at least managed to interpolate the texture's structure to a certain degree. All these filters do it smooth diagonal edges while at the same time make the pixels stand out more even with texture filtering on.

[Gez]

It's only an option, which some people would use and some wouldn't. For now, I like it, even if it may only be the novelty factor.

[DaniJ]

I've just taken a quick look at this and to me, it looks like there is a couple of bugs in their implementation as the results differ noticeably from that produced by the reference implementation.

[Chris]

I'd actually like to see the smart filter implemented, personally, for both sprites and textures. I imagine it could be done in real-time with fragment programs and proper data packing. But even if not, you could precalculate images that are 4 or 8 times the size of the original, then DXT compress them when sending to the card.

[Enjay]

Having now seen them in action in r279, I have to say that they don't loook as good as EDGE's HQx filters to me.

[Graf Zahl]

AFAIK EDGE uses the same code as ZDoomGL - and that one's indeed better - but it's not only GPL - equally problematic is that the code is very, very time consuming and can't be used in real time. It's only usable if all generated textures are precached for repeated upload.

[Enjay]

I've noticed that the filters, as included in GZdoom can be very time consuming too. Perhaps this is a function of how many textures there are in my mod but teleporting seems to create a particular problem. It seems to me that if I teleport to an area that uses a bunch of textures that I have not yet seen in game, it can take 3-4 seconds for me to see the destination room and be able to resume playing after stepping into a teleport.

Also, I've found a bug with the filters and camera textures:

http://forum.drdteam.org/viewtopic.php?p=33968

[Spleen]

I'd actually like to see the smart filter implemented, personally, for both sprites and textures. I imagine it could be done in real-time with fragment programs and proper data packing. But even if not, you could precalculate images that are 4 or 8 times the size of the original, then DXT compress them when sending to the card.

I like the second idea better. Since this filter is somewhat more "static" than something like AA, AF, or trilinear, it would make sense to perform HQ on all the textures on startup and when the options are changed, then simply use the HQ-ed textures instead of non-HQed ones. This could work a lot faster than repeatedly doing the filter every time, given enough memory.

In fact it would probably be possible for someone to write a program to hq all the textures in a wad and output a separate wad to replace those textures, sprites, patches, etc. with hq versions - this could have been done without a single renderer modification.


And I do like this filter, in fact I use it almost all the time when playing Skulltag. It may not be perfect, but I like it a lot better than the blurriness caused by the trilinear filter.

[wildweasel]

I think the "pre-filtering" should only be done if the filtering is on to begin with. I run with the nearest-neighbor filter, and if GZDoom starts pre-filtering the textures on startup, that's going to be an inconvenience for me because I'll never use this feature.

[Rachael]

I'm kinda the same way. Old game is old. Trying to "new" it up with graphics doesn't always go well, though sometimes it does. Personally, I still stick with nearest-neighbor filtering.

[Torr Samaho]

[Apparently, Torr managed to make a deal with the author to include the HQ filters in Skulltag in exchange for keeping that tiny part of the code open.

FYI, the filtering is not the HQNX filtering from ZDoom, but the ScaleNX Filter from http://scale2x.sourceforge.net/snapshot1.html. The author of HQNX never answered my mail, so to prevent any licensing problems I didn't use this filter albeit it looks nicer.

For ScaleNX I didn't need to negotiate anything with anyone. The ScaleNx algorithm itself is not (and can't be) protected by a license, only the concrete implementation. I made a straightforward custom implementation so I don't need any permission to use it. I decided to release the code not because I have to, but because I want to. I'm a friend of open source myself, which likely is not too obvious since Skulltag is closed source. I can't release Skulltag's source without Carnevil's permission, but I can release anything that I wrote on my own.

[Enjay]

I decided to release the code not because I have to, but because I want to. I'm a friend of open source myself, which likely is not too obvious since Skulltag is closed source. I can't release Skulltag's source without Carnevil's permission, but I can release anything that I wrote on my own.

No, it isn't. Saying that releasing the source can't be done because the source may be abused is one thing. But indirectly saying that the source won't be released so that bugs don't need to be fixed is just a slap in the face of the open source community. That's an attitude I will never accept.

That was also never the stance of anyone in charge of coding Skulltag. aabra may have said something to that effect, but it isn't anything Torr or I have agreed with, and aabra hasn't ever been in charge of the code. Don't put words in my or Torr's mouth.

It sounds like you and Carn may not be too far away from agreeing with each other on this point. Can any progress be made towards at least releasing some more of the not-sensitive code?

As a side issue, there has been a bug with models sitting in the bugs forum for some time now. It relates to a feature that you submitted (model rotation). Any chance that it could be looked at by you?

http://forum.drdteam.org/viewtopic.php?t=3389

[Torr Samaho]

It sounds like you and Carn may not be too far away from agreeing with each other on this point. Can any progress be made towards at least releasing some more of the not-sensitive code?

I think you misunderstood Carn's post. He didn't mention his stance on opening the source in the quoted post in any way. He just made clear that none of the Skulltag developers endorses censorship of security related information in any way.

As a side issue, there has been a bug with models sitting in the bugs forum for some time now. It relates to a feature that you submitted (model rotation). Any chance that it could be looked at by you?

Done. I haven't been able to monitor the GZDoom forums lately, so I wasn't aware of the issue.