So here's my so far.

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.

The spinning cube is really great. Could you have control over the ‘zoom’ of the animation? Say, while the cube spins, you zoom in and out?

Oooh, I might have to steal that cube too.

Wow looks great!

I made a small tweak to it - lowered the brightness on the back edges so that it looks more 3D.

The code itself could probably be optimized a lot, I’m sure. Maybe I’ll play with this “Source Control” thing and make a github for the code. :slight_smile:

Yay for depth cues!

For extra credit, upgrade Bresenham to Wu and antialias the lines! Xiaolin Wu's line algorithm - Wikipedia #overengineering #asusual

Heh. That could be fun. :slight_smile: 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 ;-).

Sure, gimme a sec. I dunno how to github anyways yet.

http://hastebin.com/eworimoqic.coffee <- that should be a working sketch on its own. Needs FastLED2.1 and @Daniel_Garcia 's modified SmartMatrix library

Thats really impressive!

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.

Has anyone played with this library? https://github.com/giladaya/arduino-particle-sys

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.

That’s called a “‘Q3.5’ fixed point representation”: three ‘integer’ bits and five ‘fractional’ bits after the imaginary decimal. http://en.m.wikipedia.org/wiki/Q_(number_format)

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.