Here is some more info about the filter and few pictures that demonstrate what it can do: http://www.hiend3d.com/hq3x.html

Perhaps someday it's an incredible cpu hog though 😀

Yeah it is, but the result is definetly worth it. I really hope to see it in Dosbox some day!

but why do you ask for HQ3x?
why not HQ2x - http://www.hiend3d.com/hq2x.html
or HQ4x - http://www.hiend3d.com/hq2x.html
or SmartFiltering - http://www.hiend3d.com/smartflt.html ? 😉

Perhaps someday it's an incredible cpu hog though

I didn't intend to annouce this right now, since I hate to announce unfinished work, but I am working on hq2x for dosbox. My intention is to donate a fast scaler to my favourite emulator 😀

Since my target platform is my p2/333 laptop (civ1 and even early protected-mode games are playable, thanks to dynamic CPU), it needs to be fast, so I optimized it "a bit". The plain C code is done so far, it's about 3 times as fast as scale2x (tested against the standalone C version). On later CPUs, the optimizations should have an even greater effect, as they are especially cache- and pipeline-friendly. I can't check that, however, due to a shortage of p4 machines.

Currently I am working on an MMX version, which could give an additional 2x to 4x speedup for intel users (estimated given the current progress).

The first patch should be available in around 1-4 weeks, as time permits. At first, it might be limited to some specific color depth(s), we'll see. I'll keep you updated somewhere here.

CU
Moe

P.S.: No, I will not do the same to hq3x. It's unlikely I will ever touch that, as the optimizations will probably not be possible with it. hq3x would be much slower than hq2x, and compared to hq2x, there's not that much visual gain, IMHO - it's not worth it.

That's great news `Moe`. I am looking forward to seeing it in action. 😎

Holy crap, that SmartFiltering looks awesome. Are there any emulators that use it? I'd love to see it work on a SNES game, or even the textures of an N64 game.

I agree Smart Filtering should be hardcoded in current accelerators chipsets, like nVIDIA or ATi. It's impressive and way much better than Bilinear or Trilinear filters. 😎

eL_PuSHeR wrote:

I agree Smart Filtering should be hardcoded in current accelerators chipsets, like nVIDIA or ATi. It's impressive and way much better than Bilinear or Trilinear filters. 😎

Provided that the textures are optimised for Smart Filtering. If you look at the texture unflitred, you'll notice that the black lines are not "anti-aliased" to begin with...

Texture used in games are smoother than this, even unfiltred. Since Smart filternig uses the contrast to decide wether it will vetorise or bilienar filter, it wouldn't look as nice as in the demo.

Good point. Would it be good for "cell shading" like the one used in 13? It appeared a little blurry. 😎

`Moe` wrote:

... it needs to be fast, so I optimized it "a bit". The plain C code is done so far...

...Currently I am working on an MMX version...

Why reinvent the wheel?
Go to http://www.hiend3d.com/hq2x.html page, and scroll all the way down.

You'll see the link to "Optimized Source code (100% asm)".
It's super-fast MMX-based code.

Why reinvent the wheel? Go to http://www.hiend3d.com/hq2x.html page, and scroll all the way down. You'll see the link to "Op […]
Show full quote

Why reinvent the wheel?
Go to http://www.hiend3d.com/hq2x.html page, and scroll all the way down.

You'll see the link to "Optimized Source code (100% asm)".
It's super-fast MMX-based code.

See, I've taken a different approach to get even faster code. First of all, I optimized the algorithm itself, so even the platform-independent C code is real fast.

Secondly, I've taken great care to make the code friendly to modern CPUs with their big pipelines, yet also effective on old CPUs (see my personal target system) with their small caches. I don't know if this is the case with the generic ASM code - though I admit I didn't look at it. It's a kind of contest for myself: when done, I intend to look at the released asm code and see what I have overlooked, and perhaps learn another trick or two - oh joys of open source.

Third, to be used in DosBox, the algorithm doesn't need to be generic - DosBox has some limitations (e.g., image size, bit depth of the palette) which enabled me to optimize more than a generic implementation could be optimized.

So, here it is:

http://sourceforge.net/tracker/index.php?func … 551&atid=467234

I've finished a first, experimental version of hq2x for dosbox. It still has a fair number of limitations, and I need to do some serious profiling to get the optimal cache-vs-cpu usage. Moreover, it is only tested on GCC. The mmx code is disabled, the mmx-less variant is (for now) faster.

Usage:

patch, recompile (with maximum optimizations!), set scaler=hq2x. Use Ctrl-F3/Ctrl-F4 to turn the hq2x trigger value up and down.

Limitation: Only works in 16 or 32 bit BGR mode (this includes opengl, but not overlay - on the todo).

Speed is roughly like advmame2x, but there are still some sound-related issues (due to cache trashing, it seems).

Stay tuned for more, and much fun while drooling over the quality.

Could you please attach the .diff file?

Might someone be so kind as to post screenshots?

Oops. SF seems to have swallowed the diff. I re-uploaded it to the tracker page.

Here are two screenshots from X-Com with hq2x scaler.

Note that the triger value is configurable, thus the same screen can look quite a bit different - this is a trigger value of around 16, I usually run ufo at 65 - it depends on the game and your preference what looks best.

I'm messing here with something I really don't know anything about, so don't take this to serious. When I apply the patch to yesterday's CVS I get undefined references in render.cpp to, e.g. Hq2x_colourTrigger. Patching produces no errors so it might be something wrong in the code.

I'm messing here with something I really don't know anything about, so don't take this to serious. When I apply the patch to yesterday's CVS I get undefined references in render.cpp to, e.g. Hq2x_colourTrigger. Patching produces no errors so it might be something wrong in the code.

You have to rerun automake & co., because the diff does not patch Makefile.in where needed. I myself needed to install automake-1.6, autoconf-2.53 and then run ./autogen.sh. Strangely, automake-1.5 screwed something up for me.

Ha! After downloading and compilgin automake, autconf and obtaining the png and zlib library everything compiles nicely. Now that I can compile, all that's left is to learn C++ 😉

I know you already dismissed HQ3x but I speculated that this might have to do something with two being even and three being odd so some things cannot be transferred easily from HQ2x to HQ3x. But what about HQ4x, would it be easier or is there a chance you are going to implement it? Would look nice on my 1400*1050 notebook display. Though perhaps unplayably slow...