Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
timmie

Fancy texture resizing

Recommended Posts

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 :)

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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..

Share this post


Link to post

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...

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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).

Share this post


Link to post

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

I cant wait for the latest version any longer :(

Share this post


Link to post

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.

Share this post


Link to post

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 :)

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×