Some precisions needed

[Newbie]

I have heard about "twiddled" texture, it seems it is usefull for 4 or 8 bits textures only so no need to twiddling texture for 16 bits (even VQ ones) ?

I have heard too about "punch-through geometry" list what it is ?

[BlueCrab]

Twiddled textures are ones where the pixel data is organized in a manner that makes it easier for the video hardware to perform specific actions. Particularly, texture filtering (bilinear, trilinear, etc) benefits, speed wise, from twiddling. Certain types of textures (palleted formats like the 4bpp and 8bpp formats) require twiddling because of how the hardware is set up. So, if you're already preprocessing your textures ahead of time (with one of the utilities that comes with KOS), you might as well have it twiddle the texture for you. It isn't going to hurt anything, unless you need to manipulate the individual pixels of textures at runtime.

Punch-thrus are polygons with one-bit alpha. That is to say, every pixel is either fully on or fully off. It's a simplification of translucent polygons that are easier for the hardware to handle. Punch-thrus are processed at pretty much the same rate as opaque polygons, whereas translucent polygons require additional processing time. So, for things like pixel art sprites (where every pixel is either fully opaque or fully transparent), it can be a big help.

[Newbie]

Hi,

Thanks a lot for your answser.

As i understand, drawing a list of "Punch-thrus" polygons is quite fast as drawing a list of "transparent" polygons.

Can we say that a polygon having a 16 bits 1555 texture (compressed as VQ or not) is a "Punch-thrus" polygon ?

My app draws only 2D sprites as list of textures.

I have a lot of 1555 textures to draw but sometimes 565 (very few), i have not a fast and easy mean of sorting those polygons in two diffrent lists (one for 565 and the other for 1555).

What happens if (time to time) a few (1 to 10) opaque polygons are inserted in the list that will be draw as "Punch-thrus" polygons ?


To recap what i understand (in 16 bits):

"Punch-thrus" : PVR_TXRFMT_ARGB1555 | PVR_LIST_PT_POLY

"Transparent" : PVR_TXRFMT_ARGB4444 | PVR_LIST_TR_POLY

"Opaque" : PVR_TXRFMT_RGB565 | PVR_LIST_OP_POLY


I use my own ressource file to load data and create texture as unsigned short interger array (unsigned short int[] ).

Do you have some source code sample that could twidlle such an array ?

To finish, i have found a "reserved word" in KOS called PVR_TXTRFMT_NOSTRIDE.

What is a stride ?

Thanks !

[bogglez]

As i understand, drawing a list of "Punch-thrus" polygons is quite fast as drawing a list of "transparent" polygons.

As crabby said, punch-thru is faster than transparent. Otherwise there would be no point in punch-thrus.

Can we say that a polygon having a 16 bits 1555 texture (compressed as VQ or not) is a "Punch-thrus" polygon ?

Yes.

My app draws only 2D sprites as list of textures.

I have a lot of 1555 textures to draw but sometimes 565 (very few), i have not a fast and easy mean of sorting those polygons in two diffrent lists (one for 565 and the other for 1555).

What happens if (time to time) a few (1 to 10) opaque polygons are inserted in the list that will be draw as "Punch-thrus" polygons ?

In that case just draw the few 565 sprites in the punch-thru list, it shouldn't affect performance much. Just bother with optimizing this if you realize later that you can't hit the framerate. Nothing bad will happen.

To recap what i understand (in 16 bits):

"Punch-thrus" : PVR_TXRFMT_ARGB1555 | PVR_LIST_PT_POLY

"Transparent" : PVR_TXRFMT_ARGB4444 | PVR_LIST_TR_POLY

"Opaque" : PVR_TXRFMT_RGB565 | PVR_LIST_OP_POLY

Yes (but there are of course other texture formats that may be used).

Do you have some source code sample that could twidlle such an array ?

Check the utils folder of KOS. There is a utility that does the twiddling. The idea is described here https://en.wikipedia.org/wiki/Z-order_curve

To finish, i have found a "reserved word" in KOS called PVR_TXTRFMT_NOSTRIDE.

What is a stride ?

Use the forum search.

[PH3NOM]

Do you have some source code sample that could twidlle such an array ?

To finish, i have found a "reserved word" in KOS called PVR_TXTRFMT_NOSTRIDE.

What is a stride ?

Thanks !

Twiddling applies to all texture pixel formats, 16bpp textures can also be Twiddled.

KOS can Twiddle the texture for you when you upload the texture to the PVR:
http://gamedev.allusion.net/docs/kos-cu ... bae8dd4624

However, it will be faster loading time to pre-process the textures on PC.
Here is a version of the KOS twiddling algorithm I have modified for my own use:

Code: Select all

/* Linear/iterative twiddling algorithm from Marcus' tatest */
#define TWIDTAB(x) ( (x&1)|((x&2)<<1)|((x&4)<<2)|((x&8)<<3)|((x&16)<<4)| \
                     ((x&32)<<5)|((x&64)<<6)|((x&128)<<7)|((x&256)<<8)|((x&512)<<9) )
                     
#define TWIDOUT(x, y) ( TWIDTAB((y)) | (TWIDTAB((x)) << 1) )

#define MIN(a, b) ( (a)<(b)? (a):(b) )

typedef struct
{
    unsigned char r, g, b;
} Pixel24;

typedef unsigned short int Pixel16;

void TextureTwiddle24bpp(Pixel24 * src, Pixel24 * dst, int w, int h)
{      
    uint32 x, y, min, min2, mask;
    
    min = MIN(w, h);
    min2 = min * min;
    mask = min - 1;

    for(y = 0; y < h; y++) 
        for(x = 0; x < w; x++)
            dst[TWIDOUT(x & mask, y & mask) + (x / min + y / min) * min2] = src[y * w + x];
}

void TextureTwiddle16bpp(Pixel16 * src, Pixel16 * dst, int w, int h)
{      
    uint32 x, y, min, min2, mask;
    
    min = MIN(w, h);
    min2 = min * min;
    mask = min - 1;

    for(y = 0; y < h; y++) 
        for(x = 0; x < w; x++)
             dst[TWIDOUT(x & mask, y & mask) + ((x + y) / min2) * min2] = src[y * w + x];
}

[Newbie]

Hello,

Sorry for the late answer but i had to test the "PT" texture drawing. First, i use my own code and it's not working. So i try with a raw drawing method and it's not working too. I have made tests with ARGB1555 and VQ ARGB1555 textures generated by a tool here : https://github.com/tvspelsfreak/texconv. I don't think the data to display are buggy because when i switch from "PT" to "TR", it displays correctly an image on screen with the one color alpha.

So i am dissapointed because i do not see why i could not display "PT" lists ....

I link the file of source code i use to test.

If someone could help.

Thanks.

[BlueCrab]

You have not enabled the punch-thru list when you initialized the video hardware. The normal pvr_init_defaults() only enables the opaque and translucent lists. You need to do something like this, instead of pvr_init_defaults():

Code: Select all

    pvr_init_params_t params = {
        /* Enable opaque, translucent, and punchthru polygons with size 16 */
        { PVR_BINSIZE_16, PVR_BINSIZE_0, PVR_BINSIZE_16, PVR_BINSIZE_0, PVR_BINSIZE_16 },

        /* Vertex buffer size 512K */
        512 * 1024,

        /* No DMA */
        0,

        /* No FSAA */
        0,

        /* Translucent Autosort enabled. */
        0
    };

    pvr_init(&params);

Also, if you're not using VQ or Strided textures, you don't have to specify that in the format. PVR_TXRFMT_VQ_DISABLE and PVR_TXRFMT_NOSTRIDE are both equal to 0. That's obviously not causing any problems in and of itself, I just thought I'd mention it.

Also, I know it's just a test program there, but you really shouldn't be re-initializing the video hardware in your TestPTRaw function. Do that once, in main() -- just copy/paste the block I put in the post into your main before you call your TestPTRaw function and get rid of the pvr_init_defaults() line.

[Newbie]

Thanks for answers.

Do not worry it's only a test code

To twiddle the texture i use :

Code: Select all

void TextureTwiddle16bpp(Pixel16 * src, Pixel16 * dst, int w, int h)
{     
    uint32 x, y, min, min2, mask;
   
    min = MIN(w, h);
    min2 = min * min;
    mask = min - 1;

    for(y = 0; y < h; y++)
        for(x = 0; x < w; x++)
             dst[TWIDOUT(x & mask, y & mask) + ((x + y) / min2) * min2] = src[y * w + x];
}

