Lista de consolas portátiles retro...

[swapd0]

Echo de menos un "profiler" para hacer la métrica de procesos... pero como nunca he usado ninguno, pues me quedo como estoy

Con los fuentes de Fenix y BennuGD no seria complicado añadir una función que active una medición con un reloj de alta precisión lo que tarda cada proceso en ejecutarse. Se podría añadir como una variable mas a cada proceso, asi se puede mostrar y ver las subidas en uso de CPU o cuál consume mas.

[Drumpi]

¿Tú no estabas haciendo un nuevo scroll tileado dónde solo refrescabas el borde de la pantalla a modificar y el resto se movía por hardware?

Lo digo porque en su día hice uno y note bastante mejora en el redimiento, aunque nunca lo probé con dos capas.

Una segunda versión mucho más complicada que hice, donde intenté bajar más todavía en número de tiles que había que repintar, utilizando el anterior algoritmo, pero modificando sólo los tiles que cambiaban, apenas mejoró rendimiento y además era complicadísima, así que la descarté y me quedé con la primera.

Leches, que me vas a hacer que lo desempolve y lo pruebe con dos capas, ¡y no tengo tiempo! XD

Motores de scroll he hecho unos cuantos. He probado:
- Un proceso por tile.
- Un proceso por tile que no sea nulo.
- Un gráfico por capa (del tamaño de todo el mapa).
- Un gráfico por capa (de algo más de tamaño que la pantalla), dentro de un scroll cíclico.

Creo que te refieres a este último. Sí, lo probé en el Echo, pero con idéntico resultado. Voy a matizarlo en la siguiente respuesta.

GP2X mueve, y usando Fénix, scroll tileado a 80 cuadros sin despeinarse,
lo programé hace ya un poquito más de 13 años:

https://www.gp32spain.com/foros/show...o+de+la+tierra


Por cierto, que viene a ser el mismo engine de scroll tileado por streaming que uso para MegaDrive,
y ésta que es muchísimo más pobre en potencia, tampoco se despeina

Sólo que ahora ya lo hago todo en C , así va más mejor

-----Actualizado-----


Claro, tienes que pintar; que para scrollear ya estoy yo xD

No, si yo he probado los distintos motores de scroll, e incluso el menos eficiente, que es un proceso por tile, he podido tener más de 200 tiles en pantalla de Wiz yendo a... no voy a mentir, no recuerdo los FPS, pero muy por encima de 60fps.

Es más, he hecho prueba de diferentes motores, tanto en Wiz como en GP2X, con Fenix y con BennuGD, y ya digo que BennuGD es mucho más eficiente que Fenix en Wiz. En Gp2X no se nota tanta diferencia, pero claro, el port de BennuGD lo hice yo en mi más completa ignorancia A pesar de ello, usa menos memoria, va más rápido (del orden de un 10% de media), y el código es mucho más estable y flexible (quise volver a hacer un juego en Fénix en la GP2X y tuve que suspenderlo porque se me complicaba demasiado el paso de parámetros, y ya no recordaba cómo lidiar con los bugs conocidos).

Volviendo a lo que le decía a fbustamante, no es cosa del motor de scroll tileado, porque por sí solo funciona perfectamente: con una capa, con dos capas, usando procesos, gráficos o scroll. El problema está cuando lo integro con el Echo, que hay una bajada brutal de rendimiento. Ya no está sólo el scroll: hay enemigos, detección de durezas, colisiones con disparos y con el prota... Hay algo más que hace que todo se venga abajo y no sé lo que es.
Como digo, tengo una versión del Echo, de cuando el primer nivel estaba a medio hacer, en que todo funciona muy suave, a 50fps estables (es la velocidad estándar de mis juegos). Y está casi todo implementado. Creo que había algunas colisiones sin terminar, apenas había 3 enemigos diferentes... Algo pasó de esa versión a la siguiente pero repito, no sé lo que fue.

