GL_Texture_HQResize 4, 5, 6 and Camera Textures

[Enjay]

This is just a embryonic bug report more to ask for help where to look or for how to narrow down the problem so that I can post an example.

With a build of the latest GZDoom (checked out today, 4 April 2014), if I activate any of the HQ resize modes, some camera textures go blank (ie completely black). The ScaleX resize modes do not do this and going back to an older build (from the end of March) allows the camera textures to work with HQX too.

Once this has happened, switching back to GL_Texture_HQResize 0 does not allow the camera texture to reappear. Even warping away to a new level and warping back, or starting a new game without quitting does not restore the camera textures. Quitting and restarting does.

However, it isn't all camera textures so I have been having difficulty compiling an example to post. I thought it might be due to models being present in the view, or large textures but in a cut-down example, these alone did not cause difficulties.

I am aware that there was a change to the HQX code in the last day or two, which is why I was checking the HQ modes (I don't normally use them). When doing so, I noticed the phenomenon.

[spoiler]Starting the level normally and with no HQ resizing active


GL_Texture_HQResize 2 activated


GL_Texture_HQResize set back to 0
[/spoiler]

Any ideas?

[Gez]

I think this is probably related to the X grid bug, which nobody has ever been able to unravel. Same behavior.

Best I can suggest is disabling hq filters for camera textures entirely. Yeah, it's sweeping the bug under the carpet, but it's quite obvious that there exist nobody with both the know-how and the motivation to fix it, so...

[Graf Zahl]

HQ filters should NEVER be applied to camera textures. Period.
It'd make more sense to auto-scale them to higher resolutions if wanted.

[Rachael]

HQ filters should NEVER be applied to camera textures. Period.
It'd make more sense to auto-scale them to higher resolutions if wanted.

Have to agree with Graf. While I know it was never your intention to HQ resize the camera textures themselves, I really don't think the end result looks good. Better idea would be to reinitialize the camera textures themselves at the higher multiplier settings without filters.

[Enjay]

If it is bad policy to HQ-resize camera textures I guess that they should be excluded from HQ-resizing on the engine side? Is it possible to exclude a particular texture or a camera texture from HQ resizing as an end user when texture resizing is otherwise enabled?

I usually define my camera textures to be reasonably hi-res in ANIMDEFS. I don't really want them to have a HQ filter applied to them too. Well, I don't generally want a HQ filter, period. I only found the problem because I'd enabled HQ resizing because I knew it had been modified in the recent commit. It was just luck that I was on a level with camera textures when I did it. I'm really just reporting this because if it affects me, it will probably affect someone else too and they might want HQ resizing to be active.

[Gez]

I guess that they should be excluded from HQ-resizing on the engine side?

That they aren't already is but an oversight.

Camera textures and any texture with a non 1:1 scaling ought to be excluded from these resize filters.

[Enjay]

When I read that, I thought - "OK, I guess someone could easily add a quick check for scaling before any HQ stuff is done". Then I remembered how many different ways there are to scale something in GZDoom (TEXTURE1, TEXTURES, Doomsday-like hi-res folder, HIRESTEX lump, scaled actors (including ones where their scale changes via DECORATE), (model skins?)...) and I realised that it may well be quite a bit more complicated. I've probably forgotten some scaling methods too.

[Graf Zahl]

All scaling ends up in the same 2 member variables of the texture object so it's hardly an issue.

[Enjay]

Fair enough. Thanks for the info.

Just thinking aloud...

If a graphic is scaled to a lesser extend than the HQ scaling setting, should it still be HQ scaled?

e.g. If a 256x256 texture is scaled to behave like a 128x128 texture, it would be pointless to scale it if HQ2X was active. However, if HQ4X was active, the scaling could still do something - so should it have the HQ filtering applied? Or would that be complicating things unnecessarily?

[Rachael]

I think it would complicate things but I think I understand the basic idea you're getting at.

The problem is when a texture is scaled down, the scaling filters only read the final texture composite excluding ANIMDEFS applications. By final texture composite I mean imagine your texture is a layered Photoshop document (in fact, that's probably the best metaphor there is for it). Within Photoshop you have the option to resize and manipulate each layer, however, Photoshop is limited by the resolution/size (pixels) settings of the document. So when you save a scaled down layer in photoshop and export its final raster as a PNG (most people do it just using "Save As", but using Layer->Flatten Image has the same effect), the number of pixels is already reduced and scaling it back up will not restore the details that were lost when it was sized down.

This is essentially what is happening with the texture manager - the final composite is a flattened image, a final rasterization, at exactly the resolution you specified - it will not read the source material to see if you scaled anything down. To do what I think you are suggesting, it would require a bit more work and, would the end result really be worth it for that complexity? Or would it just be better to start with the proper scale textures to begin with? Keep in mind, you can use "world scaling" for the textures, in terms of their offsets, so you can actually have the wall offsets read higher pixel jumps than they are set within the level, to make things easier.

To accomplish this idea, what would have to happen is, the texture would once again be opened by the texture manager and each patch would have the filter applied to it as appropriate, discerning on whether it is really necessary or not based on scaling - and given that scaling is done by float values this would enormously impact the complexity of the filtering system and not only that it would make the end result look bad in the final composite if you used non-integer numbers.

[Enjay]

Yes, I can follow that. It makes sense. Thanks.

[Rachael]

You're welcome.