Ascertaining real touch position
Tryangle
Member Posts: 37
What I want to do is locate a touch position in a scene.
The problem is that touch, mouse position, and raw mouse position all give me coordinates for the screen position, not the actual position.
Example: A scene is 5000x5000 pixels. The screen size is 1024x768, and the camera is centered on 2500x2500. If I touch directly in the middle of 2500x2500, it will give me the coordinates 512x384 instead of 2500x2500.
How does one ascertain the real touch position? Why are there three different ways to ascertain pointer positions, yet none of them gives the actual real touch position?
Answers
I don't mean to be such a negative nancy about GS, but I find myself having to do the work of a circus poodle jumping through hoops more often than I like.
In this case, I can't simply have a touch, I have to make an object move to touch position and then write its actual/correct position to values, and then have whatever objects I want to interact with it look at those values on some sort of condition, or else I need to make individual objects from prototypes that are scene specific, when I wonder why they couldn't just have at least one of those touch/mouse position values read the actual/correct position on the cartesian.
Not quite sure what you mean, the whole point of GS is that the hoop jumping is done for you behind the scenes, if you wanted to do something similar in code it wouldn't be as straightforward.
I'm not sure what any of that means either, but basically all you have to do is to add the camera offset to whatever values you are using, both touch and mouse position return the actual / correct position values, if you touch the screen at 450, 412 it will accurately return those values.
In some cases it is more straightforward, in some cases it is not. My guess is that most of what hoop jumping people run into is due to absence of common programming functions which are tied to how GS does compiles from our "code" we write in the engine, into its own code structure, then back out to different codes when we export to different OS. Whenever I can't make a direct call to a value from one object to another without using a proxy such as a global or array, this always strengthens this suspicion. How they compile is obviously never going to be public because its trade secrets, which means we can only deduce what is really going on by the shadow it casts on the functions available to us. Or what people on the forums refer to as "work arounds".
I do appreciate your help Socks, your taking a couple minutes to answer my questions have saved me hours or even days on more than one occasion.
I'm not sure what a 'direct call' is, I get easily confused by vague none-GS language when talking about GS, I'm not great at interpreting this kind of stuff !
I wouldn't say needing to add the camera's origin to your position is really workaround, it makes perfect sense to me, if it didn't work this way it would be odd, causing a lot of issues with scenes that don't match the screen size 1:1 . . . . touching the screen returns the X and Y values of where you touch the screen, if you send the camera off somewhere in a big scene, you also need to send the 'screen' with it, if that makes sense ?
Cheers, you just need to live with these (what appear to be) idiosyncrasies for a while before they become second nature - and you eventually come to realise that they couldn't realistically work any other way (at least without causing all sorts of issues)
If you think tracking the camera on a large scene is fun (!
) take a look at this from a current project . . . this is to keep a button in place while some exotic camera movements are going on . . . 
Attempting to emulate isometry? I get a picture of SNES f-zero in my head when I look at that.