I applied the patch and tried to compile in MS Visual C++ Net 2003 but without success, there were bugs like the following ones:
E:\dosbox_sources_from_d\dosbox\src\gui\render_hq2x.cpp(399): error C2086: 'int __attribute__' : redefinition
E:\dosbox_sources_from_d\dosbox\src\gui\render_hq2x.cpp(399): error C2143: syntax error : missing ';' before '='
... (more bugs like that)

What is that __attribute__ construction anyway? Is it some GCC specialty? If yes, then you should replace it by something more universal...

Mirek

the dosbox code makes use to __attribute as well. but it's ifdefed

in our case it's most of time replacable with #pragma pack

but I (while not looking at your code) think it might be some force_inline attribute or so .

(they are in render_templates.h as well I think)

I just played Wing Commander with hq2x in opengl mode and it looks great. Hq2x seems to excel at monochrome text where it smoothes out all the edges really nicely. It doesn't like some edges where the graphics artists of the beginning '90s employed manual anti-aliasing.

I noticed a strange thing with opengl and hq2x. On my desktop Athlon XP 2000+ with Geforce MX440 hq2x and opengl work fine together producing the nicest output I've ever seen from Dosbox. On my notebook (Pentium-M 1.3GHz, Radeon 9000) however, where opengl is a bit slow anyway, activating hq2x along with opengl dramatically reduces Dosbox's framerate so everything gets unplayable. If I use no scaler with opengl Dosbox on my notebook is not as fast as with overlay, but at least it's not dramatically slower than overlay. Any suggestions as to how this behaviour can be explained?

radeon's have much slower texture uploading speeds since they miss a special nvidia opengl extension that speeds it up.

the dosbox code makes use to __attribute as well. but it's ifdefed

in our case it's most of time replacable with #pragma pack

but I (while not looking at your code) think it might be some force_inline attribute or so .

Indeed, the __attribute__ is a gcc construct. It's used to enforce the best possible alignment of the big lookup tables, i.e. at cacheline boundaries (up to 32 byte). You can remove them, won't hurt much - the tables are too big anyways. This code being experimental, I will try to make your life easier, but for now I don't promise compiler independence. There's too much to be tested/profiled, especially for different CPUs.

The code as it is now is the best possible variant for pentium2. Right now I am testing it on a pentium3, which probably means the MMX code will be modified and reactivated, and in that case, compiler independence will be much work. (I can only ensure intel-compiler vs. gcc independence, as I have access to these two. I dislike manual asm programming, as the compiler, especially the intel compiler, is a lot smarter than me with respect to instruction ordering for optimal pipeline usage)

OTOH, if you have simple tips on how other compilers do things, tell me and I try to keep that in mind. And a tip on how I can recognize the other compilers would be nice.

Just a quick note to keep you updated: I've uploaded a new version of the patch, intended for latest CVS. There's nothing much new, but it should work with any rendering method and any bit depth now (except 8bit, obviously). It also includes non-gcc fixes, so please tell me if it works on other systems. Use the link some posts above.

Errors when compiling in MS VS Net 2003:

Loop(320,long,1)
c:\dosbox_sources_from_d\dosbox\src\gui\render_hq2x.cpp(715): error C2106: '-=' : left operand must be l-value

Loop(Scaler_SrcWidth,long,0)
c:\dosbox_sources_from_d\dosbox\src\gui\render_hq2x.cpp(716): error C2106: '-=' : left operand must be l-value

Loop(Scaler_SrcWidth,short,0)
c:\dosbox_sources_from_d\dosbox\src\gui\render_hq2x.cpp(726): error C2106: '-=' : left operand must be l-value

Loop(320,short,1)
c:\dosbox_sources_from_d\dosbox\src\gui\render_hq2x.cpp(725): error C2106: '-=' : left operand must be l-value

Mirek

Thanks, try again please. I hope I could fix it.

Is there any way to allow it to stretch itself when in fullscreen?

I don't entirely understand the question. Fullscreen should be exactly that: fullscreen. It works nicely here. Maybe your system doesn't switch to a lower resolution? In that case, opengl hardware scaling is an option, it should work fine.

Overlay scaling needs YUV, which isn't supported by hq2x yet (I may or may not add that some day... my tests showed it looks a bit weird and is noticeably slower. It's possible, but no priority at all)

I compiled it succesfully using MS VC Net 2003. Visually it looks very well.
😀

The only problem I have is the one I was afraid of - it is not really usable on my 1 GhZ Athlon - it is impossible to run any decent game quickly enough and without stuttering sound. 🙁
I guess it probably uses SSE instructions (not supported on older Athlons), doesn't it?

Mirek

If it's too slow, why not use the original MMX-optimized code:
http://www.hiend3d.com/bin/hq2x_src_asm.zip

If it's too slow, why not use the original MMX-optimized code:

The original code is a lot slower than my current C implementation. My code also has some MMX parts, but they are slower than the table-based routines, at least on the CPUs I can test. Thus, the current code is plain C, no MMX/SSE. It is, however, quite cache-intensive, so it makes the sound stutter much earlier than without Hq2x (due to cache misses in the sound code).

