This one is more challenging, I think.

The Setup So Far

Basically what I am doing is setting up a 2D game with textured planes. The camera is orthographic, and that's no problem. The main thing is that, in the context of this specific game, I need for the camera to be fixed and never scroll, and then various sprites get drawn in camera coordinates, essentially. But since I'm rotating and blending these sprites, simply using DrawTexture is out (and that might have performance concerns anyway).

Mostly I have this working, but I'm trying to figure out the ideal way to handle the camera. There are basically two scaling components to this, and how they interact is not entirely clear to me:

• First, you have the transform, with its positions and matrices and such which are all pretty familiar from my DirectX background.
• Second, you have the orthographic size on the camera, which makes sense but is unclear what effect that then has on the overall transform of the camera.

Goal: Scaling, Bounded Viewport

Basically, my goal is to have basically a "virtual viewport" that is at max 1280x768, and at min 800x600. Anything under that would scale everything down (as it does already), and anything over that would either scale it up or would show a bounding area that is just empty. I could be fine with either approach, but am unsure about how to go about setting this up.

Local Vs World Vs Viewport Coordinate Conversions

Ideally I could then map 0,0 in world coordinates to one of the corners of the camera -- I'm used to it being top-left and having the vertical axis inverted, but I could work with whatever. Right now I have the camera centered at 0,0, however, and with the orthographic size being set to something like 768/2, that tends to lead to unpredictable scaling in world coordinates for me.

My thought was to just set a positional transform on the camera itself in addition to the orthographic size, and then just use local positional transforms on the various planes (which are parented to the camera), but this is not yielding the precision of results I would expect. On the vertical axis the plane positions are off by a little bit, and on the horizontal axis they are off by a lot.

Last Note

This is obviously a pretty complex question and I don't expect anyone to solve it in one go for me. But as this is something of a basic requirement for an easy-to-use fixed-camera 2D game environment (aka for puzzle games, etc), I figured someone else may have already basically solved this problem. Looking through public tutorials, etc, I don't see much.

If I can get a basic proof of concept of this sort of 2D setup figured out, I'll be sure to post the code since I know people are looking for various 2D examples (the shooter one is good, but doesn't address dynamic texture loading or how to handle a fixed-position camera at varying resolutions).