Hi everyone,
The look of the display is all vector graphics. The images are saved in the OS – not generated on the fly (I don’t believe). I don’t think there is really anything particularly unique required to get the underlying nature of the graphics to work. You should probably just go with something that works nicely with what you are already doing, and then just build the graphics that work with that.
- All of the graphics are SVG files made in Adobe Illustrator.
* All parts of the image which should be dynamic are grouped and have IDs in the SVG
* There are two ways to animate them:- Simple: Including all stages of the animation already in the SVG file, only switching them from “display=none” to “display=block” and vice-versa (best example is probably the SVG for the “Finger” sequencer which we exchanged with Deadmau5 and Animal)
- Complicated: Actually calculating new vectors depending on what is happening in the device and writing them to screen (best example is maybe the “string” synth engine with the movement of the individual strings. Those are not all included in there but really animated)
- Simple: Including all stages of the animation already in the SVG file, only switching them from “display=none” to “display=block” and vice-versa (best example is probably the SVG for the “Finger” sequencer which we exchanged with Deadmau5 and Animal)
@JackBlue: I would decide on a programming language and framework to work with on the RasPi and then find a good SVG manipulation library for that.
This way you can do it like TE and separate the “programming” from the graphics work a bit.
(still have to coordinate usage of IDs and such, but you can change graphics without re-compiling all your code)
Thank you guys for your answers. Yes, I saw that deadmau5 modification, as a deadmau5 fan you deserve all my respect man!
What language are you using for everything else? Like, to make the sequencer program work? Because that would narrow down your options if you want everything to work together more cleanly. For example, Python has its own libraries for creating GUIs that may not be the same as Java or others.
For the moment I’m not using one in particular, I’ve been using python with tkinter in the past months, but I think I need something more powerful for doing that kind of interfaces with smooth transitions and all kind of fadings and fx. I’ve seen that a lot of good interface programs use c++ in combination with svg objects.
depending on the svg library there are a great number of svg features from transforms (rotate, scale, etc), through symbols and text that help with building UI.
- filesize shouldn’t be much concern on a RasPi. Choose readability and debuggability over small file size!
* from the “strings” analysis of OP1_vdk.ldr, they use “…\src\gui\3rdp\rapidxml-1.13\rapidxml.hpp” so the rapidxml library to parse the SVGs I guess (“source”/“graphical user interface”/“third party”/)
* The rest of the gui seems to be done by hand (in …\src\gui\lib, like Parser.cpp, Raster.cpp, Node.cpp, Shape.cpp… which is quite impressive
* there is also “…\src\gui\lib\AGG\agg.cpp” which may or may not mean something like this: http://antigrain.com/download/index.html. But since they neatly organized their source as it seems, I would guess that it would be in \3rdp\ if it came from a thirs party and wasn’t coded by TE
Btw: thankfully @jakeokay has the output of “strings” poured into a Gist https://gist.github.com/mcginty/44b8986a36aba7b929c5f77d56710c4c
Thank you very much guys, I’m starting to see things clearly! Your posts are helping me a lot!
Maybe for a prototype D3.js would suffice. If you need to interact with hardware a simple CGI could do the necessary stuff on the server.
@JackBlue yes and no. The SVG format ist already “programmable” because it is an XML format which can be parsed by computers.
TE seems to use the rapidXML library for that. Then their whole magic is in /src/gui/lib/ where they “Parse.cpp” the SVGs (using the rapidXML lib), then they “Shape.cpp” and “Node.cpp” it (kind of) and finally when they need to display it on the pixel-based display, the “Raster.cpp” the SVG to show it in those tiny pixels.
For Tombola and the Chopper game, they use the open source “Box2D” physics engine.
@JackBlue yes and no. The SVG format ist already "programmable" because it is an XML format which can be parsed by computers.
TE seems to use the rapidXML library for that. Then their whole magic is in /src/gui/lib/ where they "Parse.cpp" the SVGs (using the rapidXML lib), then they "Shape.cpp" and "Node.cpp" it (kind of) and finally when they need to display it on the pixel-based display, the "Raster.cpp" the SVG to show it in those tiny pixels.
For Tombola and the Chopper game, they use the open source "Box2D" physics engine.
Ah okey, the rapidxml lib makes the svg graphics usable in c++ and then it renders the vectors into pixels to finally show them in the screen?
there is no indication that the /AGG/agg.cpp has anything to do with that agg lib. Only those three letters. It could also be their own implementation of an anti-grain algorithm while rasterizing the SVG to pixels.
Given that they have a /3rdp/ directory with third-party libraries, I’m pretty sure that agg.cpp is not coming from an external entity.
So again:
- SVG is just text. And it is formatted in the XML format
- the Firmware needs a way to read all that text efficiently and find the relevant parts in it (i.e. paths/vectors, colors, etc)
- To achieve this, the GUI library that TE created uses rapidxml library which takes away the pain of writing code that knows how XML looks (i.e. search for “<”, then check what “tag” that is, keep in mind what tag came before that and build a “tree” where in the XML document you are right now, check for closing “>” and so on)
- I would guess that “Parse.cpp” uses the API of rapidxml to find in the SVG what the shapes and nodes are.
- Shape.cpp and Node.cpp describe what those are and what functions they have (Classes in c++)
- Raster.cpp uses agg.cpp (just a theory!) to make the SVG look good on the pixel screen
All screens you see on the OP-1 also have code attached to them. Those reside in /src/gui/screens/ and contain the code that is needed to manipulate the SVG to achieve animation (also theory, but pretty sure about it)