By default, we preserve the aspect ratio when scaling up limited to what resolution the screen can support, thus fullscreen output can sometimes have some black borders to achieve this.
Doing otherwise, ie. stretching to the full screen size would distort the aspect ratio which is not very desirable and would be more likely to be reported as a bug.
I think you may be able to avoid this by setting your screen resolution to exactly match the game output screen size multiplied by any scaler factor used... i.e. 320x200 game running with hq2x will output at 640x400, so if you set the screen resolution to that, the fullscreen output should then work without borders. As the screen is more likely to be 640x480, you may want to look at the "aspect ratio correction" option on the graphics tab:
http://wiki.scummvm.org/index.php/User_ ... aphics_tab
Overall, getting the screen to output fullscreen with no black borders in the general case is not easy and thus you will need to work at this per-game to get that kind of work.
Though using OpenGL output should allow arbitary scaling factors... this still can be tricky. Also, as I mentioned the entire scaler subsystem is pending some severe reworking with PR #271 ... so *shrug*
"Your mileage may vary"... I don't think I can be of any further help, though if you wish to submit a patch to the project to help with this for review, then feel free.
native resolution downscaling for scummvm
Moderator: ScummVM Team
I can understand what you say about the stretching it to full screen distorting the aspect ratio. As a personal opinion, I just don't see it as a bug, though. I think it could be an option, for example.
I can switch to hq2x and don't have any black borders, you are right. But I don't know if it's my eyes playing tricks on me (probably not) but hq2x seems A LOT more blurry than hq3x. It's undeniably noticeable, to a point that I'd rather run in in hq3x with the black borders, than in hq2x with the full screen, just because of the "blurriness".
You were very helpful, as usual. Although I didn't quite understood the last 2 paragraphs. About the scaler subsystem needing severe reworking with "PR #271" and about submitting a patch for review... how would I do that?
Thanks again mate!
I can switch to hq2x and don't have any black borders, you are right. But I don't know if it's my eyes playing tricks on me (probably not) but hq2x seems A LOT more blurry than hq3x. It's undeniably noticeable, to a point that I'd rather run in in hq3x with the black borders, than in hq2x with the full screen, just because of the "blurriness".
You were very helpful, as usual. Although I didn't quite understood the last 2 paragraphs. About the scaler subsystem needing severe reworking with "PR #271" and about submitting a patch for review... how would I do that?
Thanks again mate!
It might be more blurry because of how your monitor/graphics driver handles resoultion scaling.rotchild wrote:I can switch to hq2x and don't have any black borders, you are right. But I don't know if it's my eyes playing tricks on me (probably not) but hq2x seems A LOT more blurry than hq3x. It's undeniably noticeable, to a point that I'd rather run in in hq3x with the black borders, than in hq2x with the full screen, just because of the "blurriness".
rotchild: Unfortunately, it is not quite as simple as that...
We upscale the original graphics using https://en.wikipedia.org/wiki/Pixel_art ... algorithms. The results can vary by filter and it depends on the exact output size and whether this is a exact multiple / power of 2 of the original... if not, then rounding and aliasing effects can start to appear, especially if your graphics card also applies filters internally to improve the appearance of upsampled media:
https://en.wikipedia.org/wiki/Aliasing
I was referring to Pull Request #271 which was mentioned earlier in this thread which adds a number of new filters and is a major refactor of this subsystem, but is still pending merge as a number of issues to shake out. As for the patch, I meant that if you are capable of coding, we are an open source project and help on the code would be the best way of fixing this. Otherwise, it will have to wait until a project developer has the time and inclination to look at this.
We upscale the original graphics using https://en.wikipedia.org/wiki/Pixel_art ... algorithms. The results can vary by filter and it depends on the exact output size and whether this is a exact multiple / power of 2 of the original... if not, then rounding and aliasing effects can start to appear, especially if your graphics card also applies filters internally to improve the appearance of upsampled media:
https://en.wikipedia.org/wiki/Aliasing
I was referring to Pull Request #271 which was mentioned earlier in this thread which adds a number of new filters and is a major refactor of this subsystem, but is still pending merge as a number of issues to shake out. As for the patch, I meant that if you are capable of coding, we are an open source project and help on the code would be the best way of fixing this. Otherwise, it will have to wait until a project developer has the time and inclination to look at this.
Sorry digi, no coding capabilities whatsoever here 
User level, as you might have noticed before.
I wasn't familiar with those "newer" scalers, like xBRZ and RotSprite... I think that eventually you devs will look upon it, I mean, it's amazing to think that you can play older games with way better graphics, on HD displays. Taking months, or taking years, doesn't make a difference, as I'll keep on supporting this amazing open-source project, as usual
Thanks again for the heads up guys!
User level, as you might have noticed before.I wasn't familiar with those "newer" scalers, like xBRZ and RotSprite... I think that eventually you devs will look upon it, I mean, it's amazing to think that you can play older games with way better graphics, on HD displays. Taking months, or taking years, doesn't make a difference, as I'll keep on supporting this amazing open-source project, as usual
Thanks again for the heads up guys!
Update:
Guys, I'm kind of aware about the "policy" on new scalers and all. But with new widescreen TV's/monitors that support HD, wouldn't it seem "prudent" that better scalers would be added, like these new xBRZ scaler? I mean, if code bloat is an issue (I'm speculating here, sorry if I'm mistaken), it could replace the HQ filters, I guess... Anyway, here's a comparison (I won't link directly to the image, as it might be too big for the forum format, will just put the link):
HQx: http://i.imgur.com/RXpN5.png
xBRZ: http://i.imgur.com/9vrZR.png
Just asking though...
Guys, I'm kind of aware about the "policy" on new scalers and all. But with new widescreen TV's/monitors that support HD, wouldn't it seem "prudent" that better scalers would be added, like these new xBRZ scaler? I mean, if code bloat is an issue (I'm speculating here, sorry if I'm mistaken), it could replace the HQ filters, I guess... Anyway, here's a comparison (I won't link directly to the image, as it might be too big for the forum format, will just put the link):
HQx: http://i.imgur.com/RXpN5.png
xBRZ: http://i.imgur.com/9vrZR.png
Just asking though...
It's not about code bloat at all... the way scalers are implemented currently is hackish, thus adding new scalers will only result into more hacks being added. The scaler code has been rewritten, as mentioned, which will allow for new scalers to be added. However, this rewrite hasn't been added in ScummVM yet, as it affects some of our ports, which haven't been updated.