Bug dans routine de tracé lignes

[SlyVTT]

Hello,

encore une question, relative à un bug dans une routine de tracé de ligne horizontale.
Certaines couleurs semblent bien fonctionner, par contre d'autres ne fonctionne pas. Je pense qu'il s'agit d'un problème avec la manipulation de la mémoire via "memset" qui prend des octets, mais pas des blocs de 16bits.
y'a t il une autre fonction de manipulation de la mémoire qui permette de traiter les doubles octets ?

Pour un seul pixel ca a l'air Ok, par contre pour remplir une zone de la mémoire non...

Voici mon code qui bugge (tracé de lignes horizontales et certaines n'apparaissent tout simplement pas).
Y'a t il un moyen plus rapide qu'une boucle ?

Code: Tout sélectionner

#include <os.h>
#include <string.h>


// some RGB color definitions in high color and corresponding RGB code
#define S_Black           0x0000      /*   0,   0,   0 */
#define S_Navy            0x000F      /*   0,   0, 128 */
#define S_DarkGreen       0x03E0      /*   0, 128,   0 */
#define S_DarkCyan        0x03EF      /*   0, 128, 128 */
#define S_Brown           0x7800      /* 128,   0,   0 */
#define S_Purple          0x780F      /* 128,   0, 128 */
#define S_Olive           0x7BE0      /* 128, 128,   0 */
#define S_LightGrey       0xC618      /* 192, 192, 192 */
#define S_DarkGrey        0x7BEF      /* 128, 128, 128 */
#define S_Blue            0x001F      /*   0,   0, 255 */
#define S_Green           0x07E0      /*   0, 255,   0 */
#define S_Cyan            0x07FF      /*   0, 255, 255 */
#define S_Red             0xF800      /* 255,   0,   0 */
#define S_Magenta         0xF81F      /* 255,   0, 255 */
#define S_Yellow          0xFFE0      /* 255, 255,   0 */
#define S_White           0xFFFF      /* 255, 255, 255 */
#define S_Orange          0xFD20      /* 255, 165,   0 */
#define S_GreenYellow     0xAFE5      /* 173, 255,  47 */


void S_Clear_Screen( void )
{
    // Clear Screen and paint it black
    memset((void*) REAL_SCREEN_BASE_ADDRESS, 0x00, _scrsize());
}

void S_Draw_Pixel( int x, int y, unsigned short color )
{
    // Set the color of the pixel (x,y) to Color in R5G6B5 format
    if ((x>=0) && (x<=320) && (y>=0) && (y<=240))
    {
        unsigned short *screenAdress = REAL_SCREEN_BASE_ADDRESS;
        screenAdress += (y<<8) + (y<<6) + x;
        *(unsigned short *)screenAdress = color;
    }
}

void S_Draw_Scanline( int x0, int x1, int y, unsigned short color )
{
    // this is the optimised Horizontal Line Drawing routine for filling shapes
    if (x0==x1) S_Draw_Pixel( x0, y, color);
    if (x0<x1)
    {
        unsigned short *screenAdress = REAL_SCREEN_BASE_ADDRESS;
        screenAdress += (y<<8) + (y<<6) + x0;
        int sizeline=x1-x0;
        memset((void*) screenAdress, color, sizeline*2);
    }
    if(x0>x1)
    {
        unsigned short *screenAdress = REAL_SCREEN_BASE_ADDRESS;
        screenAdress += (y<<8) + (y<<6) + x1;
        int sizeline=x0-x1;
        memset((void*) screenAdress, color, sizeline*2);     
    }
}

int main( void )
{
    if( !has_colors )
        return 0;
    lcd_incolor();
   
    S_Clear_Screen();
   
    wait_key_pressed();
   
    S_Draw_Scanline( 10, 310, 120, S_White );
    wait_key_pressed();
   
    S_Draw_Scanline( 30, 290, 140, S_Yellow );
    wait_key_pressed();
   
    S_Draw_Scanline( 50, 270, 160, S_Orange );
    wait_key_pressed();
   
    S_Draw_Scanline( 70, 250, 180, S_Red );
    wait_key_pressed();
   
    S_Draw_Scanline( 90, 230, 200, S_Purple );
    wait_key_pressed();
   
    S_Draw_Scanline( 110, 210, 220, S_Magenta );
    wait_key_pressed();
   
    return 0;
}




Merci

Sly

[SlyVTT]

Après quelques analyses, un S_Clear_Screen prends 0.9ms (10000 boucles en 9s).
Si je réécris cette fonction "proprement" pour boucler avec des valeurs sur 16 bits (avec une boucle for sur l'ensemble de la zone mémoire de l'écran), il faut le double de temps (1.7ms).
Ces métriques ont été obtenues avec des calls au RTC (0x90090000).

Une idée pour accélérer un "clear screen" avec une couleur sur 16 bits ?

Thanks

Sly

[Vogtinator]

Please don't use REAL_SCREEN_BASE_ADDRESS, that's an implementation detail.

Certaines couleurs semblent bien fonctionner, par contre d'autres ne fonctionne pas. Je pense qu'il s'agit d'un problème avec la manipulation de la mémoire via "memset" qui prend des octets, mais pas des blocs de 16bits.
y'a t il une autre fonction de manipulation de la mémoire qui permette de traiter les doubles octets ?

Yes, memset takes an 8bit value, so the higher 8 bits are just ignored.

Une idée pour accélérer un "clear screen" avec une couleur sur 16 bits ?

You can just write a loop to write 16bit at a time, the compiler should optimize it properly. You could help it a bit by writing 32bit values instead.

Note that on the CX II, the LCD controller points to "magic VRAM", which makes it behave weirdly for certain types of access. It works best when using an off-screen buffer for drawing and then blitting it into VRAM (which is also what lcd_blit does).

How does lcd_blit's performance compare?