Ver la versión completa : Lista de consolas portátiles retro...
Sí que hay, sí... XD
https://docs.google.com/spreadsheets/d/1irg60f9qsZOkhp0cwOU7Cy4rJQeyusEUzTNQzhoTYTU/htmlview#gid=0
Mierda, me faltan muchas XD
He visto que la RGB-30 con pantalla 1:1 de N64 para arriba va regulera...
fbustamante
06/10/2023, 21:49
A cualquier cosa le llaman retro. XD
Y encima faltan las fotos de las más antiguas.
wolf_noir
07/10/2023, 12:51
:D el 95% de esa lista, no sé si considerarla videoconsolas portátiles retro xD....
blindrulo
07/10/2023, 13:12
Creo que confunden consolas retro con consolas que emulan consolas retro.
un slaudo. :brindis:
fbustamante
07/10/2023, 14:30
Y en 'Presumed Dead' no han puesto la Viciosa. [wei2]
El que ha hecho esta lista es un 'shaval de 30 años'. :D
wolf_noir
07/10/2023, 15:30
falta la gasanco xD
fbustamante
07/10/2023, 15:36
También, también... :D
Pos yo no he visto la GameGear...
¿Pero qué queréis? si los chinos sólo hacen más que copiarse, y en cuanto sale una consola, a los dos meses (tm) ya hay cuatro empresas chinas que han hecho la misma consola con distinta carcasa y distinto nombre... y luego, aparte, las que se copian a sí mismas, que crean una nueva versión con una carcasa diferente, o un SO distinto, o la siguiente versión del SOC.
Como ya no hay una consola portátil concreta para la que desarrollar homebrew, ya paso del tema. Tengo la RG350 muerta de asco, la he cogido, literalmente, 4 veces, y como no he conseguido hacer funcionar correctamente el "Echo", ya ni me he molestado en actualizar el firm desde que la compré (además, para hacerlo, tengo que abrir la consola para sacar la SD).
saboteur
09/10/2023, 13:27
Pues yo recuerdo que tenía el Echo funcionando perfectamente, eso sí, con el SO Rogue, el "oficial" tenía varias cosas rotas.
De "Echo", lo tenía en el repositorio de github del que tira la Rogue Store, xD.
A ver, en su día hice un port para el firm oficial... pero había algo chungo en el SO porque no me dejaba usar los binarios de OpenDingux que me descargué del repositorio oficial de BennuGD. Por alguna razón que no acababa de entender, el script de arranque cargaba los binarios que venían instalados, que eran de una versión bastante antigua, y eso me obligó a generar unos binarios de dicha versión (si yo usaba la RC360, tuve que usar la RC333).
Si todo hubiera funcionado bien, pues de lujo, pero es que dicha versión produce problemas en las rotaciones de los sprites, y pone pixels donde no debería, y eso provoca que las colisiones de algunos bosses sean "erráticas": no hay forma de superar al dragón de la tercera pantalla del nivel 1.
Lo que no quiero es tener que andar creando una versión para SO oficial, otra para "rogue"... de cara al usuario tengo que crear un zip que sea descomprimir y usar. Punto. Cualquier otra cosa no me vale. Si puedo hacer un paquete OpenDingux, pues perfecto, porque así funciona en todas las Anbernic y las que no lo sean, siempre que tengan Linux... u OpenDingux (aún no sé cuál es la diferencia).
Por eso, la próxima versión sólo saldrá para PC, y puede que compile para Wiz, pero quiero dar el salto a los mapas de 2 capas, y eso se le atraganta a la portátil.
fbustamante
09/10/2023, 16:00
... y eso se le atraganta a la portátil.
Eso es que eres muy malo programando y no tienes c0'ones. [wei]
Hijo de... :lol:
No, en serio, algo tiene que haber porque he hecho varias pruebas, como sustituir el motor de scroll tileado actual de 1 proceso por tile visible a 1 map/proceso por capa, o eliminar las colisiones de prota y enemigos (ambas cosas requerían cambios muy bestias en el código), que son las cosas que, generalmente, más CPU chupan, y no he notado cambio significativo... y sin embargo, encontré una versión muy antigua que apenas tenía colisiones o algo, e iba super fluida.
No sé qué será, si el algoritmo de renderizado o alguna función que en segundo plano está haciendo más de lo que quiero, pero no sé qué es lo que está haciendo que el juego se ralentice tanto, ni que pegue esos golpes cada vez que carga una nueva fila/columna.
Echo de menos un "profiler" para hacer la métrica de procesos... pero como nunca he usado ninguno, pues me quedo como estoy :D
fbustamante
09/10/2023, 21:46
¿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
masteries
10/10/2023, 00:02
Por eso, la próxima versión sólo saldrá para PC, y puede que compile para Wiz, pero quiero dar el salto a los mapas de 2 capas, y eso se le atraganta a la portátil.
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/showthread.php?75704-Fase-3-Viaje-al-Centro-de-la-Tierra-tile-scroll-engine-preview&highlight=viaje+al+centro+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-----
¿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
Claro, tienes que pintar; que para scrollear ya estoy yo xD
Echo de menos un "profiler" para hacer la métrica de procesos... pero como nunca he usado ninguno, pues me quedo como estoy :D
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.
¿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/showthread.php?75704-Fase-3-Viaje-al-Centro-de-la-Tierra-tile-scroll-engine-preview&highlight=viaje+al+centro+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 :D 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í.
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
10/10/2023, 16:28
- 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'. :lol:
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 :D
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'. :lol:
¿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 :D
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
10/10/2023, 21:03
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 :D
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. :D
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.