El blitter es un cachondo (Extraño funcionamiento de GpBitBlt() )

[Lizardos]

Hola todos, perdonadme si no me he unido a la fiebre "fenixera" de hoy, pero entre el trabajo y el port de Rogue no he tenido ocasión. Y precisamente, del rogue quiero haceros una consulta a los que habeis trabajado con sprites en el sdk.
Necesito mostrar una imagen de 320x90, pero si le pongo un bitmap de ese tamaño, la imagen sale desalineada y en las columnas finales muestra la basurilla típica de haber sobrepasado el array. Sin embargo, con la misma imagen en 320x100 (añadiendo 10 px en el borde inferior) y bliteando 320x90 la imagen sale perfecta. El archivo de imagen está en formato crudo (1 byte->1 pixel, color en paleta) y rotado a la derecha (el sdk interpreta los gráficos primero en columnas y luego en filas, o tiene que ver con que la pantalla de la gp32 está "girada"? )

¿Alguna idea de por qué hace esto? Ya está solucionado pero tengo curiosidad por saber a qué es debido.

CODIGO PARA 320X90:
#define MAINMENU_FILE "mainmenu.raw"
#define MAINMENU_SIZE 28800
.
.
.
unsigned char cMainMenuGfx[MAINMENU_SIZE];
F_HANDLE pf;
errFile = GpFileOpen (MAINMENU_FILE, OPEN_R, &pf);
if(errFile != SM_OK) return errFile;
GpFileRead (pf, cMainMenuGfx, MAINMENU_SIZE, &nCount);
GpFileClose (pf);
.
.
.
GpBitBlt(NULL,&gpDraw[nflip], 0, 150, 320, 90, cMainMenuGfx, 0, 0, 320, 90);

Y sale algo tal que así.
Saludos, Lizardos.

[Lizardos]

Y así debería salir:
CODIGO PARA 320X100:
#define MAINMENU_FILE "mainmenu.raw"
#define MAINMENU_SIZE 32000
.
.
.
unsigned char cMainMenuGfx[MAINMENU_SIZE];
F_HANDLE pf;
errFile = GpFileOpen (MAINMENU_FILE, OPEN_R, &pf);
if(errFile != SM_OK) return errFile;
GpFileRead (pf, cMainMenuGfx, MAINMENU_SIZE, &nCount);
GpFileClose (pf);
.
.
.
GpBitBlt(NULL,&gpDraw[nflip], 0, 150, 320, 90, cMainMenuGfx, 0, 0, 320, 100);

[theNestruo]

Pues eso suena a que copias líneas (columnas en este caso) de más tamaño que el destino, y entonces en memoria se van desalineando. Digamos que "sobra" un píxel que se añade a la línea siguiente, con lo que empieza un píxel más arriba y luego te "sobrarán" dos píxeles y así... (no sé si me he explicado).
El porqué se desalinea... pues no lo sé, pero quizá tenga que ver con el padding en memoria; si está ajustando a 4 bytes y tienes 8 bits per pixel (1 byte per pixel), 100 es múltiplo de 4, pero 90 no (sobrarían o faltarían dos bytes por línea, y dos píxeles es el desplazamiento que se aprecia en la primera imágen que has posteado). Prueba a hacer el bitmap de 92 píxeles de altura, por ejemplo.

[adolomitica]

No tengo ni idea de por que pasa (yo soy de los de la fiebre "fenixera") pero a mi me pasaba algo parecido con algunas imagenes de los mapas que hice para iMappy y lo solucioné cortando uno o dos pixels de ancho o de alto.

[oankali]

theNestruo va por buen camino, las funciones de 16bits del SDK oficial solo funcionan con gráficos alineados a 8 píxeles (16 bytes). O sea que las dimensiones tienen que ser un múltiplo de 8.
No suelo programar con el modo 8bits (me ahorro tener que gestionar la paleta :)), pero estoy seguro que debe de passar lo mismo, lo que no sé es de cual es el múltiplo. El cálculo de theNestruo podría ser muy correcto.

[Lizardos]

Cierto, a 320x92 también funciona bien. Parece que a 8 bits los gráficos tener un tamaño múltiplo de 4 (32 bits).
Queda pendiente el tema de la rotación en el sentido del reloj, a ver si alguien sabe algo.

Saludos y gracias a los tres, Lizardos.

[oankali]

Lo de la rotación es normal, ya que todas las funciones del SDK siguen el patrón de la pantalla, ya que así, en principio, se consigue un mejor rendimiento.
Las coordenadas reales de la pantalla en memória son las siguientes:


239, 0 ------ 239, 319
| |
| |
| |
0, 0 ------ 0, 319

Pero si utilizas las funciones del SDK y alguna utilidad como GP32Converter.exe que ya te rota los gráficos al pasarlos a C, pues no tienes que preocuparte por la rotación.
Solo si quieres acceder directamente a la pantalla necesitarás hacer las conversiones pertinentes.

Oankali

[Aiken]

tienes que usar multiplos de 4, al menos en 8bits que es lo que he probado yo.

Aiken

[oankali]

Tenía un ratito para perder y al ver lo raro que tienes el texto, me he permitido rehacer tu menú con photoshop, a ver que te parece. La paleta utilizada es la paleta por defecto de la GP32.

Un saludo, Oankali.

[Lizardos]

Escrito originalmente por oankali

Pero si utilizas las funciones del SDK y alguna utilidad como GP32Converter.exe que ya te rota los gráficos al pasarlos a C, pues no tienes que preocuparte por la rotación.
Solo si quieres acceder directamente a la pantalla necesitarás hacer las conversiones pertinentes.

Oankali

Tiene buena pinta... a descargarlo! XD Me será util para convertir gráficos a 16 bits (el que uso ahora solo va a 8 o 24). Por cierto los GPG están ya rotados y su estructura es una cabecera de 8 bytes y despues la imagen en crudo no?
Ya había visto varios conversores de bitmap a C, pero dibujar en hexadecimal me da morbo :D no, prefiero archivos externos para los gráficos (permiten cargas dinámicas y retoques más sencillos) y la herramienta que había visto para generarlos, el DevUtil 2.0, es bastante... 'ortopédica', me dio tantos problemas para generar fuentes que lo dejé.
Por cierto el autor del Gp32Converter (Edorul) también tiene imágenes de un Rogue en su página (buenos gráficos, necesito mejorar eso). Pero no las renueva desde el 2002, y tampoco tiene el fxe. Por lo que he leído en los foros de gp32x el proyecto está muerto. También he visto muchos intentos de portar Nethack pero sin novedades.

Gracias Oankali, acabo de ver que me has retocado el menú mientras escribía esto (lo hice un poco a la bulla) :D. Ahora lo pego. La paleta que uso es la estandar excepto los 16 primeros colores, que son los colores del modo texto de la VGA (BLACK, BLUE, GREEN, CYAN, etc). Si alguien se quiere currar los menus (cosa que yo dejaba para el final) puede usar 240 colores para hacerlos (me reservo los 16 del modo texto).

Saludos, Lizardos.