Does anyone know what algo XP -> full screen DOS?
Re: Does anyone know what algo XP -> full screen DOS?
I got onto my fbc machine and gave the code a trial test. I'm getting 33fps. It's pretty impressive, considering this is a CherryTrail tablet PC.
It will take me some time to understand the code and implement, so I will report back if there are any problems I may encounter.
Now, I didn't want to raise this issue up before until the code was fleshed out. But, this is what I actually did in C# to maintain a consistent look across my two tablets with the same screen size, but different resolutions (you can see the final image makes each pixel's aspect ratio 120% wide to 100% tall):
Source memory bitmap ([640/1.5]x[400/1.25]) => counting_pine's algo => 640x400 bitmap [with soft edges] => nearest neighbor 2x/3x [no interpolation] => 1280x800/1920x1200
So as you can see, it's a two pass method which results in digital perfection... C# does the nearest neighbor 2nd pass instantaneously with its own built-in algo, so no performance loss.
So now, my question is what do I need to do to make the second pass a simple nearest neighbor blow up? Can I reuse part of the code to do this?
(P.S: This method makes my images look better than a simple scaling to the display's resolution... Sort of like the MineCraft effect -- blockier graphics are more fun to look at.)
It will take me some time to understand the code and implement, so I will report back if there are any problems I may encounter.
Now, I didn't want to raise this issue up before until the code was fleshed out. But, this is what I actually did in C# to maintain a consistent look across my two tablets with the same screen size, but different resolutions (you can see the final image makes each pixel's aspect ratio 120% wide to 100% tall):
Source memory bitmap ([640/1.5]x[400/1.25]) => counting_pine's algo => 640x400 bitmap [with soft edges] => nearest neighbor 2x/3x [no interpolation] => 1280x800/1920x1200
So as you can see, it's a two pass method which results in digital perfection... C# does the nearest neighbor 2nd pass instantaneously with its own built-in algo, so no performance loss.
So now, my question is what do I need to do to make the second pass a simple nearest neighbor blow up? Can I reuse part of the code to do this?
(P.S: This method makes my images look better than a simple scaling to the display's resolution... Sort of like the MineCraft effect -- blockier graphics are more fun to look at.)
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Does anyone know what algo XP -> full screen DOS?
If I understand correctly, scaling up using nearest-neighbour after running my algorithm will result in the interpolation rows/columns from my algorithm being blown up to 2-3 times the size?
The crisper solution is to run my algorithm after nearest-neighbour, or to do everything with my algorithm (I think the two should actually be equivalent), but I appreciate that means up to 6x more work for it to do. (And also, perhaps you're saying this specific effect is what makes it look like Minecraft?)
The crisper solution is to run my algorithm after nearest-neighbour, or to do everything with my algorithm (I think the two should actually be equivalent), but I appreciate that means up to 6x more work for it to do. (And also, perhaps you're saying this specific effect is what makes it look like Minecraft?)
Re: Does anyone know what algo XP -> full screen DOS?
No prob, just ask. It isn't rocket science, don't worry.CGAMan wrote:It will take me some time to understand the code and implement, so I will report back if there are any problems I may encounter.
My, of course. The earlier version did this. Simply change the main loop (the one that does the blitting) with this:CGAMan wrote:So now, my question is what do I need to do to make the second pass a simple nearest neighbor blow up? Can I reuse part of the code to do this?
Code: Select all
dday = 0
for y as integer = 0 to img->height - 1
dday -= FPScale
startX = src
do while( ( dday < 0 ) andAlso ( yy < dstHeight ) )
ddax = 0
src = startX
xx = 0
for x as integer = 0 to img->width - 1
ddax -= FPScale
do while( ( ddax < 0 ) andAlso ( xx < dstWidth ) )
*dst = *src
dst += 1
ddax += incX
xx += 1
loop
src += 1
next
'dst += dstPadding
dday += incY
yy += 1
loop
src += srcPadding
next
This is the result I get when I blow an image to 1280x800, using your ratios:CGAMan wrote:(P.S: This method makes my images look better than a simple scaling to the display's resolution... Sort of like the MineCraft effect -- blockier graphics are more fun to look at.)
See if it's similar to the results that you get when doing all that. You see, my code isn't 'proper' LCD scaling like counting_pine's, it's a hack. It combines NN with averaging to achieve something similar but real time. With a little luck we may get something similar to what you got with the two pass method =D
EDIT: This is what I get if I apply your method:
Mmm, I don't know, some pixels got blurred out of existence. Is this look what you're after? Can you post an image that I can use as a reference?
Last edited by paul doe on Dec 15, 2017 11:36, edited 2 times in total.
Re: Does anyone know what algo XP -> full screen DOS?
Yes, indeed. I think I have an idea to actually implement it in a single pass method. Will not look as pretty as yours, that's for sure =Dcounting_pine wrote:If I understand correctly, scaling up using nearest-neighbour after running my algorithm will result in the interpolation rows/columns from my algorithm being blown up to 2-3 times the size?
The crisper solution is to run my algorithm after nearest-neighbour, or to do everything with my algorithm (I think the two should actually be equivalent)[...]
Re: Does anyone know what algo XP -> full screen DOS?
This is correct. The result I was after was a rather coarse-looking edge blur effect. Thus:counting_pine wrote:If I understand correctly, scaling up using nearest-neighbour after running my algorithm will result in the interpolation rows/columns from my algorithm being blown up to 2-3 times the size?
The crisper solution is to run my algorithm after nearest-neighbour, or to do everything with my algorithm (I think the two should actually be equivalent), but I appreciate that means up to 6x more work for it to do. (And also, perhaps you're saying this specific effect is what makes it look like Minecraft?)
1. Source => natural LCD upscaling (blur effect is too fine) aka N.L.U.
2. Source => N.L.U. => nearest neighbor (MineCraft-like look = perfect)
3. Source => nearest neighbor => N.L.U. (blur effect is too fine, once again)
Also, #1 and #3 will look different on diff resolutions. #2 will look the same (a pixel blown up 2x will not look diff than a pixel blown up 3x)
Re: Does anyone know what algo XP -> full screen DOS?
I did this all on a touch screen (so I apologize if it doesn't look as good as with keyboard and mouse):
(Full screen res is 1280x800. Bicubic looks so yucky. The last image looks like... MineCraft!)
(Full screen res is 1280x800. Bicubic looks so yucky. The last image looks like... MineCraft!)
Re: Does anyone know what algo XP -> full screen DOS?
Ah ok, I understand now. Hang on, I'll upload a version of the scaler that looks like that, and you can tweak the blur to suit the look that you want.CGAMan wrote:I did this all on a touch screen (so I apologize if it doesn't look as good as with keyboard and mouse):
...
(Full screen res is 1280x800. Bicubic looks so yucky. The last image looks like... MineCraft!)
Last edited by paul doe on Dec 15, 2017 16:19, edited 1 time in total.
Re: Does anyone know what algo XP -> full screen DOS?
As for reference image... Let's give this one a try:
(It's 640x480, but I'm thinking it could be cropped down from the top left to 640/1.5x400/1.25)
(It's 640x480, but I'm thinking it could be cropped down from the top left to 640/1.5x400/1.25)
Re: Does anyone know what algo XP -> full screen DOS?
It's already resized (the pixels are 2x2). Don't you have one in the native resolution (1:1 pixel scale)?CGAMan wrote:As for reference image... Let's give this one a try:
Re: Does anyone know what algo XP -> full screen DOS?
It must have been a 320x200 game that was upscaled 2x. But this is how it actually appeared in DOS, as a 640x400 game... Anyways, how about this one then?
(But as far as I can tell the original Mario+Yoshi pic in the DATA folder would have done just fine too...)
(But as far as I can tell the original Mario+Yoshi pic in the DATA folder would have done just fine too...)
Re: Does anyone know what algo XP -> full screen DOS?
Ok, included the original image and the one that was above (which is Dungeons of Grimlor II). That one is particularly useful for fine-tuning ;)CGAMan wrote:(But as far as I can tell the original Mario+Yoshi pic in the DATA folder would have done just fine too...)
Very well, here it is: https://github.com/glasyalabolas/fb-image-resize-demo. I included the NN rescaler and the tweakable one. To tweak it, press '1' and '2' to tweak the X-axis, '3' and '4' for the Y-axis, and with '5' and '6' you control the mix of these two.
Experiment with it a little, the settings that I left are the ones that I like the most. I get ~134 FPS, so it's ungodly slow, unfortunately...
Re: Does anyone know what algo XP -> full screen DOS?
Really? You don't think the default settings produces too much digital glare? For instance, I try to focus on that 10 in the Mario+Yoshi pic, but the algorithm really strains my eyes. Sure the pic is looking very sharp after the filter but the eyes don't want to look at any spot for too long.paul doe wrote:Ok, included the original image and the one that was above (which is Dungeons of Grimlor II). That one is particularly useful for fine-tuning ;)CGAMan wrote:(But as far as I can tell the original Mario+Yoshi pic in the DATA folder would have done just fine too...)
Very well, here it is: https://github.com/glasyalabolas/fb-image-resize-demo. I included the NN rescaler and the tweakable one. To tweak it, press '1' and '2' to tweak the X-axis, '3' and '4' for the Y-axis, and with '5' and '6' you control the mix of these two.
Experiment with it a little, the settings that I left are the ones that I like the most. I get ~134 FPS, so it's ungodly slow, unfortunately...
Anyways, might I trouble you to explain what those settings in tweakable.bas really do? Do these deal with the image blurriness/quality? For instance, if I lower avg from 255 to 189, a sort of halo comes out of the crossbow and sword. I like this very much.
BTW, I'm getting a FPS of 21 in tweakable.bas. This is perfectly acceptable! Also, when the halos come out of the weapons, I have no need to do a 2nd nearest neighbor pass as it was meant to achieve this effect...
Lastly, is this code compatible with counting_pine's algo? Meaning would I be able to achieve a 21 fps if I were to modify the scaling algorithm?
Re: Does anyone know what algo XP -> full screen DOS?
Yes, of course, but that's because the interpolation gets blown up as well. It can be done better, but you'll slow it to a crawl. As it currently stands, it behaves just as you described, only the interpolation is different. I'm looking for a way to implement counting_pine's interpolator without using FP math.CGAMan wrote:Really? You don't think the default settings produces too much digital glare? For instance, I try to focus on that 10 in the Mario+Yoshi pic, but the algorithm really strains my eyes. Sure the pic is looking very sharp after the filter but the eyes don't want to look at any spot for too long.
Not at all. They control how the horizontal and vertical scanlines get interpolated. Think of it as a 'tuneable bilinear interpolator', where the coefficients are given by you. If you leave all of them at 128, you get standard bilinear interpolation. You can create several different looking interpolations this way. You can even tune it in real time, to create some 'motion blur' feel =DCGAMan wrote:Anyways, might I trouble you to explain what those settings in tweakable.bas really do? Do these deal with the image blurriness/quality? For instance, if I lower avg from 255 to 189, a sort of halo comes out of the crossbow and sword. I like this very much.
Oh, if it's useful, that's great. It's a shame that most of the processing power goes to the resizing, no?CGAMan wrote:BTW, I'm getting a FPS of 21 in tweakable.bas. This is perfectly acceptable! Also, when the halos come out of the weapons, I have no need to do a 2nd nearest neighbor pass as it was meant to achieve this effect...
I doubt it, but nothing stops you from trying =DCGAMan wrote:Lastly, is this code compatible with counting_pine's algo? Meaning would I be able to achieve a 21 fps if I were to modify the scaling algorithm?
Bear in mind that what really determines the framerate is the source buffer, not the destination one. So, with the Yoshi's Island image (256x208) I get ~200 FPS, and with the Dungeons of Grimlor image I get ~135, at the same destination resolution (1280x800)
Re: Does anyone know what algo XP -> full screen DOS?
Eek!!! Plz no: bilinear, bicubic, etc. These are already built into C#. I couldn't use them coz the images they produced glared back at me. This is the reason I began the thread. To see if there were better alternatives, and yes it was counting_pine's algo.paul doe wrote:Yes, of course, but that's because the interpolation gets blown up as well. It can be done better, but you'll slow it to a crawl. As it currently stands, it behaves just as you described, only the interpolation is different. I'm looking for a way to implement counting_pine's interpolator without using FP math.CGAMan wrote:Really? You don't think the default settings produces too much digital glare? For instance, I try to focus on that 10 in the Mario+Yoshi pic, but the algorithm really strains my eyes. Sure the pic is looking very sharp after the filter but the eyes don't want to look at any spot for too long.Not at all. They control how the horizontal and vertical scanlines get interpolated. Think of it as a 'tuneable bilinear interpolator', where the coefficients are given by you. If you leave all of them at 128, you get standard bilinear interpolation. You can create several different looking interpolations this way. You can even tune it in real time, to create some 'motion blur' feel =DCGAMan wrote:Anyways, might I trouble you to explain what those settings in tweakable.bas really do? Do these deal with the image blurriness/quality? For instance, if I lower avg from 255 to 189, a sort of halo comes out of the crossbow and sword. I like this very much.Oh, if it's useful, that's great. It's a shame that most of the processing power goes to the resizing, no?CGAMan wrote:BTW, I'm getting a FPS of 21 in tweakable.bas. This is perfectly acceptable! Also, when the halos come out of the weapons, I have no need to do a 2nd nearest neighbor pass as it was meant to achieve this effect...I doubt it, but nothing stops you from trying =DCGAMan wrote:Lastly, is this code compatible with counting_pine's algo? Meaning would I be able to achieve a 21 fps if I were to modify the scaling algorithm?
Bear in mind that what really determines the framerate is the source buffer, not the destination one. So, with the Yoshi's Island image (256x208) I get ~200 FPS, and with the Dungeons of Grimlor image I get ~135, at the same destination resolution (1280x800)
Anyways, plz make a +20fps version of counting_pine's natural LCD upscaling exactly the way his algo worked, but at really insane speed...
Re: Does anyone know what algo XP -> full screen DOS?
Didn't you said before that you liked the looks? >=(CGAMan wrote:Eek!!! Plz no: bilinear, bicubic, etc. These are already built into C#. I couldn't use them coz the images they produced glared back at me. This is the reason I began the thread. To see if there were better alternatives, and yes it was counting_pine's algo.
You don't ask for much, eh? LCDs scale the images in hardware. I'll see what I can do, but I can't promise anything, as I'm busy now. Time to code something yourself, bubby >=DCGAMan wrote:Anyways, plz make a +20fps version of counting_pine's natural LCD upscaling exactly the way his algo worked, but at really insane speed...