I'm not too familiar with Slick2D, but assuming it's sending back uncompressed data like most other methods of this type are, the byte array just represents color channel data packed together. Each color consists of a Red, Green, Blue, and sometimes Alpha channel. Typically the order of these channels are
RGBA, but it's possible that the orders are flipped, I've seen
BGRA before. So the byte array is going to look something like
R, G, B, A, R, G, B, A.... If you wanted to figure out which order it returns (a quick search of Slick2D documentaiton doesn't find any mention of channel order), you could create an all-red or gradient transparency image and read the first few values of the byte array from the debugger.
Also note that the 2d texture has it's data unrolled so that the
byte is a single-dimensional array. You can access the
A channel of a pixel at a given location like this:
//pixel locations to look up, assume initialized and checked to be in texture bounds.
int px, py;
byte texData = tex.getTextureData();
byte alpha = texData[4 * (py * tex.getTextureWidth() + px) + 3];
Breaking down the last line of the example in order of operation:
py * tex.getTextureWidth() + px is the standard way of looking up a 2d index in a 1d array. This is the location of the pixel were this an array of pixels.
4 * takes the pixel location and scales it to represent the color channels. This gets you the location of the first channel of the selected pixel. (Assuming RGBA layout, this would be the red channel)
+ 3 offsets the red channel location to the alpha channel. This is assuming
RGBA ordering. If it were
ARGB this part isn't necessary.