vec_for_screen broken in A8

Thanks to the user rojart i finally got myself an upgrade to A8 Pro (thanks!). While testing Shade-C with A8 i found something strange.

It seems that vec_for_screen is broken in A8.

Just try this simple script


A7 outputs -9999 (correct)
A8 outputs -8202.271 (incorrect)

I need correct values for vec_for_screen, as i'm reconstructing worldspace and viewspace position in some shaders using a depthmap and 4 values vec_for_screen gives me. (more info here http://mynameismjp.wordpress.com/2009/05/05/reconstructing-position-from-depth-continued/ )

Can you confirm this bug?

Have you tried different mouse_modes?
I believe something changed with the mouse modes...

Edit: Scratch that. The mouse modes were right in my application. But for some reason I can't get mouse_ent to work any more.
Might be unrelated though. But mine is not an engine bug.

I'm not using any mouse stuff at all in the above example
Just create a new file, paste the example code and you will get the wrong value.

Does this help?

mouse_pos3d

The world coordinate position of the mouse cursor in relation to the 3D level, calculated from mouse_pos and the view parameters.
Type:
VECTOR*, read/only
Example:

// use the mouse to trace a ray into the level,
// and trigger EVENT_SHOOT of hit entities
function shoot_with_mouse()
{
VECTOR to;
vec_set(to,mouse_dir3d);
vec_scale(to,1000); // set a range
vec_add(to,mouse_pos3d);
c_trace(mouse_pos3d,to,ACTIVATE_SHOOT);

Sorry, I had somehow overlooked this bug report. We'll look into that. The mouse mode has most likely nothing to do with it.

-Update: There is nothing broken with vec_for_screen. The difference to A7 is due to a more crude algorithm used by A7, which didn't take into account the angle difference of the position ray to the screen center axis. Therefore you got the wrong -9999 coordinate in A7. This did not matter for coordinates close to the screen, as the inaccuracy is small - therefore no one has noticed this so far. But it matters for coordinates far away, as in your example. In that case, A8 gives more accurate results.

This will be added to the manual.

Thanks for looking into it jcl!
I don't understand why -9999 is wrong though.

If the camera's pan/tilt/roll values are all zero (= camera looking in X axis direction) and i give vec_for_screen a point which should be 10000 quants in front of the camera, how can the resulting point not be 10000/9999 quants aways but rather be something crude like 8202 ? It makes even less sense the longer i think about it
Plus the position reconstruction in the shader gives wrong results (the shader should be correct as i'm using it in another engine, too). Also, for the reconstruction i always need the most far away points of the view frustum (basically the far frustum edges). So if camera.clip_far = 10000 i should get points which are 10000(or 9999) quants away from the camera. Instead i get 8202.

I'll try to create a workaround and directly fetch the far frustum corners instead of using vec_for_screen and compare that to what vec_for_screen outputs. Directly fetching/calculating the far frustum points should be faster anyway

I don't know the math of your shader, but when you look through the upper left corner of your screen and see a point in a distance of 10000, its depth coordinate is about 8000, dependent on the angle of the frustum. That's just Pythagoras. If the frustum angle were 180 degrees, the depth coordinate would be zero.

The far plane of a frustum is a plane, not a sphere. A7 treated it like a sphere. Only at the screen center the depth coordinate in your example would be indeed 10000.

Thanks for the explanation, i get it now
Guess i could just change the way my depthmap is generated/stored and should be good to go