Thanks to ThVortex and gravypod for helping track down my bug that was causing an intollerable strobe effect.
This a release is ONLY the White-Text-Fix, no formatting/styling fixes, no optimizations, minimal testing.
This is marked as an alpha (a) release since it has not been tested against a full set of test cases and contains only a subset of the 'standard' features.
β release contains most of the standard features, but has not been fully tested.
Unicode glyph widths (for strings) are now calculated correctly, instead of with the default pattern (Order of Operation, my ass).
Coloured text widths (when mixed with bold) are now calculated correctly, instead of the default interpretation.
Should work with Optifine {1.2.4, 1.2.5} HD {A, A2, A3, A4, A5} and vanilla {1.2.4 and 1.2.5}.
nl.class for Optifine HD A3 1.2.5 HD Fonts test case (Docm77s Texture Pack 1.2.4)
Stretched. Spaces reduced to normal. Characters stretched to original's width and layered with self. Thin centered strokes remain thin.
Tight. Spaces reduced to normal. Characters offset by a single (normalized) pixel.
Default Bold text, normal size.
Original. Spaces expanded. Characters shifted one stroke width, running strokes together into blobs.
Stretched. Spaces reduced to normal. Characters stretched to original's width. Strokes appear to be an inconsistent width.
Stretched w/ layer. Spaces reduced to normal. Characters stretches to original's width and layered w/ self.
Default Bold text, small size.
Original. Spaces expanded. Characters shifted one stroke width, running strokes together into blobs.
stretch w/ layer 0.5. Spaces reduced to normal. Characters stretches to original's width and layered w/ self at .5 (normalized) px offset. Strokes appear to be an inconsistent width, Center strokes particularly are thin.
Stretch w/ layer 0.7. Spaces reduced to normal. Characters stretches to original's width and layered w/ self at .7 (normalized) px offset. Strokes appear to be an inconsistent width. Center strokes run into leading strokes.
Spoutcraft!
Spoutcraft (#124 from this thread) will have some version of color text fix. Currently there are a few versions being tested that take different approaches to the problem.
With instruction form Top_Cat and a last minute bug-fix from zml2008 I've managed to kludge mine into a pull request with mine as a toggleable option, but it will take time for these options to be tested and compared.
BTW,
Description
In a nutshell;
This is an awful-awful kludge for those of us using older computers that don't fully support OpenGL(1.1), and renders all text as white.
Vanilla minecraft seems to render most text white, while the background shadows are the correct colours.
Series A (discontinued)
renders text in the correct color without shadows.
While this improves readibility for chat and other blocks of text, it reduces it for text rendered ontop of buttons, icons and menu bars.
There is also a problem where in certain contexts the text will still be forced to white, even without shadows.
Series B sets text colour using RGB instead of RGBA namespace. This avoids a bug that causes the colour values to be clamed to full (white). This allows for both the shadow and foreground text to be rendered in the correct colour by sacrificing Alpha-transparent/fading text.
Overall this improves readability, with the exception of Black(0) which renders as black on black text afterwards. I have yet to encounter a situation where the text is rendered in the incorrect colour, however I do not spend time on many servers. On my machine If the color4f is invoked enough times it appears to overflow the colour stack, then all colours above an unknown limit are treated as pure white. I have not yet determined how to prevent or correct this.
Screenshots
nl.class for Vanilla 1.2.5 prerelease New testing protocol, including more and better testcases! (not all test cases shown)
Click on the "Setup" button, were we to click "Test" afterwards this would lead to the familiar crash report screen.
This is the important step! Click on the "Advanced" tab, then enter 800 for memory (equivalent to -Xmx800m).
Clicking "Test" will now lead to a better out come.
Now return to the "Mods" tab, and "Add" the mods you have downloaded.
Make certain that the mods are in the correct order to be applied;
n[x]_meow[...]must be after OptiFine to work, otherwise OptiFine will override it.
If you have altered your minecraft.jar file earlier, you should see a few warning labels.
In theory you could return to the main screen, click "Options" then "Force Update" but...
Instead if you have made a backup before changing that file, you can click the "Select" button from the "Settings" window to use that backup.
Now everything should be Okay.
(Even with those warnings it will keep working if it worked before).
Details (irrelevant)
After noticing that the shadows of the text were being rendered in the correct colour I started looking at the fontRenderer class of b1.1.0 and a1.8.1. It appeared that some thing was suppressing the colour information from being used in the second pass that renders the foreground layer of text.
After a couple hours teaching myself staring dumbly at openGL and Javabyte code- tracing the is_shadow flag, etc.- decided 'meow to this' and did the quick and dirty thing and deleted the shadow pass in the drawStringWithShadow function.
The results were less than ideal; I'd consciously traded one bug for another, and others still didn't have colour on their servers. After trying --
pushing the original string onto the stack and calling drawString directly from drawStringWithShadow (like a1.8.1 did)
Reinitilizing bidi before the second call
transcoding other private functions (unmodified) into the drawStringWithShadow
I called it good enough, and went to eat.
After learning more about the colour stack, and the daunting variety of hack/workarounds needed to accommodate bugs specific to Intel, AMD/ATI, Nvidia, etc... And failing to find an economical way to correct the {texture and colour} {blending and alpha} modes going crazy after using color4f too many times (specific implementation of GL1.1 not preserving original conditions!?), gave in again and traded one bug for another.
Replacing all calls to color4f with color3f causes the text to always be drawn fully opaque in the correct colour. However this breaks alpha-transparent/fading text effects, and makes colour 0 (black text with black shadow) difficult to read.
The specific behaviour demonstrated is like (opengl.org)glLogicOp(GL_SET), but there is no clear cause for this to change when invoking glColor4f twice. Then again given Intel's reputation in this regard...
Code
As requested, these are the code changes used in 1.2.3
renderDefaultChar micro-optimization, reduction from 199 to 185 bytes.
drawStringWithShadow white text fix, replacement of drawString (and color4f) with color3f. micro-optimization, reduction from 270 (38+(116x2)) to 165 bytes.
I am aware that this still calculates an alpha value that isn't used.
public void drawStringWithShadow(String s, int i, int j, int k)
{
if (bidiFlag)
{
s = bidiReorder(s);
}
*/renderString(s, i + 1, j + 1, k, true);
renderString(s, i, j, k, false);*/
if (s != null)
{
boundTextureName = 0;
/*if ((k & 0xfc000000) == 0)
{
k |= 0xff000000;
}*/
//if (flag) //True=Shadow, False=Foreground
//{
// k = (k & 0xfcfcfc) >> 2 | k & 0xff000000;
//}
int k2 = (k & 0xfcfcfc) >> 2 /*| k & 0xff000000*/;
GL11.glColor3f((float)(k2 >> 16 & 0xff) / 255F, (float)(k2 >> 8 & 0xff) / 255F, (float)(k2 & 0xff) / 255F/*, (float)(k2 >> 24 & 0xff) / 255F*/);
posX = i + 1;
posY = j + 1;
renderStringAtPos(s, true);
GL11.glColor3f((float)(k >> 16 & 0xff) / 255F, (float)(k >> 8 & 0xff) / 255F, (float)(k & 0xff) / 255F /*, (float)(k >> 24 & 0xff) / 255F*/ );
posX = i;
posY = j;
renderStringAtPos(s, false);
}
}
getStringWidth ThVortex's unicode string centering fix, "This fixes the centering of the new Unicode font inside buttons."
public int getStringWidth(String s)
{
if (s == null)
{
return 0;
}
int i = 0;
for (int j = 0; j < s.length(); j++)
{
char c = s.charAt(j);
if (c == '\247')
{
j++;
continue;
}
if (c == ' ')
{
i += 8F;
continue;
}
int k = ChatAllowedCharacters.allowedCharacters.indexOf(c);
if (k >= 0 && !unicodeFlag)
{
//i += charWidth[k + 32];
i += charWidth[k + 32] << 1;
continue;
}
if (glyphWidth[c] == 0)
{
continue;
}
int l = glyphWidth[c] >> 4;
int i1 = glyphWidth[c] & 0xf;
/*if (i1 > 7)
{
i1 = 15;
l = 0;
}*/
i1++;
//i += (i1 - l) / 2 + 1;
i += (i1 - l) + 2;
}
//return i;
return i >> 1;
}
Future
Series A has been discontinued now that I am sufficiently competent with Java Bytecode to go strait into series B without decompiling anything.
Series B will focus on functionality, and will implement fixes from other programmers/authors as they become availble.
Series C will attempt to restore alpha-transparancy without regard for preformance.
Incremental compatibility updates for Optifine until obsoleted.
Performance optimizations for vanilla (Optifine will still be more effecive overall, but this is an exercise for my own understanding.)
Implementation of other fixes as provided and explained by other developers.
Addendum
Those of you who are getting black screens;
To help me fix this problem would you please post the following:
What version of sp614x's Optifine you are using. (minecraftforum.net)
What series and target fix are you using (A/B - A,C,D,etc.)
Your Graphics Adapter/GPU (ATI, Intel, Nvidia, etc.)
Re: forum keywords as parameters
To make certain that the problems I have been having was not a result of my invalid BBcode formatting I whipped up a quick 'user defined language' definition in notepad++ and noticed a really stupid bug in my attempt that very closely matches the behaviour seen here on the forum.
Where a particular parameter contains a keyword separated an operator (ie:"www.opengl.org/sdk/docs/man/xhtml/glLogicOp.xml") n++ would misread this as an level-opening and would invalidate the coding.
Similarly the forum software would erroneously assume that I [was mistaken in my usage of] the BBcode and deletes it. Then finding that the rest of tags aren't paired now inserts other tags out of context until they are. Then finding that nested elements are now not encapsulated correctly by other tags deletes, that too. Consequently the coding that is invalidated by this...
So I've used my bugged UDL to weed out possible triggers for this problem.
It remains to be seen if this is sufficent to solve the problem.
It seems to be, except for nested lists which seem to unravel into extra lists when opening to edit, and other containers that seem to break apart.
I do not appreciate having my formatting corrupted by "autocorrection." I am relying on the BBcode I am using staying the way I set it-
I should never have to thank anyone for not [j] [screwing] [j/] that up for me.
(Sep 7, 2012) List tags are malformed.
(June 15, 2019) Formatting adjusted for site archiving. Spelling changes highlighted in red.
Well, for players like myself who do not have the means to obtain computers that aren't pants at rendering graphics- coloured chat on servers is difficult to follow. Colour carries allot of information such as a player's rank, and also provides an immeadiate indication/seperation of messages needing attention.
And the idea that a player would need to get a better machine for no functional reason is preposterous.
Unless you mean the missing text shadows; those provide immeadiate contrast around letters making them easier to read.
This is also a bit buggy and Optifine MQ.class doesn't work. [...]
And this barely helps me.
I know that what I have posted is buggy it trades one bug for another less annoying one- which is arguably still an improvement.
As for Optifine;
I derived the linked to mq.class directly from OptiFine HD A4 Standard for Minecraft 1.1, I appologise if you are using Smooth, Multi-Core or AA edition(s) as I do not intend to create specific versions for those until I have the second-pass-inhibit problem licked, and strongly suspect that sp614x will figure post a better solution before I can anyways...
I know that what I have posted is buggy it trades one bug for another less annoying one- which is arguably still an improvement.
As for Optifine;
I derived the linked to mq.class directly from OptiFine HD A4 Standard for Minecraft 1.1, I appologise if you are using Smooth, Multi-Core or AA edition(s) as I do not intend to create specific versions for those until I have the second-pass-inhibit problem licked, and strongly suspect that sp614x will figure post a better solution before I can anyways...
I assumed that people would know to do this, and I know better than to have done so.
I therefore offer my appologies for having caused you such distress to warrant a reply in bold red text.
Here!
Sure, I'll need a few things
I will require screenshots from your fellow players on that server.
Binary access to the exact combination mods installed on that server, and the configuration there to.
Unobstificated source code for all plugins, mods and scripts involved.
Also a box of doughnuts wouldn't hurt.
You pointed out my mistake; credit where credit is due. :smile.gif:
+ I did have Optifine Standard
Notice how was appointed to be yellow while it was still white.
And [Helper] was actually a post to be like a baby blue color, but again white.
And the [User] was apposed to be grey, but u can see some of the players rank title was white.
Here are a few plugins I know from the server /w colors:
Essentials Group Manager
AuthMe
/./ Also note that this is a public server so I can't get all of the info from it...
prefix: '[Admin]' : Produces a simple <[Admin]User>
prefix: '&e[VIP]&f' : Produces a coloured <[VIP]User>
But I would need to be able to play with the server config files and have coloured screenshots from players not using my 'fix' to really know. Best leave it alone for now.
But I would need to be able to play with the server config files and have coloured screenshots from players not using my 'fix' to really know. Best leave it alone for now.
I'm partial to iced cherry jelly.
I do know that he has made the prefixes like that. And I would also know that because my varibles on my server are just like that. Also they were all completely colored in 1.0
i am also having the same problem and i tried both files the vanilla one and the opti something the vanilla worked for me but when people talk the ranks are still not colored which kind of anoys me but thx very much for the bit less anoying fix. i would still like it to be complete so please finish the chat fix so it can be like before 1.1 and we can see all the colors and not just a few and the rest white. anyways thx and plz reply to this when you have the full fix :tongue.gif: cya.
I am using the optifine version and it worked. The only problem is the ranks are still white, but some text is fixed. It is definitely better than before but it is still a problem, if you could manage to fix all of it that would be great.
Update (Sep 7, 2012) - a Release!
Downloads
Previous newsPrevious Update!
Coloured text widths (when mixed with bold) are now calculated correctly, instead of the default interpretation.
Should work with Optifine {1.2.4, 1.2.5} HD {A, A2, A3, A4, A5} and vanilla {1.2.4 and 1.2.5}.
News
ThVortex's OpenType font support mod also restores colour!
Bold!
Altered Bold text so that is now more easily read than ALLCAPS!
Spoutcraft!
Spoutcraft (#124 from this thread) will have some version of color text fix. Currently there are a few versions being tested that take different approaches to the problem.
With instruction form Top_Cat and a last minute bug-fix from zml2008 I've managed to kludge mine into a pull request with mine as a toggleable option, but it will take time for these options to be tested and compared.
BTW,
Description
While this improves readibility for chat and other blocks of text, it reduces it for text rendered ontop of buttons, icons and menu bars.
There is also a problem where in certain contexts the text will still be forced to white, even without shadows.
I have yet to encounter a situation where the text is rendered in the incorrect colour, however I do not spend time on many servers.On my machine If the color4f is invoked enough times it appears to overflow the colour stack, then all colours above an unknown limit are treated as pure white. I have not yet determined how to prevent or correct this.
Screenshots
Details (irrelevant)
teaching myselfstaring dumbly at openGL and Javabyte code- tracing the is_shadow flag, etc.- decided 'meow to this' and did the quick and dirty thing and deleted the shadow pass in the drawStringWithShadow function.After learning more about the colour stack, and the daunting variety of hack/workarounds needed to accommodate bugs specific to Intel, AMD/ATI, Nvidia, etc... And failing to find an economical way to correct the {texture and colour} {blending and alpha} modes going crazy after using color4f too many times (specific implementation of GL1.1 not preserving original conditions!?), gave in again and traded one bug for another.
Code
I am aware that this still calculates an alpha value that isn't used.Future
Performance optimizations for vanilla(Optifine will still be more effecive overall,but this is an exercise for my own understanding.)Addendum
To help me fix this problem would you please post the following:
Re: forum keywords as parameters
So I've used my bugged UDL to weed out possible triggers for this problem.
It remains to be seen if this is sufficent to solve the problem.I do not appreciate having my formatting corrupted by "autocorrection." I am relying on the BBcode I am using staying the way I set it-
I should never have to thank anyone for not [j] [screwing] [j/] that up for me.
And the idea that a player would need to get a better machine for no functional reason is preposterous.
Unless you mean the missing text shadows; those provide immeadiate contrast around letters making them easier to read.
I have uploaded the fixed version of the optifine patch.
I'll look at the other one later when I am less angry.
I will bump this post, great work, I ****ing love you :wink.gif:
::Delete Meta-Inf on mq.class vannila!::
And this barely helps me
And can u post ur coding?
Bugs:
See how [Notice] is white?
That Notice should be colored
And when people talk there rank is still white
And [User] on me should be grey
Please fix this!
invokespecial mq/checkUpdated()V
aload_0
getfield mq/bidiFlag Z
ifeq 10
aload_0
aload_1
invokespecial mq/bidiReorder(Ljava/lang/String;)Ljava/lang/String;
astore_1
aload_0aload_1
iload_2
iconst_1
iadd
iload_3
iconst_1
iadd
iload 4
iconst_1
invokespecial mq/a(Ljava/lang/String;IIIZ)V
aload_0
aload_1
iload_2
iload_3
iload 4
iconst_0
invokespecial mq/a(Ljava/lang/String;IIIZ)V
return
+ I did have Optifine Standard
Notice how was appointed to be yellow while it was still white.
And [Helper] was actually a post to be like a baby blue color, but again white.
And the [User] was apposed to be grey, but u can see some of the players rank title was white.
Here are a few plugins I know from the server /w colors:
Essentials Group Manager
AuthMe
/./ Also note that this is a public server so I can't get all of the info from it...
And the box of donuts, what flavor?
ess.khhq.net - Group Manager > Variables
But I would need to be able to play with the server config files and have coloured screenshots from players not using my 'fix' to really know. Best leave it alone for now.
I'm partial to iced cherry jelly.
I do know that he has made the prefixes like that. And I would also know that because my varibles on my server are just like that. Also they were all completely colored in 1.0
Oh ya, and my promise :smile.gif:
did it wok for you like even when ppl talk you can see their rank color and stuff???