Incluso he probado distintas versiones del refresco de pantalla, configuraciones gráficas... ¿Puede que haya una transparencia activa por ahí que esté lastrando el juego? ¿He cargado una librería que antes no usaba?

Con los fuentes de Fenix y BennuGD no seria complicado añadir una función que active una medición con un reloj de alta precisión lo que tarda cada proceso en ejecutarse. Se podría añadir como una variable mas a cada proceso, asi se puede mostrar y ver las subidas en uso de CPU o cuál consume mas.

Pues el código fuente está en su repositorio, creo. SplinterGU cambió de repositorio, pero los fuentes siguen disponibles (y si no, yo debo tener la versión que usé en GP2X). En el foro está el enlace.
Más que el tiempo que tarda cada proceso, necesito saber si hay algún problema con las colisiones, el renderizado... o lo mismo es mi motor de scroll. No sé si es cosa de un proceso, de la suma de varios, o lo que sería el peor escenario, algo interno de BennuGD, que haya tantos sprites que el renderer tenga demasiada carga de trabajo, o algo así.

[swapd0]

Pues el código fuente está en su repositorio, creo. SplinterGU cambió de repositorio, pero los fuentes siguen disponibles (y si no, yo debo tener la versión que usé en GP2X). En el foro está el enlace.
Más que el tiempo que tarda cada proceso, necesito saber si hay algún problema con las colisiones, el renderizado... o lo mismo es mi motor de scroll. No sé si es cosa de un proceso, de la suma de varios, o lo que sería el peor escenario, algo interno de BennuGD, que haya tantos sprites que el renderer tenga demasiada carga de trabajo, o algo así.

Si, lo he bajado de github de SplinterGU, lo malo es que no hay version para OS-X y que esta todo con makefiles. Lo que no entiendo es que hay un repositorio llamado BennuGD2, yo me he bajado el otro.

[fbustamante]

- Un gráfico por capa (de algo más de tamaño que la pantalla), dentro de un scroll cíclico.

Creo que te refieres a este último. Sí, lo probé en el Echo, pero con idéntico resultado. Voy a matizarlo en la siguiente respuesta.

A ese me refería yo.

Tengo un nivel, no muy grande, pero que precisa de scroll, con unos 50 enemigos, y va de escándalo. (Mi problema, que todavía no resolví, es que todos los enemigos se juntan en uno y cuando disparas parece que sólo hay uno y no muere).

Para mí, como tu dices, te has dejado algun proceso sin matar por ahí y te está lastrando.

El Echo tiene muchos años, seguro que es código 'spagetti'.

[Drumpi]

Si, lo he bajado de github de SplinterGU, lo malo es que no hay version para OS-X y que esta todo con makefiles. Lo que no entiendo es que hay un repositorio llamado BennuGD2, yo me he bajado el otro.

Es que BennuGD se desarrolló en Linux, por lo que las herramientas que usa son de Linux. La versión de Windows la hace casi por compromiso
La de OS-X creo que la llevaban los de Colombian-developers, que no es un port realmente oficial. De hecho, creo que casi nadie lo usa :P

Lo de BennuGD2 es que SplinterGU decidió que iba siendo hora de romper totalmente con la compatibilidad con Fénix, y hacer las cosas a su manera... y de paso, arreglar algunas cosas. No recuerdo si iba a usar OpenGL o si eso era cosa del fork PixTudio. Creo que no, porque también digo que iba a hacer uso de las bondades de las SDLSurfaces, ya que tanto Fénix como Bennu usan una única SDLSurface para renderizarlo todo, y que eso lastraba bastante el rendimiento del renderizado... o eso creí haber entendido.
Yo Fénix y BennuGD los conozco a nivel de "usuario", aunque he intuido bastante cosillas internas mediante su uso y experimentación... y haberme leído el código de algunos módulos, para intentar meter el scroll tileado en una librería.

