Initial work on porting to SDL2.
Conversion to SDL2.
Removed scrap, as SDL now handled clipboard.
Added utf8 library.

Taken from http://utfcpp.sourceforge.net/
Use proper way of injecting characters.

SDL2 now handles this in a more correct way.
Fix mouse grabbing with SDL2.
Fixed issues with geometry changes.

When running in full screen we'll now use the native resolution of the
screen instead of trying to change it. We should therefore look into
scaling the rendered window instead if performance is an issue.
Handle multiple windows.
Set icon after window is created.

This is the correct way to do this in SDL2 now.
Fix SDL2 input for win32.
Revert code from old input handling.

SDL2 seems to have the same positioning issue.
So I have readded Ogre's positioning way with some extra comments.
Fix invalid iterator crash.

Assuming clear() was meant to be after the loop.
Add missing header.
Fix invalid time on win32.

The hours, minutes and seconds are set up correctly,
but the date is incorrect with latest boost.
This workaround should be thread safe and should work on all platforms.
Replace boost with C++11.
Limit FPS of config window.

It was running with 1000+ FPS on my Box, while it is just a static UI.
Fix crash when you abort configure window.

The meta server is still crashing, but we got one step further.
Reduce mouse position delay by 1 frame.

This makes gaming with low FPS much better! People has used directX
renderer, because input latency required as high FPS as possible.
I have also turned off FPS cap for win32 builds, because of this.

I was forced to look into SDL internals to find out that
SDL_GetMouseState() only gets mouse position stored in
SDL_Mouse* struct, while SDL_PollEvent() or SDL_PumpEvents()
will update the position for that struct.
Rename Scrap to SDL clipboard provider.

Also enable clipboard for win32.
Reduce input delay even further.

With this change, no input delay is noticeable with 15 FPS.
The idea is to inject input twice: Once before camera update and once
before GUI render. GUI is rendered after all render targets, which
takes up the most frame time and causes GUI input delays.
While this sounds incorrect, I can't imagine any situation,
where this would cause any problems.