In the code below, the "Translucent Autosort enabled" parameter is not recognized as my compilator says "too many arguments" ...

Code: Select all

	pvr_init_params_t params = {
        /* Enable opaque, translucent, and punchthru polygons with size 16 */
        { PVR_BINSIZE_16, PVR_BINSIZE_0, PVR_BINSIZE_16, PVR_BINSIZE_0, PVR_BINSIZE_16 },

        /* Vertex buffer size 512K */
        512 * 1024,

        /* No DMA */
        0,

        /* No FSAA */
        0,

        /* Translucent Autosort enabled. */
        0
    };

After changing PVR initialisation all is working good. It seems that a few people use PT list as i did not see very much samples in KOS examples.

In the parameters structure, i notice the use of "bin size" :

Code: Select all

	#define PVR_BINSIZE_0   0   /**< \brief 0-length (disables the list) */
	#define PVR_BINSIZE_8   8   /**< \brief 8-word (32-byte) length */
	#define PVR_BINSIZE_16  16  /**< \brief 16-word (64-byte) length */
	#define PVR_BINSIZE_32  32  /**< \brief 32-word (128-byte) length */

By default, it is set to PVR_BINSIZE_16.

Well, in my case i always use multiple of 32 texture widths, so is it a good idea to use PVR_BINSIZE_16 ?

Thanks for help.

[BlueCrab]

Thanks for answers.

Do not worry it's only a test code

I just figured I'd make a few comments on it, while I was looking anyway.

In the code below, the "Translucent Autosort enabled" parameter is not recognized as my compilator says "too many arguments" ...

Code: Select all

	pvr_init_params_t params = {
        /* Enable opaque, translucent, and punchthru polygons with size 16 */
        { PVR_BINSIZE_16, PVR_BINSIZE_0, PVR_BINSIZE_16, PVR_BINSIZE_0, PVR_BINSIZE_16 },

        /* Vertex buffer size 512K */
        512 * 1024,

        /* No DMA */
        0,

        /* No FSAA */
        0,

        /* Translucent Autosort enabled. */
        0
    };

After changing PVR initialisation all is working good. It seems that a few people use PT list as i did not see very much samples in KOS examples.

Ah... You must be using a fairly old version of KOS for the last parameter to not be available. You're not missing much with just that part, but you still probably should consider updating for all the other stuff that has changed in at least the last year and a quarter (the Translucent Autosort part was added in September of 2014).

In the parameters structure, i notice the use of "bin size" :

Code: Select all

	#define PVR_BINSIZE_0   0   /**< \brief 0-length (disables the list) */
	#define PVR_BINSIZE_8   8   /**< \brief 8-word (32-byte) length */
	#define PVR_BINSIZE_16  16  /**< \brief 16-word (64-byte) length */
	#define PVR_BINSIZE_32  32  /**< \brief 32-word (128-byte) length */

By default, it is set to PVR_BINSIZE_16.

Well, in my case i always use multiple of 32 texture widths, so is it a good idea to use PVR_BINSIZE_16 ?

The size of your textures has nothing to do with that value at all. That controls how buffers are allocated on a per-tile basis for objects in the video hardware. Unless you have a good reason to change it, you probably should just leave it as 16 for most cases.

[Newbie]

Ah... You must be using a fairly old version of KOS for the last parameter to not be available. You're not missing much with just that part, but you still probably should consider updating for all the other stuff that has changed in at least the last year and a quarter (the Translucent Autosort part was added in September of 2014).

I will use the latest stable KOS version with pleasure if you show me where to download it
And if you could provide me a "changelog" it could be very interresting

[BlueCrab]

Ah... You must be using a fairly old version of KOS for the last parameter to not be available. You're not missing much with just that part, but you still probably should consider updating for all the other stuff that has changed in at least the last year and a quarter (the Translucent Autosort part was added in September of 2014).

I will use the latest stable KOS version with pleasure if you show me where to download it
And if you could provide me a "changelog" it could be very interresting

Well, the latest "stable" version wouldn't have that either, I suppose... I guess I should do another release soon...

Anyhow, the changelog is as follows:

Code: Select all

KallistiOS version 2.1.0 -----------------------------------------------
- *** Cleaned up generated stubs files on a make clean [Lawrence Sebald = LS]
- DC  Added a function to detect if the program is being run on a retail
      Dreamcast or a Set5.xx device [LS]
