Hacker News new | comments | show | ask | jobs | submit login
Show HN: Building a Formula1 (Game) Telemetry Display Using Crystal and RethinkDB (blaze.com.au)
17 points by cyberferret on Nov 14, 2017 | hide | past | web | favorite | 6 comments

Very cool. Is there any need to wait until after pushing to rethinkdb before updating the websockets? I'd look for I/O concurrency here and block until they're all complete.

Possibly, that might make it faster and eliminate further blocking.

The entire convert/save/push to websockets activity though, is done on a separate _fibre_ in Crystal - essentially a spawned background thread. So even if one packet went awry, it shouldn't really block subsequent packets from coming through. I suppose I could go further, and within the spawned fibre, I could spawn another fibre for the write ops so it didn't get in the way of the web socket push op.

But then again, when I checked the Crystal CPU and memory footprint, it was really low, and even at the highest UDP telemetry rate of 60Hz, I don't think I lost any packets due to Crystal's sheer speed of handling them.

Any reason on why not open-sourcing this? Seems like a fun project to work on. Not much in worth tho.

I may do that, once I clean up the code a little I might throw it up on Github so that others can tweak and improve it.

Really surprised codemasters included a telemetry feed from the game, that's so cool.

Imagine if more games did that?

I believe most of the Codemasters racing games do have this feature. Documentation is a little scarce though, and we have to rely on their forum for information.

I was actually surprised by the number of third party racing wheels and displays that took advantage of this telemetry though. There are a lot of them that are now virtually indistinguishable from the real hardware in how they operate.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact