JD557
Proposal to add primitives.
Hello @JD557, first of all thanks for such a nice library. I've been playing around with it and I like it so far. I was wondering if contributions are currently accepted? I noticed that the library lacks of (correct me if I'm wrong) primitives such as Triangle, Square, Circle, which might be handy for people who just want to experiment and do some quick sketches.
May I ask if I can help with it? If so, any guidelines I should consider?
Kind regards.
Hey there,
I was wondering if contributions are currently accepted?
I haven't thought too much about that, but I would say small contributions are OK.
I wouldn't recommend sending any large PRs without creating an issue, since there's a chance that I might reject it for considering it out of scope of the library, and that sucks 😓
So I think you did the right thing by asking.
I noticed that the library lacks of (correct me if I'm wrong) primitives such as Triangle, Square, Circle, which might be handy for people who just want to experiment and do some quick sketches.
Indeed, this was something that I wanted to do, but didn't because I couldn't find out an API that I liked.
I had an initial implementation, but I really don't like how it turned out.
Having said that, the main problem was that at the time I was trying to have both a mutable and immutable API, and since I removed minart-pure (https://github.com/JD557/minart/pull/407) I think that's not a problem anymore.
May I ask if I can help with it?
Sure.
If so, any guidelines I should consider?
I haven't thought too much about that, but from the top of my head there are two things:
One thing that I would ask you for now is to add the code to a separate package (maybe eu.joaocosta.minart.graphics.geometry or something like that). I think for now it's OK to have that in minart-core, but I might want to extract that to a different module in the future, and having it in a different package makes things a bit cleaner for this.
The other is to make sure that the implementations are platform independent (e.g. you can use methods like MutableSurface#putPixel and MutableSurface#fillRegion, but not something like htmlCanvas.ctx.lineTo). I know that this is a bit annoying, but it's one of the main principles of the library.
As a side note, in general I'm OK if the implementations are not very performant. That can be worked out later and, if someone really needs performance, they should probably use a different library 😛
Hey there, I'm not sure if you ended up picking this up.
Either way, I was playing around with some rasterization algorithms, and I think I'm quite happy with how it turned out, so I might clean up that code and put it in the library.
So, this feature should be available "soon-ish" (knocks on wood).
Hello! @JD557 no, unfortunately I was not able to keep up with my proposal due to work however, I'd love to work on any other task that you have in mind? Thanks for the update by the way.