CptSpaceToaster / CptsModdingLight

Do What The F*ck You Want To Public License
39 stars 15 forks source link

Inconsistent bit order in CLApi #46

Closed octarine-noise closed 9 years ago

octarine-noise commented 9 years ago

So, I was setting up compatibility, and happened on this in CLApi:

All method javadocs show the bit-packed format of the modified brightness is: 0RRRR 0GGGG 0BBBB 0LLLL.

All methods calculate the value like this: return brightness | ((b << 15) + (g << 10) + (r << 5));

Which is the correct one?

edit: well, since the mod is working, it's obviously the code. You should correct the javadoc.

CptSpaceToaster commented 9 years ago

Doah! I'll fix the comment shortly... Thank you for the message!

0BBBB 0GGGG 0RRRR 0LLLL was intended

CptSpaceToaster commented 9 years ago

This writeup should hopefully keep things straight... or maybe it won't... but HEY... I'm trying here!

octarine-noise commented 9 years ago

Yes, that's very useful. Especially that it lists all the formats that one could encounter.

In my case, it was the 2nd one I needed (I render with the modified brightness, not put lights in the world), but it took me half an hour to find it in CLTessellatorHelper.java. Good thing that that comment was correct :P

CptSpaceToaster commented 9 years ago

Yeah... I hate that it came down to... "Mod writers now have to work with two different brightness formats in the Tessellator..."

I tried to make it backwards compat, by altering everything BEFORE the tessellator... but... I can't find another way to do this well.... for other TESR's and even custom ISBRH's

Not to mention my horrible hack and slash approach to the GL state...

In 1.8, there are some things I can do for the ISBRH replacement, as there is a point where I can lint values going through very easily... but I'll still have to deal with TESR's somehow...