ZenJu wrote:2. it calulates a scaling factor. E.g. if output screen width is 1024 pixel and the raw image with is 320 pixel, then we ideally need a scaling factor of 3.2. This factor is rounded to 3 and a 3xBRZ scaling is applied.

Can you make it scale evenly with nearest neighbor above the target resolution (in above example, 320 width would end up as 1280), and then start scaling down from there instead? This would provide better quality as the picture would get less blurred getting downscaled with the filter rather than upscaled (not only that but the proportions would be more even for the filter to begin its work); you could scale down to an exact width of 1024 if you add a second lanzcos or cubic filter to prevent distortion.

Don't understand why emulators and such don't scale this way (correct me if I'm wrong) since picture output would avoid the muddy interpolation that plagues uneven stretches; it would look razor sharp instead and not have black borders. It's really necessary in todays world of LCD's being stuck at one resolution.

Great filters by the way!

Regards

EDIT:
Did not mean to make duplicate posts! So sorry. Please remove the excess posts before this one; whoever is moderator. Sorry and thank you.

@Holering: xBRZ is a software scaler. Adding a second software scaler on top for high-quality image scaling is likely to become a CPU performance problem. Nearest-neighbor OTOH is super-fast and simple (but introduces visible artifacts).

Ideally, this second high-quality stretching step would run on the graphics card directly instead of the CPU. However if the emulator does not support D3D output natively, it's not a small task to retrofit this capability. But if there was "official" support for xBRZ, then this would likely be the way to go.

It seems you tested with "aspect=true", where Dosbox adds artificial lines (most noticeable with the numbers 81, 98, ect.). In contrast to the other scalers xBRZ is not really integrated into Dosbox, so this setting needs to be turned off, or it will give those artifacts.PS: Please don't use lossy .jpg but .png files for comparison and include the non-scaled original image, so that it's possible to reproduce and verify the results.

[quote="ZenJu"] It seems you tested with "aspect=true", where Dosbox adds artificial lines (most noticeable with the numbers 81, 98, ect.). In contrast to the other scalers xBRZ is not really integrated into Dosbox, so this setting needs to be turned off, or it will give those artifacts.PS: Please don't use lossy .jpg but .png files for comparison and include the non-scaled original image, so that it's possible to reproduce and verify the results. [/quote]

Just a quick note on xBR (I'm aware xBRZ is somewhat different). The new xBR algorithm uses a multi-pass shader, and therefor is incompatible with current shader patches for DOSBox. Would love to see a similar multi-shader approach allowed in DOSBox. The shader I'd probably be more excited to see for DOSBox would be Mdapt, a de-dithering shader that can make things like dithered transparency appear actually transparent, and significantly clean up other dither related patterns.

@oasis789:If all you want to do is try out dosbox and xBRZ without messing with your settings, then use my dosbox build at the beginning of this post. It automatically does what's required (e.g. it sets internally aspect=false, ect.). Just copy the "dosbox+xBRZ.exe" into your dosbox directory and start.

If on the other hand you want to get xBRZ working with Taewoong's / ykhwong's SVN-Daum build then it's more difficult: You have to adapt certain dosbox settings related to xBRZ manually as described in the first post, otherwise it won't work or won't look good, like on your first screenshots.

jimbo1qaz, me too. I'm trying to make a wrapper for this code, but, between your Scaler and the ZenJu Scaler, generates diferent images, Zenju, Can you help us showing your ScalerTest source code? I'm coding it in MinGW

The features on both images are the same, just some colors are different. Assuming you're using the default configuration paramaters for xBRZ (= default-constructed xbrz::ScalerCfg), maybe it has to do with the way you generate the .png image. The scaler test program uses wxImage for this purpose.