So here’s my #MatrixClock so far. I’ve been swipin’ code from everywhere, with the wireframe cube coming from the Peggy2 arduino library. It’s a little janky, but I kind of like it that way.
It’s looking pretty nice so far, though, and I’m really happy with the new font I’m using - it’s called Gohufont, and that’s the bold version. I might edit the 0 to remove the central dot, but it’s pretty good otherwise.
Still have to make animations with the temperature sensor as well.
Heh. That could be fun. also, I would like to change the sin/cos calls to the faster versions in FastLED. On a similar topic… I see a lot of code that uses a pair of if statements to keep a value within a range. Is that faster than using constrain()?
Lesson learned the hard way, repeatedly: best thing to do is actually try it and time it and see if it makes a difference and if so which way and how much.
Hunches about performance are often surprisingly wrong. My own hunches definitely included!
@Noel_Bundy I’m having a devil of a time adapting the Peggy cube demo to my setup, I’d love to see what you did. I’d take an ugly pastebin now over a pretty github repo later ;-).
So I’ve set up a github, but it’s incomplete - As I’ve added more fonts to SmartMatrix, and that’s a non-trivial task, I’m now going to have to make a fork of a fork! I think. Or something.
Anyways, my github is here: https://github.com/TwystNeko/ - I’ve put both the modified Smartmatrix library, with the extra fonts, and the MatrixClock code up.
@Mark_Kriegsman So I’ve attempted to implement the Wu line algorithm, but it’s not working right. I no longer get a cube, just horizontal lines. I’m using code I found at RosettaCode for this, with changes to suit. Care to take a look? It’s in my github.
Between that thing in the desert and a couple of other maddeningly contemporaneous projects I suspect I can’t review the code but I bet someone else here can help out!
No worries - I got it working. It’s significantly slower than bresenham, and it actually looks worse in this case. So, while I can see it being useful in other places, I’ll be sticking with the current version.
The latest annoyance: I’m working on implementing the arduino particle system lib. Unfortunately, somehow it seems to be locked to an 8x8 matrix. I’ve dug through the code, and can’t find any reason for it - the constants are all set correctly, although some of them cause stranger things to happen.
If it’s the one I looked at, you need to check out the data types! If my memory serves me correctly they used ‘char’ with only the upper 3 bits for whole x & y’s and the lower 5 bits for fractional x & y’s.
No, this one used bytes. I did finally track it down.
Originally, they used:
col = particles[i].x / PS_P_RADIUS;
where the x/y were 0-255, and PS_P_RADIUS was 32. This was, supposedly, to map it to the matrix size. Except it seemed to map everything to 0-8.
I replaced it with:
col = map(particles[i].x,0,255,0,PS_PIXELS_X);
and it worked.
It’s just a shame that it looks terrible with a larger matrix - it’s not as glowy as it was, and I can’t figure out how to force it to look better.