Rendering an image under 10x10

[danran]

It didn't work, it rendered just a black box at the size i used (8x8), when i uped the width/height to 10x10 the image rendered fine. (I used they exact same image as i used before, all i did was add it into a 10x10 frame & pasted the previous image into that frame then it worked fine.)
Also, interestingly setting the swizzle to false, half of the 8x8 image (the top half) renders fine but the bottom half remains black. I also loading the image into both VRAM & RAM but with the same results.

[Criptych]

Hmm... did 9x9 give you the same problem?  And what kind of image was it - RGB or palette?

[danran]

Hummh did try 9x9, the thing was that i had two versions of the same image, the first 10x10 which i was using before 32bit, but wanted to convert to the other image, 8x8 also 32bit.
I'll upload the images later
p.s - honestly, i don't have a clue if there rgb or palette. There most likely RGB, usually when i have an image all i care about & Bit depth, format & size. Note that obviously both images are very small in terms of size.

[Criptych]

p.s - honestly, i don't have a clue if there rgb or palette. There most likely RGB, usually when i have an image all i care about & Bit depth, format & size. Note that obviously both images are very small in terms of size.

Yes, I was referring to the bit depth; sorry for the confusion.  Put simply, RGB/A images are loaded at 32 bits/pixel, and palette images at 8 bits.
A similar issue had me looking into the PGE source today; I found that it enforces a minimum width of 16 pixels internally, regardless of bit depth.  A quick fix here solved my problem, but I haven't checked yet to see if it works with yours.

[danran]

Yes, i was actually wondering about this after looking at your own thread, about creating a 4 bit image was it?
So i had to give it a try anyway, the images:
http://img294.imageshack.us/gal.php?g=miniblock.png

I'd understand a minimum width of 1 or even 2 but 16, its a bit strange.

Edit: Indeed you are right,
taken from the source, pgeTexture.c:

Code

GeSHi (c):
	texture->swizzled = 0;
	texture->width = width;
	texture->height = height;
	texture->textureHeight = pgeTextureNextPow2(height);
	texture->textureWidth = pgeTextureNextPow2(width);
 
	if(texture->textureHeight < 8)
		texture->textureHeight = 8;
 
	if(texture->textureWidth < 16)
		texture->textureWidth = 16;
 
	texture->size = texture->textureWidth*pgeTextureNextMul8(texture->height)*(texture->bits>>3);
	texture->data = pgeMalloc(texture->size);
 
Created by GeSHI 1.0.7.20

[FaT3oYCG]

why don't you use a tile sheet then?

[danran]

why don't you use a tile sheet then?

Like i said, I'm making due with 10x10, the reason I'm not using a tile sheet in this particular occasion is because 4 of these are created when you smash a block, i update everything single one and each block moves differently. I could make one, with the same images placed for times in a individual frames but personally i feel there's no need.

[Criptych]

I'd understand a minimum width of 1 or even 2 but 16, its a bit strange.

Actually it makes sense for an 8-bit image.  Swizzling requires a minimum width of 16 bytes, so the minimum width in pixels is (16*8 =) 128 / bpp.

the reason I'm not using a tile sheet in this particular occasion is because 4 of these are created when you smash a block, i update everything single one and each block moves differently.

You can use "tile" sheets for your sprites, too; just draw a differently-sized segment of the texture at a location unrestricted by grid coordinates.  Take a look at pgeFont.c: it stores the font's characters, often of different widths, in one texture, and can print them at any location on the screen.

EDIT: I tried drawing both images in PGE 0.02, SVN PGE, and my modified version.  0.02 exhibited the problem as you described it, except that disabling swizzle seemed to have no effect.  Neither the SVN version nor my version exhibited this problem, so I assume whatever caused was fixed between 0.02 and 0.03 (which makes it hard to pin down ), but isn't related to the changes I made.

[danran]

Its good to know that it's fixed atleast

[InsertWittyName]

Yes, this was originally reported by romero126 and has been fixed for 0.03