Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Poxi – A Hackable Pixel Art Editor (github.com/maierfelix)
144 points by _s47s on Feb 27, 2017 | hide | past | favorite | 37 comments



This should probably be advertised more as renderer than editor as editor without save feature sounds like a joke - why would you create/edit anything if you can't save it?

But it looks really cool anyway! :)


"why would you create/edit anything if you can't save it?"

https://buddhists.org/buddhist-art/the-symbolism-behind-the-...


Yeah okay, but c'mon.


This comment is less helpful than the one you replied to.

@Simpliplant has a good point, people expect digital paint tools to save, but also made a blanket unqualified statement about creating anything without saving.

@jasonkostempski replied that some people don't want to save, the blanket statement doesn't apply to everyone. And that's absolutely true. This is a valid, though somewhat tangential, point of view about performance art.

There is a long history of artists using art tools that don't have save or undo. Traditional arts are still founded on this concept, the art world still largely values techniques that involve the risk of screwing it up, and are hard to copy. That's changing over time, digital arts are growing up, but the majority opinion in the art world is still that tools with undo and tools that can replicate without loss are for unserious artists.

Music is the same way, it's a performance art, and digital sequencing and digital performance have often been considered inferior. Robert Moog, one of the most famous creators of analog & digital synthesizers, even wanted to make his synth a performance instrument, and didn't like the idea of using a sequencer. Sound patches couldn't be saved either, and many famous musicians had enormous careers using Moogs.


Still, it seems incredibly unlikely that someone needing a pixel art editor would not want the ability to save their work.


It is indeed incredibly unlikely that someone needing a pixel art editor wouldn't want save, I agree with you completely, and I bet @jasonkostempski does too. But that doesn't invalidate what @jasonkostempski said. The question "why would you create/edit anything if you can't save it?" was taken literally. @Simpliplant didn't qualify people using pixel art editors, the question said why would you do anything if you couldn't save. As it turns out, people do that all the time. Just not with pixel art editors.


Part of having a productive conversation is using context clues and social norms to help your understanding of what someone means when they say something. Derailing the conversation by taking a comment literally when everyone understands the intent behind the comment is not helpful.


But one of the interesting parts of the paradigm of hierarchically-threaded online discussion, is that only one subthread/reply to a given thread has to be a "productive conversation" (i.e. to continue the thread in the "obvious" way); the other subthreads can be tangents, and tangents do not "derail" in the same way they do in a flat-linear-threaded forum.


I would disagree, because they're still visible and still structurally part of the same conversation, meaning people reading the conversation will read those tangents, or at the very least be distracted by them.


And this is why subthreads in all hierarchical discussion systems are sorted by vote-rank: the subthread that most effectively serves as the continuation of the "canonical" conversation will (almost) always appear first. The only time that doesn't happen is when that subthread doesn't exist—as has happened here. More often than not, when this is seen in a "played out" archived discussion thread, this doesn't suggest that people are "getting distracted by" the tangent, but rather just suggests that nobody is all that interested in continuing the original conversation.

