Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pickpoint Results Become Innaccurate If Resize Fails #389

Open
ParodyGames opened this issue Apr 11, 2017 · 4 comments
Open

Pickpoint Results Become Innaccurate If Resize Fails #389

ParodyGames opened this issue Apr 11, 2017 · 4 comments

Comments

@ParodyGames
Copy link

If the screen tries to set to a too large size resulting in a "OpenGLDevice::setScreenMode -- can't switch to resolution larger than desktop in windowed mode!" error being logged, if you attempt to use pickpoint on scenes to handle user input the coordinates returned will be incorrect and the picked list will not contain the expected elements.

Found this trying to run a project I'm working on from my laptop instead of my desktop. The sprite 'buttons' I had made worked fine on my desktop with a 1024x768 default resolution, but my laptop would throw an error during initialization and attempts to click on the buttons would fail or give a different buttons actions as the pickpoint values were coming back wrong.

Code snippet from script for reference:
`function InputManager::onTouchDown(%this, %touchId, %worldposition)
{

//We assign the list of objects that were hit to variable %picked
%picked = myScene.pickPoint(%worldposition);

//%picked.count is the number of items listed in the %picked variable

for(%i=0; %i<%picked.count; %i++)
{

//When iterating through the list, getWord will return item number %i in variable %picked

  %myobj = getWord(%picked,%i);
  echo(%myobj.Function);
  if(isFunction(%myobj.Function))
  {	  
   call(%myobj.Function,"");
  }
  else if(%myobj.Function !$= "")
  {
   echo("Failed to find function: " @ %myobj.Function);
  }

}
}`

@ParodyGames
Copy link
Author

As a post script, not 100% sure that this is specifically the cause. If I change the default minimum size to be smaller on my laptop, it works fine. However, I tried scaling my dekstop's default size up and wasn't able to reproduce the problem there. I have a workaround by changing the function on winOGLVideo.cc to either return false rather than to try to guess at a workable size or to set it to the screen size if you try to go over, but neither is a really great solution.

@greenfire27
Copy link
Contributor

So the problem is that the engine picks a different, smaller window size, but still uses 1024x768 for pick point? It sounds like the answer is make sure pick point is using the actual screen size instead of the default screen size. I'll look into it.

On a side note, there is a much easier way to use sprites as buttons. Each individual sprite can have it's own onTouchDown event which can be automatically called when the sprite is clicked. Here's how:

  1. Set your scene to use object input events.
    %myScene.setUseObjectInputEvents(true);
  2. Give your button a class when you create it and have it use input events.
    %myButton = new Sprite { Scene = myScene; class = "StartButton"; useInputEvents = true; };
  3. Create a onTouchDown event for that class (which is technically a namespace).
    function StartButton::onTouchDown(%this, %touchID, %worldPosition) { ... }

I like to have a button superclass that handles onTouchEnter and onTouchLeave so I can give the user a little feedback when the mouse rolls over the button, like growing the button slightly or changing it's frame. Hope this helps!

@ParodyGames
Copy link
Author

Thanks, I'm more used to the old T2D where it was all onMouseDown. I tried to used that when I was first getting started, but I think I was looking at an incorrect note on how to set the attribute.

That being said, I switched over to OnTouchDown and it has the same issue. The clicks do not register in the appropriate location, as I believe it is using the same code to determine what was touched.

@greenfire27
Copy link
Contributor

Well OnTouchDown is the same thing as OnMouseDown - just renamed - but my point is that you don't need to capture the click on the screen and then try to figure out what was clicked. The engine can do that for you and call OnTouchDown on individual sprites.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants