I could make it pick between RGB565, ARGB1555 and ARGB4444 if no format flag is given. Regarding the mipmap flag. I'm not sure it can be done easliy with the way it works now. The flags dictate what images are allowed to be loaded, not the other way around. It also allows for separate images for eac...

ODE has been ported over. It's from 2003 though.
http://www.boob.co.uk/devtools.html

Fixed! I Forgot to update the devectorization function for alpha textures.

Did you compress that?

1.1M is pretty spot on for uncompressed. 1024*512*2 = 1048576 bytes, plus codebook and header. It should be around 130kB compressed.

I've updated texconv with experimental support for rectangular, non-mipmapped VQ textures. It's been tested with a couple of RGB565 textures, one where w>h, and one where h>w. I also did some more testing with rectangular mipmaps, both with and without VQ. It seems the hardware assumes that w==h whe...

Ok, I've done some testing. Rectangular VQ textures work fine on the actual hardware, and I only need to change a couple of lines in texconv to support it. I've also tried rectangular VQ textures with mipmaps, and it may work, not sure yet. I'm getting a partially scrambled output, so I probably jus...

I'm not sure about twiddling, but VQ could in theory work with rectangles as well, so I'd be glad if you found something out about that. Many game assets have rectangular texture sizes. I'd need to build texture atlases and change the UV maps of this mesh for example.. And we really don't want to w...

Why can VQ compression not be used with non-square images though? I don't think I've ever tried doing VQ compression on rectangular images. All sources say they need to be square. But then again, they also say paletted textures can't be compressed. I might try out that later. Are there any quality ...

Hey, The VQ compression ratio is fixed at 1/8th of the uncompressed size, plus a 2kB overhead for the codebook. Any texture format supported by the PVR2DC can also utilize VQ compression. So in the end, the compressed sizes are: (num_pixels / 4 + 2048) for 16BPP images (RGB565, ARGB1555, ARGB4444, Y...

Yeah, you're right, I should've explained it better. What I meant was you'll have to send the same geometry one more time to flush the secondary accumulation buffer. EDIT: I thought you were talking about the lightmapping (which already is a one pass solution). :oops: I haven't messed around with th...

No, you'll actually need an additional pass to flush the secondary accumulation buffer.

It's mostly used to mask out multitexture effects from the transparent parts of the base texture.

I could see adding a 'presort_disabled' to the initialization parameters, which would set it in the tile region array parameters (as you detailed in your post with changing the control word there). Since auto-sort is enabled by default today, wouldn't 'presort_enabled' or 'autosort_disabled' be the...

But, it seems that changing the parameters at compile time is not the best solution here. I think it would be best to init the PVR in a way that allows the use of the ISP_FEED_CFG register to specify TR sort mode per-frame. Or is it possible to modify the tile matrix bits after initializing the PVR...

It only changes how the TR list deals with translucency. In auto-sort, it sorts the polygons per pixel and renders them back-to-front. In pre-sort, they're rendered in the order they're submitted.

Bit 21 = Region Header Type? ( 0 = TR sort mode set by ISP_FEED_CFG register, 1 = TR sort mode is specified by the pre- sort bit within the Region Array data ) And looking at the "magic value", we can see that Bit 21 is set to 1, so then in KOS ( by default ), TR sort mode is ignored in t...

I guess the PVR really struggles with blending overlapped translucent polys? Yeah, it does. You can speed it up by disabling the hardware translucency auto-sort though. It's enabled in the pvr init code somewhere, can't remember off the top of my head, but I know it's been posted how to disable it ...

plx_txr_load loads pngs with either PNG_NO_ALPHA or PNG_FULL_ALPHA depending on its alpha parameter (full alpha in your case). The PT poly list only allows for 1-bit alpha (fully opaque or fully translucent). I'm guessing the missing pixels aren't fully opaque and aren't rendered because their alpha...

Do you get the same issues if you draw everything in the PLX_LIST_TR_POLY list?

You might have some Z fighting going on. Try giving the sprites that should appear on top of the card a larger Z value.

If you want to use a non-power-of-two size vertically, allocate less than you actually specify in the polygon header. So, for instance, if you want a texture that is 24 pixels tall, allocate the space accordingly with pvr_mem_malloc() for that 24 pixel tall texture, but when you send the parameters...