(Unless the tangent leads toward a mind-killing subject like politics. I'm 100% behind you on applying careful consideration before making a tangent from a technical topic to an emotionally-charged one; people see that kind of subthread and never even make it to the rest of the subthreads in the same conversation.)


Another part of having a productive conversation is learning not to make blanket statements, and knowing that most of what you say will be taken literally, and being generous and charitable in your interpretation of others.

For me, the best part of having interesting conversations on HN is reading all the alternative points of view by smart people. Not much "productive" happens, from my point of view, by criticizing someone's show HN project, not much "productive" happens when you make blanket statements about what all people want. And not much "productive" happens by only agreeing with others.

So there might be another hidden motive behind what @jasonkostempski said. The comment he replied to literally insults the Poxi project, and perhaps @jasonkostempski was merely defending a Show HN project that's in a very early stage.

In my view, you may be defending the wrong person here. I want to see more show HN projects, and I want people to feel comfortable sharing their projects without fear of getting ripped to shreds, called a joke, and questioned why anyone would ever want to do such a thing. Let's be supportive.


>Another part of having a productive conversation is learning not to make blanket statements, and knowing that most of what you say will be taken literally, and being generous and charitable in your interpretation of others.

So the point was to teach the commenter a lesson by responding unhelpfully?

>In my view, you may be defending the wrong person here.

So, because I was pointing out someone not responding constructively I am by necessity "defending" all points the other person makes? I think that is faulty reasoning.


Screenshot?


OP might just be in a "release early, release often" stage of development, and the demo might get more impressive as time goes on (color selection would be nice, as well as a preview mode).

But yeah - it is cool - great show for the initial offering.


The demo has a "Download" button, and then you can right-click and "Save Image As..." So, not a feature per se, but the functionality is there.


If you like creating pixel art I implore you to come play Falcross! We've got a nonogram puzzle editor that allows you to create masterpieces up to 25x25px, and there are thousands of hungry players waiting to solve your puzzles :) https://www.falcross.com/


:( Any plans for an Android version?


Absolutely! I just finished re-writing the app in React Native so it will definitely be coming to Android.


Where can I sign up to get notified when the Android version is out on Google Play?


Oh my god, it's like Picross! I grew up with that on DS, and I'm extremely excited to play this now. I can't wait for it to show up on Android.


The demo is very smooth, the infinite grid feels impressive. That said, how do you know if performance is great if you haven't implemented animations yet? Did you perform benchmarks?


If you like this, you might also like Jenn Schiffer's https://make8bitart.com/


Umm... is it supposed to look like this?

https://aww.moe/wosyo0.png

I'm using Tor Browser 7.0a1-hardened (based on Mozilla Firefox 45.7.0).


It's art!


I really like using http://www.piskelapp.com/ for online pixel editing. It's useful for making 2D sprites ( and saving them for later ).

It's also open-source: https://github.com/juliandescottes/piskel


Very good, how did you do the infinite grid ?

I am also working on an infinite grid pixel art tool :)


I made an (unreleased) roguelike engine with a (virtually) infinite world, like Minecraft etc, in Java. I did it as a Hashtable<int, DataContainer>.

In your case DataContainer would be some part of the canvas, maybe a 32x32 pixel area. And the int key would be the index of the x&y coordinates of that particular area. The image dimensions could then be a max size of the square root of an unsigned int, and to get the index of each tile you'd just do (y * dimension + x). You'd throw all this into a little wrapper so you have a "virtual" canvas that could be as big as you'd ever need it to be.

Also, don't actually initialize each piece of canvas until a pixel is actually placed in it, instead returning a static empty section of canvas if the key isn't in the hashtable yet. This allows for zooming way out smoothly.


Building on this, the general approach you're describing is a "sparse" data structure. For example,

https://en.wikipedia.org/wiki/Sparse_array

A cousin to this approach would be using some type of space partition with the assumption that most of the partitions represent large, uniform (empty or solid-filled) areas:

https://en.wikipedia.org/wiki/Space_partitioning

You can see that these are fundamentally related ideas- pay for the complexity of the data you store rather than its volume.


Right, I also wanted to mention using a Quadtree but that seems excessive for pixel art (or most applications, for that matter).

e: Another consideration would be keeping level-of-detail versions of each chunk of canvas as well, so zooming very far out loads/shows a lower resolution rendering. That would let you make a Google Maps style collaborative pixel art canvas or something.


Is there a way to play with the API in Chrome dev tools? I see fillRect, for example, in Poxi.js, but it's not available in global or window scope, nor exposed to the Poxi object.


RANT: No disrespect, but why is everyone using words like hacker, hackable, etc?! Are they supposed to sound cool? Or, maybe I am too old to understand it? :)


I think hackable is referring to the client side API here.


It's extendable and "modifiable". Being written in javascript, you can do all sorts of hacks around the code while not even modifying the source code itself, but using the APIs/other means around it for customization. JS injection, monkey patching, es6 Proxy, etc. Probably doesn't apply with that specific one, but putting a custom CSS onto something also qualifies to be "hackable". Basically all the web/webview based apps can be marketed like that if they don't specifically restrict such thing.


It consumes 100% of CPU on FF and Chromium. Come on, please show a little respect toward others, it is only a pixel editor.

Edit: still nice initiative.


"please show a little respect toward others"

I'm sure he didn't mean it personally.


Hmm. Doesn't seem to be very useful on an iOS device. ;(


You should register pixelpoxi.com and have a save feature!




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: