Fenix PSP

[DCelso]

¿como que no están mas? ¿los perdiste? o no los quieres dar :D.

Por cierto lo de los colores tiene que ser algo con saltarse a mano las funciones sdl para modificar un sdl_surface, he hecho ejemplos con SDL a secas y todas las pruebas funcionan igual en PC que en PSP, es decir, sdl abstrae la inversión de bytes del sistema sobre el que rula.

[SplinterGU]

se perdieron

[FreeYourMind]

Que paranoia...
Si se perdieron, la version que ha sacado DCElso pasa a ser la ultima existente  ;D
Logicamente...

[FreeYourMind]

Free, dime qué cambios hacen que no funcione el código de fenix 0.82 y miro a ver si puedo darle retrocompatibilidad al código. Saludos.

Creo recordar que eran varios, como el funcionamiento de los write text, los fades, entre otras, si mal recuerdo estoy hablando de la 0.82, que fue la ultima que utilize de Fenix, ya que me resisti a adaptar los juegos a la siguiente, por estas diferencias, que ahora me hacen gracia, pero antes me suponian un autentico dolor de cabeza adaptar toda la mierda distinta que salia en la nueva xDDD

[SplinterGU]

Que paranoia...
Si se perdieron, la version que ha sacado DCElso pasa a ser la ultima existente  ;D
Logicamente...

la version del cvs no tiene los cambios de la 0.93pre9, que eran importantes y varios.

[SplinterGU]

DCelso, pone en el main del bgdc un printf + fflush(stdout) o graba algo a un archivo o hace algo que te des cuenta si entra o no en el main...

quizas te pase lo mismo que a mi en dingux, que directamente no arranca el bgdc, no entra ni al main... y eso no tiene que ver con cambios sino con la forma de generar el ejecutable (configure o make)

a me serviria mucho si podes hacer esa prueba y decirme que pasa...

por otro lado, cuando decis que no funciona, a que te referis?

[DCelso]

Me refiero a eso mismo, que ni arranca.
El binario no es válido, ni se ejecuta. La psp me suelta el error de "no se pudo ejecutar el juego".
Y las pruebas que estoy realizando son las siguientes, dejar el main vacío , solo con un return y en el makefile linkar con todos los .o.
Esto genera el ejecutable, pero no arranca, no se ejecuta, no es válido o como quieras llamarlo, pero nos referimos a lo mismo.
luego he ido quitando .o del makefile hasta llegar a los que te he dicho, ahora el binario resultado sin esos .o se ejecuta correctamente en la PSP, y como es lógico se sale, porque hay un return, pero al menos la salida es exitosa, la psp no suelta nigun error de que no se pudo ejecutar el juego, ya que lo ejecutó pero su ejecución fue la que fue, rápida. :D.

[SplinterGU]

pero muchacho, eso no tiene nada que ver con los cambios en los binarios... que es la imagen que se dio aca, preguntando y respondiendo cosa de los write/fade y un largo etc.. que no tienen nada que ver con el compilador, ya que de hecho ni existen en el compilador...

eso tiene que ver con la generacion del ejecutable.

[DCelso]

lo se, son problemas distintos.
Te pongo al día.

Primero compilé el bgdi para PSP porque el bgdc se resistía.
Desde el pc generé un ejemplo .dcb que carga imágenes.
Con el bgdi compilado para psp y desde la psp cargué el ejemplo y aquí es donde se veían mal los colores.

El problema nos dijo josebita que se debía al bigendian/littleendian. Así que pensamos que compilando desde psp el dcb se resolvería el problema de cambio de colores.

Por eso retomé mi exfuerzos en portar el bgdc a psp, viendo que siempre me daba un ejecutable inválido, pensé joder que mierda, ¿le pasará lo mismo al código fenix ya que este es de por sí monolítico y no tiene mis cambios monolíticos?

Entonces pasé a compilar fenix para probar mi idea, tardé bastante menos tiempo en portarlo a psp, como es normal, gracias a lo aprendido en el por de bgdi.

Pues bien, los resultados de las pruebas realizadas son las siguientes:

* psp fenix en modo 16 bits carga las imágenes png de 8 bits perfectamente.

* psp fenix en modo 16 bits carga las imágenes png de 32 bits sin la componente azul, es decir el rojo y el verde se ven, pero el azul se convierte en negro y así todas sus mezclas.

* psp bennu en modo 16 bits carga las imágnes png de 8 bits invertidas, el azul donde va el rojo y viceversa.

* psp bennu en modo 16 bits carga las imágnes png de 32 bits invertidas, el azul donde va el rojo y viceversa.

Otras pruebas no he hecho debido a que no podría compararse bennu en 32 bits con ningún otro en fenix. pero sí que de los ejemplos anteriores sabemos que

*psp bennu en modo 32 bits carga las imágenes png de 32 bits invertdas.

Es decir bennu parece ser que siempre carga las imágenes invertidas en la psp.

