Visual stimulus screen positions

In an old experiment program we used to use, there was a way to define the “anchor” of a visual rectangle. It used compass-point symbols (C N NE E SE S SW W NW), but it could also be defined graphically. What they mean: “C” means the center of the image rectangle is positioned relative to the center of the display (more or less what SuperLab has now). “N” means that the middle of the top edge of the image is positioned relative to the middle of the top of the display. “NE” means the upper right corner of the image is positioned relative to the upper right corner of the display. And so on. How this is different and more useful than just moving the center of images around relative to the center of the display (or to any other single point) is (for example) that it allows you to put something exactly at (or a certain distance in from) the lower-left (SW) corner of the display regardless of the size of the display. That’s something that otherwise, you’d have to adjust for each computer and each display resolution you use. If you allow the use of fractional coordinates (that is, for a scale resolution of 1/1000, scale a horizontal coordinate h by width*h/1000), then you can get even more display independence.

Of course, the SL scenario file would have to be modified to represent this feature, which I’m sure would be a pain. However, if there’s even a one-byte hole in the specification of stimulus locations, you could add this with only five bits: 1 to enable scaled mode, 1 to enable the compass point logic, and 3 for the 8 compass points. All zeros would mean unscaled center mode, as it is now.

On the other hand, maybe there’s already a way to do these things, which would be wonderful. (I’ll ask the question in the support forum.)

Greg Shenaut

You can choose the “anchor” position of your rectangle, but the origin is still the center of the screen.

Really, it would only need a checkbox in the UI and a single boolean value in the data file to provide the option to move the origin on a per-picture basis, but this could really confuse things when it comes to mouse responses, since they’ll still be relative to a center origin. While it’s simple in the file and simple in concept, there is a lot of stuff in the program written assuming the origin is the center of the screen.

I think the better route would be to keep the origin at the center (less confusing) and go with a resolution-independent coordinate system. The screen would always be 2000 units wide (instead of your 1000, so that the edges of the screen are ±1000 instead of ±500), and height would depend on the screen’s aspect ratio (i.e. a 4x3 ratio would make the screen 1333 units tall). This way, NxN is predictably square and not the shape of the screen.

Unfortunately, the SuperLab 4.5 feature set has already been decided, so this isn’t likely to change any time soon.


What the old program did was to always have an adjustment parameter added to each coordinate (of the screen and of the particular rectangle you were fiddling with) before the real arithmetic started. By default these were all zero, which meant “center of screen, center of rectangle”, but when you were in one of the compass point modes, they were set to the appropriate values, positive or negative x/2 and/or y/2 as needed. So you basically only had to make the adjustment one time per screen operation, and at the lower levels, you just used the absolute coordinates. The low-level routines took care of drawing things “off screen” as needed.

Having scaled coordinates would be very good if they were implemented “right”. Especially if the automatic mouse-click response feature were enhanced just a little bit, or even not.


What would be “right?” What are you considering “wrong?”


Hank, I wasn’t really meaning “right” as a contrast with “wrong”, just as a synonym for “adequate”, “competently”, “flexibly”, whatever.