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

Screen/minimap position inconsistencies #55

Closed
jstaker7 opened this issue Aug 31, 2017 · 8 comments
Closed

Screen/minimap position inconsistencies #55

jstaker7 opened this issue Aug 31, 2017 · 8 comments

Comments

@jstaker7
Copy link

jstaker7 commented Aug 31, 2017

I'm using a screen size of (64,64), a minimap size of (64,64), and camera of size 24 on map Simple64. This results in a camera on the minimap of size (16,16).

I'd expect that a 1 pixel shift on the minimap results in a 4 pixel shift across the map since 64/16 = 4. This seems to be true, except every once in a while the pixel shift is only 2 resulting in inconsistent amount of traversal across the real map for traversal across the minimap.

I'm guessing this might have to do with the map having a size that isn't a perfect factor of 64? Any thoughts on why this might be happening?

Code that reproduces the issue:

from PIL import Image

from pysc2.agents import base_agent
from pysc2.lib import actions
from pysc2.env.environment import StepType

class Prototype(base_agent.BaseAgent):

    def __init__(self):
        super(Prototype, self).__init__()
        self.action_queue = [
                              # 2 px shift
#                             actions.FunctionCall(1, [(45, 45)]),
#                             actions.FunctionCall(1, [(46, 45)])

                             # Expected 4 px shift
                             actions.FunctionCall(1, [(45, 45)]),
                             actions.FunctionCall(1, [(44, 45)])
                            ]
        self.ix = list(range(len(self.action_queue)))
    
    def step(self, obs):
        super(Prototype, self).step(obs)
        
        if obs.step_type != StepType.FIRST:
            minimap = obs.observation['minimap']
            screen = obs.observation['screen']
        
            ix = self.ix.pop(0)
            
            Image.fromarray((screen[4] > 0).astype('uint8')*255).save('~/{}_screen.png'.format(ix))
            Image.fromarray((minimap[3] > 0).astype('uint8')*255).save('~/{}_minimap.png'.format(ix))
        
        return self.action_queue.pop(0)

python -m pysc2.bin.agent --agent agents.debugging_1.Prototype --map Simple64 --screen_resolution 64 --agent_race T

@tewalds
Copy link
Member

tewalds commented Aug 31, 2017

With a map of size 64x64, a camera of 24 and minimap resolution of 64x64, the area on the minimap camera layer should be 24x24. If that isn't true, that's a bug. Moving the camera by 1px on the minimap should result in 64/24 px shift in the screen, so either 2 or 3. One reason this might not be true is the camera movement might be done with perspective so may not move to exactly the position you'd expect. @KevinCalderone any ideas?

@jstaker7
Copy link
Author

One reason this might not be true is the camera movement might be done with perspective so may not move to exactly the position you'd expect.

I thought that we don't have to worry about perspective issues? Perhaps I misunderstood the documentation:

[The screen] is rendered from a top down orthogonal camera, as opposed to a perspective camera that a human would get in a real game.

OK, maybe reading that over I can understand now. The screen is orthogonal, but that isn't true of the minimap?

@KevinCalderone
Copy link

It looks like the playable area of the map is 64x64, but that actual size of the map is 96x88. The feature layers are currently rendered in terms of the actual map size. The camera size of 24 doesn't divide nicely into 88, which is probably why moving the camera doesn't seem smooth.

We could change the renderer to use playable area if we think that would be better.

Note that this isn't fixable with just changing the map. The engine requires there to be a ~7 unit gap outside the playable area so there is something to render when you have your camera up against the edge of the map.

@jstaker7
Copy link
Author

jstaker7 commented Sep 1, 2017

Thanks for the info, this is really helpful. I think it makes sense to keep the feature layers as they are to include the full map.

As a test, what I'm attempting to do is obtain the full, high-resolution map by assembling the screen pieces. I can't do this consistently because of the differences in shifts, and is worse on maps of certain sizes, likely due to not dividing nicely as you mentioned.

I think having consistency between the minimap and full map coordinates is important, but not sure if I have a good solution yet. Any ideas?

@jstaker7
Copy link
Author

jstaker7 commented Sep 1, 2017

If the map coordinates of the screen were returned as part of the observation, that would be sufficient, I'd think.

@tewalds
Copy link
Member

tewalds commented Sep 1, 2017

You can get the camera coordinates from the raw api. I'm not sure your pixels would line up very well though. A better approach may be to set a very large camera, eg 64, and a large resolution (256) so that you can get the full map all at once.

@jstaker7
Copy link
Author

jstaker7 commented Sep 1, 2017

Setting a camera size and screen resolution that captures the full map did provide the full map in a single observation, thank you for the suggestion.

From this discussion the inconsistency appears to not be a bug but just a mismatch on dimensions between minimap, full map, and the camera.

One idea we could try is add padding to make sure the map is fully divisible by the camera, but it sounds like that would need to be added in the raw api rather than here, so I think we can close this for now.

@jstaker7 jstaker7 closed this as completed Sep 1, 2017
@OriolVinyals
Copy link
Collaborator

Hi,

Since you seem to be doing pretty cool stuff with the PySC2, I'd recommend checking out and applying to come work with us at Blizzcon in LA (Nov 3/4). Spots limited, and some travel funds available!

Info: http://us.battle.net/sc2/en/blog/21048078/announcing-the-starcraft-ii-ai-workshop-10-4-2017

GL&HF,
Oriol

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

4 participants