He compilado el código fuente de la última versión de fenix de CVS (que he visto que es la última que dejó Splinter antes de pasarse a Bennu) para PSP y sorprendentemente va todo casi a la primera. El cambio de colores en el load_png y load_pcx no se producen aqui (los colores son los buenos que se dibujaron), pero sí se produce en el put_screen (cambia lo colores), misterios de la ciencia :D
En fenix sí que he podico crear el compilador para PSP y que funcione, pero tanto el compilador de PC como el de PSP sueltan el mismo .dcb (es decir no invierten colores y el de psp funciona perfecton en PC y el de PC funciona igual que el de PSP en la PSP, cambia colores de la imagen del put_screen)
http://www.mediafire.com/?9k54gun39y8jv1l
ese no es el ultimo
con lo que decis, ya imagino cual es el problema
El problema gordo de los ports de Fenix (sí, me refiero al de GP2X) es que no carga librerías, no hubo manera de que admitiera la image.dll, la fire.dll, o las de Tristan :(
(Algún fallo le tengo que sacar, por el bien de mi autoestima ;D).
estoy casi seguro que los de 32bits en modo 32bits funciona bien.
creo que también fallaban las imagenes de 32 bits en el modo 32 bit en el bennu, pero haré el test y te lo diré para asegurarme.
Porta la version 0.82 (no me acuerdo el numero de versión), pero fué el primer Fenix portado a Gp2x.
Como tiene diferencias en relación a la versión siguiente, me vendria muy bien para portar mis juegos de Fenix mientras Bennu no rule en condiciones.
La primera versión portada de Fenix a GP2X fue la 084a, la versión más inestable de la historia de Fenix (fue donde se añadieron varios tipos nuevos de variables, entre otros, los float). La 083b es mucho mejor, o si no la 084preB.
Tampoco es plan de portar miles de versiones de fenix, sino esto va a parecer un gallinero, nens. Lo suyo es usar bennu que es fenix pero con miles de bugs mejorados y esto es lo que hay que fomentar, lo que yo hice fue una prueba para ver si era culpa de los cambios de bennu el que no funcionase el compilador de Bennu en PSP, cosa que he visto que sí. Ahora sé un poco más , a ver si corrijo el problemilla :D.
A ver, no creo que sea tan dificil hacer rular un código de fenix 0.82 en el 0.92 (que creo que es el último que hay en CVS, como CVS no va por "r"s como SVN es mas dificil controlar qué version corresponde a qué CVS, solo puedo decir que he portado el código que hay en CVS a día de 2007-05-30 con ligeras modificaciones para rularlo en psp)
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.
La inestable era la 084b, la 084 a secas (no recuerdo una 084a o preB) en muchos apartados era mejor como que no lanzara la ventana de comandos, mejoras en los dirty recs, rendimiento, floats (aquí si iban), etc..
Las siguientes versiones de Fenix partian del código de la 084b, en lugar de la 084 y hasta la 087 no se llegaron a arreglar todos los errores que arrastraba de más esa versión.
La última de Fenix es la 093pre9, de esta solo hay los binarios, el código disponible llega hasta la 092, la cual tiene bugs y pierde mucho rendimiento incluso en comparación con la 091, pero existe código de la 093 (versión a secas, ninguna preview) pues se llego a portar esa versión a algun otro SO.
Pues splinter es el que tiene las respuestas, ya que fué el último en tocar cosas, y no sé por qué me da la impresión de que perdió el código de la 93 pre9 con su último problema en el ordenador :D.
sinceramente no veo el sentido de todo esto... por que no me decis realmente que modos y que profundidad de png funcionan y cuales no...
ahora si te queres meter en hacer un nuevo fork de fenix, adelante... pero que no funcione el compilador no tiene que ver con los cambios sino con alguna dll o funcion que use, o tal vez con el configure o make... ya que el codigo y mas del compilador es exclusivamente ansi C...
ahhhhhhhh, creo que ya se porque no te anda, vos dijiste que para que te funcione el bgdi tuviste que usar el SDL_main, que hacia algunas incializaciones necesarias en PSP, bueno, el compilador de bennugd no usa SDL para nada, en cambio en fenix si lo usa, proba usando SDL_main o haciendo las inicializaciones que hace SDL_main.
Quote from: DCelso on January 26, 2011, 03:29:21 PM
Pues splinter es el que tiene las respuestas, ya que fué el último en tocar cosas, y no sé por qué me da la impresión de que perdió el código de la 93 pre9 con su último problema en el ordenador :D.
no se que pelicula te estas haciendo, pero bueno, por otro lado, si pensas usar alguna version fenix previa a la 0.93pre, estas cometiendo un grave error... pero bueno, alla tu... adelante y suerte con eso...
Splinter, no yo no quiero hacer renacer a fenix, que no digo que no estuviera mal, yo compilé la versión de CVS porque es la última que conocía del códifo fuente de fenix antes de que slaine le volviera a menter mano y sacara la versión que actualmente hay en SVN (del 2008) y creo que para la que no hay binarios.
Si tu me dices donde consegur la 0.93pre9 o me la pasas uso esta para probar el port de psp pero mi idea no es seguir con fenix, para nada, me gustaría hacer funcionar a bennu, no quiero echar por tierra todas tus mejoras introducidas (ni menos aún entrar en un camino sin fin como un fork :D)
Lo de SDL_main, he porbado por activa y por pasiva mil formas de hacer rular el bgdc de PSP, el problema es que la unión de todos los .o, genera un binario malo que no puede ejecutar la PSP, he estado haciendo pruebas de eliminación de dependencias de .o y he sacado que el .o maldito que hace que no se ejecute bgdc en la psp se encuentre en uno de estos, estoy acotando poco a poco para ver si descubro al culpable (y lo llevo a la carcel :D).
# $(BUILD_DIR)/src/c_main.o $(BUILD_DIR)/src/c_code.o $(BUILD_DIR)/src/c_data.o $(BUILD_DIR)/src/token.o
# $(BUILD_DIR)/src/codeblock.o $(BUILD_DIR)/src/constants.o $(BUILD_DIR)/src/sysstub.o $(BUILD_DIR)/src/varspace.o $(BUILD_DIR)/src/procedure.o
# $(BUILD_DIR)/src/dcbw.o $(BUILD_DIR)/src/segment.o $(BUILD_DIR)/src/typedef.o
Sí, son muchos lo se, pero son muy dependientes unos de otros lo que me enlentece las pruebas de búsqueda y captura.
si quieres hacer un fork, o echar o no por tierra todas las mejoras introducidas, no hay porque lamentarse, antes puede ser, ahora ya no... si quieres hacerlo adelante, para eso estan los fuentes de fenix, para que alguien los continue o retome en la version que se le de la gana.
los fuentes de la 0.93pre9 no estan mas...
¿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.
se perdieron
Que paranoia...
Si se perdieron, la version que ha sacado DCElso pasa a ser la ultima existente ;D
Logicamente...
Quote from: DCelso on January 26, 2011, 03:24:12 PM
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
Quote from: FreeYourMind on January 26, 2011, 04:28:15 PM
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.
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?
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.
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.
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.
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.
¿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...
He buscado un poco en google, copio y pego por si sirve de ayuda :
QuoteThe 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
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.
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.
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
proba en el files_st.h cambiar
#if defined(TARGET_CAANOO) || defined(TARGET_GP2X_WIZ)
#define __MAX_PATH 260
#else
#define __MAX_PATH 32768
#endif
y por
#ifdef _WIN32
#define __MAX_PATH 32768
#else
#define __MAX_PATH 260
#endif
DCelso, no sé si será demasiada molestia, pero, ¿cómo ves para firmar el bgdi para ejecutarlo en PSPs no flasheadas? :D
Este finde voy a estar en un evento gamedev y me encantaría poder mostrarlo :)
Pixel, pero si hasta un bebé de 3 años podría hacerlo.
http://psp.scenebeta.com/noticia/pscrypter
Otra cosa es que funcione :D.
Spliter, ok, probando.
MADRE DE DIOS!! :D
YIBA YIBA YIBA!!!!!!! :D :D :D
Quote from: SplinterGU on January 26, 2011, 06:24:37 PM
proba en el files_st.h cambiar
#if defined(TARGET_CAANOO) || defined(TARGET_GP2X_WIZ)
#define __MAX_PATH 260
#else
#define __MAX_PATH 32768
#endif
y por
#ifdef _WIN32
#define __MAX_PATH 32768
#else
#define __MAX_PATH 260
#endif
Bingo!!!!!!!, dios en la vida lo hubiese encontrado.
voooy a compilar el codigo bueno de bgdc a ver si se ejecuta bien ahoraaaaa. Gracias, Splinter.
ya me funciona tambien en dingux!
:D
gracias por encontrar que el problema era el token.c.
cuando pusiste el token.c me imagine que lo unico que podia ser era la memoria, asi que busque los arrays fijos, pensaba que era el files[] donde se almacenan los nombres de los files que se van cargando, efectivamente era eso, pero yo pensaba que era por la cantidad maxima, pero cuando vi el valor que tenia (4096) me imagine que eso no era, luego veo que estan definidas [MAX_FILES][MAX_PATH] y como hace poco cambie el MAX_PATH a 32768 en todo lo distinto a wiz y caanoo, dije ahi esta el problema...
ahora directamente lo cambie que solo lo haga en windows, solo los FS windows pueden tener paths tan grandes, aunque tambien es cierto que podemos leer fs windows desde linux, pero bueno, por ahora solo lo dejo a _win32.
ahora subo el cambio...
nuevamente, gracias por el trabajo de investigacion.
Aplausos a los dos! :D
Gracias a ti, por tu paciencia, dita sea que fuera eso tan tonto lo que generase un binario inválido :D.
de nada...
si, todas las pistas me hicieron pensar en la memoria, el mensaje "Killed" que daba en la dingoo + todo lo que me dijiste.
ahora me gustaria un set de pruebas completas, con todos los tipos de profundidad de video y de png, lo mismo para los pcx, todo lo que sea posible hacer, asi yo con eso imagino que puede ser.
Quote from: SplinterGU on January 26, 2011, 06:16:15 PM
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.
Splinter, ¿eso significa que vas a hacer una versión monolítica oficial?. Porque pensaba actualizar mi versión monolítica para Wii para que se pareciera más a la versión de DCelso, pero si vas a hacer una oficial, me espero y baso mis ports a Wii/iOS en ella.
PD: Como esto al final ha resultado ser útil, ¿alguien tiene alguna objeción con que lo cambie a la sección "General"?
si, tengo que plantear un cambio a una version monolitica oficial... obviamente con todas las limitaciones que eso implica, pero bueno, sera compilacion condicional, y seguramente a raiz de eso tengo que cambiar todo el arbol de directorios actuales, con lo organizadito que estaba.
Bueno, entonces seguiré con mi versión monolítica de momento y cuando salga la oficial, cambiaré a tu arquitectura que seguro que es más limpia que la mía. Así me será más fácil trastear con mis cacharros.
Por cierto, después de exámenes le meteré al port a la Wii soporte probado para Wiimotion plus, por si a alguien le interesa :)
Rayos, se me han acabado las palomitas, voy a hacer más.
Mientras, Karma a Mr Jones y Ms Croft por la trepidante aventura de arqueología informática (ya que cada uno escoja su personaje :D).
Quote from: josebita on January 26, 2011, 11:51:11 PM
Bueno, entonces seguiré con mi versión monolítica de momento y cuando salga la oficial, cambiaré a tu arquitectura que seguro que es más limpia que la mía. Así me será más fácil trastear con mis cacharros.
Por cierto, después de exámenes le meteré al port a la Wii soporte probado para Wiimotion plus, por si a alguien le interesa :)
si, yo no queria hacerlo, pero veo que sera necesario para algunos dispositivos... la idea sera que luego todos los cambios que vayan encontrando necesarios para los equipos especiales que requieran un monolitico se vayan incorporando en la version oficial, lamentablemente yo no me encargare de la generacion de los paquetes binarios porque no tengo los equipos para trastearlos, pero eso lo podran hacer Uds. usando la version oficial.
Quote from: SplinterGU on January 27, 2011, 12:24:13 AM
Quote from: josebita on January 26, 2011, 11:51:11 PM
Bueno, entonces seguiré con mi versión monolítica de momento y cuando salga la oficial, cambiaré a tu arquitectura que seguro que es más limpia que la mía. Así me será más fácil trastear con mis cacharros.
Por cierto, después de exámenes le meteré al port a la Wii soporte probado para Wiimotion plus, por si a alguien le interesa :)
si, yo no queria hacerlo, pero veo que sera necesario para algunos dispositivos... la idea sera que luego todos los cambios que vayan encontrando necesarios para los equipos especiales que requieran un monolitico se vayan incorporando en la version oficial, lamentablemente yo no me encargare de la generacion de los paquetes binarios porque no tengo los equipos para trastearlos, pero eso lo podran hacer Uds. usando la version oficial.
Me parece un plan excelente :) Por mi parte, en cuanto saques tiempo para hacerlo, te enviaré mi parche para la Wii y yo me encargaré de ir generando los binarios según vayas actualizando Bennu.
Es una pena que haya que hacer estas cosas para según qué dispositivos, pero parece que en algunos campos es lo habitual.
cualquier cosa, siempre puedes poner los parches de la version wii en tu version, y usar la base el codigo oficial, pero es mejor que una vez bien depurados se pasen a oficial...
Hombre, una versión monolítica sería de ayuda en algunos casos, y teniendo el código fuente, pues se pueden generar binarios y añadir a mano sólo los módulos que se necesiten o los no oficiales que se quieran incluir.
Además, permitiría generar un binario y firmarlo para que funcione en sitios como FunGP o en la appStore (incluir el DCB en el ejecutable también sería una posibilidad interesante para evitar las pegas legales que le puedan poner por ser un formato multiplataforma y poderse jugar en PC de forma gratuita, a poco que sepas cómo funciona Bennu).
Pero como siempre, es algo que no corre prisa,