Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add example how to draw on the LCD screen #21

Open
Passiday opened this issue Feb 11, 2017 · 4 comments
Open

Add example how to draw on the LCD screen #21

Passiday opened this issue Feb 11, 2017 · 4 comments

Comments

@Passiday
Copy link

I guess ev3dev-lang-js does not include explicit class for the LCD screen because the drawing is carried out by more general system drivers/libraries? Even if so, it would be very helpful if the examples had one script that outputs some graphics on the brick's built-in LCD screen. The ev3dev.org site provides some info on the topic http://www.ev3dev.org/docs/tutorials/using-ev3-lcd/, but that makes one think that you have to code all the functions (pixel, text, geometry, image) yourself.

@WasabiFan
Copy link
Owner

Yeah, currently there isn't an LCD class implemented. As of now, you need to directly interact with the framebuffer; in theory, any general framebuffer manipulation library should work, but I am not aware of any for node.js. I've wanted to add this functionality for a while, but there has been some discussion in ev3dev/ev3dev#431 that may result in a unified easy-to-use interface that would render such work obsolete; obviously, that hasn't come to fruition yet.

In the Python library for ev3dev, they were able to use PIL -- an image manipulation library -- with no modifications and it integrated well with ev3dev and its framebuffer. However, there isn't an equivalent for Node as far as I know, so I'd likely have to implement it myself.

@donwojtallo's snake game uses some custom code for operating on the framebuffer which may be a good example to look at. In general, the idea is to open a Buffer for the framebuffer file and then write individual pixel values; the math is fairly straightforward. But that requires building/finding your own font data, managing shapes, etc., which is a pain.

If you find a node.js library that may work, let me know; I can definitely try it out and see if I can get something implemented.

@Passiday
Copy link
Author

Passiday commented Feb 12, 2017

Coding up a library that does all kinds of functions would be, of course, quite enormous task. I think that a good compromise would be to use some command-line image processing tools to create the images and then pipe them to a program (doesn't matter, node script or something else) that outputs that image to the framebuffer.

For example: Image Magick has quite powerful set of functions. This example would create an image in Portable Bitmap Map format (http://netpbm.sourceforge.net/doc/pbm.html) that is very easy to parse:

$ convert -size 178x128 -fill black -font 'Courier-New-Bold' -pointsize 52 -gravity center label:Hello output.pbm

Node.js program would execute these shell commands to get the images on the screen. Not sure what would be the performance of such approach but we should not expect rapid animation from the ev3 brick anyway.

@WasabiFan
Copy link
Owner

I'll look into this if I get time over the next few days. Honestly, I might just sit down and write a graphics library... Otherwise I'll pick a tool and wrap it as you demoed.

@Passiday
Copy link
Author

You can check out how far I've got, perhaps something can be used from that: https://github.com/Passiday/ev3-screen
The time it takes to load a fairly small bitmap, though, is pretty miserable. Of course, there's plenty of space for optimisation, but still. And the executing the ImageMagick convert via shell is even more pathetic. It seems the only practical method of delivering images to the screen in reasonable time is direct file copy to /dev/fb0 of previously prepared image file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants