DAY 009:_PutImage

[grymmjack]

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_...algorithms

It would be awesome to have these as options alternatively to

_SMOOTH

More stuff:
https://www.reddit.com/r/programming/com...lgorithms/

Repos with code and examples:
https://github.com/search?q=pixel%20art%...positories

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!

[bplus]

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.

• 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.

[a740g]

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_...algorithms

It would be awesome to have these as options alternatively to

_SMOOTH

More stuff:
https://www.reddit.com/r/programming/com...lgorithms/

Repos with code and examples:
https://github.com/search?q=pixel%20art%...positories

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.

[grymmjack]

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_...algorithms

It would be awesome to have these as options alternatively to

_SMOOTH

More stuff:
https://www.reddit.com/r/programming/com...lgorithms/

Repos with code and examples:
https://github.com/search?q=pixel%20art%...positories

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.

Does _PUTIMAGE _SMOOTH do it in advance too? Would imagine yes, like pre-processing?

[grymmjack]

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_...algorithms

It would be awesome to have these as options alternatively to

_SMOOTH

More stuff:
https://www.reddit.com/r/programming/com...lgorithms/

Repos with code and examples:
https://github.com/search?q=pixel%20art%...positories

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.

C pixel scalers here
https://github.com/janert/pixelscalers

XBR guide here @a740g https://github.com/janert/pixelscalers/b...cs/xbr.pdf

[bplus]

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.

• 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/showthre...6#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.

[grymmjack]

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.

• 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/showthre...6#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.

[grymmjack]

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/showthre...6#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.

@grymmjack test to me.

[grymmjack]

test @grymmjack

[grymmjack]

@grymmjack test