Blit(T,i,i,i,i,i,i,i,i,i,b) not using pixel values (using proportions)

[Cowbox]

Ok this time I'm sure I've found a bug.

I just converted an old bitmap font decoder from Slick2D into jPCT. The principles are basically exactly the same.

The code I would want to use would be something like this: (for numbers)

Code: [Select]

public static void drawString(FrameBuffer b,int x,int y,String string)
{
if(string.length()>0)
{
for(int c=0;c<string.length();c++)
{
int ascii=(int)string.charAt(c);
if(ascii>47&&ascii<58)
{
b.blit(bmpFont,(ascii-48)*letterSize,letterSize*2,x+(c*letterSize),y,letterSize,letterSize,letterSize,letterSize,5,false);
}
}
}
}
This should theoretically work on this image:


But it displays a seemingly random jumbled subset of the image.

The only way I could get it to display the right numbers (or letters in other parts of the whole code) was to do something like this:
b.blit(bmpFont,(ascii-48)*letterSize,64*2,x+(c*letterSize),y,letterSize,64,letterSize,letterSize,5,false);
But I mean, why 64? How am I to use this usefully?

If I resize the image to 260x260, the original works, but has artifacts around the edges of characters and wastes space.

[EgonOlsen]

It's not bug..your texture doesn't follow the conventions, i.e. neither its width nor its height are a power of 2. jPCT will rescale the image at load time to match this requirement, but that will of course render your coordinates based on the old image useless.

Try to embed the image into a 512*64 texture and try again.

[Cowbox]

Hmm, well I suppose that makes sense.

I've just sucked it up and I'm using a 512x512 image for the sake of speed of conversion.

But the documentation on the blit commands is misleading therefore.

Because, in other libraries (AWT and Slick2D), whenever I use the 8 integers for source(x/y/x2/y2) dest(x/y/x2/y2) they all work in true pixels values, and this is what the documentation seemed to suggest to me.

Perhaps just a note to say something like "Make sure your image complies with powers of 2" or change the wording so it doesn't sound like destination pixel from/to and source pixel from/to.

[EgonOlsen]

But they are real pixel values. The problem is that in your case, the pixel values that you think you are dealing with aren't the correct ones anymore because of the rescaling.

[Cowbox]

But the problem lies in the fact that when someone says "take a 32x32 image from 16,16 on this 400x300" image, you expect to get  a picture with dimensions 32x32 at the very least. xD
And most would expect the top left pixel of the image to have the same colour as 16,16 on the 400x300 image.

The documentation is just misleading and doesn't hint that this might be a problem some encounter with these particular methods.

[EgonOlsen]

Sorry, but i don't understand the problem...you'll get a 32*32 image if you say so in the method call. Of course, it won't look like you would expect it, but at least it will be 32*32 in size. The docs and the forum always state that textures (which is what you are using to blit) have to have a width and height or 2^x. That jPCT rescales them to make them fit is a convenience for people who forget about it.
In this case, it might be misleading somehow...but it's written in the Texture class, in the constructors of Texture and you'll get a warning printed into the log if you ignore it. What else can i do? The only other solution is to do what i did in the Android version of jPCT: Throw an exception.