Closed euphy closed 5 years ago
Thanks!
wrt g.smooth, I think it is because you are still on Processing 2.x and this may be something they introduced in Processing 3.x, but I'm not sure about it.
Yes I couldn't really track back to when it changed from being a boolean to an int, guessed it was a 2 vs 3 thing. But can't quite see why it works ok running from the jar with ints, but not when compiling against it. I wonder if that's because both versions compile down to the same bytecode!
…//github.com/rikrd/geomerative/issues/9.
Very simple fix - but I want to let you know that I had to make some other (irrelevant, I think) changes to other parts of the project to get this to compile locally - and that's why I haven't included a fresh geomerative.jar.
There are a few places where you have something like:
Where g is a PGraphics. That would not compile for me (core.jar from processing 2.2.1), I get an error saying that PGraphics.smooth is a boolean ("error: incompatible types: boolean cannot be converted to int").
Changing these instances to a boolean like this:
Means it compiles fine.
The source for PGraphics says it's an int (https://github.com/processing/processing/blob/master/core/src/processing/core/PGraphics.java#L176). And your code (treating it as an int) ran fine on my machine.
However, compiling Geomerative using your ant scripts on my installation does not like it.
So I can add those changes to the PR if you like, along with the compiled geomerative.jar... But I'm reluctant to do that because I don't want to break it for everyone except me!
Let me know if you'd like that, or for me to do some more experimenting.
sn