[Duplicate] Resize textures breaks security cameras

[ZDL_800]

Hello SanyaWaffles hope you are good.

Enjay has kindly provided a sample demo Camera.pk3 I don't understand why you asking for another demo? Have you missed the post?

I was just about to post here and ask how we can create a new thread with all the information including Enjay's demo, what do you mean nagging? Were fixing bugs here what are you talking about with all due respect? Maybe you need to read the posts here.

Again with the highest respect I'm just submitting legit bugs nearly a year old, it took myself a while to figure this out myself.

Thanks again.

[Rachael]

what do you mean nagging?

This is nagging:

That was Nov 2020, I see threads from June 2020

viewtopic.php?f=7&t=69106

I experienced this issue back in April/May 2020 I'm sure of it, nearly a year later still persists.

https://en.wikipedia.org/wiki/Nagging

[ZDL_800]

My apologies I was only replying to zhadoom, it wasn't directed to any developer, just a reply trying to get the first time this occurred. Some users have wrote that it was fixed that's all, I did eventually test this out on AMD/Intel/NVidia GPU's to 100% prove the theory.

Sorry again.

[phantombeta]

All those upscalers are always giving all kind of problems specially in the software renderer, i wonder if it would be possible to "just" apply them to the entire screen rendering to a lower resolution first and then upsampling to the full resolution like it's done in 2D emulators i believe. The only one i find valuable is NormalNx BTW and there's a suggestion to emulate it with a shader.

I've been thinking about that too. Like those emulators with the HQ scalers. It just smears the whole screen.

Those smear the whole screen, yeah. Doing it per-texture like GZDoom does tends to look far better from what I've noticed, and to me, at least, something like xBRZ seems to look alright on wall textures.

Besides, that would require finding efficient GPU versions of the upscalers (for everything other than NormalNx, that is), which is probably not an easy task in the first place. And they might end up not being as fast as on the CPU - after all, these algorithms were all designed with CPUs in mind, some even without SIMD usage.
The biggest downside, though, is that it'd actually affect performance. The existing CPU-based upscalers don't really affect performance much (if at all) in most GPUs, and they only run when a texture is being loaded.

[drfrag]

Yeah but they already affect performance when textures are huge or they eat all video ram, people using them would need a fast GPU but i don't think that's much of a problem. Another possibility would be to remove those scalers completely.

[Graf Zahl]

You cannot run these scalers on the GPU while rendering, they'd be far, far too expensive because it's not only the upscaling but also the subsequent downscaling for mipmapping and texture filtering that all needs to work around the hardware.

[SanyaWaffles]

Hello SanyaWaffles hope you are good.

Enjay has kindly provided a sample demo Camera.pk3 I don't understand why you asking for another demo? Have you missed the post?

I was just about to post here and ask how we can create a new thread with all the information including Enjay's demo, what do you mean nagging? Were fixing bugs here what are you talking about with all due respect? Maybe you need to read the posts here.

Again with the highest respect I'm just submitting legit bugs nearly a year old, it took myself a while to figure this out myself.

Thanks again.

Just to be clear, I did read everything.

As for having a demo, then link to that demo in the relevant thread. It's not rocket science.

You cannot run these scalers on the GPU while rendering, they'd be far, far too expensive because it's not only the upscaling but also the subsequent downscaling for mipmapping and texture filtering that all needs to work around the hardware.

It seems these scalers cause more trouble than anything, makes me wonder why they were implemented and why they still exist.

[Graf Zahl]

They were implemented by people who felt they are an essential feature. These peole were not me. The first ones were backported from Zandronum.

[SanyaWaffles]

And of course if we were to consider removing it, there'd be a major outcry wouldn't there? Even though such things have caused infinitely more trouble than it's worth IMO.

Outside wanting your Doom experience to look a certain way (which I find doesn't even look that good in some cases), is there an actual tangible benefit to this?

One reason I never use it is even with my 1080 (still a decent card, even if's now a few generations back) it's 4GB of video memory quickly gets eaten up by the video memory required to scale these textures and other assets.

[Graf Zahl]

Same here. Aside from a general dislike of how these upscales look. Just like the 5x and 6x scalings were added because for some people 4x just wasn't enough and some other people had to add the feature.
And of course one should never forget all those bug reports for stuttering and bad performance, only to find out that those users went for a high scaling factor here.

[SanyaWaffles]

It seems like it's a root cause of a ton of issues in this engine - people seem to turn this on and not realize just how badly it performs. A badly implemented feature years ago is biting us in the arse now. And now we're all paying the price. And as I said, if you remove it, people will riot in the streets over it.

Which sucks. It pisses me off how the developers here, including you, are in a rock and a hard place: you want to improve and optimize the engine, but baggage and shit features must be kept because people insist upon using them, even if they cause the engine to utterly lag and choke.

As an aside, It also doesn't help that say, with ZScript, alot of the engine relies on everything being stored in the Actor class and Tick()ing every function. Fortunately there's ways around that for scripters, but people don't want to do that. They want the easy way.

Oh the woes of stuff that made sense back in the day, but not now.

[ZDL_800]

Please for the love of the lord please do not remove the resize algorithms, they are one of the BEST features of GZDoom.

Personally I love the ''ScaleNx'' with ''2X'', absolutely fantastic rendering, I know a lot of streamers that use XBRZ which I also like but prefer XBRZ on Megadrive emulators and such.

The fact that you have the options for resize for the users is brilliant and genius works, don't just remove it because of a bug? Isn't that just giving up on the solution? Let us help here, send us the last working pull request and I'm sure we can work this out.

What I don't understand is that resize worked for 3+ years with no issues, so what's changed here that broke it? I always use resize on all ZDoom games so removing it will send us back to the stoneage it will look like software mode.

Thanks again.

[SanyaWaffles]

I'm just discussing options here. It's not up to me - I am not a developer for the engine (note I do not have a developer role), I am just some shmuck on the internet who is making a cringe standalone game series. I just personally stated I personally feel it causes a lot of issues. The fact it eats up video memory and bogs down system resources doesn't seem to be a good benefit to me personally, and personally to me it looks fugly as sin.

The reason it broke was probably something to do with the Raze refactoring and due to it being an edge case that not many people would experience, it likely would happen that a bug would occur.

I do hope, you do realize Graf's working on two engines and is trying hard to unify the codebase to make it more manageable? That's a monumental task, considering the nuances between the Build engine and ZDoom.

As an aside, I'd appreciate it if you were less hostile towards me in the future. I'm just trying to help. I felt like voicing my concerns that this was an ill advised feature that was added with no real thought about the performance hit or the maintainability it'd require.

People are allowed to disagree.

[_mental_]

Upscaling is disabled by default, and mods cannot force its usage. For the same reason, I could name post-processing a problematic feature. On a system with weak GPU, switching all options for maximum quality will lead to similar performance issues. Let’s vote for removal of post-processing then, right?

[SanyaWaffles]

I don't get why people think we're voting. All I did was say I personally feel the feature needs to be removed. I wasn't "calling a vote" on anything. I don't have that kind of power.