Author Topic: [REQUEST] Pixel Scaling Algorithms in DX9 (Read 1476 times) Tweet Share

subspark · « **on:** 17 Oct 2009, 15:27 »

I'm not sure how long Hq3x has been in the AGS DirectDraw5 rendering system but I beleive it and other perhaps more sophistocated scaling algorithms are due to make their way into the DirectX9 rendering mode.

Such filters as:

Cheers,
Sparky.

Shane 'ProgZmax' Stevens · « **Reply #1 on:** 17 Oct 2009, 17:46 »

I've always found these filters to be horribly ugly and destructive to pixel art, so I can't really get behind this suggestion.

Iceboty V7000a · « **Reply #2 on:** 17 Oct 2009, 18:42 »

As far as I remember, CJ mentioned that some of the filters use a license that require the software using them to be distributed with the source (i.e. that will force AGS to become open source, which is stupid).

I too agree that filters just make graphics look worse. They are just a big insult to pixel graphics, but that doesn't mean we should prevent everyone from using them if they really want to (sometimes smoothing photorealistic graphics may look good to some people).

I think this could only be solved if the filters are not integrated into the engine, but separate plugins. In this way, you can just provide the source to the plugins but not the engine. I think many people have their software designed in this way (particular emulators) partly because of this reason (and partly because the flexibility of being able to have new filters added without updating the software).

Snarky · « **Reply #3 on:** 17 Oct 2009, 19:54 »

Well, we already have Hq3x, and these other two are essentially the same effect. I don't see why we'd need a choice of three different filters that look almost the same. Isn't there a setting in the config file that lets you adjust the gradient/sharp edge threshold in Hq3x (which could probably improve how the door looks in the AGS version).

Pumaman · « **Reply #4 on:** 17 Oct 2009, 21:33 »

Yes, when I originally added the filters, Hq2x/3x was the only one with a license permissive enough to allow it to be used in AGS.

Since the other two you suggest basically look the same, as Snarky says, I don't see much point in adding them even if their licenses did allow it.

As for DX9 mode, as far as I know these sort of filters aren't really possible to do, due to the way Direct3D and hardware acceleration works.

subspark · « **Reply #5 on:** 18 Oct 2009, 14:57 »

Quote

I've always found these filters to be horribly ugly and destructive to pixel art, so I can't really get behind this suggestion.

I've always found that pixel art at 2560x1600 looks horribly ugly and requires filters for feature distinguishability. Having said that, I'm sure Hq3x is good enough for some but it doesn't quite offer the best smoothing as you can see above.
So no chance of emulating these algorithms in DX9 Mode Chris? The DX9 Antialias filter just blurs everything at large resolutions. Not something I'd recommend for my players. It almost seems the only way to experience decent graphics in all its glory is to run games below 800x600 in a window. Personally, I don't like the desktop looming about in the background of my games because it breaks immersion. Anyone enjoyed the cinemas with the lights on? :'(

Perhaps another suggestion: full-screen + black border could be introduced? This is a long-time request so.....BUMP!

Cheers guys,
Sparky.

Pumaman · « **Reply #6 on:** 18 Oct 2009, 15:01 »

Quote from: subspark on 18 Oct 2009, 14:57

So no chance of emulating these algorithms in DX9 Mode Chris?

It might be possible to emulate these in D3D using custom pixel shaders, however it's not something I would see as any sort of priority in the near future.

Quote

Perhaps another suggestion: full-screen + black border instead of scaling? This is a long-time request so.....BUMP!

Would you really want to run a 320x200 game at normal size with a black border around it filling up the rest of the screen? If would be like watching the game through a telescope...

Ryan Timothy · « **Reply #7 on:** 18 Oct 2009, 19:54 »

Quote

Would you really want to run a 320x200 game at normal size with a black border around it filling up the rest of the screen? If would be like watching the game through a telescope...

Well I wouldn't want to play a 320x200 game without scaling and with black borders, but I do agree that along with scaling, that a black border filling the screen would be great.

Given the option, I would definitely select it.

subspark · « **Reply #8 on:** 19 Oct 2009, 03:17 »

As would I. Although not clearly stated, the suggestion implied that a black border could be drawn fullscreen with or without scaling on.

Agreed on the telescoping though Chris - I used to play all the LucasArts games with black borders on because I hated the double sized pixels but that was in a time before HD monitors. I'm all for pixel clarity if it can be managed, and for some, pixel smoothing might be the style your going for.
Hq3x does tend to blur a bit more than the other algorithms I suggested which is why one of the reasons I started this topic. The key words here are clarity and scale. Mixed together you have a pretty darn good excuse to play the latest 320x200 games on a widescreen monitor at full-screen.

I have the misfortune to have to scan through a screen filled with triple sized pixels due to my 30"monitor and its not a pleasant walk in the park. Running DirectX9, naturally, the scene looks like a godforsaken mosaic.
I continue to press the DirectX9 implementation because AGS still supports low res games and therefore some kind of smoothing (not to be confused with blurring) needs to happen.

Please treat this request extremely casually, it's not a slit-your-wrists if not had feature but I strongly believe it needs to happen at some point. If only for the sake of enjoying our beloved low res games AGS first became famous for.

Cheers,
Sparky.

Thrakk · « **Reply #9 on:** 31 Mar 2012, 03:28 »

