You know, the latest ATI cards are available starting at 80 euros for the low-budgte variant, I dare not guess how cheap a "old" but nice Radoen 9800 would be.

You're welcome to figure out how to plug them into my notebook... 😉

Hi folks!

I'm a long time DOSBox user and enjoy playing all my old games immensly.
Usually, I download the newest CVS from gulikoza - thanks, by the way - and I know, that these versions are actually not supported.

I didn't have time to play for a couple of months and basically just updated DOSBox without actually playing.
A few days ago, I wanted to play again and noticed the following problem:

I usually use Direct3D with 2xSAI (I like this filter the most) but something is wrong with the picture.
It has a strange dithered look. As if suddenly the color palette would not suffice (kinda like a truecolor-picture looks with 256 colors).
I don't know exacltly if it is the new DOSBox-build or perhaps the new nvidia-driver (the most actual on the nvidia-homepage).
Since I don't want all the hassle with downgrading stuff, I thought I'll ask first. Maybe someone knows this problem.

Once again, I know that CVS-builds are not supported but I thought maybe here in the Direct3D-patch-topic a problem like this kinda serves as beta-test-feedback...

Thank you for any help you can give me!

Keep up the great work, you really made me very happy with DOSBox!

- Pat

Could it be that you're running your desktop in 16-bit color instead of 32-bit color?

Yup, feedback is most welcome 😀

A screenshot would be nice (with print screen...not dosbox ctrl-f5) to see what we're talking about. Also, all earlier dosbox versions are available on my page, you can simply download, unzip to a different directory and copy your current config file to test an older release. But there hasn't been that much changes in the D3D code that something like this could happen...

Thanks for the suggestions.
I'm currently not at home, so I'll try to post some screenshots later.

My desktop is set to 32 bit color, so I guess that should not cause that problem. By the way, does 2xSAI need 32 bit color depth or does 16 bit suffice for a 256 color game?

Yesterday, I tried DOSBox with an older nvidia-driver (77.77) but that doesn't fix the issue - quite the contrary. With the 77.77 drivers my pc crashes when I try to close DOSBox via CTRL-F9 and presents a nice bluescreen.
As the reason it shows me some nvidia-dll-file (nv4_*.dll) so I guess it's back to the actual 78.01-drivers.

I'll try an old DOSBox-version later today to see if that works.

One interresting aspect of the whole thing is, that i can use other scalers just fine. HQ2x works like a charm - I just prefer 2xSAI.

Well, I tried using three older versions of DOSBox but no cigar.
I am sure, that at least with the 050630-build it worked before. So I guess, it's not a problem with the build nor with nvidia-driver.

There are only two things remaining (as far as I can see):
Number 1 - Something is wrong with my version of directx. However, whenever I try to install directx 9c it just zips through the installation and tells me everything is all right.

Or Number 2 - my nvidia-card has some sort of defective pixel-shader. It's one of these geforce 6800 and they should be compatible up to 3.0 if I'm not mistaken.
But until now I had no problems with other games. I just installed Black & White 2 and that games works like a charm and I'm guessing it make heavy use of various pixelshaders.

I still try to make some screenshots later.

- Run dxdiag to see if your DirectX files are okay.
- You're not using the WINDIB hack for DOSBox/SDL are you? If you don't know what that is then you're not 😀
- Post a screenshot
- Try disabling FSAA and anisotropic filtering in your nVidia driver settings. Try fiddling with other options too.
- Did you change video driver versions since the last time you remember it working properly?

I don't know if this is the right place to post this, but...

I like the scale2x.fx shader, and it's faster than 2xSaI.fx; however it has a problem: it doesn't work very well with photorealistic images with countinuous tones, such as carefully hand-shaded sprites.

Having no idea of anything, I took a look at scale2x.fx. It seems to select whether to use the original pixel or another "predicted" pixel the shader (well, the algorithm) checks for patterns by cheching whether pixels are equal.

For photorealistic scenes, even close pixels have usually sightly different colors, and the algorithm degenerates into simple nearest filtering.

So I changed:

1	bool al	= all(A	== L);
2	bool ar	= all(A	== R);
3	bool bl	= all(B	== L);

To:

1	half4 LL = L-0.1;
2	half4 LH = L+0.1;
3	half4 RL = R-0.1;
4	half4 RH = R+0.1;
5
6	bool al	= all((A < LH) && (A > LL));
7	bool ar	= all((A < RH) && (A > RL));
8	bool bl	= all((B < LH) && (B > LL));

