Revision [1674]
Last edited on 2011-04-28 05:02:19 by IanA [add info on 32bit kernel requirement for NVInject]Additions:
If you use Mac OS X 10.5 or 10.6 and NVIDIA graphics (this may also be necessary for newer ATI cards according to Mario), the Apple driver appears to permanently enable temporal dithering, which means that the T-Lock unlock code only gets recognised on 25% of frames. This behaviour is consistent with an 8-bit pixel that is temporally modulated via an 8/6 LUT to achieve 8-bit resolution on a 6-bit capable display (e.g. a laptop LCD screen). Trust us about this: we built a DVI logic analyser to capture the DVI output so we can see the raw digital pixel data.
To disable the temporal dithering feature, you need to install a third-party OS X kernel extension called "[[http://support.crsltd.com/FileManagement/Download/829619657b484700ab7e57de5b88a481 NVinject]]" which adds arbitrary keys into the OS X IORegistry at boot time, before the actual NVIDIA graphics driver starts. The driver accepts the keys when it starts and configures the graphics pipeline in the required way. **This requires a 32bit kernel**, newer Macs default to 64bit and you can swap between them using the information contained [[http://support.apple.com/kb/HT3773 in this Apple KB article]].
1. Download this //customised// version: "[[http://support.crsltd.com/FileManagement/Download/829619657b484700ab7e57de5b88a481 NVinject]]"
To disable the temporal dithering feature, you need to install a third-party OS X kernel extension called "[[http://support.crsltd.com/FileManagement/Download/829619657b484700ab7e57de5b88a481 NVinject]]" which adds arbitrary keys into the OS X IORegistry at boot time, before the actual NVIDIA graphics driver starts. The driver accepts the keys when it starts and configures the graphics pipeline in the required way. **This requires a 32bit kernel**, newer Macs default to 64bit and you can swap between them using the information contained [[http://support.apple.com/kb/HT3773 in this Apple KB article]].
1. Download this //customised// version: "[[http://support.crsltd.com/FileManagement/Download/829619657b484700ab7e57de5b88a481 NVinject]]"
Deletions:
To disable the temporal dithering feature, you need to install a third-party OS X kernel extension called "[[http://support.crsltd.com/FileManagement/Download/829619657b484700ab7e57de5b88a481 NVinject]]" which adds arbitrary keys into the OS X IORegistry at boot time, before the actual NVIDIA graphics driver starts. The driver accepts the keys when it starts and configures the graphics pipeline in the required way.
1. Download "[[http://support.crsltd.com/FileManagement/Download/829619657b484700ab7e57de5b88a481 NVinject]]"
Additions:
You may encounter the same problem on some modern ATI graphics cards under Microsoft Windows or Linux due to the same graphics driver bug. The Psychtoolbox function //""PsychGPUControl('SetDitheringEnabled', 0);""// should get rid of the problem.
Deletions:
Revision [1556]
Edited on 2009-12-06 00:20:33 by MarioKleiner [Update with new info and fix some bugs.]Additions:
If you try using the demos referred to in this article and have problems getting them to work as expected it could be because of the fact that some of the ""OpenGL"" functions used by Psychtoolbox do not run in a consistent way on different graphics cards, due to bugs in the different operating systems and vendor supplied graphics device drivers. I have listed all the problems we know about here. It is probably advisable to read this section before seriously attempting to write stimuli. Readers are welcome to contribute to this section if they discover other issues.
Sometimes you just need to reset everything. Unplug the the Bits""++"" and restart the computer. Then startup Matlab and run the ""LoadIdentityClut"".m script in the Bits""++"" demos. This will ensure that your graphics card doesn't interfere with the pixels passing through it by loading an identity gamma table into the graphics card. Now try running one of the Bits""++"" mode demos.
If you use calls to setup subfunctions in the ""PsychImaging"".m script, as recommended for all new stimulus presentation scripts, loading identity gamma tables and other setup steps will be performed automatically for you. See, e.g., ""BitsPlusCSFDemo"" for an example of setting up for Mono""++"" mode, ""AdditiveBlendingForLinearSuperpositionTutorial('Color++')"" as an example of setting up Color""++"" mode, or ""MinimumMotionExp"" for a full example experiment in Bits""++"" mode.
You are in the wrong mode. Only in Bits""++"" mode does the Bits""++"" use CLUTs. If you are in Colour""++"" mode or Mono""++"" mode CLUTs won't work. However, in Mono""++"" mode, CLUTs will be used to define the colors of the color overlay.
At some screen resolutions your secondary screen might not be properly lined up. Sometimes you can see some of it spilling over onto the primary screen. If the T-Lock code is being written to the top left corner of the secondary screen some of it may be missed out, and it might cause this problem. If you suspect that this is the case you could try drawing the T-Lock code to a different part of the screen. Look at the ""BitsPlusPlusEncodeClutRow"".m to see how to do this. This should not be a problem if you use calls to setup subfunctions in the ""PsychImaging"".m script, as recommended for all new stimulus presentation scripts, as this will try to automatically compensate for such variations.
One solution is to use 'nearest neighbour' mode. This effectively means that no interpolation occurs and the problem goes away.
A better solution, if you have used ""PsychImaging"" to setup your display, is to use the Screen('""LoadNormalizedGammaTable""', wptr, Clut, 2); function to assign a new Clut to the window wptr.
You may encounter the same problem on some modern ATI graphics cards under Microsoft Windows or Linux due to the same graphics driver bug. Future versions of Psychtoolbox will provide workarounds for Linux, but so far, there isn't any known solution for Microsoft Windows.
Some graphics cards don't implement the ""OpenGL"" AUX buffers mechanism.
Update to a recent version of the Psychtoolbox. As of November 2009, Psychtoolbox will work around the lack of AUX buffers, with a minimal decrease in performance.
If for some reason this isn't an option for you, you can try the following:
""BlueYellowTemporalGrating"".m draws the grating onto both back and front screens and then, when drawing the T-Lock code and CLUT, keeps flipping between the two. But it has to set the dontclear flag to 2 to avoid erasing the gratings.
Sometimes you just need to reset everything. Unplug the the Bits""++"" and restart the computer. Then startup Matlab and run the ""LoadIdentityClut"".m script in the Bits""++"" demos. This will ensure that your graphics card doesn't interfere with the pixels passing through it by loading an identity gamma table into the graphics card. Now try running one of the Bits""++"" mode demos.
If you use calls to setup subfunctions in the ""PsychImaging"".m script, as recommended for all new stimulus presentation scripts, loading identity gamma tables and other setup steps will be performed automatically for you. See, e.g., ""BitsPlusCSFDemo"" for an example of setting up for Mono""++"" mode, ""AdditiveBlendingForLinearSuperpositionTutorial('Color++')"" as an example of setting up Color""++"" mode, or ""MinimumMotionExp"" for a full example experiment in Bits""++"" mode.
You are in the wrong mode. Only in Bits""++"" mode does the Bits""++"" use CLUTs. If you are in Colour""++"" mode or Mono""++"" mode CLUTs won't work. However, in Mono""++"" mode, CLUTs will be used to define the colors of the color overlay.
At some screen resolutions your secondary screen might not be properly lined up. Sometimes you can see some of it spilling over onto the primary screen. If the T-Lock code is being written to the top left corner of the secondary screen some of it may be missed out, and it might cause this problem. If you suspect that this is the case you could try drawing the T-Lock code to a different part of the screen. Look at the ""BitsPlusPlusEncodeClutRow"".m to see how to do this. This should not be a problem if you use calls to setup subfunctions in the ""PsychImaging"".m script, as recommended for all new stimulus presentation scripts, as this will try to automatically compensate for such variations.
One solution is to use 'nearest neighbour' mode. This effectively means that no interpolation occurs and the problem goes away.
A better solution, if you have used ""PsychImaging"" to setup your display, is to use the Screen('""LoadNormalizedGammaTable""', wptr, Clut, 2); function to assign a new Clut to the window wptr.
You may encounter the same problem on some modern ATI graphics cards under Microsoft Windows or Linux due to the same graphics driver bug. Future versions of Psychtoolbox will provide workarounds for Linux, but so far, there isn't any known solution for Microsoft Windows.
Some graphics cards don't implement the ""OpenGL"" AUX buffers mechanism.
Update to a recent version of the Psychtoolbox. As of November 2009, Psychtoolbox will work around the lack of AUX buffers, with a minimal decrease in performance.
If for some reason this isn't an option for you, you can try the following:
""BlueYellowTemporalGrating"".m draws the grating onto both back and front screens and then, when drawing the T-Lock code and CLUT, keeps flipping between the two. But it has to set the dontclear flag to 2 to avoid erasing the gratings.
Deletions:
Sometimes you just need to reset everything. Unplug the the Bits""++"" and restart the computer. Then startup Matlab and run the ""LoadGammaTable"".m script in the Bits""++"" demos. This will ensure that your graphics card doesn't interfere with the pixels passing through it. Now try running one of the Bits""++"" mode demos.
You are in the wrong mode. Only in Bits""++"" mode does the Bits""++"" use CLUTs. If you are in Colour""++"" mode or Mono""++"" mode CLUTs won't work.
At some screen resolutions your secondary screen might not be properly lined up. Sometimes you can see some of it spilling over onto the primary screen. If the T-Lock code is being written to the top left corner of the secondary screen some of it may be missed out, and it might cause this problem. If you suspect that this is the case you could try drawing the T-Lock code to a different part of the screen. Look at the ""BitsPlusPlusEncodeClutRow"".m to see how to do this.
The solution is to use 'nearest neighbour' mode. This effectively means that no interpolation occurs and the problem goes away.
Some graphics cards implement ""OpenGL"" in a different way to others.
On most cards there is a double buffering system. This means that there are two areas of video memory used to represent the screen. At any one time one of these is on display (the front screen) and one is hidden (the back screen). You can quickly flip them over. This is so that images can be prepared in advance, without being seen, and then displayed all in one go. Typically, when doing computer animation, each frame is displayed on the front screen while the next frame is being prepared on the back screen.
So, when double buffering is enabled, Screen('""DrawTexture""',...) draws onto the back screen and Screen('Flip'...) displays what you have drawn by swapping the screens.
If you are doing palette animation you typically use the Screen('""DrawTexture""',...) function to quickly pass the Bits""++"" its new CLUT every frame. This means you keep flipping between back and front screens. So to make sure your stimulus is always visible you draw an identical copy of it onto both front and back screens and, in the Screen('Flip'...) function you set the parameter 'dontclear' to 1 to make sure that you don't erase them.
The trouble is, on card that don't support double buffering, you get this error.
Either switch to a graphics card that supports double buffering or try using a script that doesn't use double buffering.
""BlueYellowTemporalGrating"".m draws the grating onto both back and front screens and then, when drawing the T-Lock code and CLUT, keeps flipping between the two. But it has to set the dontclear flag to 1 to avoid erasing the gratings.
Additions:
You can also verify that the IORegistry has been changed using the Xcode [[http://developer.apple.com/mac/library/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/TheRegistry/TheRegistry.html I/O Registry Explorer tool]]:
To verify that your Bits""++"" is working correctly, load the Mono""++"" firmware and run the Psychtoolbox script [[http://docs.psychtoolbox.org/BitsPlusIdentityClutTest BitsPlusIdentityClutTest]]. This test script is distributed with [[http://tech.groups.yahoo.com/group/psychtoolbox/message/10197 Psychtoolbox-3 release 27.10.2009]] or later. If you are using an earlier version of PTB-3, run the [[http://psychtoolbox.org/wikka.php?wakka=PsychtoolboxDownload UpdatePsychtoolbox]] command at the MATLAB command prompt. This version is described in message 10197 posted to the Psychtoolbox forum and also contains a revised [[http://docs.psychtoolbox.org/LoadIdentityClut LoadIdentityClut]] implementation.
To verify that your Bits""++"" is working correctly, load the Mono""++"" firmware and run the Psychtoolbox script [[http://docs.psychtoolbox.org/BitsPlusIdentityClutTest BitsPlusIdentityClutTest]]. This test script is distributed with [[http://tech.groups.yahoo.com/group/psychtoolbox/message/10197 Psychtoolbox-3 release 27.10.2009]] or later. If you are using an earlier version of PTB-3, run the [[http://psychtoolbox.org/wikka.php?wakka=PsychtoolboxDownload UpdatePsychtoolbox]] command at the MATLAB command prompt. This version is described in message 10197 posted to the Psychtoolbox forum and also contains a revised [[http://docs.psychtoolbox.org/LoadIdentityClut LoadIdentityClut]] implementation.
Deletions:
To verify that your Bits""++"" is working correctly, load the Mono""++"" firmware and run the Psychtoolbox script [[http://docs.psychtoolbox.org/BitsPlusIdentityClutTest BitsPlusIdentityClutTest]]. This test script is distributed with [[http://tech.groups.yahoo.com/group/psychtoolbox/message/10197 Psychtoolbox-3 release 27.10.2009]] or later. If you are using an earlier version of PTB-3, run the UpdatePsychtoolbox command at the MATLAB command prompt. This version is described in message 10197 posted to the Psychtoolbox forum and also contains a revised [[http://docs.psychtoolbox.org/LoadIdentityClut LoadIdentityClut]] implementation.
Additions:
==Possible Solution 5==
If you use Mac OS X 10.5 or 10.6 and NVIDIA graphics, the Apple driver for NVIDIA graphics cards appears to permanently enable temporal dithering, which means that the T-Lock unlock code only gets recognised on 25% of frames. This behaviour is consistent with an 8-bit pixel that is temporally modulated via an 8/6 LUT to achieve 8-bit resolution on a 6-bit capable display (e.g. a laptop LCD screen). Trust us about this: we built a DVI logic analyser to capture the DVI output so we can see the raw digital pixel data.
To disable the temporal dithering feature, you need to install a third-party OS X kernel extension called "[[http://support.crsltd.com/FileManagement/Download/829619657b484700ab7e57de5b88a481 NVinject]]" which adds arbitrary keys into the OS X IORegistry at boot time, before the actual NVIDIA graphics driver starts. The driver accepts the keys when it starts and configures the graphics pipeline in the required way.
To install:
1. Download "[[http://support.crsltd.com/FileManagement/Download/829619657b484700ab7e57de5b88a481 NVinject]]"
2. In a terminal: sudo cp -R NVinject.kext /System/Library/Extensions/
3. Reboot.
4. The system console log will show some messages from it, reporting that it injected a AAPL00,Dither key and a AAPL01,Dither key, one for each display head:
{{image url="http://support.crsltd.com/FileManagement/Download/1ac7d37edb914bb2a526187dbbcc2ed4" title="OS X System Console" alt="OS X System Console"}}
The kernel extension is configured so that it doesn't get loaded on a safe-boot (hold down the shift key while starting up the computer). This means you always have an option to prevent the driver from loading if something should go wrong.
You can also verify that the IORegistry has been changed using the Xcode IORegistryExplorer tool:
{{image url="http://support.crsltd.com/FileManagement/Download/f15bc50ed3104cd98691e683aab84ae9" title="Xcode IORegistryExplorer" alt="Xcode IORegistryExplorer"}}
To verify that your Bits""++"" is working correctly, load the Mono""++"" firmware and run the Psychtoolbox script [[http://docs.psychtoolbox.org/BitsPlusIdentityClutTest BitsPlusIdentityClutTest]]. This test script is distributed with [[http://tech.groups.yahoo.com/group/psychtoolbox/message/10197 Psychtoolbox-3 release 27.10.2009]] or later. If you are using an earlier version of PTB-3, run the UpdatePsychtoolbox command at the MATLAB command prompt. This version is described in message 10197 posted to the Psychtoolbox forum and also contains a revised [[http://docs.psychtoolbox.org/LoadIdentityClut LoadIdentityClut]] implementation.
If you use Mac OS X 10.5 or 10.6 and NVIDIA graphics, the Apple driver for NVIDIA graphics cards appears to permanently enable temporal dithering, which means that the T-Lock unlock code only gets recognised on 25% of frames. This behaviour is consistent with an 8-bit pixel that is temporally modulated via an 8/6 LUT to achieve 8-bit resolution on a 6-bit capable display (e.g. a laptop LCD screen). Trust us about this: we built a DVI logic analyser to capture the DVI output so we can see the raw digital pixel data.
To disable the temporal dithering feature, you need to install a third-party OS X kernel extension called "[[http://support.crsltd.com/FileManagement/Download/829619657b484700ab7e57de5b88a481 NVinject]]" which adds arbitrary keys into the OS X IORegistry at boot time, before the actual NVIDIA graphics driver starts. The driver accepts the keys when it starts and configures the graphics pipeline in the required way.
To install:
1. Download "[[http://support.crsltd.com/FileManagement/Download/829619657b484700ab7e57de5b88a481 NVinject]]"
2. In a terminal: sudo cp -R NVinject.kext /System/Library/Extensions/
3. Reboot.
4. The system console log will show some messages from it, reporting that it injected a AAPL00,Dither key and a AAPL01,Dither key, one for each display head:
{{image url="http://support.crsltd.com/FileManagement/Download/1ac7d37edb914bb2a526187dbbcc2ed4" title="OS X System Console" alt="OS X System Console"}}
The kernel extension is configured so that it doesn't get loaded on a safe-boot (hold down the shift key while starting up the computer). This means you always have an option to prevent the driver from loading if something should go wrong.
You can also verify that the IORegistry has been changed using the Xcode IORegistryExplorer tool:
{{image url="http://support.crsltd.com/FileManagement/Download/f15bc50ed3104cd98691e683aab84ae9" title="Xcode IORegistryExplorer" alt="Xcode IORegistryExplorer"}}
To verify that your Bits""++"" is working correctly, load the Mono""++"" firmware and run the Psychtoolbox script [[http://docs.psychtoolbox.org/BitsPlusIdentityClutTest BitsPlusIdentityClutTest]]. This test script is distributed with [[http://tech.groups.yahoo.com/group/psychtoolbox/message/10197 Psychtoolbox-3 release 27.10.2009]] or later. If you are using an earlier version of PTB-3, run the UpdatePsychtoolbox command at the MATLAB command prompt. This version is described in message 10197 posted to the Psychtoolbox forum and also contains a revised [[http://docs.psychtoolbox.org/LoadIdentityClut LoadIdentityClut]] implementation.
Additions:
Sometimes you just need to reset everything. Unplug the the Bits""++"" and restart the computer. Then startup Matlab and run the ""LoadGammaTable"".m script in the Bits""++"" demos. This will ensure that your graphics card doesn't interfere with the pixels passing through it. Now try running one of the Bits""++"" mode demos.
Deletions:
Additions:
Sometimes you just need to reset everything. Unplug the the Bits""++"" and restart the computer. Then startup Matlab and run the LoadGammaTable.m script in the Bits""++"" demos. This will ensure that your graphics card doesn't interfere with the pixels passing through it. Now try running one of the Bits""++"" mode demos.
Deletions:
Additions:
Sometimes you just need to reset everything. Unplug the the Bits""++"" and restart the computer.
==Possible Solution 3==
==Possible Solution 4==
==Possible Solution 3==
==Possible Solution 4==
Deletions:
Additions:
In Bits""++"" mode, animated stimuli don't work. I just get a line of dancing pixels along the top of the screen.
Either switch to a graphics card that supports double buffering or try using a script that doesn't use double buffering.
Actually, I've already written alternative versions of the demo scripts that don't do a flip with the dontclear flag equal to 1. So you can try basing your script on one of these. Let's take, as an example, the demos called ""BlueYellowTemporalGrating"".m and ""BlueYellowTemporalGrating_NoDoubleBuffering"".m:
Both scripts display a grating on the screen and vary its contrast by re-loading a different CLUT to the Bits""++"" every frame. They use the Screen('""DrawTexture""'...) function both for drawing the grating and for drawing the T-Lock code and CLUT, because it is fast. The trouble is, as I've said, this command draws onto the back screen so you have to do a 'flip' afterwards to display what you've drawn.
""BlueYellowTemporalGrating"".m draws the grating onto both back and front screens and then, when drawing the T-Lock code and CLUT, keeps flipping between the two. But it has to set the dontclear flag to 1 to avoid erasing the gratings.
""BlueYellowTemporalGrating_NoDoubleBuffering"".m draws the grating onto just one screen but it draws it every frame. This is acceptably fast because it has already prepared the texture which represents the grating so it only has to call Screen('""DrawTexture""'...).
Either switch to a graphics card that supports double buffering or try using a script that doesn't use double buffering.
Actually, I've already written alternative versions of the demo scripts that don't do a flip with the dontclear flag equal to 1. So you can try basing your script on one of these. Let's take, as an example, the demos called ""BlueYellowTemporalGrating"".m and ""BlueYellowTemporalGrating_NoDoubleBuffering"".m:
Both scripts display a grating on the screen and vary its contrast by re-loading a different CLUT to the Bits""++"" every frame. They use the Screen('""DrawTexture""'...) function both for drawing the grating and for drawing the T-Lock code and CLUT, because it is fast. The trouble is, as I've said, this command draws onto the back screen so you have to do a 'flip' afterwards to display what you've drawn.
""BlueYellowTemporalGrating"".m draws the grating onto both back and front screens and then, when drawing the T-Lock code and CLUT, keeps flipping between the two. But it has to set the dontclear flag to 1 to avoid erasing the gratings.
""BlueYellowTemporalGrating_NoDoubleBuffering"".m draws the grating onto just one screen but it draws it every frame. This is acceptably fast because it has already prepared the texture which represents the grating so it only has to call Screen('""DrawTexture""'...).
Deletions:
Either switch to a graphics card that supports double buffering or re-write the stimulus script so that it doesn't use double buffering.
Additions:
You are in the wrong mode. Only in Bits""++"" mode does the Bits""++"" use CLUTs. If you are in Colour""++"" mode or Mono""++"" mode CLUTs won't work.
==Possible Solution 2==
== Possible Solution 3==
==Possible Solution 2==
== Possible Solution 3==
Deletions:
Additions:
If you are doing palette animation you typically use the Screen('""DrawTexture""',...) function to quickly pass the Bits""++"" its new CLUT every frame. This means you keep flipping between back and front screens. So to make sure your stimulus is always visible you draw an identical copy of it onto both front and back screens and, in the Screen('Flip'...) function you set the parameter 'dontclear' to 1 to make sure that you don't erase them.
The trouble is, on card that don't support double buffering, you get this error.
==Possible Solution==
Either switch to a graphics card that supports double buffering or re-write the stimulus script so that it doesn't use double buffering.
The trouble is, on card that don't support double buffering, you get this error.
==Possible Solution==
Either switch to a graphics card that supports double buffering or re-write the stimulus script so that it doesn't use double buffering.
Deletions:
Additions:
So, when double buffering is enabled, Screen('""DrawTexture""',...) draws onto the back screen and Screen('Flip'...) displays what you have drawn by swapping the screens.
Deletions:
Additions:
So, when double buffering is enabled, Screen('""DrawTexture""',...) draws onto the back screen and Screen('Flip'...) displays what you have drawn.
Deletions:
Additions:
On most cards there is a double buffering system. This means that there are two areas of video memory used to represent the screen. At any one time one of these is on display (the front screen) and one is hidden (the back screen). You can quickly flip them over. This is so that images can be prepared in advance, without being seen, and then displayed all in one go. Typically, when doing computer animation, each frame is displayed on the front screen while the next frame is being prepared on the back screen.
Deletions:
Additions:
Some graphics cards implement ""OpenGL"" in a different way to others.
Deletions:
Additions:
Some graphics cards implement OpenGL in a different way to others.
On most cards there is a double buffering system. This means that there are two areas of video memory used to represent the screen. At any one time one of these is on display - the front screen - and one is hidden - the back screen. You can quickly flip them over. This is so that images can be prepared in advance, without being seen, and then displayed all in one go. Typically, when doing computer animation, each frame is displayed on the front screen while the next frame is being prepared on the back screen.
When this happens, Screen('""DrawTexture""',...) draws onto the back screen and Screen('Flip'...) displays what you have drawn.
If you are doing palette animation you typically use the Screen('""DrawTexture""',...) function to quickly pass the Bits""++"" its new CLUT every frame. This means you keep flipping between back and front screens. So to make sure your stimulus is always visible you draw an identical copy of it onto both front and back screens.
On most cards there is a double buffering system. This means that there are two areas of video memory used to represent the screen. At any one time one of these is on display - the front screen - and one is hidden - the back screen. You can quickly flip them over. This is so that images can be prepared in advance, without being seen, and then displayed all in one go. Typically, when doing computer animation, each frame is displayed on the front screen while the next frame is being prepared on the back screen.
When this happens, Screen('""DrawTexture""',...) draws onto the back screen and Screen('Flip'...) displays what you have drawn.
If you are doing palette animation you typically use the Screen('""DrawTexture""',...) function to quickly pass the Bits""++"" its new CLUT every frame. This means you keep flipping between back and front screens. So to make sure your stimulus is always visible you draw an identical copy of it onto both front and back screens.
Additions:
""OpenGL"" AUX buffers unavailable! dontclear=1 in Screen-Flip doesn't work without them.
Either unsupported by your graphics card, or you disabled them via call to Screen('Preference', '""ConserveVRAM""')?//
Either unsupported by your graphics card, or you disabled them via call to Screen('Preference', '""ConserveVRAM""')?//
Deletions:
Either unsupported by your graphics card, or you disabled them via call to Screen('Preference', 'ConserveVRAM')?//
Additions:
In some stimulus scripts I get an error like this:
//Error in function Flip: Usage error
OpenGL AUX buffers unavailable! dontclear=1 in Screen-Flip doesn't work without them.
Either unsupported by your graphics card, or you disabled them via call to Screen('Preference', 'ConserveVRAM')?//
//Error in function Flip: Usage error
OpenGL AUX buffers unavailable! dontclear=1 in Screen-Flip doesn't work without them.
Either unsupported by your graphics card, or you disabled them via call to Screen('Preference', 'ConserveVRAM')?//
Additions:
The solution is to use 'nearest neighbour' mode. This effectively means that no interpolation occurs and the problem goes away.
Deletions:
Additions:
The Screen('""DrawTexture""'...) Psychtoolbox/""OpenGL"" function can be used to draw images to the screen and/or to change the Bits""++""'s CLUT by drawing the T-Lock code. As with most codes, changing the numbers even slightly will break it completely. This is in contrast to image data, where changing the value of one or two of the pixels very slightly will only change the colour of those pixels very slightly and probably won't even be noticed.
The Screen('""DrawTexture""'...) function is designed for drawing images to the screen and it can, if desired, reduce or enlarge those images before drawing them. When it does this it needs to do some interpolation or extrapolation when it reduces or increases the number of pixels in the image. You get a choice of two methods for this interpolation/extrapolation and they are set in the 'filterMode' parameter of the function. (Type Screen ""DrawTexture""? at the Matlab prompt to see this for yourself.) You can choose 'nearest neighbour' or 'bilinear' filtering. If you do not specify a mode, the default is 'bilinear'.
When using this function to draw the T-Lock code and CLUT, you obviously don't want to reduce or enlarge, so this should not be an issue. But, actually, in 'bilinear' mode, some residual interpolation does still sometimes occur, probably because of rounding errors in the ""OpenGL"". The result is that one or two of the pixels sometimes change their values by a very small amount. If this happens in an image it's not noticeable. But if it happens in the T-Lock code it breaks.
The Screen('""DrawTexture""'...) function is designed for drawing images to the screen and it can, if desired, reduce or enlarge those images before drawing them. When it does this it needs to do some interpolation or extrapolation when it reduces or increases the number of pixels in the image. You get a choice of two methods for this interpolation/extrapolation and they are set in the 'filterMode' parameter of the function. (Type Screen ""DrawTexture""? at the Matlab prompt to see this for yourself.) You can choose 'nearest neighbour' or 'bilinear' filtering. If you do not specify a mode, the default is 'bilinear'.
When using this function to draw the T-Lock code and CLUT, you obviously don't want to reduce or enlarge, so this should not be an issue. But, actually, in 'bilinear' mode, some residual interpolation does still sometimes occur, probably because of rounding errors in the ""OpenGL"". The result is that one or two of the pixels sometimes change their values by a very small amount. If this happens in an image it's not noticeable. But if it happens in the T-Lock code it breaks.
Deletions:
The Screen('""DrawTexture""'...) function is designed for drawing images to the screen and it can, if desired, reduce or enlarge those images before drawing them. When it does this it needs to do some interpolation or extrapolation when it reduces or increases the number of pixels in the image. You get a choice of two methods for this interpolation/extrapolation and they are set in the 'filterMode' parameter of the function. (Type Screen DrawTexture? at the Matlab prompt to see this for yourself.) You can choose 'nearest neighbour' or 'bilinear' filtering. If you do not specify a mode, the default is 'bilinear'.
When using this function to draw the T-Lock code and CLUT, you obviously don't want to reduce or enlarge, so this should not be an issue. But, actually, in 'bilinear' mode, some residual interpolation does still sometimes occur, probably because of rounding errors in the OpenGL. The result is that one or two of the pixels sometimes change their values by a very small amount. If this happens in an image it's not noticeable. But if it happens in the T-Lock code it breaks.
Additions:
In Bits""++"" mode, animated stimuli don't work. I just get a line of dancing pixels along the top of the screen
Deletions:
Additions:
==Problem==
In Bits""++"" mode, animated stimuli don't work. I just get a line of dancing pixels along the top of the screen==
==Explanation==
==Possible Solution 1==
At some screen resolutions your secondary screen might not be properly lined up. Sometimes you can see some of it spilling over onto the primary screen. If the T-Lock code is being written to the top left corner of the secondary screen some of it may be missed out, and it might cause this problem. If you suspect that this is the case you could try drawing the T-Lock code to a different part of the screen. Look at the ""BitsPlusPlusEncodeClutRow"".m to see how to do this.
== Possible Solution 2==
The Screen('""DrawTexture""'...) Psychtoolbox/OpenGL function can be used to draw images to the screen and/or to change the Bits""++""'s CLUT by drawing the T-Lock code. As with most codes, changing the numbers even slightly will break it completely. This is in contrast to image data, where changing the value of one or two of the pixels very slightly will only change the colour of those pixels very slightly and probably won't even be noticed.
In Bits""++"" mode, animated stimuli don't work. I just get a line of dancing pixels along the top of the screen==
==Explanation==
==Possible Solution 1==
At some screen resolutions your secondary screen might not be properly lined up. Sometimes you can see some of it spilling over onto the primary screen. If the T-Lock code is being written to the top left corner of the secondary screen some of it may be missed out, and it might cause this problem. If you suspect that this is the case you could try drawing the T-Lock code to a different part of the screen. Look at the ""BitsPlusPlusEncodeClutRow"".m to see how to do this.
== Possible Solution 2==
The Screen('""DrawTexture""'...) Psychtoolbox/OpenGL function can be used to draw images to the screen and/or to change the Bits""++""'s CLUT by drawing the T-Lock code. As with most codes, changing the numbers even slightly will break it completely. This is in contrast to image data, where changing the value of one or two of the pixels very slightly will only change the colour of those pixels very slightly and probably won't even be noticed.
Deletions:
~-At some screen resolutions your secondary screen might not be properly lined up. Sometimes you can see some of it spilling over onto the primary screen. If the T-Lock code is being written to the top left corner of the secondary screen some of it may be missed out, and it might cause this problem. If you suspect that this is the case you could try drawing the T-Lock code to a different part of the screen. Look at the ""BitsPlusPlusEncodeClutRow"".m to see how to do this.
~-The Screen('""DrawTexture""'...) Psychtoolbox/OpenGL function can be used to draw images to the screen and/or to change the Bits""++""'s CLUT by drawing the T-Lock code. As with most codes, changing the numbers even slightly will break it completely. This is in contrast to image data, where changing the value of one or two of the pixels very slightly will only change the colour of those pixels very slightly and probably won't even be noticed.
Additions:
~-The Screen('""DrawTexture""'...) Psychtoolbox/OpenGL function can be used to draw images to the screen and/or to change the Bits""++""'s CLUT by drawing the T-Lock code. As with most codes, changing the numbers even slightly will break it completely. This is in contrast to image data, where changing the value of one or two of the pixels very slightly will only change the colour of those pixels very slightly and probably won't even be noticed.
The Screen('""DrawTexture""'...) function is designed for drawing images to the screen and it can, if desired, reduce or enlarge those images before drawing them. When it does this it needs to do some interpolation or extrapolation when it reduces or increases the number of pixels in the image. You get a choice of two methods for this interpolation/extrapolation and they are set in the 'filterMode' parameter of the function. (Type Screen DrawTexture? at the Matlab prompt to see this for yourself.) You can choose 'nearest neighbour' or 'bilinear' filtering. If you do not specify a mode, the default is 'bilinear'.
When using this function to draw the T-Lock code and CLUT, you obviously don't want to reduce or enlarge, so this should not be an issue. But, actually, in 'bilinear' mode, some residual interpolation does still sometimes occur, probably because of rounding errors in the OpenGL. The result is that one or two of the pixels sometimes change their values by a very small amount. If this happens in an image it's not noticeable. But if it happens in the T-Lock code it breaks.
The solution is to use 'nearest neighbour' mode. This is effectively means that no interpolation occurs and problem goes away.
The Screen('""DrawTexture""'...) function is designed for drawing images to the screen and it can, if desired, reduce or enlarge those images before drawing them. When it does this it needs to do some interpolation or extrapolation when it reduces or increases the number of pixels in the image. You get a choice of two methods for this interpolation/extrapolation and they are set in the 'filterMode' parameter of the function. (Type Screen DrawTexture? at the Matlab prompt to see this for yourself.) You can choose 'nearest neighbour' or 'bilinear' filtering. If you do not specify a mode, the default is 'bilinear'.
When using this function to draw the T-Lock code and CLUT, you obviously don't want to reduce or enlarge, so this should not be an issue. But, actually, in 'bilinear' mode, some residual interpolation does still sometimes occur, probably because of rounding errors in the OpenGL. The result is that one or two of the pixels sometimes change their values by a very small amount. If this happens in an image it's not noticeable. But if it happens in the T-Lock code it breaks.
The solution is to use 'nearest neighbour' mode. This is effectively means that no interpolation occurs and problem goes away.
Additions:
~-At some screen resolutions your secondary screen might not be properly lined up. Sometimes you can see some of it spilling over onto the primary screen. If the T-Lock code is being written to the top left corner of the secondary screen some of it may be missed out, and it might cause this problem. If you suspect that this is the case you could try drawing the T-Lock code to a different part of the screen. Look at the ""BitsPlusPlusEncodeClutRow"".m to see how to do this.
Deletions:
Additions:
This means that the T-Lock code has not been recognised. The line of pixels you see is the T-Lock code followed by the CLUT which is supposed to be loaded into the Bits""++"". If the T-Lock code //were// being properly recognised by the Bits""++"" it would know that this line is not supposed to be displayed, but should be used to set its CLUT.
~-At some screen resolutions your secondary screen might not be properly lined up. Sometimes you can see some of it spilling over onto the primary screen. If the T-Lock code is being written to the top left corner of the secondary screen some of it may be missed out, and it might cause this problem. If you suspect that this is the case you could try drawing the T-Lock code to a different part of the screen. Look at the BitsPlusPlusEncodeClutRow.m to see how to do this.
~-At some screen resolutions your secondary screen might not be properly lined up. Sometimes you can see some of it spilling over onto the primary screen. If the T-Lock code is being written to the top left corner of the secondary screen some of it may be missed out, and it might cause this problem. If you suspect that this is the case you could try drawing the T-Lock code to a different part of the screen. Look at the BitsPlusPlusEncodeClutRow.m to see how to do this.
Deletions:
Additions:
==In Bits""++"" mode, animated stimuli don't work. I just get a line of dancing pixels along the top of the screen==
Deletions:
In Bits""++"" mode, animated stimuli don't work. I just get a line of dancing pixels along the top of the screen;
no;
no;
###"}}
Additions:
{{table columns="2" cellpadding="1" cells="Problem;Explanation;
In Bits""++"" mode, animated stimuli don't work. I just get a line of dancing pixels along the top of the screen;
This means that the T-Lock code has not been recognised.;
no;
no;
###"}}
In Bits""++"" mode, animated stimuli don't work. I just get a line of dancing pixels along the top of the screen;
This means that the T-Lock code has not been recognised.;
no;
no;
###"}}
Additions:
<<@@**[[BitsPlusPlusTLockProblems Making T-Lock Work < Previous Section]]**@@<<>>@@**[[BitsPlusPlusListOfDemos Next Section > List and Explanation of the Demos]]**@@>>
Additions:
If you try using the demos referred to in this article and have problems getting them to work as expected it could be because of the fact that some of the ""OpenGL"" functions implemented in Psychtoolbox do not run in a consistent way on different graphics cards. I have listed all the problems we know about here. It is probably advisable to read this section before seriously attempting to write stimuli. Readers are welcome to contribute to this section if they discover other issues.
Deletions:
Additions:
===Variations in ""OpenGL"" Functionality===
==Introduction==
If you try using the demos referred to in this article and have problems getting them to work as expected it could be because of the fact that some of the OpenGL functions implemented in Psychtoolbox do not run in a consistent way on different graphics cards. I have listed all the problems we know about here. It is probably advisable to read this section before seriously attempting to write stimuli. Readers are welcome to contribute to this section if they discover other issues.
==Introduction==
If you try using the demos referred to in this article and have problems getting them to work as expected it could be because of the fact that some of the OpenGL functions implemented in Psychtoolbox do not run in a consistent way on different graphics cards. I have listed all the problems we know about here. It is probably advisable to read this section before seriously attempting to write stimuli. Readers are welcome to contribute to this section if they discover other issues.
Deletions:
TODO