I would also like to request AdvMAME2x and AdvMAME3x. I think they provide a nice alternative to the normal scalar without completely losing the pixelated look. At the very least they are more blocky than HQ2X and HQ3X. They're also faster.

gif comparison 1 (with magnification 200%)

gif comparison 2

Thanks for your consideration. I know you personally prefer no filtering. I, however, like a smidgen of filtering.

fuzzie · « **Reply #10 on:** 31 Mar 2012, 08:24 »

Quote from: Thrakk on 31 Mar 2012, 03:28

I would also like to request AdvMAME2x and AdvMAME3x. I think they provide a nice alternative to the normal scalar without completely losing the pixelated look. At the very least they are more blocky than HQ2X and HQ3X. They're also faster.

The only public implementation of the AdvMAME Scale2x/Scale3x filters is GPL (or "no commercial use"), I think, so the licensing is still a problem for the main AGS code.

Thrakk · « **Reply #11 on:** 31 Mar 2012, 16:44 »

Quote from: fuzzie on 31 Mar 2012, 08:24

Quote from: Thrakk on 31 Mar 2012, 03:28
I would also like to request AdvMAME2x and AdvMAME3x. I think they provide a nice alternative to the normal scalar without completely losing the pixelated look. At the very least they are more blocky than HQ2X and HQ3X. They're also faster.

The only public implementation of the AdvMAME Scale2x/Scale3x filters is GPL (or "no commercial use"), I think, so the licensing is still a problem for the main AGS code.

I was worried about that... but you did help me figure out what to google.

The Scale2x (homepage) author is apparently very considerate about letting other people use his filter. So far he has allowed and maybe helped implement Scale2x in at least 3 closed source projects (using rewritten implementations due the license restrictions). I don't know how hard it would be to contact him nowadays even though he has provided a couple different ways to contact him.

One thing I gathered from the SourceForge forum:

"You must follow the license terms only if you include in your project in any form (compiled or not) the source code or binaries downloaded from the Scale2x site.

If you reimplement the scale2x effect from the definition you don't need to follow the license. Essentially it means that only the assembler version is licensed because the C implementation is almost identical at the effect definition and it's immediate to rewrite."

some examples... and here's an example of someone getting permission for their closed source project

Anyways, this is just a suggestion. Keapon keeping on

Armageddon · « **Reply #12 on:** 01 Apr 2012, 03:44 »

Quote from: ProgZmax on 17 Oct 2009, 17:46

I've always found these filters to be horribly ugly and destructive to pixel art, so I can't really get behind this suggestion.

I agree, but I actually kind of liked playing The Dig with this filter (I couldn't turn it off) it made the world feel more alien and strange.

subspark · « **Reply #13 on:** 01 Apr 2012, 05:28 »

You guys should create a new thread. You just Necro'd this one from '09.

Iceboty V7000a · « **Reply #14 on:** 01 Apr 2012, 07:49 »

I am actually okay with this, as this is indeed a somewhat sensible continuation of the discussion. It is better to have them sticking in one place, other than having multiple threads.

subspark · « **Reply #15 on:** 01 Apr 2012, 14:05 »

Yep. Good point.

KamikazeHighland · « **Reply #16 on:** 03 Apr 2012, 16:04 »

If it were possible to both paint and detect absolutely every RGB value (255,255,255) of each color within AGS it'd be really easy to make your own filters using AGS.

Alan v.Drake · « **Reply #17 on:** 03 Apr 2012, 18:26 »

Quote from: KamikazeHighland on 03 Apr 2012, 16:04

If it were possible to both paint and detect absolutely every RGB value (255,255,255) of each color within AGS it'd be really easy to make your own filters using AGS.

Sure, if you wanna make a stop motion game. A filter needs processing power, the only sensible choice is to implement it in the engine source.

- Alan

fuzzie · « **Reply #18 on:** 03 Apr 2012, 18:46 »

Quote from: Alan v.Drake on 03 Apr 2012, 18:26

Sure, if you wanna make a stop motion game. A filter needs processing power, the only sensible choice is to implement it in the engine source.

Shaders can also be a good option (as mentioned already), and they're a lot easier to just 'plug in' as a game developer. I was messing with them in ScummVM the other day - although of course rather than something sensible I ended up playing with CRT shaders like http://i.imgur.com/nKnEW.png :-) But there's various rather nice interpolation shaders from emulator projects out there, for example.

Alan v.Drake · « **Reply #19 on:** 03 Apr 2012, 19:41 »

Quote from: fuzzie on 03 Apr 2012, 18:46

Quote from: Alan v.Drake on 03 Apr 2012, 18:26
Sure, if you wanna make a stop motion game. A filter needs processing power, the only sensible choice is to implement it in the engine source.

Shaders can also be a good option (as mentioned already), and they're a lot easier to just 'plug in' as a game developer. I was messing with them in ScummVM the other day - although of course rather than something sensible I ended up playing with CRT shaders like http://i.imgur.com/nKnEW.png :-) But there's various rather nice interpolation shaders from emulator projects out there, for example.

If only I knew how to actually implement one, I remember trying a while ago, but I failed, perhaps programming under a flu wasn't the greatest idea. I probably missed some elementar stuff. I'm not versed in D3D.

- Alan