Forums

Full Version: Car data API for external applications
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
VDrift needs a car data API to allow external applications to get access to information about the game while it is in progress. The goal is to aid integration between VDrift and special hardware drivers, for instance those used in driving simulators, as well as other programs such as, possibly, a VDrift car editor/testing application.

I don't have a lot of ideas about exactly how this should be implemented. However we do need to provide a C or C++ library to interface with this API. C/C++ make sense because they are fast and portable, and can easily be wrapped by other languages like Python. C might be the best choice so that applications can easily be written in C which interface with it (C++ makes this harder).

As for the method of data flow, I'm not exactly sure of the best method. Joe suggested UDP earlier, another idea might be sockets (though some platforms may not work well with sockets).
I don't quite understand -- what would the C++ library do? Why not just provide configurable UDP outputs for the main vdrift app?
The idea behind the C/C++ lib would be that developers would just need to include this in their project and then make calls to it, perhaps vdrift_get_player_car_speed() to retrieve the speed. In other words we need to (1) get the data out of VDrift, (2) set up some kind of client that captures the data, and (3) make a library that takes this data and makes it available to developers. I think you're just talking about doing step 1, which is fine, we can't do 2 or 3 until that's done, and if we do 1 and make it available, it's possible someone else will come up with the library. However there's no reason to make every developer who wants to interface with VDrift parse UDP packets, or something along those lines - why not provide this to them?
So that would imply the lib would handle all of the networking for them? Let's just take this one step at a time. :-)
Thinking out loud: is networking the best way to go? Many people will want to do analysis directly on the machine so that wouldn't help them any, it would just be extra time/effort to get the messages out of packets. What other methods could we use and what are the advantages/disadvantages?