- DC  Fixed an issue with the SIP driver that would cause programs to freeze
      if a microphone was connected at program startup [LS]
- DC  Rearranged the SIP driver to get rid of the internal buffer [LS]
- *** Removed the GBA, ia32, and ps2 ports. If someone really wants them back
      and wants to maintain them, let me know. [LS]
- DC  Fixed fmath functions so they compile in C99 mode [LS]
- *** Cleaned up warnings with -std=gnu99 for C code [LS]
- *** Cleaned up warnings with -std=c99 for C code [LS]
- DC  Changed the PVR render-to-texture support to allow for two render-to-
      texture passes without an intervening render-to-screen pass [LS]
- *** Fixed an issue in fs_ext2 that would allow you to rename a directory to be
      a child of itself, thus chopping it off from the rest of the directory
      tree [LS]
- *** Added a fs_readlink() function to resolve symlinks [LS]
- *** Fixed the vqenc and kmgenc utilities for compilation on a 64-bit OS [LS]
- DC  Corrected an issue with video cable detection with GCC 4.8.x [LS]
- DC  Added support for ATA devices on the G1 bus [LS]
- DC  Fixed an infinite loop in ATA initialization if nothing except the GD-ROM
      drive is connected [LS]
- *** Added documentation for the addons tree [LS]
- DC  Made the hardware auto-initialization/shutdown functions weakly linked so
      that they can be overridden without modifying KOS [LS]
- DC  Corrected render-to-texture mode so that you don't have to wait for a
      vblank to actually render to the texture [LS]
- *** Modified fs_stat to conform (mostly) to the POSIX standard for the stat
      function [LS]
- DC  Modified the cdrom driver so that it will set itself as the active ATA
      device before trying to do any CD related reading [LS]
- DC  Fixed potential race conditions between the cdrom code and g1ata [LS]
- DC  Fixed full sector reading of non-data CDs (thanks to SWAT for pointing out
      that it needed fixing) [LS]
- DC  Added many new matrix/vector math-related macros [Josh Pearson = JP]
- *** Added libppp for dialup internet access to the addons tree [LS]
- *** Added DNS resolver functions getaddrinfo() and gethostbyname() [LS]
- *** Fixed a problem where poll() would deadlock if the timeout expired [LS]
- *** Modified getaddrinfo() so that it would try multiple times to contact the
      DNS server with a timeout between messages [LS]
- DC  Various cleanups and modifications to the cdrom code, including subcode
      reading functionality, DMA-based sector reads, and using a recursive mutex
      for the G1 lock [Donald Haase == DH]
- DC  Fixed pvr_mem_available() to report all available texture memory, not just
      what was available in the pvr_malloc() arena [LS]
- DC  Added a utility function to the PVR code for controlling the cheap shadow
      scale register [LS]
- DC  Added an example of the PVR's cheap shadow functionality [LS]
- DC  Added a tool for generation of bumpmaps that was sent to the mailing list
      all the way back in 2005 [Fredrik Ehnbom = FE]
- *** Added the fs_path_append() function to append path components [LS]
- *** Added a nanosleep() function to koslib by request [LS]
- *** Added rewinddir() support to the VFS and serveral filesystems [LS]
- *** Added in C11 threading support [LS]
- *** Added UDP Lite support to the network stack [LS]
- DC  Adjust sq_cpy() to use a const pointer for the source [JP]
- DC  Retrieve the IP address from dcload-ip when we can [LS]
- *** Added the mutex_unlock_as_thread() function to allow an IRQ handler to
      unlock a mutex as if it were a specified thread [LS]
- DC  Fixed a deadlock issue in the G1ATA code related to the use of a recursive
      mutex for locking -- Thanks to SWAT for noticing the issue [LS]
- DC  Added support for German (DE) and UK keyboards [Christian Groessler == CG]
- DC  Minor cleanups to the flashrom code [DH && LS]
- DC  Added light gun support roughly based on how it is done in libronin [LS]
- DC  Added a very simple light gun example [LS]
- DC  Added support for Spanish keyboards [Xavier Vallejo == XV]
- DC  Added rudimentary support for OCRAM in linker script [CG]
- *** Added the C11 aligned_alloc() function [LS]