¡Fenixero al borde del abismo :(!

[Rivroner]

Pues eso compañeros, que me atasco con lo más tonto, al final voy a tener que hacer una aventura conversacional y ni eso. :quepalmo:

Pues resulta que modifico un fpg que está en 8 bits y sustituyo los gráficos del personaje original por los mios (son de 32 bits y no sé como transformarlos ni en Paint ni en Gimp) y los colores se ven bien, y el fondo es negro igual que los originales pero no sé porqué cohones en pantalla jugando no me detecta bien las colisiones con el suelo de mi personaje, sí lo hace bien con el original.

Mi personaje toca fondo y puedo saltar y todo pero se queda hundido hasta la mitad del suelo. :confused:

Vamos, que el original se queda con los pies en el suelo como debe ser y el mio con la cintura al nivel del suelo y los pies enterrados. [wei2]

He probado de todo pero no hay manera.

El FPG es de 8 bits, tengo puesto el programa a 16 bits a 320x240 y los gráficos que meto son de 32 bits. [wei]

He probado a ponerlo todo en 8 bits menos los gráficos de mi personaje que introduzco en el fpg de 8 bits.( si alguien me dice como transformarlo por si fuera este el problema.)

Tb he probado a ponerlo todo en 16 bits y nada.

Ni esta chorrada me sale bien. :D


Gracias, me voy a la cama, cuando me despierte os respondo. :brindis:

[Darumo]

Es sencillo una vez lo sabes, lo que te pasa es por que tiene indicados el centro de coordenadas abajo del dibujo a la altura de los pies (asi cuando pones ese dibujo en X=100,y=100 ahi estara el pie del personaje y no el centro del personaje), en el DIV GAMES STUDIO (de donde viene el formato FPG) podias marcar el "CENTRO" (o si quieres imaginartelo como una chincheta, tu imagen tiene la chincheta en el centro y el dibujo en el FPG original en el pie)

Puedes mirar si el editor que usas para FPG te deja hacerlo, o modificar la programacion y añadir esa diferencia entre tu CENTRO y el del original.

[Drumpi]

Con el FPGEdit puedes cambiar dicho "centro", lo que realmente se conoce como "punto de control".
Los FPG y MAP permiten definir un total de 100 puntos de control por gráfico, siendo el 0 el "centro" del dibujo, es decir, la referencia. Ese punto se dibujará en las coordenadas X e Y del proceso, tambien sirve de centro en las rotaciones, etc... Si no se define por defecto estará en el centro del gráfico.
El resto de puntos se usan como referencia, por ejemplo, para colocar un arma, un brazo o lo que quieras, y puedes obtener sus coordenadas relativas con get_point, o absolutas respecto a la pantalla con get_real_point. Ideal para animaciones vectoriales, o como las de algunos monstruos del Castlevania...

[GameMaster]

Rivroner parece que estas teniendo pesadillas cada vez más intensas con Fenix :)
Venga, veras que poco a poco lo dominarás, hasta que seas el amo absoluto :lamer:
(No estas sólo, tambien las voy teniendo de vez en cuando :D)

[Drumpi]

Todos tenemos pesadillas con Fenix alguna vez... en ocasiones de la forma más literal (con dolor de cabeza por el sobreesfuerzo).
No hay que desanimarse, hay que ser más cabezota que el PC y tomarse las cosas con calma. Nadie nace sabiendo.

[GameMaster]

Drumpi he traido mis Gp2x para probar tu Bennu runtime y resulta que me olvide de los cargadores ;) La opcion alcalinas parece que tendra que ser la solucion momentanea (no quiero comprar mas pilas que las 2 que tengo del mando wii). Donde tienes la ultima revision del runtime ?, me estoy liando con tantos foros que tienes abiertos sobre el tema.

[Drumpi]

Sólo tengo una, y es la que está en el foro de Fenix de la sección de GP2X, copio el enlace:
http://www.fenixworld.com/e107_plugins//depot/files/fw75.bennugp2x.zip
Por desgracia he comprobado que sólo va a funcionar en el firm Open2X, porque es con las toolchains que he compilado. He intentado que me funcione en modo compatibilidad (que parece que se comporta igual que el firm oficial) añadiendo las librerías que me pedía, pero algunas me las buscaba en /libs, dentro de lo que es el firm (ruta absoluta), y como no puedo cambiarla de dirección ni sobreescribirlas (peligro de ladrillo), pues no se puede hasta que lo recompile con el SDK oficial (y dado mi nivel de sabiduria por estos lares...).
Si quieres reintentarlo: http://www.fenixworld.com/e107_plugins//depot/files/fw75.gp2xlibs.rar

[Rivroner]

A ver, con el FPGEDIT miré eso del centro de gravedad, y en el original estaba en el centro, por eso no he cambiado el mio, probaré a ver. :)

Mira que como sea esa chorrada. :D

EDITO:Pues si es eso no consigo que me lo coja bien.Pooto FPGEDIT2005 en Win7 que se me ve todo con NULL. :D

Le he puesto el punto debajo en el centro y luego abajo en la izquierda poruq emi personaje tien las piernas en así ^ en V invertida pero nada.Eso lo he hecho por si acaso la colisión de la dureza con lo rojo de la dureza no la hace con la zona negra (la que es transaprente) sino con el gráfico en sí.

