Multi-player and screen capture using a Chrome app

(Ben McLean) #21

Multiplayer does not interest me. But the possibility of doing screen captures for the purpose of making YouTube videos that show off your Arduboy apps seems like the real potential of this process. Think you could steer development of this more in that direction?


@BenMcLean Screen capture is already implemented. You just need to follow the instruction here.

@spinal What kind of string/bytes could we use to reset the screen? We have to be careful because then this series of bytes cannot appear in a picture.

(spinal) #23

good question… maybe a delay then? perhaps make sure there is a gap between frames, not too big, but big enough to be detected?

(Taylor Hansen) #24

When I use this application nothing shows up on the screen capture for some reason (It does show an error though: Receive error on serial connection: device_lost ). The Arduboy also seemed to be taking a huge performance hit while the app is open, reducing the frame rate from 30 to about 10 or so.

Here’s a generalized version of my code:

void setup()
	// setup arduboy, etc

void loop()
	// ...
	// ...
	Serial.write(arduboy.getBuffer(), 128 * 64 / 8);

I uploaded a program similar to this onto my Arduboy and, while it was still on, opened the app and got the results described above. Any reason why something like this is happening?

(Josh Goebel) #25

The serial port stuff is very slow, esp at 9600.

(Scott) #26

Sending the screen data over USB serial will indeed take time but the baud rate setting has no effect. Since this is USB end to end, data will be sent based on USB transfer speeds. You can set any baud rate and the transfer speed will be the same.

If it actually was sending at 9600 baud, transferring the 1K buffer would take over a second, so the loop would run at less than 1 FPS.

(Josh Goebel) #27

Now I know that’s not true cause I’ve seen it speed up and slow down depending on the baud rate set - unless FTDI is so very different (although it’s also attached via USB).

(Scott) #28

FTDI is the manufacturer of USB to TTL serial conversion chips but I guess “FTDI” is now generically being used to mean USB to wired serial conversion.

If an FTDI chip or other USB to asynchronous serial converter is used, then the baud rate setting will indeed matter. The converter will maintain the configured speed on the TTL side of the link, thus pacing the USB data flow.

If there’s only a “virtual” end to end serial link using USB protocols the whole way, then the baud rate setting is ignored (unless there’s some software out there that artificially controls the rate, for realistic simulation of a real asynchronous link or something).

(Josh Goebel) #29

Learning something new… all my other devices (several) have been 328s with FTDI chips.

(Taylor Hansen) #30

Thanks for the insight on baud rates, but I would especially like some insight on why the screen capture won’t even show up.

(James Anderson) #31

@davidperrenoud How hard would it be to make the Arduboy(first one if many are connected) receive keystrokes as button presses? This could be useful when testing(might save wear and tear on Arduboy USB port too). Something like WASD as D-pad with KL as AB buttons

(Sarah Cartwright) #32

This can work the other way too!

Send the PC the screen description, “Sprite here, here, here, background offset here…” then the PC sends a fully rendered OLED RAM image that can just be placed in the buffer.

Megabytes of sprites and animation!

All the gameplay’s on the Arduboy so there’s no making the whole thing on the PC… which means you can disconnect the PC, and get some sort of Arduboy supplied graphics… perhaps 1/5 the animated frames? Using the same “display description” code running on the PC.