For the sake of argument. No. ;)
However....
ghalfwidth=graphicswidth()*0.5
ghalfheight=graphicsheight()*0.5
screenX# = CameraX*(ghalfwidth*Camzoom)+ghalfwidth
screenY# = -CameraY*(ghalfwidth*Camzoom)+ghalfheight
CameraX# = (ScreenX - ghalfwidth ) / (camzoom * ghalfwidth)
CameraY# = -(ScreenY - ghalfheight) / (camzoom * ghalfwidth)
Note: when I say cameraX and cameraY I mean the location in camera space, not the location of the camera, and of course you need to supply Z yourself.
Depending on how you set things up you may need to tform from worldspace (or indeed objectspace) to cameraspace and vice-versa. If do not rotate or move the camera then I think the above will be to and from world space. Not extensively tested though, I do not use ortho mode much. This is based on the observation that you get a 1:1 correspondence between cameraspace and screenspace resolution if camerazoom is set to 1.0/(Graphicswidth()/2).
However....
ghalfwidth=graphicswidth()*0.5
ghalfheight=graphicsheight()*0.5
screenX# = CameraX*(ghalfwidth*Camzoom)+ghalfwidth
screenY# = -CameraY*(ghalfwidth*Camzoom)+ghalfheight
CameraX# = (ScreenX - ghalfwidth ) / (camzoom * ghalfwidth)
CameraY# = -(ScreenY - ghalfheight) / (camzoom * ghalfwidth)
Note: when I say cameraX and cameraY I mean the location in camera space, not the location of the camera, and of course you need to supply Z yourself.
Depending on how you set things up you may need to tform from worldspace (or indeed objectspace) to cameraspace and vice-versa. If do not rotate or move the camera then I think the above will be to and from world space. Not extensively tested though, I do not use ortho mode much. This is based on the observation that you get a 1:1 correspondence between cameraspace and screenspace resolution if camerazoom is set to 1.0/(Graphicswidth()/2).