Page 1 of 1

r680 HQnX problems

Posted: Mon Dec 28, 2009 2:24
by Enjay
Not sure if you want these or if the code is still in progress or whatever but...

decals lose translucency with hqnx. They are either fully opaque or fully transparent depending of how transparent a particular pixel was (I think).

Image

Image

A similar effect happens with crosshairs.

The old scale4x (looks much the same as unscaled)
Image

hq4x
Image


I also noticed that it is very slow. With my Burghead mod, hq4x gave noticeable delays of a second or more when a new area came into view, as did selecting different hqnx options in the menu when a wide open area was in view.

Re: r680 HQnX problems

Posted: Mon Dec 28, 2009 9:06
by Graf Zahl
HQnX destroys the alpha channel so this needs to be disabled for shaded textures.

As for the speed, sorry, can't do much there. This algorithm is not very fast. Without texture precaching enabled it's probably useless. I could add some harddisk caching of the upscaled images but of course that'd fill the HD quite quickly because such images are huge.

Re: r680 HQnX problems

Posted: Mon Dec 28, 2009 12:29
by Enjay
Graf Zahl wrote:As for the speed, sorry, can't do much there. This algorithm is not very fast. Without texture precaching enabled it's probably useless. I could add some harddisk caching of the upscaled images but of course that'd fill the HD quite quickly because such images are huge.
No worries. To be fair, I don't think I'll find myself using it too often anyway. I guess that, if I do, it will be in simpler maps/projects.

To give you an idea of the kind of speed issues I experienced, if I start a game of "Burghead" without hqx enabled and move to the place in front of the inca HQ where I took the screenshots for the 3D floor decal bug (thanks for fixing that BTW) then call up the menu and enable hq4x by pressing the left arrow, it takes ~6 seconds before the menu becomes responsive again. During actual play, with hqx enabled, the delays aren't generally as long as that but pauses of a second or two are not unusual when first moving in to a new area.

It's a shame because I think it looks better than the ScaleX system but, I have to say, I'm not fully convinced by either.

I remember when EDGE first started using hqx, it was asked if you could also implement it into GZdoom. I think, at the time, you said that there were licensing issues. I take it that is no longer the case?

Oh, and another minor thing with hqx which is perhaps not worth opening a new bug report for, at the corner of each flat, there is a small dark dot. This is not really noticeable with hq2x but it is with 3 and 4.

[spoiler]these screenshots all taken in map02
Image[/spoiler]

Re: r680 HQnX problems

Posted: Mon Dec 28, 2009 13:18
by Graf Zahl
Enjay wrote: I remember when EDGE first started using hqx, it was asked if you could also implement it into GZdoom. I think, at the time, you said that there were licensing issues. I take it that is no longer the case?
Indeed. Torr Samaho managed to get it relicensed under the LGPL which I can use.
Enjay wrote: Oh, and another minor thing with hqx which is perhaps not worth opening a new bug report for, at the corner of each flat, there is a small dark dot. This is not really noticeable with hq2x but it is with 3 and 4.

Only flats? That's weird. But since I don't do anything here myself I suspect a problem in the algorithm.

Re: r680 HQnX problems

Posted: Mon Dec 28, 2009 13:29
by Enjay
Graf Zahl wrote:Only flats?
My mistake. I'd only noticed it on flats but it is on walls too:

Image

Notice how hqnx also makes the tiling of wall textures (and flats) more obvious.

Re: r680 HQnX problems

Posted: Mon Jan 04, 2010 16:23
by Torr Samaho
Enjay wrote:[spoiler]these screenshots all taken in map02
Image[/spoiler]
That's a bug in the algorithm that AFAIR already was visible in ZDoomGL.