Fancy texture resizing

[timmie]

So I've been adding the hq2x/hq4x filters into ZDoomGL for 0.75 (controlled with the gl_texture_hqresize [0/1/2] cvar) and finally got most of the funny bugs out of the way so I could finally take some screenshots...

These shots were taken with the hq4x filter enabled (gl_texture_hqresize 2):
http://www.timmie.squabble.org/screenshots/hq_1.jpg
http://www.timmie.squabble.org/screenshots/hq_2.jpg

More information on the filters can be found at http://www.hiend3d.com... Heh, the guy who made the filters (Maxim Stepin) was even kind enough to do a special version of them that directly supports the alpha channel for me :)

[Linguica]

Meh... I guess it's better than bilinear filtering? But the algorithm obviously wasn't meant for even 8-bit images.

[timmie]

Heh, some textures look way better and others don't actually look much different at all. It looks better in action and the ingame fonts look way sharper.

[KCat]

Ooh, those pics look sweet. How much VRAM do you suppose will be needed? Obviously textures at 2+x the size will require more texture memory and stuff..

[DaniJ]

What is the benefit in using this filter at run time?

Surely you would only need to resample an image once then save it out into a wad for future use...

[chilvence]

I dunno, considering the amount of wads that would be run through ZdoomGL, that would be a whole lotta custom textures to save on your HD. Plus having it taken care of by the game itself is a nice luxury.

[DaniJ]

Yeah in the case of custom wads it would be impracticle to do this, but with the Doom wads it's a little pointless keep running the filters on the same graphics all the time.

[timmie]

The filter is actually really fast (it is designed to run in realtime, after all) and the textures are only processed when you load the map. With the hq4x filter it's a bit slower to load but not too bad. The benefit of using it at run time is it works on every image loaded via the texture manager, so that includes the status bar, the fonts, the sprites, the flats, well everything except the load/save preview images, pretty much.

Of course, you can preprocess all the graphics before hand if you want (it won't run the filter on hires textures since it's fairly safe to assume you don't really need to).

[DaniJ]

Thats cool then, as long as it doesn't slow it down during play.

[SyntherAugustus]

Woohoo! Now all you have to do is just add .61 support. (I think).

I cant wait for the latest version any longer :(

[KCat]

It was my understanding that the textures are processed with the hqx filters and then uploaded to video memory. You can't run them in real time, can you? OpenGL has no way of doing that, afaik. I figured this is what happens:

• The texture/patch is loaded into system memory as a 32bit alpha-enabled image.
  
• The HQx filter is used on the 32-bit image, increasing it's size.
  
• The enlarged image is then uploaded to the video card, where it behaves as if it's just a regular hi-res texture.

The image is still bilinear filtered, but because the original image is larger, you don't get the enlargement (blurring) artifacts unless you have a really high resolution screen, and stand super close. And even then it won't be nearly as bad as if the card was enlarging the original sized image, since it's not enlarging it as much.

[timmie]

KCat, that is 100% correct. The only change is the hq filters work on 16 bit images, so the 32 bit RGBA image is converted to a 16 bit version first (well, 17 bit: 16 bit color + 1 bit alpha). It's hardly noticable, though, since the source images are 8 bit to start with :)

[Graf Zahl]

Cool that the filters work now. I couldn't get them to do so. I have one question, though. The texture loading of the latest version seems to be significantly slower than the last official release. Any reason why?

[KCat]

It's hardly noticable, though, since the source images are 8 bit to start with

With the exception that the source images use, for all intents and purposes, a 24 bit palette. Not complaining per se, just pointing out. Hopefully the filters can be extended to work on full 32 bit images sometime in the future.

[Graf Zahl]

KCat said:

With the exception that the source images use, for all intents and purposes, a 24 bit palette. Not complaining per se, just pointing out. Hopefully the filters can be extended to work on full 32 bit images sometime in the future.

Probably not in real time. They rely on a 65536 entry lookup table and that's exactly 16 bit.

[timmie]

Here's some comparison screenshots to show how it looks going from software to OpenGL with the hq4x filter.

http://timmie.squabble.org/screenshots/hq_cmp_sw.jpg
http://timmie.squabble.org/screenshots/hq_cmp_4x.jpg

[toxicfluff]

Comparing the pictures, I find the filtering looks worse close up, but considerably better than normal when the filtered texture/sprite is further away.