I seem to be having a problem with DrawText on one particular computer I
am using (but not the others). The problem is that text drawn to the
screen seems broken up and rather illegible. Changing the color of the
text does odd things, including drawing the text in multiple colors in
some instances. I will include a sample program, and I'll describe the
results. At the end of the message is the screentest report for the
problem computer.
The program is rather simple:
-----
% first we just define a simple CLUT
clut = zeros(256, 3);
BLACK_INDEX = 0;
RED_INDEX = 1;
GREEN_INDEX = 2;
BLUE_INDEX = 3;
WHITE_INDEX = 4;
clut(BLACK_INDEX + 1, :) = [0 0 0];
clut(RED_INDEX + 1, :) = [255 0 0];
clut(GREEN_INDEX + 1, :) = [0 255 0];
clut(BLUE_INDEX + 1, :) = [0 0 255];
clut(WHITE_INDEX + 1, :) = [255 255 255];
res=nearestresolution(0,1024,768,85,8); %the res. doesn't affect problem
[wp, rect] = SCREEN(0, 'OpenWindow', Bkcolor,[0 0 p.w p.h],res);
SCREEN(wp, 'SetClut', clut); % Set the CLUT (color look-up table)
% now draw text to screen and clear text after key is pressed
center = [rect(3) rect(4)]/2; % center of screen (pixel coordinates)
txt = 'PRESS ANY KEY TO BEGIN';
txtloc = [center(1) - length(txt) * 7 / 2, center(2) + 40];
[newX newY] = SCREEN(wp,'DrawText',txt,txtloc(1),txtloc(2),BLACK_INDEX);
kbwait;
keyIsDown = 1;
while(keyIsDown)
[keyIsDown,secs,keyCode] = KbCheck;
end
[newX newY] = SCREEN(wp,'DrawText',txt,txtloc(1),txtloc(2),Bkcolor);
kbwait;
SCREEN(wp,'Close');
-----
The result of this program? The text draws to the screen in red, but it
is broken and almost unintelligible. If we draw the text to the screen
using BLUE_INDEX instead of RED_INDEX, the parts of the text that were red
now appear blue, but the parts of the letters that were not drawn in red
before (they were black or missing) are now drawn in red or green. If the
text is drawn with GREEN_INDEX, the main parts of the letters are green,
and the fragments are red. If the text is drawn with WHITE_INDEX, the
main part of the text is drawn in white, but the fragmented parts are
mixed between red, blue and green.
In each case, the text is properly erased with the second call to DrawText
(using BLACK_INDEX), though this isn't necessarily the case in another
similar program I'm using.
Does anyone know what is going on?
Thanks for any help. The screentest report from the problem computer
follows.
keith
-----
****** daphne's PowerMac G3 Series/400, Mac OS 8.6 ******
PsychToolbox 2.42, 7 March 2000, MATLAB 5.2.1.1421
QuickTime 4.1
FileSharing is on.
Screen saver present, now disabled.
Using UpTime-based timing, which is very accurate and reliable.
G3, 400 MHz, memory bus 100 MHz, 49.966 Mflop/s
*** Screen 0 *************************************************************
ATY,Rage128y (.Display_Rage128 version 1.0f26) in slot J12
8 bit dacs. 1024x768 85 Hz. (56,60,65,67,70,72,75,85,90,100,120 Hz avail)
NOTE: DipPriorityAfterSetClut is true. Works around Rage128 driver bug.
NOTE: MinimumSetClutPriority is 2. Works around Rage128 driver bug.
pixel size 8 16 32 bits
pages 1 1 1
CopyWindow (ie CopyBits) 64 65 64 MB/s
GetClut equals SetClut? == na na
SetClutDriverWaitsForBlanking? Yes
At priority 7 ... No blanking intrpts.
SetClut (cscSetEntries) min dur. 0.1 0.1 0.1 frames
At priority 1 ... Blanking interrupts.
SetClut (cscSetEntries) min dur. 0.1 0.1 0.1 frames
SetClut suppresses ints. for 0.0 0.0 0.0 frames
**************************************************************************
am using (but not the others). The problem is that text drawn to the
screen seems broken up and rather illegible. Changing the color of the
text does odd things, including drawing the text in multiple colors in
some instances. I will include a sample program, and I'll describe the
results. At the end of the message is the screentest report for the
problem computer.
The program is rather simple:
-----
% first we just define a simple CLUT
clut = zeros(256, 3);
BLACK_INDEX = 0;
RED_INDEX = 1;
GREEN_INDEX = 2;
BLUE_INDEX = 3;
WHITE_INDEX = 4;
clut(BLACK_INDEX + 1, :) = [0 0 0];
clut(RED_INDEX + 1, :) = [255 0 0];
clut(GREEN_INDEX + 1, :) = [0 255 0];
clut(BLUE_INDEX + 1, :) = [0 0 255];
clut(WHITE_INDEX + 1, :) = [255 255 255];
res=nearestresolution(0,1024,768,85,8); %the res. doesn't affect problem
[wp, rect] = SCREEN(0, 'OpenWindow', Bkcolor,[0 0 p.w p.h],res);
SCREEN(wp, 'SetClut', clut); % Set the CLUT (color look-up table)
% now draw text to screen and clear text after key is pressed
center = [rect(3) rect(4)]/2; % center of screen (pixel coordinates)
txt = 'PRESS ANY KEY TO BEGIN';
txtloc = [center(1) - length(txt) * 7 / 2, center(2) + 40];
[newX newY] = SCREEN(wp,'DrawText',txt,txtloc(1),txtloc(2),BLACK_INDEX);
kbwait;
keyIsDown = 1;
while(keyIsDown)
[keyIsDown,secs,keyCode] = KbCheck;
end
[newX newY] = SCREEN(wp,'DrawText',txt,txtloc(1),txtloc(2),Bkcolor);
kbwait;
SCREEN(wp,'Close');
-----
The result of this program? The text draws to the screen in red, but it
is broken and almost unintelligible. If we draw the text to the screen
using BLUE_INDEX instead of RED_INDEX, the parts of the text that were red
now appear blue, but the parts of the letters that were not drawn in red
before (they were black or missing) are now drawn in red or green. If the
text is drawn with GREEN_INDEX, the main parts of the letters are green,
and the fragments are red. If the text is drawn with WHITE_INDEX, the
main part of the text is drawn in white, but the fragmented parts are
mixed between red, blue and green.
In each case, the text is properly erased with the second call to DrawText
(using BLACK_INDEX), though this isn't necessarily the case in another
similar program I'm using.
Does anyone know what is going on?
Thanks for any help. The screentest report from the problem computer
follows.
keith
-----
****** daphne's PowerMac G3 Series/400, Mac OS 8.6 ******
PsychToolbox 2.42, 7 March 2000, MATLAB 5.2.1.1421
QuickTime 4.1
FileSharing is on.
Screen saver present, now disabled.
Using UpTime-based timing, which is very accurate and reliable.
G3, 400 MHz, memory bus 100 MHz, 49.966 Mflop/s
*** Screen 0 *************************************************************
ATY,Rage128y (.Display_Rage128 version 1.0f26) in slot J12
8 bit dacs. 1024x768 85 Hz. (56,60,65,67,70,72,75,85,90,100,120 Hz avail)
NOTE: DipPriorityAfterSetClut is true. Works around Rage128 driver bug.
NOTE: MinimumSetClutPriority is 2. Works around Rage128 driver bug.
pixel size 8 16 32 bits
pages 1 1 1
CopyWindow (ie CopyBits) 64 65 64 MB/s
GetClut equals SetClut? == na na
SetClutDriverWaitsForBlanking? Yes
At priority 7 ... No blanking intrpts.
SetClut (cscSetEntries) min dur. 0.1 0.1 0.1 frames
At priority 1 ... Blanking interrupts.
SetClut (cscSetEntries) min dur. 0.1 0.1 0.1 frames
SetClut suppresses ints. for 0.0 0.0 0.0 frames
**************************************************************************