Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
DAY 009:_PutImage
#41
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!
grymmjack (gj!)
GitHubYouTube | Soundcloud | 16colo.rs
Reply
#42
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.
b = b + ...
Reply
#43
(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_...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.
Reply
#44
(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_...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 (gj!)
GitHubYouTube | Soundcloud | 16colo.rs
Reply
#45
(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_...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
grymmjack (gj!)
GitHubYouTube | Soundcloud | 16colo.rs
Reply
#46
(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://qb64phoenix.com/forum/showthread...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.
b = b + ...
Reply
#47
(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://qb64phoenix.com/forum/showthread...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 (gj!)
GitHubYouTube | Soundcloud | 16colo.rs
Reply




Users browsing this thread: 3 Guest(s)