Fixed compilation with MiNGW64.

…ter> functions.

Created set_parameters function in ps3eyedriver to expose set_<parm>

Fixes for GCC (homebrew and mingw).

Fixes for GCC (homebrew and mingw).

Fixes an issue in Win 8.1 where PS3Eye shows up as two devices, presumably camera and microphone. Microphone cannot be opened with libusb so check for lack of err in opening device.

Fix debug macro. Add debug target to sdl example.

SDL example closes camera when quiting.

Added Green balance.

Exposed paramter getters through ps3eyedriver

Compiles in VS2013

…ndle_events_timeout_completed with a 50ms timeout. Internally libusb_handle_events calls libusb_handle_events_timeout_completed with a 60sec timeout. On rare occasions lib usb on Windows can stall waiting for an event to complete, resulting in a 60sec wait before the video stream recovers. Realistically, 50ms is more than long enough to wait.

Switch usb event polling from using libusb_handle_events to libusb_ha…

…and to timeEndPeriod(1) at PS3EYECam::stop(). I hope this improves PS3EYEDriver->libusb performance in Windows.

Added windows-only calls to timeBeginPeriod(1) at PS3EYECam::start() …

Added windows-only calls to timeBeginPeriod(1) at PS3EYECam::start() …

Increase timer resolution in Windows so libusb calls can return faster.

Conflicts:
	sdl/main.cpp
	src/ps3eye.cpp
	src/ps3eye.h

SDL example changes: Include SDL now the same for Windows and OS X

…optimization-clean

   - Increased the number of concurrent USB transfers active from 2 to 8. I've tested this on three different machines (low, medium, high spec), and this seems to hit the sweet spot for raw USB performance (max throughput)
   - Removed timeBeginPeriod/timeEndPeriod calls (they were not needed)
   - All cameras are now updated from a single thread (internal to the API). This thread is responsible for running the libusb event loop. This is to ensure that the performance of the camera is decoupled from the performance of the application polling the frames; the cameras will always update at the FPS specified during PS3EYECam::init, the application (consumer) can run as slow or fast as it wants.
   - There is now a per-camera frame queue. Internally it's implemented as a ring buffer; the camera update thread (producer) writes to *head*, the client (consumer) reads from *tail*. If no data is available, the consumer will block. However, if the buffer is full, the producer (camera update thread) will *not* block. This is to ensure that the camera update thread will always run at the max possible FPS, independent of the consumer and of the number of cameras in the system.

API changes
   - PS3EYECam::handleEvents has been removed (this is now done internally by a dedicated libusb event thread)
   - PS3EYECam::isNewFrame() has been removed
   - PS3EYECam::getLastFramePointer has been renamed to PS3EYECam::getFrame. This function blocks if no frame is available and now returns a malloc'd copy of the frame; the client is responsible for free'ing the buffer when done with it.
   - The SDL test app has been updated with these API changes (openframeworks and cinder have not, because I don't know how to build them...)

PS3EYEDriver C-wrapper changes (PS3EyeDriver.cpp)
   - Removed the yuv buffer management; there is no longer a need for it since the ps3eye driver now always returns a single frame
   - yuv422_buffer_t is now a simple wrapper around the buffer returned by  PS3EYECam::getFrame. It's purely responsible for making sure the frame is free'd when it's no longer needed

With this, it's now possible to update the PS3Eye at 60 FPS, independent of the number of cameras in the system. The only limiting factor should be how fast your client is.

…r what the difference is with ps3eye.h/.cpp

- Added frame counter to sdl test app