I tried to make such a system in the past by panning the camera periodically to the hero and using periodically applied camera bounds to limit camera movement.
You can then detect micro-camera movement caused by moving the mouse to the corner of the screens (or using the arrow keys) and apply the rotation.
However, the attempt failed, as there was no method to pan the camera instantly to a point without interrupting default camera movement.
This means that as soon as the mouse moved to the corner, the camera turned only by 1 step and then stopped turning.
I worked around this by using camera bound adjustment to pan the camera (the only method to pan a camera without interrupting the mouse/key movement), but this method was too slow to create a graphically smooth result.
Long story short:
It's possible, but it doesn't look good on moving units, as the camera will "stutter" a lot.
EDIT:
It's possible to use a combination of trackables and the method described above.
Basicly, an algorithm that works like this:
- Periodically doing the vector job and moving trackables so that they always match the corners of the screen
- detecting mouse-over-trackable events
- using the camera bounds method to detect when the mouse actually hits the screen border for the first time
- rotating the camera until the mouse leaves the trackable area again
This basicly counters the problem I described above, that panning the camera back to the unit periodically via
PanCameraToTimed() interrupts the camera movement, as you only need the initial hit of the screen border and can then rely on the trackables to detect when the mouse leaves the corners again.
However, moving trackables around to match the camera vector is a total pain in the ass.
EDIT2:
I might have come up with a better idea. The initial problem of using camera bounds to pan the camera was that you basicly needed two camera bound adjustments for one update cycle: one to pan the camera to the center of the unit and one with slightly increased camera bounds to detect camera player-initiated camera movement. This resulted in a lot lower FPS than what could be possible with camera bounds in the first place.
So, a possible method to double those FPS (and probably bring it into the range at which it looks acceptable) is to alternate between camera bounds that allow vertical camera movement only and horizontal camera movement only.
That basicly doubles the sampling rate, as both bound adjustments can be partially combined to one.
Adjusting the bounds to only allow X coordinates tracked pans the camera back in the Y-direction and the opposite.
The only troubling point here is that you have to make sure that moving the camera always results in both X and Y coordinates to change. This means that 0°,90°,180° and 270° camera rotation values can not be allowed.
However, as a minor difference in rotation (like 1 degrees) basicly is not noticable by the player, it might totally work!
I'll definitely try that out when I get home. This might be the solution I've been looking for.
EDIT 3:
If you are interested in this, check out the thread in the lab:
http://www.hiveworkshop.com/forums/...mera-rotation-locked-cams-252078/#post2526921