Que eso, que BennuGD2 es un proyecto aparte que empezó, y que dejó a medias por falta de interés, tanto suya como de la comunidad. Hay un hilo dedicado a ello en el foro de desarrollo.

A ese me refería yo.

Tengo un nivel, no muy grande, pero que precisa de scroll, con unos 50 enemigos, y va de escándalo. (Mi problema, que todavía no resolví, es que todos los enemigos se juntan en uno y cuando disparas parece que sólo hay uno y no muere).

Para mí, como tu dices, te has dejado algun proceso sin matar por ahí y te está lastrando.

El Echo tiene muchos años, seguro que es código 'spagetti'.

¿Llegué a liberar el motor ese? No recuerdo ^^U
A ver, lo de los enemigos, pues depende de la IA que hayas implementado: si todos se comportan igual y van al mismo punto de destino pues va a pasar eso, a menos que implementes colisiones entre ellos. Puedes intentar que no se comporten exactamente igual, o que se "equivoquen", eso hará que todo sea más orgánico.

Respecto al código del Echo, sí que tiene años, y tiene cosas que hay que mejorar... pero en cada "major release", hay gran parte del código que es modificado. Vosotros es que veis sólo que se ha añadido un nuevo nivel o una nueva arma, pero por dentro hay una cantidad de código nuevo que ni os hacéis una idea: una vez reescribí el motor de scroll, en otra ocasión reescribí todos los procesos de control que cargaban los niveles, los assets y el juego... en esta versión lo he vuelto a reescribir para poder ejecutar niveles de forma independiente, para poder añadir niveles de testeo (sí, hasta hace un lustro, testeaba sobre los mismos mapas de juego, usando partidas salvadas para abrirlos ^^U).

Es más, ese código lo saqué de otro proyecto que no he lanzado, que fue la evolución del GoBaUg, que salió del Echo... todo evoluciona y se retroalimenta
Aparte, que el código está bastante estructurado, y hay muchas cosas, pero aunque todas se lanzan desde el mismo sitio, luego cada cosa va por su parte y es (casi) independiente del resto... Luego, cuando empecé con Unity, vi que usaba (salvando las distancias) un sistema muy parecido... y las diferencias que vi interesantes, las acabé metiendo también en el código.

[fbustamante]

A ver, lo de los enemigos, pues depende de la IA que hayas implementado: si todos se comportan igual y van al mismo punto de destino pues va a pasar eso, a menos que implementes colisiones entre ellos. Puedes intentar que no se comporten exactamente igual, o que se "equivoquen", eso hará que todo sea más orgánico.

Respecto al código del Echo, sí que tiene años, y tiene cosas que hay que mejorar... pero en cada "major release", hay gran parte del código que es modificado. Vosotros es que veis sólo que se ha añadido un nuevo nivel o una nueva arma, pero por dentro hay una cantidad de código nuevo que ni os hacéis una idea: una vez reescribí el motor de scroll, en otra ocasión reescribí todos los procesos de control que cargaban los niveles, los assets y el juego... en esta versión lo he vuelto a reescribir para poder ejecutar niveles de forma independiente, para poder añadir niveles de testeo (sí, hasta hace un lustro, testeaba sobre los mismos mapas de juego, usando partidas salvadas para abrirlos ^^U).

Es más, ese código lo saqué de otro proyecto que no he lanzado, que fue la evolución del GoBaUg, que salió del Echo... todo evoluciona y se retroalimenta
Aparte, que el código está bastante estructurado, y hay muchas cosas, pero aunque todas se lanzan desde el mismo sitio, luego cada cosa va por su parte y es (casi) independiente del resto... Luego, cuando empecé con Unity, vi que usaba (salvando las distancias) un sistema muy parecido... y las diferencias que vi interesantes, las acabé metiendo también en el código.

Si, ya me di cuenta con lo de la IA, sobre todo al ver cómo se comportan los enemigos de masteries.

Por cierto, mi motor ya es lo suficientemente estructura para hacer todo eso que me cuentas, y no soy programador.