Hi,
I need to draw multiple circles while controlling how they overlap and an ability to tell which “layer” a particular circle is in.
Currently, I’m generating the circles with DrawDots function, supplying it with a vector of random positions, pre-defined colors for different circles and a certain size (the same for all). Given that positions are random, sometimes the circles overlap. I’m assuming that which circle ends up on top of another one is determined by the order in which they are drawn. Is it correct?
What would be the best approach to be able to tell which specific circle is on top such that when a user touches within the two circle radius, I can know which one should move (the top one)? Currently I’m moving the circle whose center is closest to the touch coordinates but that’s not ideal because it might mean that the bottom circle is moved.
Would it be possible to explicitly assign the circles to certain “layers”? Would it require invoking different calls to DrawDots?
A background for what I’m trying to accomplish:
I have an experiment with simulated digital “marbles” stored in a bowl (a bigger oval) and users have to sort these marbles by color. They do this by moving the marbles by hand using a touch screen. I would like to create specific trials in which as the sorting is being done, situations arise in which only one color of marbles (or a specific proportion) is revealed after some marbles have been moved.
I think this is both a conceptual programming question and regarding available drawing functions (maybe dealing with sprites would be preferable?).
Thanks!
In case you need advice from myself on this topic, this would be the point for your lab to buy a community membership with priority support.
-mario
I don’t have time to research the issue, but should be straightforward for you to determine if indeed circles are drawn in order of appearance in the input to DrawDots. And if so, if the first is the one furthest on the bottom.
Code would then be, upon click/touch, find all circles this touch was in, and choose the top-most, i…e, the latest in the input vector
@mariokleiner Is it 150€ per year per lab? Or per user? What would this support cover: 1) answering the questions or 2) help with implementation?
@dcnieho Yes, that was my idea to try next, I thought that maybe it’s already known what the order is, even though it’s not specified in the documentation or here on the forum. Thanks anyway for confirming my intuitions.
The drawing order is the order specified in the vector, first come first served, like with pretty much any low-level to mid-level 2D drawing api in existence.
The idea is that each lab gives 150 Euros per year, and not only if they need specific questions asked, but as a little contribution to PTB’s upkeep and development. PTB itself is free, but keeping PTB in good shape and advancing is not free at all for us, given that it is multiple full-time jobs, so voluntary monetary contributions are absolutely needed.
What you get is up to 3 support incidents within the contract year, for up to a total of 1 hour of work time combined over all incidents. The hope, based on a large user survey over the last years, is that not every lab will try to get the most out of it, or we’d have to raise prices and/or not answer any questions (like the two you already asked) for free, or think of other ways to monetize a free software, the only things i could think of would all be more expensive, strict and tedious for users, than what we got now on offer.
Actual priority support covers 1), but sometimes that implies 2) if code samples make sense and there isn’t already something in the demos. In the end you get an hour of support time per contract, so whatever makes most sense within roughly that time constraint to get the job done.
-mario
You could use procedural discs instead of DrawDots, which you would control by the order you run seperate Screen('DrawTexture') commands for each marble, it may be more intuitive than reordering the position matrix passed to draw dots? Textures are positioned using a PsychRect, so may also be easier to calculate than inferring from the XY center passed to DrawDots. See ProceduralSmoothedDiscsDemo for an example, although note that demo uses a single DrawTextures command whereas you want to separate them out…