This improved image quality quite a bit. You can experiment with different thresholds (in my example it's 0.1), for example 0.25 for very aggresive filtering. 0.5 will make all the conditions pass and degenerate the algorithm into nearest filtering again. 0.0 is the original algorithm, which still gives the best results for games with few colors (most of them).

Now, a question:

I tried the following optimization:

1	bool al	= ((A.rgb < LH.rgb) && (A.rgb > LL.rgb));
2	bool ar	= ((A.rgb < RH.rgb) && (A.rgb > RL.rgb));
3	bool bl	= ((B.rgb < LH.rgb) && (B.rgb > LL.rgb));

So only RGB (and not unused "A") had to be checked. On the modified shader, it reduces intruction count from 48 to 41. On the original shader it reduces from 35 to 29. However, the output is shightly different. Why?

To tell the truth, I don't even know if the syntax of what I did is correct: I assume all(A<B) is true when all the components of A are lower than the respective components of B; and A.rgb<B.rgb is true when components r, g and b are lower, ignoring a. And I assume A=A-0.1 means "substract 0.1 from all and every component of A".

Another question: Is 2xSaI.fx supposed to be the same as hq2x?

Noo idea about the rest, but:

BioFSlow wrote:

Another question: Is 2xSaI.fx supposed to be the same as hq2x?

Not even close. Hq2x (and the hardware-accelerated variant OpenGL-HQ) is very different from all other well-known scalers. Look at screenshots of OpenGL-HQ (http://www.garni.ch/dosbox/) to see how different it is. It's more complex, so it's probably impossible to implement in a single .fx file (OpenGL-HQ uses 3 different fragment programs at once to achieve the desired effect)

Finally a screenshot! I decided to post a screenshot form the title of "Dagger of Amon Ra", since it has two very different colors, so you can see the effect clearly plus it i suppoed to have a lot of clear lines, that are now dithered.

I use a resolution of 640x480, which should be enough since it's the double of the game's resolution.

Interrestingly, I tried this OpenGL-hq2x thingy and strangely enough it didn't work - just froze my pc.
The built-in hq2x works just fine and so I'm using that for the moment. Still, I'm a big fan of 2xSAI...

Ran dxdiag but it tells me everything is all right. Made all the tests and everything. So I guess there's no problem there.

I'm definitely not using WINDIB sicne I have absolutely no clue what you're talking about. 😉 Except if it is built in in gulikozas build...

Tried disabling all fancy grafic-stuff (FSAA, anistotropic filtering, even vsync) but no difference.

Yes, I did change videodrivers but I already tried changing it back. I even went one driver-version further back but alas no luck.

I loaded up LB2 this morning (my version is from my KQ Collection Series) and I couldn't reproduce your graphics problem whatever settings I tried.

@ Moe & gulikoza (or anyone that really understands it!) - Any chance of pointing me towards or providing simple docs on what settings do what in conjunction with what else for the config file entries (for example opengl[hq]/direct3d/scaler/hwscale/pixelshader,fullfixed - note the mix of entried between the [sdl] and [render] sections). It's clear that some settings wouldn't be used/appropriate if others are used. Surely I can't be the only one wondering if this seems a little under explained?! Thanks guys.

I'm not really sure what to look for in your image...the jagged lines?
Anyway here's a screenshot of how it looks at my place (d3d, 2xsai)...is this image normal? I'm afraid that 2xsai is not really nvidia frendly and I only have ATi to test with...
The problem might be texture aligement, if the texture is shifted by 0.5 pixel something like this might happen. But I think I got it right, perhaps check your settings if there is something that might affect this...

@BioFSlow: I'm afraid I don't know much about shader programming...but if you figure something out let me know, I'll include your modified shaders 😁. SaI filter is not related to HQ filters. There's a link to SaI homepage on my page if you want to know more about it...

@Reckless: You're probably right. It's seems clear to me cause I programmed it. I'll try to explain:

hwscale - scale final image by this factor, if the output mode supports hardware scaling. Works with everything except surface.
pixelshader - obviously only works with d3d, loads an advanced scaler (that is then used when hwscale > 1, or normal2x is set)
fullfixed - set a fixed fullscreen resolution. If this resolution is > then game resolution, the image will be scaled to this resolution. It uses hardware for scaling, bilinear sampling in opengl, overlay and ddraw, point sampling in d3d (no pixelshader set) and openglnb or some advanced algorithm with d3d (pixelshader set) and openglhq (hq obviously)
scaler - sets a software scaler. This should be set to none or normal2x when hardware scaling is desired. Software scalers use CPU to resize the final image.

I run against a GF6600GT and can confirm that the 2xsai filter works the same as gulikoza's example screenshot.

Thanks for the update on the settings. From what you've said I understand that all the scalers available in [render] section are all CPU based. Can I assume that 'one day' some shader guru could possibly provider the necessary shader file for hq[2/3/4]x so that the processing is offloaded to the video card instead of the CPU?

Openglhq is the opengl equivalent of the HQ shader. So say thanks to Moe 😀

Wow! OpenglHQ rocks, and I didn't event test it... There's a lack of clear documentation.

* Both opengl and openglnb run extremely slow for me, especially openglnb, which I think is opengl with nearest filtering. (at 35fps, max 4500 CPU cycles)
* However, openglhq is the FASTEST hardware scaler with filtering that I have! It's faster than D3D+scale2x.fx. (at 70fps, max 18000 CPU cycles!!!)

(I have a Mobility Radeon 9700, which basically is a 9600XT)

* I read somewhere that hq2x is as fast as normal2x. Wothout hardware support, on my machine, is several times slower. The slowerst of them all. Never thought I would be able to actually use it...

OK, so (correct me if I'm wrong):
* advmame2x = scale2x.fx
* interp2x = bilineal filtering
* advinterp2x = ???
* hq2x = openglhq
* <not done in software (why not?)> = 2xSaI.fx

* On direct3d or openglhq mode, shader is used when scaler=normal2x OR hwscale>1. In either case in direct3d, first a 2x version is created, and then scaled again (???) openglhq scales well to any vaule.

What a mess 😀 Having two different sections ([sdl] and [render]) doesn't help...

BioFSlow wrote:

* I read somewhere that hq2x is as fast as normal2x

You must be joking, right? OpenGL + HQ2x filtering bring my computer to an utter crawl when used.

eL_PuSHeR wrote:

You must be joking, right? OpenGL + HQ2x filtering bring my computer to an utter crawl when used.

As I saild, mine too. But:

Moe wrote:

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

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

That's what I was pointing out: It's slow, but Moe himself said that (???)

Opengl and openglb are not suited for Radeon cards. If you want software hq2x any output other than opengl is better. I've even done some tests and hq2x works somewhat faster with D3D than overlay on my computer...Moe, however, spent some time optimizing openglhq mode (including making the whole thing threaded, something I still plan for D3D) which makes it much faster, although it's still slower than D3D for me, especially in higher resolutions.
I once proposed to make a config entry for hardware scalers but it did not get far 😀. Different sections are because sw & hw scalers are applied at different points of the whole drawing procedure.
As for the last * in BioFSlow's post...the original shaders were never designed to scale to any value. So they might perform less than optimal with != 2 scaling...

BioFSlow wrote:

As I saild, mine too. But: […]
Show full quote

eL_PuSHeR wrote:

You must be joking, right? OpenGL + HQ2x filtering bring my computer to an utter crawl when used.

As I saild, mine too. But:

Moe wrote:

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

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

That's what I was pointing out: It's slow, but Moe himself said that (???)

Yes, I did. The statement depends a lot on your CPU, however, and isn't that true anymore, I'm afraid. Two issues:

Firstly, advmame is relatively slow (compared to the little work it does) on Pentium4 boxes, because of tons of conditionals - branch prediction doesn't work well with it, and P4 suffers most due to it's long pipeline. If you use a different CPU, advmame might be a little faster.

Secondly, I had to adapt Hq2x to changes in CVS, which made it run noticeably slower. Video emulation got better, but it killed some optimizations I did in hq2x. Sorry about that, not much I can do. Accuracy of emulation and speed do not always mix well.

About OpenGL on ATI: It's slow because it uses non-optimal memory layout and data transfer. It was obviously optimized by an nvidia user 😉. OpenGL-HQ is better since I optimized for ATI as well (kept nvidia stuff, of course). By the way, of course it runs well on a Mobility 9700, that's what I own 😀