Wow, a whole day passed and noone corrected me :)
What I said was incorrect (more precisely, the way I said it): the "virtual monitor surface" would still be perpendicular to the view direction, but the center of this surface would no be any more on this view direction. That is the view vectorwouldn't intersect any more the "monitor" center. So, this is the line from the view point to the center of the surface that wouldn't be perpendicular to the surface any more.
This *cannNOT* be done with what we have in blitz right now (except - as said - by grabing a sub portion of a view port, wich is limited and a simple waste of rendering processing). Or please someone make me happy and prove me wrong :)
What I said was incorrect (more precisely, the way I said it): the "virtual monitor surface" would still be perpendicular to the view direction, but the center of this surface would no be any more on this view direction. That is the view vectorwouldn't intersect any more the "monitor" center. So, this is the line from the view point to the center of the surface that wouldn't be perpendicular to the surface any more.
Normal case: ------------- | | | o (view point) What the request is about: ------------- \ \ \ o (view point)
This *cannNOT* be done with what we have in blitz right now (except - as said - by grabing a sub portion of a view port, wich is limited and a simple waste of rendering processing). Or please someone make me happy and prove me wrong :)
Is this I presume a problem that wouldn't occur if you were say coding the camera properties in another language like DirectX and OpenGL?
Precisely, as then you have acces to the projection matrix as well as the transformation matrix. Thus you can shear the matrix, no problem.