[SplinterGU]

pero esa solucion es simple... hay 2 posibles soluciones.

1) hay que invertir las mascaras de rotaciones segun los endians o usar la configuracion que informa la SDL (cosa que asi fenix en algunos casos)

2) eliminar algunos arranges que posiblemente ya los este haciendo las lib externas

realmente me haria falta un sistema con estos endians, me seria tan simple resolver estas cosas, porque se donde hay que buscar.

[josebita]

¿Has probado a usar algún otro SDK para compilar el bgdc?. No hablo de usarlo de forma definitiva, pero quizás ayude a encontrar una solución...

PD: ¿Estais seguros de que la PSP es bigendian?. He encontrado el siguiente código en el google:
[code language="c"]int is_big_endian(void)
{
    union {
        uint32_t i;
        char c[4];
    } bint = {0x01020304};

    return bint.c[0] == 1;
}[/code]
¿Podríais probarlo?. Creo recordar que Daniel me dijo que le salía little-endian...

[BoMbErLiNk]

He buscado un poco en google, copio y pego por si sirve de ayuda :

The issue is that the PSP GPU takes little-endian to an all-time low. We all know the PSP has a little-endian CPU. It's rather like the x86 in that respect. No big deal. It makes a little difference in the graphics for converting games written for something like the Amiga or Mac where the CPU is big-endian. All your bytes are "backwards". Where a big-endian CPU interprets a longword this way,

Byte 0: bits 31-24, Byte 1: bits 23-16, Byte 2:bits 15-8, Byte 3:bits 7-0

a little-endian CPU interprets it this way,

Byte 3: bits 31-24, Byte 2: bits 23-16, Byte 1:bits 15-8, Byte 0:bits 7-0

No problem. Keep it in mind and you're fine. That clearly affects video modes with more than one byte per pixel. It clearly doesn't affect modes using one byte per pixel. Now the FREAKY part... and you WILL FREAK!

In sixteen color chunky graphics, each pixel takes four bits, so you can put two in every byte. But there's clearly two ways you could do it:

pixel 0: bits 7-4, pixel 1: bits 3-0

or

pixel 1: bits 7-4, pixel 0: bits 3-0


EVERY SINGLE COMPUTER AND VIDEO CARD IN THE UNIVERSE USES THE FIRST ORDERING!!!!!! So, now the million dollar question: which way doe the PSP's GU_PSM_T4 texture mode do it?? DING DING DING DING DING!!! You're right!! It does it the SECOND WAY. I always wondered why no one ever used four bit textures... I have yet to see a PSP app/game that did. Now I know why - people couldn't figure out why all their textures came out screwed up. So what you have to do is swap all the nibbles in the bytes of the texture:

Code:
    int i,j;
    for (j=0; j<576; j++)
        for (i=0; i<768/8; i++)
        {
            uint32 v = srp[j*768/8 + i];
            uint32 vv1 = (v>>4)&0x0F0F0F0F | (v<<4)&0xF0F0F0F0;
            dp[j*768/8 + i] = vv1;
        }


That's what I now do before passing the result on to a stretch blit set for GU_PSM_T4, and it works great. So now that you know the "trick", feel free to start using four bit textures. ;)

In my case, when I do my new video refresh routines, I just need to remember to do this swap. I'll probably use a logic op to handle it.

Fuente (ps2dev) :
http://forums.ps2dev.org/viewtopic.php?t=3741&postdays=0&postorder=asc&start=300

[DCelso]

el problema de compilación lo produce token.o, he probado a compilar sin el, simulando las referencias no definidas que se producen sin él, y mágicamente funciona el binario final, será cuestión de ver porqué el .o generado de token.c da un binario malo.

En cuanto al endian y los colores, voy a mirar, pero lo que me dice Splinter es lo que concuerda, SDL de psp usa mascaras distintas que SDL PC, y si fenix usaba la info de máscaras de SDL a veces es por eso que va con imagenes de 8 bits correctamente. Splinter, eres mi ídolo, si arreglas eso lo pruebo en un plisplas y mientras voy a mirar también lo del token.c.

Gracias a todos, realmente sois de gran ayudaaaa.

[SplinterGU]

yo tengo pensado hacer una version bennugd, igual a como tenia el sistema fenix, con esto me refiero a eliminar en esa compilacion todo el sistema de fixups y todo, pero tengo que montar un sistema simple de hacer y publicar las funciones, que sirva para los 2 metodos... ya lo tengo pensado, solo tengo que implementarlo.

[DCelso]

jouas, splinterGU, me reitero, eres mi ídolo, tonces si vas a hacer eso saldrán ports para casi cualquier sistema dentro de poco :D.

En cuanto al resultado de josebas, efectivamente, psp es little_endian, el ejemplo devuelve 0. Ya me extrañaba a mi que funcionase tan bien los dcbs de linux en la psp a fallos nada más que del color. :D