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

Question: Will this allow me to use sdl2 and send the output to arduino / matrix? #28

Open
JordyMoos opened this issue Jun 1, 2018 · 6 comments
Labels

Comments

@JordyMoos
Copy link

Just so I understand this repo correctly, this will allow me to write code with sdl2 and use arduino / matrix as the output? That would be exactly what I have been looking for then ;P

Cheers

@vifino
Copy link
Member

vifino commented Jun 1, 2018

Well, sort of.

It allows you to write effects generically, one of the possible outputs is SDL2. You yourself can't use SDL2 functions in the effects, but you can definitly write effects and run them both on a real matrix and on a virtual one.

We don't have an Arduino port, we have..

  • a WIP esp8266 port using ws2812b leds
  • an Arduino sketch for an esp8266 that receives pixel data via the network
  • raspberry pi support, simply attach ws2812b leds to a specific pin on the Pi, it'll work.
  • some other things as well..

One could probably send pixel data out to serial if you don't have an esp8266 or a raspberry pi.

Still needs a Linux machine to run the effects, though.

@vifino vifino added the question label Jun 1, 2018
@orithena
Copy link
Collaborator

orithena commented Jun 1, 2018

@vifino: I'm not sure whether that meets @JordyMoos' intention.

I read it as: "Can I write an effect (animation, game, whatever) in SDL2 while taking advantage of SDL2 functions and still transfer the result to an LED matrix".

This isn't quite how SLED is built, but it might be possible. Off the top of my head, this requires a new gfx module that initializes and takes care of its own SDL window; then reads the resulting pixels from that window and writes them into the SLED framebuffer using matrix_set(x,y,rgb). Then any out module of SLED can be used for display.

This might be slow, depending on the output size; however, it might be possible to write e.g. a matrix_memcpy() function to speed up the process of copying the framebuffer. This, however, would require the SDL framebuffer to run in the same memory model as the SLED framebuffer (and I'm not fluent enough in SDL to know whether this is possible at all).

@vifino
Copy link
Member

vifino commented Jun 1, 2018

@orithena Good point.
Not sure if that's much help, as there are only very limited algorithms implemented in SDL2/relevant to drawing pixels.
Drawing lines, rectangles and circles(?) is already supported with simple methods.

All the other actual drawing will still be done by some algorithm and setting the pixels, so it doesn't make much difference, in my opinion.

@vifino
Copy link
Member

vifino commented Jun 1, 2018

@orithena Actually, now I understand what you meant.

It is not just about graphical effects, but rather SDL2 apps and the possibility of drawing to LED matrices!

Yeah, reading the pixels from the SDL2 window of the app and setting it would be the easiest.
One could make an SDL2-metawrapper module as a bgm module, with some specific "wake up/go to sleep" function that some app could call if it wants to draw now.

Probably not too hard to repurpose the module loader for this as well. We could load apps compiled to .so's from a subfolder in modules, like modules/sdl2.

@orithena
Copy link
Collaborator

orithena commented Jun 1, 2018

Hmmm... probably the most flexible solution would be to perpetually screenshot an SDL window maintained by another process. Don't know whether that works or is practical. This would only require a small gfx module on SLEDs side.

@vifino
Copy link
Member

vifino commented Jun 1, 2018

I think that's the simplest and most universal solution too.
One could just implement a grabbing-code on the app side, send frames every time SDL render is called.

We already have OpenPixelControl and Pixelflut support, so it should be doable. :)

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

No branches or pull requests

3 participants