Feature request: left to right gradient about gradient-blaster HOT 16 OPEN

Yeah the simple option would be to just add a 'scale' option to the PNG output that just repeats pixels as you described. I'd like to have a go at implementing the more 'correct' solution though :-)

from gradient-blaster.

I could add an option to the PNG output format to save in different orientations and potentially offer different preview modes in the editor. Is this what you had in mind?

from gradient-blaster.

Yes, that would be sufficient. I realize that storing it as asm output would be a bit more difficult (because you are not writing palette values anymore but real pixels) so I'm totally fine with a bitmap output only for such cases.

from gradient-blaster.

I've added a horizontal option to the PNG output mode:

Changing the editor display too would be bit more complex as I'd need to redo the dragging behaviour. Is this something that's important to you?

from gradient-blaster.

Wow, that was fast. I doesn't need it to be rotated, not at all.

However I have noticed one thing which was perhaps not that important for the horizontal version: differentiating between resolution and the number of steps.

The horizontal version is basically built around the idea that you can change the colour on every scanline (or every second scanline etc) from an unlimited number of colours (limited only by the palette).

However the vertical version doesn't have this luxury: if I want to create a vertical gradient, I must write pixels there. So now, if I want to create a gradient with 16 steps, I get... a 16-column image. It would be cool if one could specify the amount of pixels to write these steps into (maybe even for the horizontal version?) so one can say "hey, I want 16 colours/shades distributed over 320 pixels".

Is it asking too much? ;-)

EDIT: it's totally ok to do this only for the PNG export.

from gradient-blaster.

Ok so we're talking about limiting the gradient to a distinct number of palette entries, regardless of steps. This would be really useful but I'll need to think about the best way to implement it. It needs to go in further up the chain when it's calculating the hex values, taking into account dithering, colour models etc. rather than just being part of the output module.

I would really like to implement this though so leave it with me!

from gradient-blaster.

Frankly, I could even work around it in my code: all it takes is to have an integral multiplier of the final value. So for instance I generate 16 vertical steps (i.e. using 16 colours), save it as 16xN PNG and every 320/16 = 20th step I just fill the same colour for 16 the next pixels.

But you are right, if you want to do this nicely (especially with the dithering in play), this has to be calculated on a higher level, too.

from gradient-blaster.

Another thing to consider is that currently this tool only does one dimensional dithering, given that the expected output format was a single array of colour values. When we look at bitmap output formats this opens up the scope to 2D dither patterns such as bayer or Floyd Steinberg that repeat over multiple lines. This changes the scope of this tool a bit, but I'll think about whether there's a good way to incorporate this.

from gradient-blaster.

You could also think about stuff like two dimensional gradients :) But if we stay with the initial requirements (one line / one column gradient), I think you don't have to worry about 2D dithering at all.

from gradient-blaster.

Hey, any updates on this?

from gradient-blaster.

Sorry, I started this and completely forgot about it! I'll pick it up again this week.

from gradient-blaster.