Additions:
The implementations of Psychtoolbox-3 for Microsoft Windows and GNU/Linux are derived from the ""Mac OS/X"" implementation. As of December 2011, all versions are mostly compatible to each other and equally capable in core functionality. The different operating systems differ in their capabilities and limitations. You will have to take this into account if you want to write portable scripts. The following information should allow you to write scripts that are as portable as possible and to assess if PTB on a specific operating system is suitable for you.
All functions that are implemented as Matlab M-Files should work without any differences between system platforms, as long as they don't depend on system dependent MEX files. M-Files are tested with the Matlab 7.x series and the ""GNU/Octave 3.2.x"" series. Most functions should work on older Matlab 6.5 or later, but we do not test for or guarantee compatibility.
- //""IsLinux(1)""// returns 1 when the script is executed under GNU/Linux with a 64 bit version of Matlab or Octave, 0 otherwise.
The old and crufty //""PsychSerial""// command is available for Windows under Matlab. It is identical to the version bundled with the old Windows PTB-2.54. Matlab itself also allows to control the serial port via its //serial// command on Windows and Linux. It works well but has the drawback of only working when Java is enabled and it is significantly slower. Our //""IOPort""// driver provides high quality, flexible serial port support (and for USB serial ports) with high timing precision on all operating systems, so use of //""IOPort""// is strongly recommended.
The OS-X and Linux versions support joysticks via the new //""GamePad""// function. We provide some simple joystick support for Windows via //""WinJoystickMex""//.
[[PsychPortAudio Our new sound driver PsychPortAudio is a much better replacement for the old deprecated SND function and has many advantages. We strongly recommend you use PsychPortAudio for sound playback or capture. Click this link for more info.]]
Support for ""OpenGL"" low level commands is identical for all systems. Well, almost: Support for specific functions depends on the capabilities of your graphics hardware and ""OpenGL"" implementation, so some of the most recent features of ""OpenGL"" may not be supported on old graphics hardware. The solution to this problem is simple: Upgrade your graphics drivers or your hardware. We currently support the OpenGL 2.1 API and earlier versions, including various extensions.
//""PsychHID""// for control of USB HID devices is implemented on all systems since the end of 2011. You may encounter differences in the information provided about connected HID devices when calling //""PsychHID('Devices')""// due to differences in the underlying operating systems. If you write code that uses device enumeration to detect your devices, make sure to test on different operating systems to take these differences into account.
The ""GamePad"" function is only available on Mac OS/X and Linux for now.
Support for ""ActiveWire"" USB devices is included for Microsoft Windows for Matlab versions up to V 7.3. It is the same support file as in the old Windows PTB 2.54. There isn't any support for ""MacOS-X"" or Linux, and probably there won't be any in the future due to complete lack of support from the manufacturer of ""ActiveWire"" for other operating systems. For the same reason, Matlab 7.4 and later, as well as Octave on Windows is unsupported.
In Matlabs regular GUI mode, functions for character input are implemented as a Java class via Matlabs built-in Java virtual machine (JVM). Usage on all platforms is identical, no known principal differences, except that it doesn't work well on MS Windows Vista and Windows-7 (see the FAQ section about Vista problems for more info). Differences, if any, would be due to differences in the implementation of the JVM in different versions of Matlab. We need JVM version 1.4.2 or later. If Matlab is run without Java support or GUI (//matlab -nojvm// mode or //matlab -nodesktop// mode selected at startup), or if you are using Octave instead of Matlab, a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info. The //""GetKbChar""// function is often a viable and more robust replacement for //""GetChar""//.
The mapping of keyboard scancodes to key names used to be different in the Psychtoolboxes for OS 9, OS/X, Windows and Linux. E.g., the left arrow cursor control key used to be named 'left' on Windows, ""'LeftArrow'"" on Mac OS/X and 'Left' on Linux. This is annoying if one wants to write portable scripts. When writing new code, you should add the command //""KbName('UnifyKeyNames');""// at the top of your script. This will make sure that KbName accepts and returns identical keynames on all operating system platforms, allowing you to write portable code without extra effort. However, mapping of some special or exotic keys may be incomplete, so you should probably avoid those keys for portable scripts.
No known relevant differences in behaviour or quality, tell us if you find some! "GetSecs" timestamps are accurate at sub-millisecond level on all systems. The mouse and cursor handling functions on Linux allow to query and control multiple mice or mouse cursors individually. Only one mouse or mouse cursor is supported on ""OS/X"" and Windows, multiple mice are "merged" into one mouse input.
The range of values accepted by the //Priority// command differs between OS-X, Windows and Linux. //Priority(0)// disables realtime scheduling on all operating systems. On Linux, the Priority command can utilize some special system facilities to make realtime mode more effective and robust than on the other operating systems. On Linux you can also optionally install a low-latency or hard-realtime operating system kernel and various other tweaks to the system configuration if you require especially precise or robust realtime behaviour. This is generally not needed for most experimental setups, but if you choose to do it, it can provide realtime behaviour and timing precision that is orders of magnitude better than what Windows or ""OSX"" can possibly achieve. See the Linux specific setup pages on the Wiki for more information.
//""WaitSecs""// accepts values with microsecond precision. The robustness and accuracy of the //real waiting time// compared to the //requested waiting time// depends on the scheduling accuracy and timing jitter of the underlying operating system. My experience is that scheduling on a well configured Linux system or Mac OS/X Tiger / Leopard system is very accurate and robust, whereas Microsoft Windows systems are //significantly worse// on many tasks. For best possible precision, use a Linux system with low-latency or realtime kernel installed.
~~-**""Linux"":** Each X-Windows system x-screen will be enumerated as a separate Psychtoolbox screen. A x-screen can cover multiple connected physical display devices, depending on how you configured your setup in the xorg.conf file. On a single display setup you only have one x-screen, which maps to Psychtoolbox screenid 0. On a multi-display setup you would group physical displays together into one or multiple x-screens. Each x-screen maps to a Psychtoolbox screenid and is either covered and displayed to by a separate fullscreen Psychtoolbox onscreen window for stimulus presentation, or not used by Psychtoolbox, e.g., for operator control displays. The individual physical display devices (aka outputs) attached to a Psychtoolbox screen can be individually controlled via the //""Screen('ConfigureDisplay')""// command and the optional //""physicalDisplay""// parameter of various //Screen// subcommands, e.g., the //""LoadNormalizedGammaTable""// command for setting individual gamma tables per display.
~~-**""Mac OS/X"":** //""Screen('OpenWindow', screenid, color, rect)""// correctly handles the //rect// argument - You can open windows that don't cover the full display area for debugging purpose. However, timing precision and stimulus onset timing is strongly impaired in windowed mode due to limitations of MacOS/X. By default, an onscreen window always covers the full area of a specific display device.
~-Color depth setting //pixelsize//: This parameter is mostly there for backwards compatibility. It should be left at its default setting in almost all cases.
~~-**""Linux"":** Works with 24 bpp or 32 bpp, depending on graphics card. Simply leave out this parameter so PTB can choose the correct default.
~~-**""Mac OS/X"":** All modes are supported with high performance. For dual-display stereo you need to use a different setup code than on Windows. On Windows you'd use stereo mode 4, whereas on Mac OS you'd use stereo mode 10 and a slightly different setup code. Look at ""ImagingStereoDemo"" on how to do this. **Caution:** The different displays on a ""Mac OS/X"" system are not synchronized wrt. their display refresh cycles! This can cause tearing artifacts on one of the two displays if you use dual-display mode for binocular stimulation and show stereo movie animations.
~~-**""Windows"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. All other modes (Anaglyph stereo, dual display stereo, free fusion) should work on all hardware with high performance.
~~-**""Linux"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. All other modes (Anaglyph stereo, dual display stereo, free fusion) should work on all hardware with high performance.
~-""Quicktime/GStreamer"" support for audio- and movie playback:
~~-**""Windows"":** You can only play pure video or video+audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible. However, if you install the GStreamer multi-media framework (see "help GStreamer" for instructions) and enable it via a call to //""Screen('Preference', 'OverrideMultimediaEngine', 1);""// then these restrictions disappear. GStreamer will become the default playback engine in the near future, replacing the more limited Quicktime for Windows.
~~-**""Linux"":** Movie playback is fully supported via GStreamer at a performance that generally exceeds the performance of either Windows or ""Mac OS/X"".
~-Drawtext and TextBounds functions for drawing text: No difference in functionality or quality, only in speed.
~~-**""Windows"":** By default, a text renderer based on the Windows GDI is used: It provides accurate text bounding boxes, anti-aliased text (although not at the superb quality level of OSX, but still good), and Unicode support, just as on OSX with moderate speed. An older text renderer can be optionally selected, which is based on OpenGL display lists: Less flexible, significantly lower text quality (no text Anti-Aliasing), only the standard ASCII character set, but //very fast//. Limitations of the fast optional renderer: Computation of text bounding boxes doesn't take descenders of letters into account, due to some Microsoft implementation brain-damage. The text size setting is not correctly handled due to some unresolved bug. Text shows up at a size approximately 2/3rd of what was requested.
~~-**""Linux"":** Fast text rendering of high quality, anti-aliased, unicode text with true type text fonts is fully supported. The speed of the Linux text renderer is usually significantly higher than the speed of the Windows or ""OSX"" renderer, while retaining their quality, functionality and flexibility.
~~-**""Mac OS/X"":** On all ""PowerPC"" computers and on many Intel Macs, the timestamps are guaranteed to be sub-millisecond accurate, regardless of system load or scheduling jitter. Synchronization of stimulus onset to the vertical retrace is guaranteed to be microsecond accurate on properly working hardware. However, on some recent versions of the operating system with ATI or Intel graphics cards, installation of the //""PsychtoolboxKernelDriver""// is required for reliable timestamping to compensate for various operating system bugs. As the driver is currently incompatible with 64 bit versions of the ""OS/X"" kernel, you need to boot your system in 32 bit mode and suffer reduced overall system performance if you require precision timestamping. Without this driver installed, a different set of workarounds so far provided at least millisecond accurate timestamping, but this workarounds are ineffective due to new additional bugs introduced in ""OS/X"" 10.7 "Lion".
~~-**""Linux"":** Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X. Currently you need to run Matlab or Octave as root user via the "sudo" command if you use the proprietary graphics drivers from NVidia or ATI/AMD to get the same timestamping precision as on a well working ""OS/X"" or Windows systems. This limitation will be lifted in a future release of Psychtoolbox. If you choose to use the free graphics drivers for Intel, ATI/AMD or NVidia graphics cards instead of the proprietary drivers, timestamp precision and visual stimulus onset precision will be even better and more robust than on any other operating system or graphics hardware without any need for additional setup steps or use of root mode.
~~On recent graphics hardware, the //""PsychImaging('AddTask','General','EnableCLUTMapping')""// function allows to restore clut animation in a portable and reliable way on all operating systems. This needs hardware with fragment shader support. This method of clut animation also allows for perfectly frame-accurate animation.
~~However, we consider clut animation mostly an obsolete, ancient feature - There are almost always better ways to create animated stimuli with all the new PTB drawing functions.
All functions that are implemented as Matlab M-Files should work without any differences between system platforms, as long as they don't depend on system dependent MEX files. M-Files are tested with the Matlab 7.x series and the ""GNU/Octave 3.2.x"" series. Most functions should work on older Matlab 6.5 or later, but we do not test for or guarantee compatibility.
- //""IsLinux(1)""// returns 1 when the script is executed under GNU/Linux with a 64 bit version of Matlab or Octave, 0 otherwise.
The old and crufty //""PsychSerial""// command is available for Windows under Matlab. It is identical to the version bundled with the old Windows PTB-2.54. Matlab itself also allows to control the serial port via its //serial// command on Windows and Linux. It works well but has the drawback of only working when Java is enabled and it is significantly slower. Our //""IOPort""// driver provides high quality, flexible serial port support (and for USB serial ports) with high timing precision on all operating systems, so use of //""IOPort""// is strongly recommended.
The OS-X and Linux versions support joysticks via the new //""GamePad""// function. We provide some simple joystick support for Windows via //""WinJoystickMex""//.
[[PsychPortAudio Our new sound driver PsychPortAudio is a much better replacement for the old deprecated SND function and has many advantages. We strongly recommend you use PsychPortAudio for sound playback or capture. Click this link for more info.]]
Support for ""OpenGL"" low level commands is identical for all systems. Well, almost: Support for specific functions depends on the capabilities of your graphics hardware and ""OpenGL"" implementation, so some of the most recent features of ""OpenGL"" may not be supported on old graphics hardware. The solution to this problem is simple: Upgrade your graphics drivers or your hardware. We currently support the OpenGL 2.1 API and earlier versions, including various extensions.
//""PsychHID""// for control of USB HID devices is implemented on all systems since the end of 2011. You may encounter differences in the information provided about connected HID devices when calling //""PsychHID('Devices')""// due to differences in the underlying operating systems. If you write code that uses device enumeration to detect your devices, make sure to test on different operating systems to take these differences into account.
The ""GamePad"" function is only available on Mac OS/X and Linux for now.
Support for ""ActiveWire"" USB devices is included for Microsoft Windows for Matlab versions up to V 7.3. It is the same support file as in the old Windows PTB 2.54. There isn't any support for ""MacOS-X"" or Linux, and probably there won't be any in the future due to complete lack of support from the manufacturer of ""ActiveWire"" for other operating systems. For the same reason, Matlab 7.4 and later, as well as Octave on Windows is unsupported.
In Matlabs regular GUI mode, functions for character input are implemented as a Java class via Matlabs built-in Java virtual machine (JVM). Usage on all platforms is identical, no known principal differences, except that it doesn't work well on MS Windows Vista and Windows-7 (see the FAQ section about Vista problems for more info). Differences, if any, would be due to differences in the implementation of the JVM in different versions of Matlab. We need JVM version 1.4.2 or later. If Matlab is run without Java support or GUI (//matlab -nojvm// mode or //matlab -nodesktop// mode selected at startup), or if you are using Octave instead of Matlab, a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info. The //""GetKbChar""// function is often a viable and more robust replacement for //""GetChar""//.
The mapping of keyboard scancodes to key names used to be different in the Psychtoolboxes for OS 9, OS/X, Windows and Linux. E.g., the left arrow cursor control key used to be named 'left' on Windows, ""'LeftArrow'"" on Mac OS/X and 'Left' on Linux. This is annoying if one wants to write portable scripts. When writing new code, you should add the command //""KbName('UnifyKeyNames');""// at the top of your script. This will make sure that KbName accepts and returns identical keynames on all operating system platforms, allowing you to write portable code without extra effort. However, mapping of some special or exotic keys may be incomplete, so you should probably avoid those keys for portable scripts.
No known relevant differences in behaviour or quality, tell us if you find some! "GetSecs" timestamps are accurate at sub-millisecond level on all systems. The mouse and cursor handling functions on Linux allow to query and control multiple mice or mouse cursors individually. Only one mouse or mouse cursor is supported on ""OS/X"" and Windows, multiple mice are "merged" into one mouse input.
The range of values accepted by the //Priority// command differs between OS-X, Windows and Linux. //Priority(0)// disables realtime scheduling on all operating systems. On Linux, the Priority command can utilize some special system facilities to make realtime mode more effective and robust than on the other operating systems. On Linux you can also optionally install a low-latency or hard-realtime operating system kernel and various other tweaks to the system configuration if you require especially precise or robust realtime behaviour. This is generally not needed for most experimental setups, but if you choose to do it, it can provide realtime behaviour and timing precision that is orders of magnitude better than what Windows or ""OSX"" can possibly achieve. See the Linux specific setup pages on the Wiki for more information.
//""WaitSecs""// accepts values with microsecond precision. The robustness and accuracy of the //real waiting time// compared to the //requested waiting time// depends on the scheduling accuracy and timing jitter of the underlying operating system. My experience is that scheduling on a well configured Linux system or Mac OS/X Tiger / Leopard system is very accurate and robust, whereas Microsoft Windows systems are //significantly worse// on many tasks. For best possible precision, use a Linux system with low-latency or realtime kernel installed.
~~-**""Linux"":** Each X-Windows system x-screen will be enumerated as a separate Psychtoolbox screen. A x-screen can cover multiple connected physical display devices, depending on how you configured your setup in the xorg.conf file. On a single display setup you only have one x-screen, which maps to Psychtoolbox screenid 0. On a multi-display setup you would group physical displays together into one or multiple x-screens. Each x-screen maps to a Psychtoolbox screenid and is either covered and displayed to by a separate fullscreen Psychtoolbox onscreen window for stimulus presentation, or not used by Psychtoolbox, e.g., for operator control displays. The individual physical display devices (aka outputs) attached to a Psychtoolbox screen can be individually controlled via the //""Screen('ConfigureDisplay')""// command and the optional //""physicalDisplay""// parameter of various //Screen// subcommands, e.g., the //""LoadNormalizedGammaTable""// command for setting individual gamma tables per display.
~~-**""Mac OS/X"":** //""Screen('OpenWindow', screenid, color, rect)""// correctly handles the //rect// argument - You can open windows that don't cover the full display area for debugging purpose. However, timing precision and stimulus onset timing is strongly impaired in windowed mode due to limitations of MacOS/X. By default, an onscreen window always covers the full area of a specific display device.
~-Color depth setting //pixelsize//: This parameter is mostly there for backwards compatibility. It should be left at its default setting in almost all cases.
~~-**""Linux"":** Works with 24 bpp or 32 bpp, depending on graphics card. Simply leave out this parameter so PTB can choose the correct default.
~~-**""Mac OS/X"":** All modes are supported with high performance. For dual-display stereo you need to use a different setup code than on Windows. On Windows you'd use stereo mode 4, whereas on Mac OS you'd use stereo mode 10 and a slightly different setup code. Look at ""ImagingStereoDemo"" on how to do this. **Caution:** The different displays on a ""Mac OS/X"" system are not synchronized wrt. their display refresh cycles! This can cause tearing artifacts on one of the two displays if you use dual-display mode for binocular stimulation and show stereo movie animations.
~~-**""Windows"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. All other modes (Anaglyph stereo, dual display stereo, free fusion) should work on all hardware with high performance.
~~-**""Linux"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. All other modes (Anaglyph stereo, dual display stereo, free fusion) should work on all hardware with high performance.
~-""Quicktime/GStreamer"" support for audio- and movie playback:
~~-**""Windows"":** You can only play pure video or video+audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible. However, if you install the GStreamer multi-media framework (see "help GStreamer" for instructions) and enable it via a call to //""Screen('Preference', 'OverrideMultimediaEngine', 1);""// then these restrictions disappear. GStreamer will become the default playback engine in the near future, replacing the more limited Quicktime for Windows.
~~-**""Linux"":** Movie playback is fully supported via GStreamer at a performance that generally exceeds the performance of either Windows or ""Mac OS/X"".
~-Drawtext and TextBounds functions for drawing text: No difference in functionality or quality, only in speed.
~~-**""Windows"":** By default, a text renderer based on the Windows GDI is used: It provides accurate text bounding boxes, anti-aliased text (although not at the superb quality level of OSX, but still good), and Unicode support, just as on OSX with moderate speed. An older text renderer can be optionally selected, which is based on OpenGL display lists: Less flexible, significantly lower text quality (no text Anti-Aliasing), only the standard ASCII character set, but //very fast//. Limitations of the fast optional renderer: Computation of text bounding boxes doesn't take descenders of letters into account, due to some Microsoft implementation brain-damage. The text size setting is not correctly handled due to some unresolved bug. Text shows up at a size approximately 2/3rd of what was requested.
~~-**""Linux"":** Fast text rendering of high quality, anti-aliased, unicode text with true type text fonts is fully supported. The speed of the Linux text renderer is usually significantly higher than the speed of the Windows or ""OSX"" renderer, while retaining their quality, functionality and flexibility.
~~-**""Mac OS/X"":** On all ""PowerPC"" computers and on many Intel Macs, the timestamps are guaranteed to be sub-millisecond accurate, regardless of system load or scheduling jitter. Synchronization of stimulus onset to the vertical retrace is guaranteed to be microsecond accurate on properly working hardware. However, on some recent versions of the operating system with ATI or Intel graphics cards, installation of the //""PsychtoolboxKernelDriver""// is required for reliable timestamping to compensate for various operating system bugs. As the driver is currently incompatible with 64 bit versions of the ""OS/X"" kernel, you need to boot your system in 32 bit mode and suffer reduced overall system performance if you require precision timestamping. Without this driver installed, a different set of workarounds so far provided at least millisecond accurate timestamping, but this workarounds are ineffective due to new additional bugs introduced in ""OS/X"" 10.7 "Lion".
~~-**""Linux"":** Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X. Currently you need to run Matlab or Octave as root user via the "sudo" command if you use the proprietary graphics drivers from NVidia or ATI/AMD to get the same timestamping precision as on a well working ""OS/X"" or Windows systems. This limitation will be lifted in a future release of Psychtoolbox. If you choose to use the free graphics drivers for Intel, ATI/AMD or NVidia graphics cards instead of the proprietary drivers, timestamp precision and visual stimulus onset precision will be even better and more robust than on any other operating system or graphics hardware without any need for additional setup steps or use of root mode.
~~On recent graphics hardware, the //""PsychImaging('AddTask','General','EnableCLUTMapping')""// function allows to restore clut animation in a portable and reliable way on all operating systems. This needs hardware with fragment shader support. This method of clut animation also allows for perfectly frame-accurate animation.
~~However, we consider clut animation mostly an obsolete, ancient feature - There are almost always better ways to create animated stimuli with all the new PTB drawing functions.
Deletions:
All functions that are implemented as Matlab M-Files should work without any differences between system platforms, as long as they don't depend on system dependent MEX files. M-Files are tested with the Matlab 7.x series. Most functions should work on older Matlab 6.x or 5.x as well, but we do not test for or guarantee compatibility.
The old and crufty //""PsychSerial""// command is available for Windows. It is identical to the version bundled with the old Windows PTB2.54. Matlab itself also allows to control the serial port via its //serial// command on Windows and Linux. It works well but has the drawback of only working when Java is enabled and it is significantly slower. Our //""IOPort""// driver provides high quality, flexible serial port support (and for USB serial ports) with high timing precision on all operating systems, so use of //""IOPort""// is strongly recommended.
The OS-X version supports joysticks via the new //""GamePad""// functions. We provide some simple joystick support for Windows via //""WinJoystickMex""// and this link: [[http://www.ece.utah.edu/~bodson/fun/index.html Seems to have some downloadable joystick driver for Matlab on Windows.]].
[[PsychPortAudio Our new sound driver PsychPortAudio is a much better replacement for the old deprecated SND function and has many advantages. Click this link for more info.]]
Support for ""OpenGL"" low level commands in Matlab is identical for all systems. Well, almost: Support for specific functions depends on the capabilities of your graphics hardware and ""OpenGL"" implementation, so some of the most recent features of ""OpenGL"" may not be supported on old graphics hardware. The solution to this problem is simple: Upgrade your graphics drivers or your hardware.
//""PsychHID""// for control of USB HID devices is only implemented on Mac OS/X for now. The DAQ toolbox depends on ""PsychHID"", therefore it is unavailable as well on non OS/X systems. Porting ""PsychHID"" to Linux or Windows would not be difficult for an experienced C programmer, but this is not on anybodies todo list for now. //Volunteers?//
The ""GamePad"" function depends on ""PsychHID"", therefore it is only available on Mac OS/X for now.
Support for ""ActiveWire"" USB devices is included for Microsoft Windows for Matlab versions up to V 7.3. It is the same support file as in the old Windows PTB 2.54. There isn't any support for ""MacOS-X"" or Linux, and probably there won't be any in the future due to complete lack of support from the manufacturer of ""ActiveWire"" for other operating systems. For the same reason, Matlab 7.4 and later on Windows is unsupported.
In Matlabs regular GUI mode, functions for character input are implemented as a Java class via Matlabs built-in Java virtual machine (JVM). Usage on all platforms is identical, no known principal differences, except that it doesn't work well on MS Windows Vista and Windows-7 (see the FAQ section about Vista problems for more info). Differences, if any, would be due to differences in the implementation of the JVM in different versions of Matlab. We need JVM version 1.4.2 or later. If Matlab is run without Java support or GUI (//matlab -nojvm// mode or //matlab -nodesktop// mode selected at startup), or if you are using Octave instead of Matlab, a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info.
The mapping of keyboard scancodes to key names used to be different in the Psychtoolboxes for OS 9, OS/X, Windows and Linux. E.g., the left arrow cursor control key used to be named 'left' on Windows, ""'LeftArrow'"" on Mac OS/X and 'Left' on Linux. This is annoying if one wants to write portable scripts. When writing new code, you should add the command //""KbName('UnifyKeyNames');""// at the top of your script. This will make sure that KbName accepts and returns identical keynames on all operating system platforms, allowing you to write portable code without extra effort. However, mapping of special keys (not the alphanumeric mones, but things like keys on the numeric keypad etc.) may be incomplete for some operating systems, so you should probably avoid those keys for portable scripts.
No known relevant differences in behaviour or quality, tell us if you find some! "GetSecs" timestamps are accurate at sub-millisecond level on all systems.
The range of values accepted by the //Priority// command differs between OS-X, Windows and Linux. //Priority(0)// disables realtime scheduling on all operating systems.
//""WaitSecs""// accepts values with microsecond precision. The robustness and accuracy of the //real waiting time// compared to the //requested waiting time// depends on the scheduling accuracy and timing jitter of the underlying operating system. My experience is that scheduling on a well configured Linux system or Mac OS/X Tiger / Leopard system is very accurate and robust, whereas Microsoft Windows systems are //significantly worse// on many tasks.
~~-**""Linux"":** Will behave mostly like ""Mac OS/X"". Well, should behave like that, but testing this happened quite a while ago, so i can't remember if there were any smallish differences.
~~-**""Mac OS/X"":** //""Screen('OpenWindow', screenid, color, rect)""// correctly handles the //rect// argument - You can open windows that don't cover the full display area for debugging purpose. However, timing precision and stimulus onset timing is strongly impaired in windowed mode due to limitations of MacOS/X. By default, all onscreen windows always cover the full area of a specific display device.,
~-Color depth setting //pixelsize//:
~~-**""Linux"":** Works with 24 bpp or 32 bpp, depending on graphics card. Simply leave out this parameter so PTB can choose correct default.
~~-**""Mac OS/X"":** All modes are supported with high performance. For dual-display stereo you need to use a different setup code than on Windows. On Windows you'd use stereo mode 4, whereas on Mac OS you'd use stereo mode 10 and a slightly different setup code. Look at ""StereoDemo"" on how to do this. **Caution:** According to some user reports, the different displays on a ""Mac OS/X"" system are not synchronized wrt. their display refresh cycles! This can cause tearing artifacts on one of the two displays if you use dual-display mode for binocular stimulation and show stereo movie animations. One way of avoiding this problem is to use a so called display splitter. More infos about this topic soon... Ask on the forum if you have urgent questions on this.
~~-**""Windows"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of ""OpenGL"" AUX buffer support on Windows, unless you enable the Psychtoolbox imaging pipeline on recent hardware (See ""ImagingStereoDemo"" for howto). All other modes (Anaglyph stereo, dual display stereo, free fusion) should work with high performance.
~~-**""Linux"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of ""OpenGL"" AUX buffer support on Windows, unless you enable the Psychtoolbox imaging pipeline on recent hardware (See ""ImagingStereoDemo"" for howto). All other modes (Anaglyph stereo, dual display stereo, free fusion) should work with high performance.
~-Quicktime support for audio- and movie playback:
~~-**""Windows"":** You can only play pure video or video+audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Linux"":** Movie playback is not supported due to lack of Quicktime support by Apple for Linux. A future version of PTB would need to reimplement movie playback via some other toolkit than Quicktime.
~-Drawtext and TextBounds functions for drawing text:
~~-**""Windows"":** By default, a text renderer based on the Windows GDI is used: It provides accurate text bounding boxes, anti-aliased text (although not at the superb quality level of OSX, but still good, and Unicode support, just as on OSX with moderate speed). An older text renderer can be optionally selected, which is based on OpenGL display lists: Less flexible, significantly lower text quality (no text Anti-Aliasing), only the standard ASCII character set, but //very fast//. Limitations of the fast optional renderer: Computation of text bounding boxes doesn't take descenders of letters into account, due to some Microsoft implementation brain-damage. The text size setting is not correctly handled due to some unresolved bug. Text shows up at a size approximately 2/3rd of what was requested.
~~-**""Linux"":** The current text renderer is based on ""OpenGL"" display lists. It is very fast, but text quality is limited (no anti-aliasing), flexibility is limited and there isn't any support for Unicode. It is good enough for displaying instructions to subjects etc., but for complex text perception / letter recognition studies, it isn't really the best choice. As a work-around you'd need to predraw text, e.g., via Matlab or in an external application, then load the "text slides" as textures and draw them via the texture drawing functions.
~~-**""Mac OS/X"":** On all ""PowerPC"" computers and probably on most Intel Macs, the timestamps are guaranteed to be sub-millisecond accurate, regardless of system load or scheduling jitter. Synchronization of stimulus onset to the vertical retrace is guaranteed to be microsecond accurate on properly working hardware.
~~-**""Linux"":** Linux graphics subsystem lacks general support for some mechanisms used for precise timestamping as on Windows and ""Mac OS/X"". However, Linux accurate realtime behaviour usually turns this into a non-issue. For ATI hardware of the Radeon X1000 series or Radeon HD series, Linux provides the same accurate timestamping mechanism as the other operating systems due to our own special ATI specific implementations.
~~On recent graphics hardware, the //""moglClutBlit""// helper function allows to restore clut animation in a portable reliable way on all operating systems. This needs hardware with fragment shader support. See/Run ""GLSLCLUTAnimDemo"" to test if it works and to learn how to use it. This method of clut animation also allows for perfectly frame-accurate animation.
~~However, we consider clut animation mostly an obsolete feature - There are almost always better ways to create animated stimuli with all the new PTB drawing functions.
Revision [1576]
Edited on 2010-04-05 19:37:57 by MarioKleiner [Update info about WinJoystick and other fluff.]Additions:
The old and crufty //""PsychSerial""// command is available for Windows. It is identical to the version bundled with the old Windows PTB2.54. Matlab itself also allows to control the serial port via its //serial// command on Windows and Linux. It works well but has the drawback of only working when Java is enabled and it is significantly slower. Our //""IOPort""// driver provides high quality, flexible serial port support (and for USB serial ports) with high timing precision on all operating systems, so use of //""IOPort""// is strongly recommended.
The OS-X version supports joysticks via the new //""GamePad""// functions. We provide some simple joystick support for Windows via //""WinJoystickMex""// and this link: [[http://www.ece.utah.edu/~bodson/fun/index.html Seems to have some downloadable joystick driver for Matlab on Windows.]].
In Matlabs regular GUI mode, functions for character input are implemented as a Java class via Matlabs built-in Java virtual machine (JVM). Usage on all platforms is identical, no known principal differences, except that it doesn't work well on MS Windows Vista and Windows-7 (see the FAQ section about Vista problems for more info). Differences, if any, would be due to differences in the implementation of the JVM in different versions of Matlab. We need JVM version 1.4.2 or later. If Matlab is run without Java support or GUI (//matlab -nojvm// mode or //matlab -nodesktop// mode selected at startup), or if you are using Octave instead of Matlab, a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info.
The OS-X version supports joysticks via the new //""GamePad""// functions. We provide some simple joystick support for Windows via //""WinJoystickMex""// and this link: [[http://www.ece.utah.edu/~bodson/fun/index.html Seems to have some downloadable joystick driver for Matlab on Windows.]].
In Matlabs regular GUI mode, functions for character input are implemented as a Java class via Matlabs built-in Java virtual machine (JVM). Usage on all platforms is identical, no known principal differences, except that it doesn't work well on MS Windows Vista and Windows-7 (see the FAQ section about Vista problems for more info). Differences, if any, would be due to differences in the implementation of the JVM in different versions of Matlab. We need JVM version 1.4.2 or later. If Matlab is run without Java support or GUI (//matlab -nojvm// mode or //matlab -nodesktop// mode selected at startup), or if you are using Octave instead of Matlab, a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info.
Deletions:
The OS-X version supports joysticks via the new //""GamePad""// functions. We currently don't provide joystick support for Windows or Linux, but this link: [[http://www.ece.utah.edu/~bodson/fun/index.html Seems to have some downloadable joystick driver for Matlab on Windows.]]
In Matlabs regular GUI mode, functions for character input are implemented as a Java class via Matlabs built-in Java virtual machine (JVM). Usage on all platforms is identical, no known principal differences. Differences, if any, would be due to differences in the implementation of the JVM in different versions of Matlab. We need JVM version 1.4.2 or later. If Matlab is run without Java support or GUI (//matlab -nojvm// mode or //matlab -nodesktop// mode selected at startup), or if you are using Octave instead of Matlab, a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info.
Additions:
The //""PsychSerial""// command is available for Windows. Its identical to the version bundled with the old Windows PTB2.54. Matlab itself also allows to control the serial port via its //serial// command on Windows and Linux. It works well but has the drawback of only working when Java is enabled and it is significantly slower. Our //""IOPort""// driver provides high quality, flexible serial port support (and for USB serial ports) with high timing precision on all operating systems.
Sound output via the old and deprecated //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab or Octave implementation. Unfortunately, the only valid general statement that can be made about Matlab's past and current sound output function is "poor". Octave's support for //sound// is also rudimentary.
In Matlabs regular GUI mode, functions for character input are implemented as a Java class via Matlabs built-in Java virtual machine (JVM). Usage on all platforms is identical, no known principal differences. Differences, if any, would be due to differences in the implementation of the JVM in different versions of Matlab. We need JVM version 1.4.2 or later. If Matlab is run without Java support or GUI (//matlab -nojvm// mode or //matlab -nodesktop// mode selected at startup), or if you are using Octave instead of Matlab, a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info.
For Java mode:
~-**""Mac OS/X"":** The functions should work with all Matlab versions under OS/X 10.3.9 and later.
~-**""Windows"":** Should work with Matlab 7.0 and later, not on earlier Matlabs.
~-**""Linux"":** Should work with Matlab 7.0 and later, not on earlier Matlabs.
The mapping of keyboard scancodes to key names used to be different in the Psychtoolboxes for OS 9, OS/X, Windows and Linux. E.g., the left arrow cursor control key used to be named 'left' on Windows, ""'LeftArrow'"" on Mac OS/X and 'Left' on Linux. This is annoying if one wants to write portable scripts. When writing new code, you should add the command //""KbName('UnifyKeyNames');""// at the top of your script. This will make sure that KbName accepts and returns identical keynames on all operating system platforms, allowing you to write portable code without extra effort. However, mapping of special keys (not the alphanumeric mones, but things like keys on the numeric keypad etc.) may be incomplete for some operating systems, so you should probably avoid those keys for portable scripts.
~~-**""Windows"":** The color depth setting is ignored. You'd need to change the settings in the display properties control panel of your system. However, any setting except the default of 32 bpp will cause abortion of your script with an error message.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on older Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Windows + Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
~~//Most older graphics cards are restricted to 8 bits DAC precision and even the latest models from ATI or NVidia have at most 10 bits of DAC precision, so the 16 bit limit imposed by the operating systems is a theoretical limit, not a practical one!//
Sound output via the old and deprecated //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab or Octave implementation. Unfortunately, the only valid general statement that can be made about Matlab's past and current sound output function is "poor". Octave's support for //sound// is also rudimentary.
In Matlabs regular GUI mode, functions for character input are implemented as a Java class via Matlabs built-in Java virtual machine (JVM). Usage on all platforms is identical, no known principal differences. Differences, if any, would be due to differences in the implementation of the JVM in different versions of Matlab. We need JVM version 1.4.2 or later. If Matlab is run without Java support or GUI (//matlab -nojvm// mode or //matlab -nodesktop// mode selected at startup), or if you are using Octave instead of Matlab, a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info.
For Java mode:
~-**""Mac OS/X"":** The functions should work with all Matlab versions under OS/X 10.3.9 and later.
~-**""Windows"":** Should work with Matlab 7.0 and later, not on earlier Matlabs.
~-**""Linux"":** Should work with Matlab 7.0 and later, not on earlier Matlabs.
The mapping of keyboard scancodes to key names used to be different in the Psychtoolboxes for OS 9, OS/X, Windows and Linux. E.g., the left arrow cursor control key used to be named 'left' on Windows, ""'LeftArrow'"" on Mac OS/X and 'Left' on Linux. This is annoying if one wants to write portable scripts. When writing new code, you should add the command //""KbName('UnifyKeyNames');""// at the top of your script. This will make sure that KbName accepts and returns identical keynames on all operating system platforms, allowing you to write portable code without extra effort. However, mapping of special keys (not the alphanumeric mones, but things like keys on the numeric keypad etc.) may be incomplete for some operating systems, so you should probably avoid those keys for portable scripts.
~~-**""Windows"":** The color depth setting is ignored. You'd need to change the settings in the display properties control panel of your system. However, any setting except the default of 32 bpp will cause abortion of your script with an error message.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on older Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Windows + Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
~~//Most older graphics cards are restricted to 8 bits DAC precision and even the latest models from ATI or NVidia have at most 10 bits of DAC precision, so the 16 bit limit imposed by the operating systems is a theoretical limit, not a practical one!//
Deletions:
Sound output via the old and deprecated //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab implementation. Unfortunately, the only valid general statement that can be made about Matlab's past and current sound output function is "poor".
Functions for character input are implemented as a Java class via Matlabs built-in Java virtual machine (JVM). Usage on all platforms is identical, no known principal differences. Differences are due to differences in the implementation of the JVM in different versions of Matlab. We need JVM version 1.4.2 or later:
~-**""Mac OS/X"":** The functions should work with all Matlab versions under OS/X 10.3.9 and later. They don't work at all in //matlab -nojvm// mode.
~-**""Windows"":** Should work with Matlab 7.0 and later, not on earlier Matlabs. In //matlab -nojvm// mode on Matlabs before V7.4 (Release 2007a), a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info.
~-**""Linux"":** Should work with Matlab 7.0 and later, not on earlier Matlabs. They don't work at all in //matlab -nojvm// mode.
~- These commands don't work at all under the GNU / Octave runtime environment at all, but Octaves //kbhit// command may be a workable work-around.
The mapping of keyboard scancodes to key names used to be different in the Psychtoolboxes for OS 9, OS/X, Windows and Linux. E.g., the left arrow cursor control key used to be named 'left' on Windows, ""'LeftArrow'"" on Mac OS/X and 'Left' on Linux. This is annoying if one wants to write portable scripts. When writing new code, you should add the command //""KbName('UnifyKeyNames');""// at the top of your script. This will make sure that KbName accepts and returns identical keynames on all operating system platforms, allowing you to write portable code without extra effort.
~~-**""Windows"":** The color depth setting is ignored. You need to change the settings in the display properties control panel of your system. Any setting except the default of 32 bpp will cause abortion of your script with an error message.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window + Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
Additions:
===**//The information on this page is periodically updated (i.e., at any point in time slightly outdated). It always refers to the state of the current beta flavor of PTB.//**===
All functions that are implemented as Matlab M-Files should work without any differences between system platforms, as long as they don't depend on system dependent MEX files. M-Files are tested with the Matlab 7.x series. Most functions should work on older Matlab 6.x or 5.x as well, but we do not test for or guarantee compatibility.
The //""PsychSerial""// command is available for Windows. Its identical to the version bundled with the old Windows PTB2.54. Matlab itself also allows to control the serial port via its //serial// command on Windows and Linux. It works well but has the drawback of only working when Java is enabled and it is significantly slower.
The OS-X version supports joysticks via the new //""GamePad""// functions. We currently don't provide joystick support for Windows or Linux, but this link: [[http://www.ece.utah.edu/~bodson/fun/index.html Seems to have some downloadable joystick driver for Matlab on Windows.]]
A functional implementation of the Eyelink toolbox is included in the Psychhardware folder of PTB for all operating systems. It is reported to work well, although it's not polished yet, e.g., the documentation and some of the demos are not yet updated and cleaned in all parts. You must install the runtime libraries from SR - Research on your system for this to work. They come bundled with your Eyelink and are also downloadable from their website.
[[PsychPortAudio Our new sound driver PsychPortAudio is a much better replacement for the old deprecated SND function and has many advantages. Click this link for more info.]]
Support for ""ActiveWire"" USB devices is included for Microsoft Windows for Matlab versions up to V 7.3. It is the same support file as in the old Windows PTB 2.54. There isn't any support for ""MacOS-X"" or Linux, and probably there won't be any in the future due to complete lack of support from the manufacturer of ""ActiveWire"" for other operating systems. For the same reason, Matlab 7.4 and later on Windows is unsupported.
~-**""Linux"":** Should work with Matlab 7.0 and later, not on earlier Matlabs. They don't work at all in //matlab -nojvm// mode.
~- These commands don't work at all under the GNU / Octave runtime environment at all, but Octaves //kbhit// command may be a workable work-around.
//""WaitSecs""// accepts values with microsecond precision. The robustness and accuracy of the //real waiting time// compared to the //requested waiting time// depends on the scheduling accuracy and timing jitter of the underlying operating system. My experience is that scheduling on a well configured Linux system or Mac OS/X Tiger / Leopard system is very accurate and robust, whereas Microsoft Windows systems are //significantly worse// on many tasks.
~~-**""Linux"":** Will behave mostly like ""Mac OS/X"". Well, should behave like that, but testing this happened quite a while ago, so i can't remember if there were any smallish differences.
~~-**""Linux"":** ditto.
~~-**""Linux"":** Works with 24 bpp or 32 bpp, depending on graphics card. Simply leave out this parameter so PTB can choose correct default.
~~-**""Linux"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of ""OpenGL"" AUX buffer support on Windows, unless you enable the Psychtoolbox imaging pipeline on recent hardware (See ""ImagingStereoDemo"" for howto). All other modes (Anaglyph stereo, dual display stereo, free fusion) should work with high performance.
~~-**""Linux"":** Movie playback is not supported due to lack of Quicktime support by Apple for Linux. A future version of PTB would need to reimplement movie playback via some other toolkit than Quicktime.
~~-**""Linux"":** The current text renderer is based on ""OpenGL"" display lists. It is very fast, but text quality is limited (no anti-aliasing), flexibility is limited and there isn't any support for Unicode. It is good enough for displaying instructions to subjects etc., but for complex text perception / letter recognition studies, it isn't really the best choice. As a work-around you'd need to predraw text, e.g., via Matlab or in an external application, then load the "text slides" as textures and draw them via the texture drawing functions.
~~-**""Linux"":** Linux graphics subsystem lacks general support for some mechanisms used for precise timestamping as on Windows and ""Mac OS/X"". However, Linux accurate realtime behaviour usually turns this into a non-issue. For ATI hardware of the Radeon X1000 series or Radeon HD series, Linux provides the same accurate timestamping mechanism as the other operating systems due to our own special ATI specific implementations.
~~-**""Linux"":** Has the same capabilities as ""Mac OS/X"", the status of CLUT synchronization is hardware dependent.
~~-**""Linux"":** Reports only bare minimum.
All functions that are implemented as Matlab M-Files should work without any differences between system platforms, as long as they don't depend on system dependent MEX files. M-Files are tested with the Matlab 7.x series. Most functions should work on older Matlab 6.x or 5.x as well, but we do not test for or guarantee compatibility.
The //""PsychSerial""// command is available for Windows. Its identical to the version bundled with the old Windows PTB2.54. Matlab itself also allows to control the serial port via its //serial// command on Windows and Linux. It works well but has the drawback of only working when Java is enabled and it is significantly slower.
The OS-X version supports joysticks via the new //""GamePad""// functions. We currently don't provide joystick support for Windows or Linux, but this link: [[http://www.ece.utah.edu/~bodson/fun/index.html Seems to have some downloadable joystick driver for Matlab on Windows.]]
A functional implementation of the Eyelink toolbox is included in the Psychhardware folder of PTB for all operating systems. It is reported to work well, although it's not polished yet, e.g., the documentation and some of the demos are not yet updated and cleaned in all parts. You must install the runtime libraries from SR - Research on your system for this to work. They come bundled with your Eyelink and are also downloadable from their website.
[[PsychPortAudio Our new sound driver PsychPortAudio is a much better replacement for the old deprecated SND function and has many advantages. Click this link for more info.]]
Support for ""ActiveWire"" USB devices is included for Microsoft Windows for Matlab versions up to V 7.3. It is the same support file as in the old Windows PTB 2.54. There isn't any support for ""MacOS-X"" or Linux, and probably there won't be any in the future due to complete lack of support from the manufacturer of ""ActiveWire"" for other operating systems. For the same reason, Matlab 7.4 and later on Windows is unsupported.
~-**""Linux"":** Should work with Matlab 7.0 and later, not on earlier Matlabs. They don't work at all in //matlab -nojvm// mode.
~- These commands don't work at all under the GNU / Octave runtime environment at all, but Octaves //kbhit// command may be a workable work-around.
//""WaitSecs""// accepts values with microsecond precision. The robustness and accuracy of the //real waiting time// compared to the //requested waiting time// depends on the scheduling accuracy and timing jitter of the underlying operating system. My experience is that scheduling on a well configured Linux system or Mac OS/X Tiger / Leopard system is very accurate and robust, whereas Microsoft Windows systems are //significantly worse// on many tasks.
~~-**""Linux"":** Will behave mostly like ""Mac OS/X"". Well, should behave like that, but testing this happened quite a while ago, so i can't remember if there were any smallish differences.
~~-**""Linux"":** ditto.
~~-**""Linux"":** Works with 24 bpp or 32 bpp, depending on graphics card. Simply leave out this parameter so PTB can choose correct default.
~~-**""Linux"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of ""OpenGL"" AUX buffer support on Windows, unless you enable the Psychtoolbox imaging pipeline on recent hardware (See ""ImagingStereoDemo"" for howto). All other modes (Anaglyph stereo, dual display stereo, free fusion) should work with high performance.
~~-**""Linux"":** Movie playback is not supported due to lack of Quicktime support by Apple for Linux. A future version of PTB would need to reimplement movie playback via some other toolkit than Quicktime.
~~-**""Linux"":** The current text renderer is based on ""OpenGL"" display lists. It is very fast, but text quality is limited (no anti-aliasing), flexibility is limited and there isn't any support for Unicode. It is good enough for displaying instructions to subjects etc., but for complex text perception / letter recognition studies, it isn't really the best choice. As a work-around you'd need to predraw text, e.g., via Matlab or in an external application, then load the "text slides" as textures and draw them via the texture drawing functions.
~~-**""Linux"":** Linux graphics subsystem lacks general support for some mechanisms used for precise timestamping as on Windows and ""Mac OS/X"". However, Linux accurate realtime behaviour usually turns this into a non-issue. For ATI hardware of the Radeon X1000 series or Radeon HD series, Linux provides the same accurate timestamping mechanism as the other operating systems due to our own special ATI specific implementations.
~~-**""Linux"":** Has the same capabilities as ""Mac OS/X"", the status of CLUT synchronization is hardware dependent.
~~-**""Linux"":** Reports only bare minimum.
Deletions:
All functions that are implemented as Matlab M-Files should work without any differences between system platforms, as long as they don't depend on system dependent MEX files. M-Files are tested with the Matlab 7.x series. Most functions should work on older Matlab 6.x as well, but we do not test for or guarantee compatibility.
The //""PsychSerial""// command is available for Windows. Its identical to the version bundled with the old Windows PTB2.54. Matlab itself also allows to control the serial port via its //serial// command. It works well but has the drawback of only working when Java is enabled and it is significantly slower.
The OS-X version supports joysticks via the new //""GamePad""// functions. We currently don't provide joystick support for Windows, but this link: [[http://www.ece.utah.edu/~bodson/fun/index.html Seems to have some downloadable joystick driver for Matlab on Windows.]]
~-**""Mac OS/X and Windows"":** A functional implementation of the Eyelink toolbox is included in the Psychhardware folder of PTB. It is reported to work well, although it's not polished yet, e.g., the documentation is not yet updated and cleaned in all parts.
[[PsychPortAudio Therefore we recommend using our new sound driver PsychPortAudio instead of the old deprecated SND function. Click this link for more info.]]
Support for ""ActiveWire"" USB devices is included for Microsoft Windows for Matlab versions up to V 7.3. It is the same support files as in the old Windows PTB 2.54. There isn't any support for ""MacOS-X"" or Linux, and probably there won't be any in the future due to complete lack of support from the manufacturer of ""ActiveWire"" for other operating systems. For the same reason, Matlab 7.4 and later on Windows is unsupported.
//""WaitSecs""// accepts values with microsecond precision. The robustness and accuracy of the //real waiting time// compared to the //requested waiting time// depends on the scheduling accuracy and timing jitter of the underlying operating system. My experience is that scheduling on a well configured Linux system or Mac OS/X Tiger system is very accurate and robust, whereas Microsoft Windows systems are //significantly worse// on many tasks.
Revision [1310]
Edited on 2008-03-04 12:20:53 by MarioKleiner [Update wrt. dual-display sync on OS/X and text rendering on Windows.]Additions:
~~-**""Mac OS/X"":** All modes are supported with high performance. For dual-display stereo you need to use a different setup code than on Windows. On Windows you'd use stereo mode 4, whereas on Mac OS you'd use stereo mode 10 and a slightly different setup code. Look at ""StereoDemo"" on how to do this. **Caution:** According to some user reports, the different displays on a ""Mac OS/X"" system are not synchronized wrt. their display refresh cycles! This can cause tearing artifacts on one of the two displays if you use dual-display mode for binocular stimulation and show stereo movie animations. One way of avoiding this problem is to use a so called display splitter. More infos about this topic soon... Ask on the forum if you have urgent questions on this.
~~-**""Windows"":** By default, a text renderer based on the Windows GDI is used: It provides accurate text bounding boxes, anti-aliased text (although not at the superb quality level of OSX, but still good, and Unicode support, just as on OSX with moderate speed). An older text renderer can be optionally selected, which is based on OpenGL display lists: Less flexible, significantly lower text quality (no text Anti-Aliasing), only the standard ASCII character set, but //very fast//. Limitations of the fast optional renderer: Computation of text bounding boxes doesn't take descenders of letters into account, due to some Microsoft implementation brain-damage. The text size setting is not correctly handled due to some unresolved bug. Text shows up at a size approximately 2/3rd of what was requested.
~~-**""Windows"":** By default, a text renderer based on the Windows GDI is used: It provides accurate text bounding boxes, anti-aliased text (although not at the superb quality level of OSX, but still good, and Unicode support, just as on OSX with moderate speed). An older text renderer can be optionally selected, which is based on OpenGL display lists: Less flexible, significantly lower text quality (no text Anti-Aliasing), only the standard ASCII character set, but //very fast//. Limitations of the fast optional renderer: Computation of text bounding boxes doesn't take descenders of letters into account, due to some Microsoft implementation brain-damage. The text size setting is not correctly handled due to some unresolved bug. Text shows up at a size approximately 2/3rd of what was requested.
Deletions:
~~-**""Windows"":** A text renderer based on OpenGL display lists is used: Less flexible, significantly lower text quality (no text Anti-Aliasing), only the standard ASCII character set, but //much faster//. Computation of text bounding boxes doesn't take descenders of letters into account, due to some Microsoft implementation brain-damage. The text size setting is not correctly handled due to some unresolved bug. Text shows up at a size approximately 2/3rd of what was requested.
Revision [1252]
Edited on 2007-09-12 19:48:11 by MarioKleiner [Updates on text rendering and clut animation]Additions:
~~-**""Windows"":** A text renderer based on OpenGL display lists is used: Less flexible, significantly lower text quality (no text Anti-Aliasing), only the standard ASCII character set, but //much faster//. Computation of text bounding boxes doesn't take descenders of letters into account, due to some Microsoft implementation brain-damage. The text size setting is not correctly handled due to some unresolved bug. Text shows up at a size approximately 2/3rd of what was requested.
~~On recent graphics hardware, the //""moglClutBlit""// helper function allows to restore clut animation in a portable reliable way on all operating systems. This needs hardware with fragment shader support. See/Run ""GLSLCLUTAnimDemo"" to test if it works and to learn how to use it. This method of clut animation also allows for perfectly frame-accurate animation.
~~However, we consider clut animation mostly an obsolete feature - There are almost always better ways to create animated stimuli with all the new PTB drawing functions.
~~On recent graphics hardware, the //""moglClutBlit""// helper function allows to restore clut animation in a portable reliable way on all operating systems. This needs hardware with fragment shader support. See/Run ""GLSLCLUTAnimDemo"" to test if it works and to learn how to use it. This method of clut animation also allows for perfectly frame-accurate animation.
~~However, we consider clut animation mostly an obsolete feature - There are almost always better ways to create animated stimuli with all the new PTB drawing functions.
Deletions:
Revision [1251]
Edited on 2007-09-12 19:40:32 by MarioKleiner [More infos about stereo modes, imaging pipe, anaglyph...]Additions:
~~-**""Mac OS/X"":** All modes are supported with high performance. For dual-display stereo you need to use a different setup code than on Windows. On Windows you'd use stereo mode 4, whereas on Mac OS you'd use stereo mode 10 and a slightly different setup code. Look at ""StereoDemo"" on how to do this.
~~-**""Windows"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of ""OpenGL"" AUX buffer support on Windows, unless you enable the Psychtoolbox imaging pipeline on recent hardware (See ""ImagingStereoDemo"" for howto). All other modes (Anaglyph stereo, dual display stereo, free fusion) should work with high performance.
~~In general, it is beneficial to use the stereo modes with the PTB imaging pipeline enabled. See ""ImagingStereoDemo"" for an example of use. On OS/X this is crucial for dual display stereo. On all operating systems if you use Anaglyph stereo presentation, it will allow for very flexible control over gains and other parameters via //""SetAnaglyphStereoParameter()""//.
~~-**""Windows"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of ""OpenGL"" AUX buffer support on Windows, unless you enable the Psychtoolbox imaging pipeline on recent hardware (See ""ImagingStereoDemo"" for howto). All other modes (Anaglyph stereo, dual display stereo, free fusion) should work with high performance.
~~In general, it is beneficial to use the stereo modes with the PTB imaging pipeline enabled. See ""ImagingStereoDemo"" for an example of use. On OS/X this is crucial for dual display stereo. On all operating systems if you use Anaglyph stereo presentation, it will allow for very flexible control over gains and other parameters via //""SetAnaglyphStereoParameter()""//.
Deletions:
~~-**""Windows"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of ""OpenGL"" AUX buffer support on Windows. All other modes (Anaglyph stereo, dual display stereo, free fusion) should work with high performance.
Revision [1250]
Edited on 2007-09-12 19:31:12 by MarioKleiner [More infos about stereo modes, imaging pipe, anaglyph...]Additions:
~~-**""Mac OS/X"":** //""Screen('OpenWindow', screenid, color, rect)""// correctly handles the //rect// argument - You can open windows that don't cover the full display area for debugging purpose. However, timing precision and stimulus onset timing is strongly impaired in windowed mode due to limitations of MacOS/X. By default, all onscreen windows always cover the full area of a specific display device.,
Deletions:
Additions:
Support for ""ActiveWire"" USB devices is included for Microsoft Windows for Matlab versions up to V 7.3. It is the same support files as in the old Windows PTB 2.54. There isn't any support for ""MacOS-X"" or Linux, and probably there won't be any in the future due to complete lack of support from the manufacturer of ""ActiveWire"" for other operating systems. For the same reason, Matlab 7.4 and later on Windows is unsupported.
~-**""Windows"":** Should work with Matlab 7.0 and later, not on earlier Matlabs. In //matlab -nojvm// mode on Matlabs before V7.4 (Release 2007a), a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info.
~-**""Windows"":** Should work with Matlab 7.0 and later, not on earlier Matlabs. In //matlab -nojvm// mode on Matlabs before V7.4 (Release 2007a), a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info.
Deletions:
~-**""Windows"":** Should work with Matlab 7.0 and later, not on earlier Matlabs. In //matlab -nojvm// mode, a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info.
Revision [1248]
Edited on 2007-09-12 19:24:29 by MarioKleiner [Pointer to PsychPortAudio as replacement for Snd added.]Additions:
Sound output via the old and deprecated //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab implementation. Unfortunately, the only valid general statement that can be made about Matlab's past and current sound output function is "poor".
[[PsychPortAudio Therefore we recommend using our new sound driver PsychPortAudio instead of the old deprecated SND function. Click this link for more info.]]
[[PsychPortAudio Therefore we recommend using our new sound driver PsychPortAudio instead of the old deprecated SND function. Click this link for more info.]]
Deletions:
Revision [1247]
Edited on 2007-09-12 19:17:07 by MarioKleiner [Add link to joystick driver on Windows]Additions:
The OS-X version supports joysticks via the new //""GamePad""// functions. We currently don't provide joystick support for Windows, but this link: [[http://www.ece.utah.edu/~bodson/fun/index.html Seems to have some downloadable joystick driver for Matlab on Windows.]]
Deletions:
Additions:
~~-**""Windows"":** If your system is switched to multi-monitor mode, //Screen('Screens')// will report //n+1// displays for a setup with //n// displays. The display with index zero is special: It corresponds to the display area of //all// connected displays. If you open an onscreen window on display zero, it will occupy all connected display devices. This is useful for presentation of stereo stimuli or other binocular stimuli. The screens with indices //1, 2, ..., n// correspond to the display areas of display devices //1, 2, ..., n//, so specifying these screen ids allows you to open onscreen windows on individual displays or to query and set properties of individual displays, e.g., refresh rate, resolution, color depth, size or the hardware color lookup tables. If you have an unusual display arrangement, you can also explicitely specify a //rect// argument to the //""Screen('OpenWindow', screenid, color, rect)""// command to create a window that occupies the specified //rect// on the desktop, partially covering multiple monitors.
~~-**""Windows"":** You can only play pure video or video+audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window + Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
~~-**""Windows"":** You can only play pure video or video+audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window + Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
Deletions:
~~-**""Windows"":** You can only play pure video or video audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
Additions:
~~-**""Windows"":** If your system is switched to multi-monitor mode, //Screen('Screens')// will report //n 1// displays for a setup with //n// displays. The display with index zero is special: It corresponds to the display area of //all// connected displays. If you open an onscreen window on display zero, it will occupy all connected display devices. This is useful for presentation of stereo stimuli or other binocular stimuli. The screens with indices //1, 2, ..., n// correspond to the display areas of display devices //1, 2, ..., n//, so specifying these screen ids allows you to open onscreen windows on individual displays or to query and set properties of individual displays, e.g., refresh rate, resolution, color depth, size or the hardware color lookup tables. If you have an unusual display arrangement, you can also explicitely specify a //rect// argument to the //""Screen('OpenWindow', screenid, color, rect)""// command to create a window that occupies the specified //rect// on the desktop, partially covering multiple monitors.
~~-**""Windows"":** You can only play pure video or video audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
~~-**""Windows"":** You can only play pure video or video audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
Deletions:
~~-**""Windows"":** You can only play pure video or video+audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window + Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
Additions:
~~-**""Windows"":** If your system is switched to multi-monitor mode, //Screen('Screens')// will report //n+1// displays for a setup with //n// displays. The display with index zero is special: It corresponds to the display area of //all// connected displays. If you open an onscreen window on display zero, it will occupy all connected display devices. This is useful for presentation of stereo stimuli or other binocular stimuli. The screens with indices //1, 2, ..., n// correspond to the display areas of display devices //1, 2, ..., n//, so specifying these screen ids allows you to open onscreen windows on individual displays or to query and set properties of individual displays, e.g., refresh rate, resolution, color depth, size or the hardware color lookup tables. If you have an unusual display arrangement, you can also explicitely specify a //rect// argument to the //""Screen('OpenWindow', screenid, color, rect)""// command to create a window that occupies the specified //rect// on the desktop, partially covering multiple monitors.
~~-**""Windows"":** You can only play pure video or video+audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window + Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
~~-**""Windows"":** You can only play pure video or video+audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window + Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
Deletions:
~~-**""Windows"":** You can only play pure video or video audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
Additions:
~~-**""Windows"":** If your system is switched to multi-monitor mode, //Screen('Screens')// will report //n 1// displays for a setup with //n// displays. The display with index zero is special: It corresponds to the display area of //all// connected displays. If you open an onscreen window on display zero, it will occupy all connected display devices. This is useful for presentation of stereo stimuli or other binocular stimuli. The screens with indices //1, 2, ..., n// correspond to the display areas of display devices //1, 2, ..., n//, so specifying these screen ids allows you to open onscreen windows on individual displays or to query and set properties of individual displays, e.g., refresh rate, resolution, color depth, size or the hardware color lookup tables. If you have an unusual display arrangement, you can also explicitely specify a //rect// argument to the //""Screen('OpenWindow', screenid, color, rect)""// command to create a window that occupies the specified //rect// on the desktop, partially covering multiple monitors.
~~-**""Windows"":** You can only play pure video or video audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
~~-**""Windows"":** You can only play pure video or video audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
Deletions:
~~-**""Windows"":** You can only play pure video or video+audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window + Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
Additions:
The //""PsychSerial""// command is available for Windows. Its identical to the version bundled with the old Windows PTB2.54. Matlab itself also allows to control the serial port via its //serial// command. It works well but has the drawback of only working when Java is enabled and it is significantly slower.
The Status of Joystick support for Windows is unknown, the OS-X version supports joysticks via the new //""GamePad""// functions.
Sound output via the //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab implementation. Unfortunately, the only valid general statement that can be made about Matlab's current sound output function is "poor". However, there exist improved versions of the Matlab low-level sound drivers for Windows and Macintosh which at least eliminate a few serious bugs. Due to copyright reasons we can not distribute these with PTB, but you can download them from the [[http://tech.groups.yahoo.com/group/psychtoolbox/messages/ files section of the Psychtoolbox forum]].
The Status of Joystick support for Windows is unknown, the OS-X version supports joysticks via the new //""GamePad""// functions.
Sound output via the //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab implementation. Unfortunately, the only valid general statement that can be made about Matlab's current sound output function is "poor". However, there exist improved versions of the Matlab low-level sound drivers for Windows and Macintosh which at least eliminate a few serious bugs. Due to copyright reasons we can not distribute these with PTB, but you can download them from the [[http://tech.groups.yahoo.com/group/psychtoolbox/messages/ files section of the Psychtoolbox forum]].
Deletions:
Sound output via the //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab implementation. Unfortunately, the only valid general statement that can be made about Matlab's current sound output function is "poor". However, there exist improved versions of the Matlab low-level sound drivers for Windows and Macintosh which at least eliminate a few serious bugs. Due to copyright reasons we can not distribute these with PTB, but you can download them from the Files - Section of the Psychtoolbox forum.
Additions:
Sound output via the //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab implementation. Unfortunately, the only valid general statement that can be made about Matlab's current sound output function is "poor". However, there exist improved versions of the Matlab low-level sound drivers for Windows and Macintosh which at least eliminate a few serious bugs. Due to copyright reasons we can not distribute these with PTB, but you can download them from the Files - Section of the Psychtoolbox forum.
Deletions:
Additions:
~~-**""Windows"":** Accuracy of returned timestamps is the same as on OS/X on NVidia and ATI hardware, but not on Intel onboard graphics hardware. There it will be millisecond accurate in most cases, but no guarantees can be made due to technical limitations of the Window + Intel graphics combo. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
Deletions:
Additions:
~-**""Mac OS/X and Windows"":** A functional implementation of the Eyelink toolbox is included in the Psychhardware folder of PTB. It is reported to work well, although it's not polished yet, e.g., the documentation is not yet updated and cleaned in all parts.
//""PsychHID""// for control of USB HID devices is only implemented on Mac OS/X for now. The DAQ toolbox depends on ""PsychHID"", therefore it is unavailable as well on non OS/X systems. Porting ""PsychHID"" to Linux or Windows would not be difficult for an experienced C programmer, but this is not on anybodies todo list for now. //Volunteers?//
Support for ""ActiveWire"" USB devices is included for Microsoft Windows. It is the same support files as in the old Windows PTB 2.54. There isn't any support for ""MacOS-X"" or Linux, and probably there won't be any in the future due to complete lack of support from the manufacturer of ""ActiveWire"" for other operating systems.
//""PsychHID""// for control of USB HID devices is only implemented on Mac OS/X for now. The DAQ toolbox depends on ""PsychHID"", therefore it is unavailable as well on non OS/X systems. Porting ""PsychHID"" to Linux or Windows would not be difficult for an experienced C programmer, but this is not on anybodies todo list for now. //Volunteers?//
Support for ""ActiveWire"" USB devices is included for Microsoft Windows. It is the same support files as in the old Windows PTB 2.54. There isn't any support for ""MacOS-X"" or Linux, and probably there won't be any in the future due to complete lack of support from the manufacturer of ""ActiveWire"" for other operating systems.
Deletions:
~-**""Windows"":** The old Eyelink toolbox is not compatible with PTB-3 and the PTB-3 Eyelink toolbox is not yet available for Windows. However, one user reported a hack on the Psychtoolbox forum that allows to merge bits of the old Windows Eyelink toolbox into the PTB-3 Eyelink toolbox to create a useable hybrid. Search the forum for info.
//""PsychHID""// for control of USB HID devices is only implemented on Mac OS/X for now. The DAQ toolbox depends on ""PsychHID"", therefore it is unavailable as well. Porting ""PsychHID"" to Linux or Windows would not be difficult for an experienced C programmer, but this is not on anybodies todo list for now. //Volunteers?//
Support for ""ActiveWire"" USB devices is included for Microsoft Windows. It is the same support files as in the old Windows PTB 2.54. There isn't any support for ""MacOS-X"" or Linux, and probably there won't be any in the future.
Additions:
== ""ActiveWire"" ==
Support for ""ActiveWire"" USB devices is included for Microsoft Windows. It is the same support files as in the old Windows PTB 2.54. There isn't any support for ""MacOS-X"" or Linux, and probably there won't be any in the future.
KbName('UnifyKeyNames');
Priority(MaxPriority);
Support for ""ActiveWire"" USB devices is included for Microsoft Windows. It is the same support files as in the old Windows PTB 2.54. There isn't any support for ""MacOS-X"" or Linux, and probably there won't be any in the future.
KbName('UnifyKeyNames');
Priority(MaxPriority);
Deletions:
""Priority(MaxPriority);""
Additions:
== Psychserial, Joystick ==
== ""GamePad"" ==
The ""GamePad"" function depends on ""PsychHID"", therefore it is only available on Mac OS/X for now.
== ""GamePad"" ==
The ""GamePad"" function depends on ""PsychHID"", therefore it is only available on Mac OS/X for now.
Deletions:
Revision [264]
Edited on 2006-10-18 22:04:12 by DavidBrainard [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
=== [[http://psychtoolbox.org Psychtoolbox-3]] Differences between PTB-3 versions for OS/X, Windows and Linux ===
The implementations of Psychtoolbox-3 for Microsoft Windows and GNU/Linux are derived from the ""Mac OS/X"" implementation. They are incomplete derivates of the OS-X toolbox, which implement a subset of the OS-X features. We aim to have fully compatible implementations on all operating systems, but this is a //low priority, long term goal//, nothing to be achieved in the foreseeable future, and certainly not without the help of volunteers. The different operating systems also differ in their capabilities and limitations. You will have to take this into account if you want to write portable scripts. The following information should allow you to write scripts that are as portable as possible and to assess if PTB on a specific operating system is suitable for you.
- //""IsOSX""// returns 1 when the script is executed under Mac OS/X, 0 otherwise.
- //""AssertOSX""// aborts execution of your script if someone tries to execute it on a operating system other than Mac OS/X.
~-**""Mac OS/X"":** A functional beta quality implementation of the Eyelink toolbox is included in the Psychhardware folder of PTB. It is reported to work well, although it's not polished yet, e.g., the documentation is not yet updated and cleaned in all parts.
Sound output via the //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab implementation. Unfortunately, the only valid general statement that can be made about Matlab's current sound output function is "poor".
//""PsychHID""// for control of USB HID devices is only implemented on Mac OS/X for now. The DAQ toolbox depends on ""PsychHID"", therefore it is unavailable as well. Porting ""PsychHID"" to Linux or Windows would not be difficult for an experienced C programmer, but this is not on anybodies todo list for now. //Volunteers?//
The //Fonts// command for flexible query and handling of character fonts //only exists on Mac OS/X// with no plans to ever implement it on Windows or Linux.
~-**""Mac OS/X"":** The functions should work with all Matlab versions under OS/X 10.3.9 and later. They don't work at all in //matlab -nojvm// mode.
Usage, behaviour and timing of //""KbCheck"", ""KbWait""// and //""KbName""// should be identical / similar on all systems - no known relevant differences.
The mapping of keyboard scancodes to key names used to be different in the Psychtoolboxes for OS 9, OS/X, Windows and Linux. E.g., the left arrow cursor control key used to be named 'left' on Windows, ""'LeftArrow'"" on Mac OS/X and 'Left' on Linux. This is annoying if one wants to write portable scripts. When writing new code, you should add the command //""KbName('UnifyKeyNames');""// at the top of your script. This will make sure that KbName accepts and returns identical keynames on all operating system platforms, allowing you to write portable code without extra effort.
""KbName('UnifyKeyNames');""
No known relevant differences in behaviour or quality, tell us if you find some! "GetSecs" timestamps are accurate at sub-millisecond level on all systems.
Use the //""MaxPriority""// function to query maximum allowable priority levels for realtime scheduling (//help ""MaxPriority""//) in order to keep your code portable.
""Priority(MaxPriority);""
//""WaitSecs""// accepts values with microsecond precision. The robustness and accuracy of the //real waiting time// compared to the //requested waiting time// depends on the scheduling accuracy and timing jitter of the underlying operating system. My experience is that scheduling on a well configured Linux system or Mac OS/X Tiger system is very accurate and robust, whereas Microsoft Windows systems are //significantly worse// on many tasks.
~~-**""Mac OS/X"":** //Screen('Screens')// will return a vector with one numerical screen id for each connected display device, e.g., [0 1] for a dual-display system. Display 0 corresponds to the main display (the one with the Dock), Display 1 corresponds to the secondary display.
~~-**""Windows"":** If your system is switched to multi-monitor mode, //Screen('Screens')// will report //n+1// displays for a setup with //n// displays. The display with index zero is special: It corresponds to the display area of //all// connected displays. If you open an onscreen window on display zero, it will occupy all connected display devices. This is useful for presentation of stereo stimuli or other binocular stimuli. The screens with indices //1, 2, ..., n// correspond to the display areas of display devices //1, 2, ..., n//, so specifying these screen ids allows you to open onscreen windows on individual displays or to query and set properties of individual displays, e.g., refresh rate, resolution, color depth, size or the hardware color lookup tables. If you have an unusual display arrangement, you can also explicitely specify a //rect// argument to the //""Screen('OpenWindow', screenid, color, rect)""// command to create a window that occupies the specified //rect// on the desktop, partially covering multiple monitors.
~~-**""Mac OS/X"":** //""Screen('OpenWindow', screenid, color, rect)""// ignores the //rect// argument. All onscreen windows always cover the full area of a specific display device.,
~~-**""Mac OS/X"":** Screen tries to switch a display device to the requested color depth before opening an onscreen window on it. Psychtoolbox may work at a setting of 24 bpp or 16 bpp with reduced functionality, i.e., some alpha blending modes are not supported at a depth of 24 bpp and color resolution is drastically reduced at 16 bpp. Color index mode with 8 bpp is not supported on OS-X.
~~-**""Mac OS/X"":** All modes are supported with high performance.
~~-**""Windows"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of ""OpenGL"" AUX buffer support on Windows. All other modes (Anaglyph stereo, dual display stereo, free fusion) should work with high performance.
~~-**""Mac OS/X"":** Playback of audio-only files (e.g., mp3 or wav) is supported. Asynchronous loading of movies (without sound) is supported and known to work on fast machines.
~~-**""Mac OS/X"":** Apples ATSU text renderer is used. Provides very flexible, very high quality text rendering at a comparably low speed. Unicode character strings are supported. Text bounding boxes are highly accurate.
~~-**""Mac OS/X"":** On all ""PowerPC"" computers and probably on most Intel Macs, the timestamps are guaranteed to be sub-millisecond accurate, regardless of system load or scheduling jitter. Synchronization of stimulus onset to the vertical retrace is guaranteed to be microsecond accurate on properly working hardware.
~~-**""Windows"":** Accuracy of returned timestamps is limited by the timing accuracy of the underlying operating system. Will be millisecond accurate in most cases, but no guarantees can be made, because due to technical limitations of the Windows-OS, a less robust timing algorithm must be used. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
~~-**""Mac OS/X"":** OS/X supports up to 16 bit DAC precision on graphics hardware that supports this. CLUT animation works, but updates to the CLUTS can't be synchronized to Screen('Flip').
~~-**""Mac OS/X"":** The command returns lots of information about the host system, many of which seems to be pretty uninteresting for any practical purpose.
The implementations of Psychtoolbox-3 for Microsoft Windows and GNU/Linux are derived from the ""Mac OS/X"" implementation. They are incomplete derivates of the OS-X toolbox, which implement a subset of the OS-X features. We aim to have fully compatible implementations on all operating systems, but this is a //low priority, long term goal//, nothing to be achieved in the foreseeable future, and certainly not without the help of volunteers. The different operating systems also differ in their capabilities and limitations. You will have to take this into account if you want to write portable scripts. The following information should allow you to write scripts that are as portable as possible and to assess if PTB on a specific operating system is suitable for you.
- //""IsOSX""// returns 1 when the script is executed under Mac OS/X, 0 otherwise.
- //""AssertOSX""// aborts execution of your script if someone tries to execute it on a operating system other than Mac OS/X.
~-**""Mac OS/X"":** A functional beta quality implementation of the Eyelink toolbox is included in the Psychhardware folder of PTB. It is reported to work well, although it's not polished yet, e.g., the documentation is not yet updated and cleaned in all parts.
Sound output via the //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab implementation. Unfortunately, the only valid general statement that can be made about Matlab's current sound output function is "poor".
//""PsychHID""// for control of USB HID devices is only implemented on Mac OS/X for now. The DAQ toolbox depends on ""PsychHID"", therefore it is unavailable as well. Porting ""PsychHID"" to Linux or Windows would not be difficult for an experienced C programmer, but this is not on anybodies todo list for now. //Volunteers?//
The //Fonts// command for flexible query and handling of character fonts //only exists on Mac OS/X// with no plans to ever implement it on Windows or Linux.
~-**""Mac OS/X"":** The functions should work with all Matlab versions under OS/X 10.3.9 and later. They don't work at all in //matlab -nojvm// mode.
Usage, behaviour and timing of //""KbCheck"", ""KbWait""// and //""KbName""// should be identical / similar on all systems - no known relevant differences.
The mapping of keyboard scancodes to key names used to be different in the Psychtoolboxes for OS 9, OS/X, Windows and Linux. E.g., the left arrow cursor control key used to be named 'left' on Windows, ""'LeftArrow'"" on Mac OS/X and 'Left' on Linux. This is annoying if one wants to write portable scripts. When writing new code, you should add the command //""KbName('UnifyKeyNames');""// at the top of your script. This will make sure that KbName accepts and returns identical keynames on all operating system platforms, allowing you to write portable code without extra effort.
""KbName('UnifyKeyNames');""
No known relevant differences in behaviour or quality, tell us if you find some! "GetSecs" timestamps are accurate at sub-millisecond level on all systems.
Use the //""MaxPriority""// function to query maximum allowable priority levels for realtime scheduling (//help ""MaxPriority""//) in order to keep your code portable.
""Priority(MaxPriority);""
//""WaitSecs""// accepts values with microsecond precision. The robustness and accuracy of the //real waiting time// compared to the //requested waiting time// depends on the scheduling accuracy and timing jitter of the underlying operating system. My experience is that scheduling on a well configured Linux system or Mac OS/X Tiger system is very accurate and robust, whereas Microsoft Windows systems are //significantly worse// on many tasks.
~~-**""Mac OS/X"":** //Screen('Screens')// will return a vector with one numerical screen id for each connected display device, e.g., [0 1] for a dual-display system. Display 0 corresponds to the main display (the one with the Dock), Display 1 corresponds to the secondary display.
~~-**""Windows"":** If your system is switched to multi-monitor mode, //Screen('Screens')// will report //n+1// displays for a setup with //n// displays. The display with index zero is special: It corresponds to the display area of //all// connected displays. If you open an onscreen window on display zero, it will occupy all connected display devices. This is useful for presentation of stereo stimuli or other binocular stimuli. The screens with indices //1, 2, ..., n// correspond to the display areas of display devices //1, 2, ..., n//, so specifying these screen ids allows you to open onscreen windows on individual displays or to query and set properties of individual displays, e.g., refresh rate, resolution, color depth, size or the hardware color lookup tables. If you have an unusual display arrangement, you can also explicitely specify a //rect// argument to the //""Screen('OpenWindow', screenid, color, rect)""// command to create a window that occupies the specified //rect// on the desktop, partially covering multiple monitors.
~~-**""Mac OS/X"":** //""Screen('OpenWindow', screenid, color, rect)""// ignores the //rect// argument. All onscreen windows always cover the full area of a specific display device.,
~~-**""Mac OS/X"":** Screen tries to switch a display device to the requested color depth before opening an onscreen window on it. Psychtoolbox may work at a setting of 24 bpp or 16 bpp with reduced functionality, i.e., some alpha blending modes are not supported at a depth of 24 bpp and color resolution is drastically reduced at 16 bpp. Color index mode with 8 bpp is not supported on OS-X.
~~-**""Mac OS/X"":** All modes are supported with high performance.
~~-**""Windows"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and ""NVidia"" Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of ""OpenGL"" AUX buffer support on Windows. All other modes (Anaglyph stereo, dual display stereo, free fusion) should work with high performance.
~~-**""Mac OS/X"":** Playback of audio-only files (e.g., mp3 or wav) is supported. Asynchronous loading of movies (without sound) is supported and known to work on fast machines.
~~-**""Mac OS/X"":** Apples ATSU text renderer is used. Provides very flexible, very high quality text rendering at a comparably low speed. Unicode character strings are supported. Text bounding boxes are highly accurate.
~~-**""Mac OS/X"":** On all ""PowerPC"" computers and probably on most Intel Macs, the timestamps are guaranteed to be sub-millisecond accurate, regardless of system load or scheduling jitter. Synchronization of stimulus onset to the vertical retrace is guaranteed to be microsecond accurate on properly working hardware.
~~-**""Windows"":** Accuracy of returned timestamps is limited by the timing accuracy of the underlying operating system. Will be millisecond accurate in most cases, but no guarantees can be made, because due to technical limitations of the Windows-OS, a less robust timing algorithm must be used. Stimulus onset is microsecond accurate wrt. vertical retrace, as on Mac OS/X.
~~-**""Mac OS/X"":** OS/X supports up to 16 bit DAC precision on graphics hardware that supports this. CLUT animation works, but updates to the CLUTS can't be synchronized to Screen('Flip').
~~-**""Mac OS/X"":** The command returns lots of information about the host system, many of which seems to be pretty uninteresting for any practical purpose.
Deletions:
The implementations of Psychtoolbox-3 for Microsoft Windows and GNU/Linux are derived from the ""MacOS-X"" implementation. They are incomplete derivates of the OS-X toolbox, which implement a subset of the OS-X features. We aim to have fully compatible implementations on all operating systems, but this is a //low priority, long term goal//, nothing to be achieved in the foreseeable future, and certainly not without the help of volunteers. The different operating systems also differ in their capabilities and limitations. You will have to take this into account if you want to write portable scripts. The following information should allow you to write scripts that are as portable as possible and to assess if PTB on a specific operating system is suitable for you.
- //""IsOSX""// returns 1 when the script is executed under MacOS-X, 0 otherwise.
- //""AssertOSX""// aborts execution of your script if someone tries to execute it on a operating system other than MacOS-X.
~-**""MacOS-X"":** A functional beta quality implementation of the Eyelink toolbox is included in the Psychhardware folder of PTB. It is reported to work well, although it's not polished yet, e.g., the documentation is not yet updated and cleaned in all parts.
Sound output via the //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab implementation. Unfortunately, the only valid general statement that can be made about Matlabs current sound output function is "//**poor**//".
//""PsychHID""// for control of USB HID devices is only implemented on MacOS-X for now. The DAQ toolbox depends on ""PsychHID"", therefore it is unavailable as well. Porting ""PsychHID"" to Linux or Windows would not be difficult for an experienced C programmer, but this is not on anybodies todo list for now. //Volunteers?//
The //Fonts// command for flexible query and handling of character fonts //only exists on MacOS-X// with no plans to ever implement it on Windows or Linux.
~-**""MacOS-X"":** The functions should work with all Matlab versions under OS-X 10.3.9 and later. They don't work at all in //matlab -nojvm// mode.
Usage, behaviour and timing of //KbCheck, KbWait// and //KbName// should be identical / similar on all systems - no known relevant differences.
The mapping of keyboard scancodes to key names used to be different in the Psychtoolboxes for OS-9, OS-X, Windows and Linux. E.g., the left arrow cursor control key used to be named 'left' on Windows, 'LeftArrow' on MacOS-X and 'Left' on Linux. This is annoying if one wants to write portable scripts. When writing new code, you should add the command //KbName('UnifyKeyNames');// at the top of your script. This will make sure that KbName accepts and returns identical keynames on all operating system platforms, allowing you to write portable code without extra effort.
KbName('UnifyKeyNames');
No known relevant differences in behaviour or quality, tell us if you find some! GetSecs timestamps are accurate at sub-millisecond level on all systems.
Use the //MaxPriority// function to query maximum allowable priority levels for realtime scheduling (//help MaxPriority//) in order to keep your code portable.
Priority(MaxPriority);
//WaitSecs// accepts values with microsecond precision. The robustness and accuracy of the //real waiting time// compared to the //requested waiting time// depends on the scheduling accuracy and timing jitter of the underlying operating system. My experience is that scheduling on a well configured Linux system or MacOS-X Tiger system is very accurate and robust, whereas Microsoft Windows systems are //significantly worse// on many tasks.
~~-**""MacOS-X"":** //Screen('Screens')// will return a vector with one numerical screen id for each connected display device, e.g., [0 1] for a dual-display system. Display 0 corresponds to the main display (the one with the Dock), Display 1 corresponds to the secondary display.
~~-**""Windows"":** If your system is switched to multi-monitor mode, //Screen('Screens')// will report //n+1// displays for a setup with //n// displays. The display with index zero is special: It corresponds to the display area of //all// connected displays. If you open an onscreen window on display zero, it will occupy all connected display devices. This is useful for presentation of stereo stimuli or other binocular stimuli. The screens with indices //1, 2, ..., n// correspond to the display areas of display devices //1, 2, ..., n//, so specifying these screen ids allows you to open onscreen windows on individual displays or to query and set properties of individual displays, e.g., refresh rate, resolution, color depth, size or the hardware color lookup tables. If you have an unusual display arrangement, you can also explicitely specify a //rect// argument to the //Screen('OpenWindow', screenid, color, rect)// command to create a window that occupies the specified //rect// on the desktop, partially covering multiple monitors.
~~-**""MacOS-X"":** //Screen('OpenWindow', screenid, color, rect)// ignores the //rect// argument. All onscreen windows always cover the full area of a specific display device.,
~~-**""MacOS-X"":** Screen tries to switch a display device to the requested color depth before opening an onscreen window on it. Psychtoolbox may work at a setting of 24 bpp or 16 bpp with reduced functionality, i.e., some alpha blending modes are not supported at a depth of 24 bpp and color resolution is drastically reduced at 16 bpp. Color index mode with 8 bpp is not supported on OS-X.
~~-**""MacOS-X"":** All modes are supported with high performance.
~~-**""Windows"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and NVidia Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of OpenGL AUX buffer support on Windows. All other modes (Anaglyph stereo, dual display stereo, free fusion) should work with high performance.
~~-**""MacOS-X"":** Playback of audio-only files (e.g., mp3 or wav) is supported. Asynchronous loading of movies (without sound) is supported and known to work on fast machines.
~~-**""MacOS-X"":** Apples ATSU text renderer is used. Provides very flexible, very high quality text rendering at a comparably low speed. Unicode character strings are supported. Text bounding boxes are highly accurate.
~~-**""MacOS-X"":** On all PowerPC computers and probably on most IntelMacs, the timestamps are guaranteed to be sub-millisecond accurate, regardless of system load or scheduling jitter. Synchronization of stimulus onset to the vertical retrace is guaranteed to be microsecond accurate on properly working hardware.
~~-**""Windows"":** Accuracy of returned timestamps is limited by the timing accuracy of the underlying operating system. Will be millisecond accurate in most cases, but no guarantees can be made, because due to technical limitations of the Windows-OS, a less robust timing algorithm must be used. Stimulus onset is microsecond accurate wrt. vertical retrace, as on MacOS-X.
~~-**""MacOS-X"":** OS-X supports up to 16 bit DAC precision on graphics hardware that supports this. CLUT animation works, but updates to the CLUTS can't be synchronized to Screen('Flip').
~~-**""MacOS-X"":** The command returns lots of information about the host system, many of which seems to be pretty uninteresting for any practical purpose.
Revision [225]
Edited on 2006-10-15 22:17:32 by DavidBrainard [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
=== [[http://psychtoolbox.org Psychtoolbox-3]] Differences between PTB-3 versions for OS-X, Windows and Linux ===
Deletions:
Revision [183]
Edited on 2006-10-15 20:36:25 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
If you need to write scripts that have to behave differently on the different platforms, the following functions may be helpful:
- //""IsOSX""// returns 1 when the script is executed under MacOS-X, 0 otherwise.
- //""IsWin""// returns 1 when the script is executed under Microsoft Windows, 0 otherwise.
- //""IsLinux""// returns 1 when the script is executed under GNU/Linux, 0 otherwise.
- //""IsOctave""// returns 1 when the script is executed in GNU/Octave, 0 if the script is executed in Matlab.
- //""OSName""// returns the name of the operating system platform.
- //""AssertOpenGL""// aborts execution of your script if someone tries to execute it in PTB-2 instead of PTB-3.
- //""AssertOSX""// aborts execution of your script if someone tries to execute it on a operating system other than MacOS-X.
- //""AssertGLSL""// aborts execution of your script if it is executed on graphics hardware that does not support the ""OpenGL Shading language GLSL"".
- //""IsOSX""// returns 1 when the script is executed under MacOS-X, 0 otherwise.
- //""IsWin""// returns 1 when the script is executed under Microsoft Windows, 0 otherwise.
- //""IsLinux""// returns 1 when the script is executed under GNU/Linux, 0 otherwise.
- //""IsOctave""// returns 1 when the script is executed in GNU/Octave, 0 if the script is executed in Matlab.
- //""OSName""// returns the name of the operating system platform.
- //""AssertOpenGL""// aborts execution of your script if someone tries to execute it in PTB-2 instead of PTB-3.
- //""AssertOSX""// aborts execution of your script if someone tries to execute it on a operating system other than MacOS-X.
- //""AssertGLSL""// aborts execution of your script if it is executed on graphics hardware that does not support the ""OpenGL Shading language GLSL"".
Revision [182]
Edited on 2006-10-15 20:22:40 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
%%
% Add this at top of new scripts for maximum portability due to unified names on all systems:
KbName('UnifyKeyNames');
%%
%%
% Select maximum allowable realtime priority for current operating system:
Priority(MaxPriority);
%%
% Add this at top of new scripts for maximum portability due to unified names on all systems:
KbName('UnifyKeyNames');
%%
%%
% Select maximum allowable realtime priority for current operating system:
Priority(MaxPriority);
%%
Revision [181]
Edited on 2006-10-15 20:14:49 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
== Psychserial ==
Status unknown.
== Eyelink toolbox ==
~-**""MacOS-X"":** A functional beta quality implementation of the Eyelink toolbox is included in the Psychhardware folder of PTB. It is reported to work well, although it's not polished yet, e.g., the documentation is not yet updated and cleaned in all parts.
~-**""Windows"":** The old Eyelink toolbox is not compatible with PTB-3 and the PTB-3 Eyelink toolbox is not yet available for Windows. However, one user reported a hack on the Psychtoolbox forum that allows to merge bits of the old Windows Eyelink toolbox into the PTB-3 Eyelink toolbox to create a useable hybrid. Search the forum for info.
== Snd command for sound output ==
Sound output via the //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab implementation. Unfortunately, the only valid general statement that can be made about Matlabs current sound output function is "//**poor**//".
== ""OpenGL for Matlab support MOGL"" ==
Support for ""OpenGL"" low level commands in Matlab is identical for all systems. Well, almost: Support for specific functions depends on the capabilities of your graphics hardware and ""OpenGL"" implementation, so some of the most recent features of ""OpenGL"" may not be supported on old graphics hardware. The solution to this problem is simple: Upgrade your graphics drivers or your hardware.
Status unknown.
== Eyelink toolbox ==
~-**""MacOS-X"":** A functional beta quality implementation of the Eyelink toolbox is included in the Psychhardware folder of PTB. It is reported to work well, although it's not polished yet, e.g., the documentation is not yet updated and cleaned in all parts.
~-**""Windows"":** The old Eyelink toolbox is not compatible with PTB-3 and the PTB-3 Eyelink toolbox is not yet available for Windows. However, one user reported a hack on the Psychtoolbox forum that allows to merge bits of the old Windows Eyelink toolbox into the PTB-3 Eyelink toolbox to create a useable hybrid. Search the forum for info.
== Snd command for sound output ==
Sound output via the //Snd// command is currently implemented as a wrapper around the //sound// command of your Matlab installation, so its capabilities and timing accuracy are dependent on the Matlab implementation. Unfortunately, the only valid general statement that can be made about Matlabs current sound output function is "//**poor**//".
== ""OpenGL for Matlab support MOGL"" ==
Support for ""OpenGL"" low level commands in Matlab is identical for all systems. Well, almost: Support for specific functions depends on the capabilities of your graphics hardware and ""OpenGL"" implementation, so some of the most recent features of ""OpenGL"" may not be supported on old graphics hardware. The solution to this problem is simple: Upgrade your graphics drivers or your hardware.
Deletions:
todo.
Revision [180]
Edited on 2006-10-15 19:50:51 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
//""PsychHID""// for control of USB HID devices is only implemented on MacOS-X for now. The DAQ toolbox depends on ""PsychHID"", therefore it is unavailable as well. Porting ""PsychHID"" to Linux or Windows would not be difficult for an experienced C programmer, but this is not on anybodies todo list for now. //Volunteers?//
Deletions:
Revision [156]
Edited on 2006-10-14 01:36:01 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
----
===**//The information on this page is incomplete. It always refers to the state of the current beta flavor of PTB.//**===
----
== Matlab M-File functions ==
All functions that are implemented as Matlab M-Files should work without any differences between system platforms, as long as they don't depend on system dependent MEX files. M-Files are tested with the Matlab 7.x series. Most functions should work on older Matlab 6.x as well, but we do not test for or guarantee compatibility.
== Eyelink toolbox, moglcore, psychserial, sound ==
todo.
== ""PsychHID and the DAQ toolbox"" ==
//PsychHID// for control of USB HID devices is only implemented on MacOS-X for now. The DAQ toolbox depends on PsychHID, therefore it is unavailable as well. Porting PsychHID to Linux or Windows would not be difficult for an experienced C programmer, but this is not on anybodies todo list for now. //Volunteers?//
== Fonts ==
The //Fonts// command for flexible query and handling of character fonts //only exists on MacOS-X// with no plans to ever implement it on Windows or Linux.
== ""ListenChar, CharAvail, GetChar, FlushEvents"" ==
Functions for character input are implemented as a Java class via Matlabs built-in Java virtual machine (JVM). Usage on all platforms is identical, no known principal differences. Differences are due to differences in the implementation of the JVM in different versions of Matlab. We need JVM version 1.4.2 or later:
~-**""MacOS-X"":** The functions should work with all Matlab versions under OS-X 10.3.9 and later. They don't work at all in //matlab -nojvm// mode.
~-**""Windows"":** Should work with Matlab 7.0 and later, not on earlier Matlabs. In //matlab -nojvm// mode, a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info.
~-//Screen('Computer')// command:
~~-**""MacOS-X"":** The command returns lots of information about the host system, many of which seems to be pretty uninteresting for any practical purpose.
~~-**""Windows"":** Mostly unimplemented, reports only bare minimum.
===**//The information on this page is incomplete. It always refers to the state of the current beta flavor of PTB.//**===
----
== Matlab M-File functions ==
All functions that are implemented as Matlab M-Files should work without any differences between system platforms, as long as they don't depend on system dependent MEX files. M-Files are tested with the Matlab 7.x series. Most functions should work on older Matlab 6.x as well, but we do not test for or guarantee compatibility.
== Eyelink toolbox, moglcore, psychserial, sound ==
todo.
== ""PsychHID and the DAQ toolbox"" ==
//PsychHID// for control of USB HID devices is only implemented on MacOS-X for now. The DAQ toolbox depends on PsychHID, therefore it is unavailable as well. Porting PsychHID to Linux or Windows would not be difficult for an experienced C programmer, but this is not on anybodies todo list for now. //Volunteers?//
== Fonts ==
The //Fonts// command for flexible query and handling of character fonts //only exists on MacOS-X// with no plans to ever implement it on Windows or Linux.
== ""ListenChar, CharAvail, GetChar, FlushEvents"" ==
Functions for character input are implemented as a Java class via Matlabs built-in Java virtual machine (JVM). Usage on all platforms is identical, no known principal differences. Differences are due to differences in the implementation of the JVM in different versions of Matlab. We need JVM version 1.4.2 or later:
~-**""MacOS-X"":** The functions should work with all Matlab versions under OS-X 10.3.9 and later. They don't work at all in //matlab -nojvm// mode.
~-**""Windows"":** Should work with Matlab 7.0 and later, not on earlier Matlabs. In //matlab -nojvm// mode, a different implementation is used, which works but is more limited in its capabilities. Read //help ""GetChar""// and //help ""ListenChar""// for more info.
~-//Screen('Computer')// command:
~~-**""MacOS-X"":** The command returns lots of information about the host system, many of which seems to be pretty uninteresting for any practical purpose.
~~-**""Windows"":** Mostly unimplemented, reports only bare minimum.
Deletions:
Revision [155]
Edited on 2006-10-14 01:09:22 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
== ""KbCheck, KbWait, KbName"" ==
Usage, behaviour and timing of //KbCheck, KbWait// and //KbName// should be identical / similar on all systems - no known relevant differences.
The mapping of keyboard scancodes to key names used to be different in the Psychtoolboxes for OS-9, OS-X, Windows and Linux. E.g., the left arrow cursor control key used to be named 'left' on Windows, 'LeftArrow' on MacOS-X and 'Left' on Linux. This is annoying if one wants to write portable scripts. When writing new code, you should add the command //KbName('UnifyKeyNames');// at the top of your script. This will make sure that KbName accepts and returns identical keynames on all operating system platforms, allowing you to write portable code without extra effort.
== ""SetMouse, GetMouse, ShowCursor, HideCursor, GetSecs"" ==
No known relevant differences in behaviour or quality, tell us if you find some! GetSecs timestamps are accurate at sub-millisecond level on all systems.
== Priority and ""WaitSecs"" ==
The range of values accepted by the //Priority// command differs between OS-X, Windows and Linux. //Priority(0)// disables realtime scheduling on all operating systems.
Use the //MaxPriority// function to query maximum allowable priority levels for realtime scheduling (//help MaxPriority//) in order to keep your code portable.
//WaitSecs// accepts values with microsecond precision. The robustness and accuracy of the //real waiting time// compared to the //requested waiting time// depends on the scheduling accuracy and timing jitter of the underlying operating system. My experience is that scheduling on a well configured Linux system or MacOS-X Tiger system is very accurate and robust, whereas Microsoft Windows systems are //significantly worse// on many tasks.
Usage, behaviour and timing of //KbCheck, KbWait// and //KbName// should be identical / similar on all systems - no known relevant differences.
The mapping of keyboard scancodes to key names used to be different in the Psychtoolboxes for OS-9, OS-X, Windows and Linux. E.g., the left arrow cursor control key used to be named 'left' on Windows, 'LeftArrow' on MacOS-X and 'Left' on Linux. This is annoying if one wants to write portable scripts. When writing new code, you should add the command //KbName('UnifyKeyNames');// at the top of your script. This will make sure that KbName accepts and returns identical keynames on all operating system platforms, allowing you to write portable code without extra effort.
== ""SetMouse, GetMouse, ShowCursor, HideCursor, GetSecs"" ==
No known relevant differences in behaviour or quality, tell us if you find some! GetSecs timestamps are accurate at sub-millisecond level on all systems.
== Priority and ""WaitSecs"" ==
The range of values accepted by the //Priority// command differs between OS-X, Windows and Linux. //Priority(0)// disables realtime scheduling on all operating systems.
Use the //MaxPriority// function to query maximum allowable priority levels for realtime scheduling (//help MaxPriority//) in order to keep your code portable.
//WaitSecs// accepts values with microsecond precision. The robustness and accuracy of the //real waiting time// compared to the //requested waiting time// depends on the scheduling accuracy and timing jitter of the underlying operating system. My experience is that scheduling on a well configured Linux system or MacOS-X Tiger system is very accurate and robust, whereas Microsoft Windows systems are //significantly worse// on many tasks.
Revision [154]
Edited on 2006-10-14 00:40:49 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
The implementation of //Screen// is mostly identical on all systems, providing the same capabilities and performance on all operating systems. The following differences are known to exist. These differences are mostly unavoidable and therefore unfixable due to different designs and limitations in the underlying operating systems.
Deletions:
Revision [153]
Edited on 2006-10-14 00:37:40 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
~~-**""Windows"":** You can only play pure video or video+audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented. Non-blocking polling for video frames is not possible.
Deletions:
Revision [152]
Edited on 2006-10-14 00:31:18 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
~-Stimulus onset timestamps reported by //Screen('Flip')//:
~~-**""MacOS-X"":** On all PowerPC computers and probably on most IntelMacs, the timestamps are guaranteed to be sub-millisecond accurate, regardless of system load or scheduling jitter. Synchronization of stimulus onset to the vertical retrace is guaranteed to be microsecond accurate on properly working hardware.
~~-**""Windows"":** Accuracy of returned timestamps is limited by the timing accuracy of the underlying operating system. Will be millisecond accurate in most cases, but no guarantees can be made, because due to technical limitations of the Windows-OS, a less robust timing algorithm must be used. Stimulus onset is microsecond accurate wrt. vertical retrace, as on MacOS-X.
~-Color lookup tables, gamma tables, CLUT animation:
~~-**""MacOS-X"":** OS-X supports up to 16 bit DAC precision on graphics hardware that supports this. CLUT animation works, but updates to the CLUTS can't be synchronized to Screen('Flip').
~~-**""Windows"":** Windows supports up to 16 bit DAC precision on graphics hardware that supports this. CLUT animation is mostly impossible due to extreme brain-damage in the Windows CLUT implementation. Synchronization of CLUT updates to the execution of Screen('Flip') is possible.
~~-**""MacOS-X"":** On all PowerPC computers and probably on most IntelMacs, the timestamps are guaranteed to be sub-millisecond accurate, regardless of system load or scheduling jitter. Synchronization of stimulus onset to the vertical retrace is guaranteed to be microsecond accurate on properly working hardware.
~~-**""Windows"":** Accuracy of returned timestamps is limited by the timing accuracy of the underlying operating system. Will be millisecond accurate in most cases, but no guarantees can be made, because due to technical limitations of the Windows-OS, a less robust timing algorithm must be used. Stimulus onset is microsecond accurate wrt. vertical retrace, as on MacOS-X.
~-Color lookup tables, gamma tables, CLUT animation:
~~-**""MacOS-X"":** OS-X supports up to 16 bit DAC precision on graphics hardware that supports this. CLUT animation works, but updates to the CLUTS can't be synchronized to Screen('Flip').
~~-**""Windows"":** Windows supports up to 16 bit DAC precision on graphics hardware that supports this. CLUT animation is mostly impossible due to extreme brain-damage in the Windows CLUT implementation. Synchronization of CLUT updates to the execution of Screen('Flip') is possible.
Revision [151]
Edited on 2006-10-14 00:13:18 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
~~-**""Windows"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI ""FireGL"" and NVidia Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of OpenGL AUX buffer support on Windows. All other modes (Anaglyph stereo, dual display stereo, free fusion) should work with high performance.
~-Quicktime support for audio- and movie playback:
~~-**""MacOS-X"":** Playback of audio-only files (e.g., mp3 or wav) is supported. Asynchronous loading of movies (without sound) is supported and known to work on fast machines.
~~-**""Windows"":** You can only play pure video or video+audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented.
~-Drawtext and TextBounds functions for drawing text:
~~-**""MacOS-X"":** Apples ATSU text renderer is used. Provides very flexible, very high quality text rendering at a comparably low speed. Unicode character strings are supported. Text bounding boxes are highly accurate.
~~-**""Windows"":** A text renderer based on OpenGL display lists is used: Less flexible, slightly lower text quality (unless you choose the proper true type fonts), only the standard ASCII character set, but //much faster//. Computation of text bounding boxes doesn't take descenders of letters into account, due to some Microsoft implementation brain-damage.
~-Quicktime support for audio- and movie playback:
~~-**""MacOS-X"":** Playback of audio-only files (e.g., mp3 or wav) is supported. Asynchronous loading of movies (without sound) is supported and known to work on fast machines.
~~-**""Windows"":** You can only play pure video or video+audio files. Pure audio files will fail to play. Asynchronous movie loading is not implemented.
~-Drawtext and TextBounds functions for drawing text:
~~-**""MacOS-X"":** Apples ATSU text renderer is used. Provides very flexible, very high quality text rendering at a comparably low speed. Unicode character strings are supported. Text bounding boxes are highly accurate.
~~-**""Windows"":** A text renderer based on OpenGL display lists is used: Less flexible, slightly lower text quality (unless you choose the proper true type fonts), only the standard ASCII character set, but //much faster//. Computation of text bounding boxes doesn't take descenders of letters into account, due to some Microsoft implementation brain-damage.
Deletions:
Revision [150]
Edited on 2006-10-13 23:48:16 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
~~In any case, you have to run your displays at a color depth of 32 bits per pixel - which is the default setting - to take full advantage of Psychtoolbox alpha blending functions.
~-Stereo presentation modes //stereomode//:
~~-**""MacOS-X"":** All modes are supported with high performance.
~~-**""Windows"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI FireGL and NVidia Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of OpenGL AUX buffer support on Windows. All other modes should work with high performance.
~-Stereo presentation modes //stereomode//:
~~-**""MacOS-X"":** All modes are supported with high performance.
~~-**""Windows"":** Mode 1 //frame sequential stereo// for driving shutter glasses is unsupported on consumer hardware. The professional line of gfx-cards (ATI FireGL and NVidia Quadro series) should support this mode. Modes 2 and 3 //vertical compression stereo// are supported but at such a low performance to be unuseable for all practical purpose, due to very inefficient implementations of OpenGL AUX buffer support on Windows. All other modes should work with high performance.
Deletions:
Revision [149]
Edited on 2006-10-13 23:41:52 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
~-Color depth setting //pixelsize//:
~~-**""MacOS-X"":** Screen tries to switch a display device to the requested color depth before opening an onscreen window on it. Psychtoolbox may work at a setting of 24 bpp or 16 bpp with reduced functionality, i.e., some alpha blending modes are not supported at a depth of 24 bpp and color resolution is drastically reduced at 16 bpp. Color index mode with 8 bpp is not supported on OS-X.
~~-**""Windows"":** The color depth setting is ignored. You need to change the settings in the display properties control panel of your system. Any setting except the default of 32 bpp will cause abortion of your script with an error message.
In any case, you have to run your displays at a color depth of 32 bits per pixel - which is the default setting - to take full advantage of Psychtoolbox graphics functions.
~~-**""MacOS-X"":** Screen tries to switch a display device to the requested color depth before opening an onscreen window on it. Psychtoolbox may work at a setting of 24 bpp or 16 bpp with reduced functionality, i.e., some alpha blending modes are not supported at a depth of 24 bpp and color resolution is drastically reduced at 16 bpp. Color index mode with 8 bpp is not supported on OS-X.
~~-**""Windows"":** The color depth setting is ignored. You need to change the settings in the display properties control panel of your system. Any setting except the default of 32 bpp will cause abortion of your script with an error message.
In any case, you have to run your displays at a color depth of 32 bits per pixel - which is the default setting - to take full advantage of Psychtoolbox graphics functions.
Revision [148]
Edited on 2006-10-13 23:33:45 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
=== Status of different core features and how to handle differences: ===
== Screen ==
The implementation of //Screen// is mostly identical on all systems, providing the same capabilities and performance on all operating systems. The following known differences exist:
~-Multi display support: On single display setups, Screen behaves identically. On multi display setups, enumeration of displays is handled slightly different: ---
~~-**""MacOS-X"":** //Screen('Screens')// will return a vector with one numerical screen id for each connected display device, e.g., [0 1] for a dual-display system. Display 0 corresponds to the main display (the one with the Dock), Display 1 corresponds to the secondary display.
~~-**""Windows"":** If your system is switched to multi-monitor mode, //Screen('Screens')// will report //n+1// displays for a setup with //n// displays. The display with index zero is special: It corresponds to the display area of //all// connected displays. If you open an onscreen window on display zero, it will occupy all connected display devices. This is useful for presentation of stereo stimuli or other binocular stimuli. The screens with indices //1, 2, ..., n// correspond to the display areas of display devices //1, 2, ..., n//, so specifying these screen ids allows you to open onscreen windows on individual displays or to query and set properties of individual displays, e.g., refresh rate, resolution, color depth, size or the hardware color lookup tables. If you have an unusual display arrangement, you can also explicitely specify a //rect// argument to the //Screen('OpenWindow', screenid, color, rect)// command to create a window that occupies the specified //rect// on the desktop, partially covering multiple monitors.
~-Window placement and size:
~~-**""MacOS-X"":** //Screen('OpenWindow', screenid, color, rect)// ignores the //rect// argument. All onscreen windows always cover the full area of a specific display device.,
~~-**""Windows"":** Onscreen windows cover the full display area as on OS-X by default. If you provide a //rect// argument, Psychtoolbox will open a onscreen window that only covers the area specified by the //rect// parameter. E.g., //Screen('OpenWindow', 0, [], [0 0 800 600])// would open an onscreen window on display device zero, with its top-left corner at (0,0) and its bottom-right corner at (800,600). The window will have the usual decorations, title bar and buttons, so it can be closed, minimized/maximized, resized and dragged around on the screen. This is useful for debugging. You can also open multiple windows on the same display device.
== Screen ==
The implementation of //Screen// is mostly identical on all systems, providing the same capabilities and performance on all operating systems. The following known differences exist:
~-Multi display support: On single display setups, Screen behaves identically. On multi display setups, enumeration of displays is handled slightly different: ---
~~-**""MacOS-X"":** //Screen('Screens')// will return a vector with one numerical screen id for each connected display device, e.g., [0 1] for a dual-display system. Display 0 corresponds to the main display (the one with the Dock), Display 1 corresponds to the secondary display.
~~-**""Windows"":** If your system is switched to multi-monitor mode, //Screen('Screens')// will report //n+1// displays for a setup with //n// displays. The display with index zero is special: It corresponds to the display area of //all// connected displays. If you open an onscreen window on display zero, it will occupy all connected display devices. This is useful for presentation of stereo stimuli or other binocular stimuli. The screens with indices //1, 2, ..., n// correspond to the display areas of display devices //1, 2, ..., n//, so specifying these screen ids allows you to open onscreen windows on individual displays or to query and set properties of individual displays, e.g., refresh rate, resolution, color depth, size or the hardware color lookup tables. If you have an unusual display arrangement, you can also explicitely specify a //rect// argument to the //Screen('OpenWindow', screenid, color, rect)// command to create a window that occupies the specified //rect// on the desktop, partially covering multiple monitors.
~-Window placement and size:
~~-**""MacOS-X"":** //Screen('OpenWindow', screenid, color, rect)// ignores the //rect// argument. All onscreen windows always cover the full area of a specific display device.,
~~-**""Windows"":** Onscreen windows cover the full display area as on OS-X by default. If you provide a //rect// argument, Psychtoolbox will open a onscreen window that only covers the area specified by the //rect// parameter. E.g., //Screen('OpenWindow', 0, [], [0 0 800 600])// would open an onscreen window on display device zero, with its top-left corner at (0,0) and its bottom-right corner at (800,600). The window will have the usual decorations, title bar and buttons, so it can be closed, minimized/maximized, resized and dragged around on the screen. This is useful for debugging. You can also open multiple windows on the same display device.
Revision [147]
Edited on 2006-10-13 23:05:27 by MarioKleiner [Added double quotes to reduce WikiNames. MacOS-X -> Mac OS/X. Etc.]Additions:
==== Differences between PTB-3 versions for OS-X, Windows and Linux ====
The implementations of Psychtoolbox-3 for Microsoft Windows and GNU/Linux are derived from the ""MacOS-X"" implementation. They are incomplete derivates of the OS-X toolbox, which implement a subset of the OS-X features. We aim to have fully compatible implementations on all operating systems, but this is a //low priority, long term goal//, nothing to be achieved in the foreseeable future, and certainly not without the help of volunteers. The different operating systems also differ in their capabilities and limitations. You will have to take this into account if you want to write portable scripts. The following information should allow you to write scripts that are as portable as possible and to assess if PTB on a specific operating system is suitable for you.
**//The information on this page is incomplete. It always refers to the state of the current beta flavor of PTB.//**
The implementations of Psychtoolbox-3 for Microsoft Windows and GNU/Linux are derived from the ""MacOS-X"" implementation. They are incomplete derivates of the OS-X toolbox, which implement a subset of the OS-X features. We aim to have fully compatible implementations on all operating systems, but this is a //low priority, long term goal//, nothing to be achieved in the foreseeable future, and certainly not without the help of volunteers. The different operating systems also differ in their capabilities and limitations. You will have to take this into account if you want to write portable scripts. The following information should allow you to write scripts that are as portable as possible and to assess if PTB on a specific operating system is suitable for you.
**//The information on this page is incomplete. It always refers to the state of the current beta flavor of PTB.//**