I haven't yet have a chance to check on more modern CPUs. I wrote the new MMX code in order to massively reduce cache usage, so it might very well pay off on Athlons/P4s. It didn't on P II/P III. I won't forget that, but I don't have regular access to a developer box with these CPUs.

One thing I noticed is, on an Athlon the full core is a lot faster than the dynamic core. Perhaps another cache issue, worsened by Hq2x.

I hope to get into that soon.

As a sidenote: There's a new version to come soon, it uses an adaptive colour distance calculation, which improves quality even more, at only a very small performance hit. The adaptive version manages to smooth all the borders in newer games, where game graphics already uses some kind of anti-aliasing, while still giving crips edges where they exist.

That's very good news since I the main weakness of the scaler lies in graphics which already use some kind of anti-aliasing. A good example is Day of the Tentacle where the scaler mainly improves the character sprites which don't use many colours. The background graphics though, which seem to be scanned in from drawings are barely improved.

So here it is. Or rather, on sourceforge, see link on page 1.

This time, I need to talk about the technical details, as you need this knowledge to find the best parameters for your game. The latest patch uses a dual approach:

A static threshold is used to find areas of nearly-equal colours. The static threshold ranges from 0-255 and has the exact same meaning as before.

After applying the static threshold, the 4 input pixels involved in each output pixel are analyzed and the maximum and minimum difference is calculated. Then an average value of these two is calculated, which is user-configurable from 100% maximum/0% minimum to 0% maximum/100% minimum. This adaptive threshold ranges from 0-100, 75 means the adaptive threshold value is 75%max + 25%min.

Thus, there are 4 keys to tweak these settings: Ctrl+Alt+F3/F4 decrease/increase the static threshold. Ctrl+Alt+F5/F6 decrease/increase the adaptive ratio.

The default value is 0/75 (no static threshold, 75%max adaptive threshold), which is very good for simple cases. But when you have games like Master of Magic, with rendered&anti-aliased graphics but also many sharp edges, you need both settings. Likewise for X-Com, which has many (supposedly) smooth areas, yet also some edges which differ by only a small colour amount. Final example is Ultima 4 (+VGA patch), which has mostly easy scalable line graphics, but a few very noticeable line steps, the avatar even has some anti-aliasing.

Each one has different properties. The key to success is to find the optimum usage of static vs. adaptive threshold. Using this procedure, you get the optimum values for your game in 15 minutes at most:

Start the game, play it a bit with default settings. Look for edges or line steps you don't like. Also watch for edges it gets right. Try to get the working and non-working places on screen simultaneously, or at least near each other.

Now try to increase the dynamic threshold. Doesn't work? Fine, turn it down to 0. Increase the static threshold until it gets some edges (hopefully some of the previously non-working ones). As soon as that happens, turn the dynamic threshold up again, see if it gets the rest of the edges as well. Nothing happens, or it gets too much? Turn down the static threshold until the wrong edges are right again. Turn up the dynamic threshold until the missing edges get recognized. Repeat 5-10 times until everything looks right.

No success? Then try the opposite direction: dynamic threshold 100, turn up static until all edges are recognized. If wrong edges remain, lower dynamic until the wrong edges disappear. Repeat until everything works okay.

So you think you are done? Move the mouse. See if the mouse pointer is interrupted, especially in busy areas. If it is, increase the adaptive threshold (if using the first approach) or the static one (if using the second approach). Keep the correct edges always correct, and try to get as much mouse pointer correctness as possible - this is simply not possible at all times, but try to get the best possible value.

Peek at the console to see which values you have set last and set them in dosbox.conf. Complicated, but worth the effort, IMHO.

Feel free to post your values here, I'd like to see some more. If it works well enough, I may feel inclined to do Hq3x next. Funny how opinions can change - Hq2x is so good, now the blurriness of fullscreen-on-a-LCD annoys me 😀

P.S.: My prime success case is X-Com: I use static 16, adaptive 54, which works 98% perfect. (The last part I'd love to see would be the pattern on ufo floor tiles, but I guess that's impossible to get while having smoothened outer ufo walls.)
Masters of Magic was also hard to get: I use static 54, adaptive 100, but I'm not entirely convinced by that yet - gets everything, but too blurry in some parts.

If it works well enough, I may feel inclined to do Hq3x next. Funny how opinions can change - Hq2x is so good, now the blurriness of fullscreen-on-a-LCD annoys me 😀

Moe, any news on Hq3x? I'd really like to see it in action. 😁

Well the matter will be looked at by the dosbox team later.

At the moment features are frozen. (have been for while) as we are preparing and testing a new release.

After that new stuff like this will be considered for the cvs tree.

Alkarion, Hq2x is more or less finished. I am very pleased with the quality, which is noticeably better than stock Hq2x due to some custom coding. I don't think it can be improved any more (unless you write something completely new).

Speed is an issue on some CPUs, but I will tackle that when I can work on such a machine.

Well, I know Hq2x is a great filter and I am using your adaptive version for a while now (it's a dream combined with the gentle blurring OpenGL provides). It's just that you mentioned working on Hq3x and I wanted to know if you made any progress with that.