_SMOOTH

_SMOOTH

Quote:

• L16 - The reason we use 
  -1
   in 
  COLS * scale% -1
   and 
  ROWS * scale% - 1
   is because in the first iteration of the loop with 
  i%
   being 1, if we did not subtract one, it would offset them, and so the passed in desired positions would be actually offset for the first character.
  

(08-28-2023, 12:14 AM)grymmjack Wrote: Back to the

_SMOOTH

topic.

That algorithm is fine for photographic elements but it looks bad (IMO) for pixel art.

However! There are anti-aliasing (I think they might be called shaders) algorithms we could also implement into QB64PE - (well you smart people could).

https://en.wikipedia.org/wiki/Pixel-art_scaling_algorithms

It would be awesome to have these as options alternatively to

_SMOOTH

More stuff:
https://www.reddit.com/r/programming/comments/ftd8v/pixel_art_scaling_algorithms/

Repos with code and examples:
https://github.com/search?q=pixel%20art%20scaling&type=repositories

C example *cough*: @mkilgore @a740g @smcneill @rhosigma
https://github.com/Treeki/libxbr-standalone

Anyway, if you wanted to try to implement this stuff I would be grateful!

(08-28-2023, 07:49 AM)a740g Wrote:

(08-28-2023, 12:14 AM)grymmjack Wrote: Back to the

_SMOOTH

topic.

That algorithm is fine for photographic elements but it looks bad (IMO) for pixel art.

However! There are anti-aliasing (I think they might be called shaders) algorithms we could also implement into QB64PE - (well you smart people could).

https://en.wikipedia.org/wiki/Pixel-art_scaling_algorithms

It would be awesome to have these as options alternatively to

_SMOOTH

More stuff:
https://www.reddit.com/r/programming/comments/ftd8v/pixel_art_scaling_algorithms/

Repos with code and examples:
https://github.com/search?q=pixel%20art%20scaling&type=repositories

C example *cough*: @mkilgore @a740g @smcneill @rhosigma
https://github.com/Treeki/libxbr-standalone

Anyway, if you wanted to try to implement this stuff I would be grateful!

I love the xBRZ algo. First saw it in action in GZDoom. However, I do not think these algos can be used in real-time unless it is implemented as GPU shaders. GZDoom uses it during the asset loading stage. Which means the textures are pre-processed before any kind of rendering happens.

(08-28-2023, 07:49 AM)a740g Wrote:

(08-28-2023, 12:14 AM)grymmjack Wrote: Back to the

_SMOOTH

topic.

That algorithm is fine for photographic elements but it looks bad (IMO) for pixel art.

However! There are anti-aliasing (I think they might be called shaders) algorithms we could also implement into QB64PE - (well you smart people could).

https://en.wikipedia.org/wiki/Pixel-art_scaling_algorithms

It would be awesome to have these as options alternatively to

_SMOOTH

More stuff:
https://www.reddit.com/r/programming/comments/ftd8v/pixel_art_scaling_algorithms/

Repos with code and examples:
https://github.com/search?q=pixel%20art%20scaling&type=repositories

C example *cough*: @mkilgore @a740g @smcneill @rhosigma
https://github.com/Treeki/libxbr-standalone

Anyway, if you wanted to try to implement this stuff I would be grateful!

I love the xBRZ algo. First saw it in action in GZDoom. However, I do not think these algos can be used in real-time unless it is implemented as GPU shaders. GZDoom uses it during the asset loading stage. Which means the textures are pre-processed before any kind of rendering happens.

(08-28-2023, 01:33 AM)bplus Wrote: i -1 was about the letter indexes for the string. I am sure to keep the fist point drawn at x you have to subtract 1 from i to make a zero offset from x otherwise you will be a whole column right of where you need that first draw point.

Quote:

• L16 - The reason we use 
  -1
   in 
  COLS * scale% -1
   and 
  ROWS * scale% - 1
   is because in the first iteration of the loop with 
  i%
   being 1, if we did not subtract one, it would offset them, and so the passed in desired positions would be actually offset for the first character.
  

Copy / paste above has odd format above, 

Anyway, honestly maybe the -1's might not be necessary. Mathologically sometimes you need a -1 and sometimes you don't. A screen with 0,0 top, left corner has bottom right corner at _width -1, _Height -1
If x, y is top, left corner add width, height for bottom right or add width -1, height -1?
Best way to tell is try both. I just tried with the -1's and didn't see any problems.
I think our letter boxes would overlap without the -1's. That is if we outlined the space each letter resides in as boxes, the boxes would overlap without the -1's, whereas the boxes would neatly abut one another with the -1's.

(08-29-2023, 03:21 PM)bplus Wrote:

(08-28-2023, 01:33 AM)bplus Wrote: i -1 was about the letter indexes for the string. I am sure to keep the fist point drawn at x you have to subtract 1 from i to make a zero offset from x otherwise you will be a whole column right of where you need that first draw point.

Quote:

• L16 - The reason we use 
  -1
   in 
  COLS * scale% -1
   and 
  ROWS * scale% - 1
   is because in the first iteration of the loop with 
  i%
   being 1, if we did not subtract one, it would offset them, and so the passed in desired positions would be actually offset for the first character.
  

Copy / paste above has odd format above, 

Anyway, honestly maybe the -1's might not be necessary. Mathologically sometimes you need a -1 and sometimes you don't. A screen with 0,0 top, left corner has bottom right corner at _width -1, _Height -1
If x, y is top, left corner add width, height for bottom right or add width -1, height -1?
Best way to tell is try both. I just tried with the -1's and didn't see any problems.
I think our letter boxes would overlap without the -1's. That is if we outlined the space each letter resides in as boxes, the boxes would overlap without the -1's, whereas the boxes would neatly abut one another with the -1's.

Aha! @grymmjack this proves the -1's do neatly place the box spaces next to each other without overlap.
https://staging.qb64phoenix.com/showthread.php?tid=1938&pid=19096#pid19096
I fixed my own "Font Print" sub by adding -1's to the Step when drawing the pixelated boxes that form a letter.
Notice how you can see each pixel individually specially at the bottom b+ with 5x5 font.

(08-29-2023, 10:41 PM)grymmjack Wrote:

(08-29-2023, 03:21 PM)bplus Wrote:

(08-28-2023, 01:33 AM)bplus Wrote: i -1 was about the letter indexes for the string. I am sure to keep the fist point drawn at x you have to subtract 1 from i to make a zero offset from x otherwise you will be a whole column right of where you need that first draw point.

Copy / paste above has odd format above, 

Anyway, honestly maybe the -1's might not be necessary. Mathologically sometimes you need a -1 and sometimes you don't. A screen with 0,0 top, left corner has bottom right corner at _width -1, _Height -1
If x, y is top, left corner add width, height for bottom right or add width -1, height -1?
Best way to tell is try both. I just tried with the -1's and didn't see any problems.
I think our letter boxes would overlap without the -1's. That is if we outlined the space each letter resides in as boxes, the boxes would overlap without the -1's, whereas the boxes would neatly abut one another with the -1's.

Aha! @grymmjack this proves the -1's do neatly place the box spaces next to each other without overlap.
https://staging.qb64phoenix.com/showthread.php?tid=1938&pid=19096#pid19096
I fixed my own "Font Print" sub by adding -1's to the Step when drawing the pixelated boxes that form a letter.
Notice how you can see each pixel individually specially at the bottom b+ with 5x5 font.

Yeah I noticed a big difference. Your second attempt is a lot cleaner! Well done.