The Neg portion of the resources have been limited use in the client.
the CC Coord in the Neg files are used mostly for specifying a point or offset in some calculation for finding the correctly spot on the screen.
Examples:
- Code: Select all
setCursor(makeawtcurs(curs.layer(Resource.imgc).img, curs.layer(Resource.Negc).cc));
...
private static Cursor makeawtcurs(BufferedImage img, Coord hs) {
java.awt.Dimension cd = Toolkit.getDefaultToolkit().getBestCursorSize(img.getWidth(), img.getHeight());
BufferedImage buf = TexI.mkbuf(new Coord((int)cd.getWidth(), (int)cd.getHeight()));
java.awt.Graphics g = buf.getGraphics();
g.drawImage(img, 0, 0, null);
g.dispose();
return(Toolkit.getDefaultToolkit().createCustomCursor(buf, new java.awt.Point(hs.x, hs.y), ""));
}
In that case the CC is used to specify the 'hot-spot' point in a cursor
In many others you find things like:
- Code: Select all
Coord dc = mousepos.add(curs.layer(Resource.Negc).cc.inv());
Which has more to do with properly centering the object or in the case of the above properly finding the real coordinate of the mouse pointer.
If you look in ImageSprite.java you'll also find CC being used as an offset to once again properly position a coordinate:
- Code: Select all
public boolean checkhit(Coord c) {
c = c.add(ImageSprite.this.cc);
if((c.x < img.o.x) || (c.y < img.o.y) || (c.x >= img.o.x + img.sz.x) || (c.y >= img.o.y + img.sz.y))
return(false);
int cl = img.img.getRGB(c.x - img.o.x, c.y - img.o.y);
return(Utils.rgbm.getAlpha(cl) >= 128);
}
Moving on back to BS and BC coordinates in Neg you'll find that they are used in a manner that suggests that they are the defining hitboxes of the resource, BS and BC are also used with the creation of crop sprites however a bit more strangely there which i don't fully comprehend.
Also you can refer to Ender's 'hitbox' highlighting of hidden objects which also uses BC and BS:
- Code: Select all
if(Config.showHidden && Config.hide) {
g.chcolor(255, 0, 0, 128);
synchronized(glob.oc) {
for(Gob gob : glob.oc) {
Resource res = gob.getres();
if(!gob.hide || ((res != null)&&(res.skiphighlight)))
continue;
Resource.Neg neg = gob.getneg();
if(neg == null)
continue;
if((neg.bs.x > 0) && (neg.bs.y > 0)) {
Coord c1 = gob.getc().add(neg.bc);
Coord c2 = c1.add(neg.bs);
g.frect(m2s(c1).add(oc),
m2s(new Coord(c2.x, c1.y)).add(oc),
m2s(c2).add(oc),
m2s(new Coord(c1.x, c2.y)).add(oc));
}
}
}
g.chcolor();
}
the SZ coord is unknown, i didn't notice it being used at all in the default client.
however, one thing to note about the Neg is that outside of it's use in offsets with CC or crops with BS and BC they aren't used anywhere else. The bounding box drawing that i mentioned with BS and BC is only turned on by a variable that you can't normally turn on without proper command line arguments. This suggests that some of the coordinates inside Neg were most likely used by Loftar or Jorb to help figure out if they did their hitboxes correctly or for debugging purposes. So if one of them is wrong or others are just missing then it's most likely that they stopped having to use them for that purpose; therefore, they lost their meaning overtime and they didn't care to fix them.
The ones that really needed their correct values are mostly crops which did directly use BS and BC to generate the random strands that you see when they are rendered. Aside from that I don't see their purpose in the default client at all outside of debugging for Loftar, which really doesn't surprise me if a few of them aren't 100% correct.