Y me he fijado en otra cosa, en mi código (el del Malvado digo :D) no hay ningún código explícito para comparar el rgb 255 del rojo con nada, vamos como si lo hiciera por defecto el Fenix o algo así, ¿puede ser ese el problema? Pero lo que no entoendo es por qué con el personaje original (y teniendo el puntito de la gravedad en el centro) si que se queda como debe. O_o

EL PNG de mi personaje está a 32 bits (no sé como cambiarlo) pero tiene 255 colores realmente.

Ains...


MEGA SUPER EDITO :D :

¡Síiiiiiiiiiiiiiiiiiiiiiiiiiiii :D, ha sido cambiar el idioma al FPGEDTI2005 al inglés y enseguida he visto cual era mi fallo. :D Ya tengo el muñequito bien colocao. :) Por cierto, la ayuda la he encontrado aquí mismo :D: http://www.gp32spain.com/foros/archive/index.php/t-12062.html

Gracias por la ayuda chicos. ;) ¡Volveré!

Me gustaría poder ayudar yo alguna vez pero de momento ya veis en lo que estoy atascado, como par aponerme a resolver las dudas de Aiken que pregunta una de cosas más raras para mí. :D

[Drumpi]

Segun creo recordar, el "Malvado" está hecho a 256 colores, por lo que el color 255 no es rojo, sino el que está en dicha posición de la paleta (puede ser cualquiera, pues a cada posición de la paleta le podemos definir el color que queramos, INCLUSO DURANTE EL JUEGO), por eso no se compara.
Get_pixel y familia devuelve el ID de un color. (Hay 256 IDs en modo 8 bits, 2^16 en modo 16 bits y 2^32 en modo 32 bits)
Get_rgb devuelve las componentes RGB de un ID de color.

[Rivroner]

Gracias Drumpi, pero ya ves como meto yo eso en el código del Malvado que estoy modificando. :D

No doy pa más :(

[Drumpi]

Pues en el otro mensaje de durezas he dado un truco: poner los colores que usas de durezas en los primeros pixels del mapa, así sólo tienes que hacer map_get_pixel a cada uno y almacenarlos en una variable, con lo que luego sólo tienes que hacer de nuevo map_get_pixel sobre el mapa y compararlo con dichas variables, no se si me explico.

[GameMaster]

Mañana miro lo de Bennu en las Gp2x, pero me estabas comentando lo del ladrillo. Tengo riesgo de ladrillo (sino ni pensarlo vamos) ? :)

[Drumpi]

Riesgo de ladrillo hay SI COPIAS EN LAS CARPETAS DEL SISTEMA. Pero lo que yo quería era meter las librerías necesarias junto al runtime y que funcionase, pero no puede ser debido a las rutas absolutas que usa la libc.so, y tampoco puedo copiar las librerías en donde dice la libc.so porque ya existen unas con el mismo nombre y habría que sobreescribirlas, y entonces el resto del sistema... vamos, que hay que instalar el firm completo Open2x a menos que consiga que el cygwin compile con el SDK oficial, que como ya he dicho, NPI.

Por eso sugiero que si hay alguien que domine la programación de forma más "profesional" (porque lo mio es Fenix y dev-c++) que lo compile, porque yo dependo de splinter para hacerlo, y ahora estoy centrado en el motor de tiles y el PFC.
:llorosa::llorosa::llorosa::llorosa:

[GameMaster]

Yo lo que no entiendo, es que Sandman ya hizo un port de una version antigua, y porque no saca una actual ? No seria muy distinto volver a compilarlo o no ? Pero tambien te estuvo ayudando... que hay de nuevo que os este impidiendo hacerlo ? La verdad estoy un poco perdido o algo se me escapa, y no he entendido muy bien porque actualmente existe esta situación.

Tampoco voy a correr el riesgo del ladrillo, si es solo copiar en la SD no tendria problemas para hacer pruebas, desde que este de lejos lo del ladrillo, y yo tengo los firmware originales.

[Drumpi]

Sandman portó la wip33, y tenía serios problemas: no funcionaba el modo 16 bits y perdía rendimiento de forma bestial al hacer un desplazamiento de gráficos.
Después de aquello no pudo seguir... porque se quedó sin adaptador de corriente, y si no le funciona la GP2X poco puede portar.
Y en realidad es algo sencillo de hacer... cuando sabes, claro. Yo ahora lo tengo motado de forma que cada vez que Splinter actualiza el SVN sólo tengo que descargar los .c nuevos y hacer MAKE para tener la última version (de hecho, ahora tengo una más moderna que la última snapshot, creo que la r107).
Pero si tengo que cambiar las toolchains, debo cambiar direcciones de librerías a mano, recompilar librerías que no vienen en el firm y hacer algunos cambios en los makefiles (los cuales están en chino para mi) para sortear los errores que de el compilador.
Súmale lo dicho a lo que estoy centrado y a una falta de tiempo bestial y tienes la razón de por qué no hay nada por mi parte.

[GameMaster]

Vale, gracias por la explicación. A ver si me meto de una vez con las SDK's de estas consolas para ver si puedo ayudar en algo en un futuro cercano.