Show HN: I made a pixel art editor for Windows desktop(lightcube.art) |
Show HN: I made a pixel art editor for Windows desktop(lightcube.art) |
"why would I buy this and when paint.net is free?"
$15 seems like a big ask when equivalent or greater functionality can be had at no cost.
You can also compile for yourself if you want - even though I have bought it on Steam I have my own build too that I use in an old Linux computer when I want to draw in non-distracted almost offline way.
https://lospec.com/pixel-art-tutorials/hd-index-painting-in-...
You've got a really good start though, the UI looks clean and you've got a good feature set as-is.
Realtime palette conversion would let people author pixel art using truecolor tools while staring at the palettized result, which is a fun way to work.
I love the idea of an "isometric grid!"
I will buy this software once I figure out how to use Steam.
I'll make a note to check this out. Also kudos for supporting Windows 7, even if one of your distribution channels no longer does.
Potentially sacrilegious question, given this is very clearly made for Windows: Do you plan on eventually supporting macos? :D
- Isometric shape tool
- Built-in pattern brushes (for things like brickwork, landscapes, fences, windows, doors, meshes etc., stuff thats painstaking to draw)
- Color ramp generator with configurable hue shifting
- Inline text tool
Some higher-res or smoothly animated styles do use 2D or 3D renderings that get cleaned up into pixel sprites; if you're old enough to remember the Donkey Kong Country games for the SNES, that's one example. I think 2017's Sonic Mania also used 3D assets in its pixel art pipeline. But most professional-quality pixel art isn't built from higher-res art because there's usually no benefit, especially if it's a low-res "retro" style.
Different resolution demand different solutions. For example, if an artist uses a very low resolution such as 16x16 pixels for a character sprite, he will often favour an excessively large head because only then will he have enough pixels for his facial expressions. Likewise it does not make sense to use too many different colours in such a resolution. In contrast, if the arist wants to use more "realistic" sprites, she or he would probably choose a higher resolution with a larger colour palette from the start. So basically one is designing for a specific pixel-resolution and instead of adjusting the pixel-resolution to a screen-resolution one just scales the pixels themselves into little boxes when showing them on higher screen-resolutions.
If you took a vector drawing and rasterized it to 16x16, I think that might kind of look like crap, because it'd be hard to know ahead of time how the rasterizing will work. How will it handle diagonal lines? How will it figure out which pixels to shade and which ones not to? I'm not saying you couldn't make a vector renderer that handles these things in a way that you'd like, but I am saying that you'd most likely not be terribly happy with the default results.
I assume that Aseprite runs on all these platforms.