Echo v1.4: road to season two

[Drumpi]

Hola a todos:

Acabado el Tilemap Editor 2 (o al menos, dado por "finalizado", de momento), antes de entrar en el periodo "entre proyectos", he decidido darle caña a un juego que lleva ya demasiados años en desarrollo, y que sólo pretendía ser un aperitivo para el juego de verdad.

El juego: "the amazing adventures of Echo". Objetivo: completar los tres niveles diseñados inicialmente, acabar el nivel extra creado en exclusiva para la versión 1.3 (la del concurso del hamster), y reordenar todo el código para dejarlo listo para "Doggy!!!".
Así que hoy empiezo otro worklog en el que iré diciendo los avances que vaya haciendo sobre el código, e iré subiendo a este mensaje  las betas que vaya completando. Así que empezamos.

[Drumpi]

Día 1: el momento de más ilusión de todo el proyecto, mezclado con el de más terror. Aunque el último día del desarrollo es el que más alegría da por tener el producto terminado, y el de más miedito es el día previo por la presión del tiempo, el primer día es una mezcla de ambos difícil de definir. Por un lado te has propuesto dar vida a algo nuevo, algo que llevas días, semanas e incluso meses preparando, y sabes que va a ser genial, tienes todas esas ideas en la cabeza, y sabes cómo quieres que quede, pero justo cuando te sientas delante del ordenador, comienzan las dudas, los sudores fríos, no sabes por dónde empezar y ves una montaña de trabajo del tamaño del Everest.

Pues en eso estoy.

Antes de empezar me he marcado una hoja de ruta, que espero poder seguir... más o menos. Quiero desviarme cuando el trabajo sea demasiado agobiante, e ir avanzando trabajo que no tenga nada que ver con lo que estoy haciendo, porque por suerte, hay trabajo de limpieza, programación, gráficos, diseño y música.

El primer paso es coger el código del Echo y reordenarlo. Aquellos que hayan tenido la osadía de leerlo, habrán visto que todos los ficheros de código están en la carpeta raiz, algo que en su día consideraba correcto porque no sabía compilar el código en otras carpetas. Hoy ya se hacerlo manteniendo sólo el prg principal y el bgdc.import.
Luego está el separar aun más el código porque cuando empiezas es normal tener 15 ficheros de código, pero lo he estado revisando y hay ficheros con más de 1000 lineas y más de 15 e incluso 20 procesos/funciones. Así que me toca reidentarlo todo, e intentar separar, por ejemplo, los eventos del código de los bosses, y agruparlos por niveles. O esas funciones que están en ficheros tipo game_generic.inc en separarlas si son de sonido, de carga de recursos, de búsqueda de enemigos...
Y finalmente volver a cambiar el sistema de carga de niveles, para que sea más modular y menos dependiente de lo que contenga el nivel (es decir, que dentro del switch del load_level, cada case no tenga más de 10 líneas).

Para el juego tengo previstos tres grandes cambios:
El primero es intentar cambiar el motor de scroll tileado por otro más rápido. Ya lo he comentado otras veces, que tengo en mente uno basado en dibujar en un mapa cíclico, y espero mejorar el rendimiento al menos un 30%, porque quiero que funcione fluido en Wiz sin overclock, y tener potencia de sobra para añadir nuevas cosas.
Eso nos lleva al segundo cambio: estaba previsto que la v1.3 tuviera fondos de scroll, e incluso scroll en primer plano... De hecho estaba previsto desde la v1.0, pero primero por falta de tiempo, y después por falta de potencia, no se ha añadido. También quería poder cargar los enemigos antes de empezar el nivel, o al menos, en bloque, para poder sincronizarlos, porque aquel que haya llegado al nivel 1-4, habrá visto que hay unos 8 "solecitos" juntos que, en teoría, deberían subir y bajar a la vez, pero como dependen del scroll tileado para ser creados... Y otro añadido gracias a la potencia extra sería una segunda capa a los mapas de tiles, porque hay partes del castillo del primer nivel, o de las pirámides del cuarto, que mejorarían muchísimo si se pudieran poner paredes detrás para que contrastasen con el fondo.
Y el tercer cambio es... ¿os habeis fijado que he llamado al nivel de Egipto "cuarto nivel"? Desde la versión 1.0, la fase "2012: alien invasion" siempre ha sido la tercera fase que se iba a desarrollar (aunque fue incluso la primera en tener parte del mapa y los gráficos ^^U). Pues esa es la idea: terminar el nivel de "Egipto" (porque la tercera pantalla, aun no desarrollada, es el verdadero núcleo del nivel) y crear esa "fase 2", que cambia el desarrollo plataformero ligeramente... aunque me estoy planteando ampliar la parte de las pirámides y crear un nuevo nivel en el que Echo luche contra momias y dioses egipcios mientras se abre paso hasta la cámara secreta que contiene la entrada a las cuevas que ya habeis visto y... No, me voy a guardar la sorpresa :D

También le quería dedicar tiempo, si es posible, a corregir el código del detector de durezas. Tiene un par de fallos que a más de uno os habrá hecho tiraros de los pelos, como intentar saltar a un pasillo de poca altura y no poder entrar hasta el tercer  cuarto intento, esos saltos frenados lateralmente por el techo, o los teletransportes contra las paredes cuando estábais cayendo.
Y añadir algunos detalles más, como mostrar los nombres de los bosses antes del combate.

Y una vez terminado ¿qué? Bueno, lo primero lanzarlo al público, como siempre. Versiones para Windows, Linux, Wiz/Caanoo y, si cabe, GP2X. Es posible que salgan otros ports, pero dependerá del tiempo, del HW disponible y/o de la colaboración ciudadana. Quería también subirlo a GameJolt, para tenerlo con el resto de proyectos, y de paso, probar su nueva función de compra. Don't panic, mi idea es ponerlo con donación voluntaria, ya que cada uno valore el esfuerzo.
Y si el tiempo me lo permite, iniciar una campaña de crowfunding, usando este juego como reclamo, para desarrollar finalmente "Doggy!!!" como un juego comercial. Usaría el mismo motor, pero el juego estaría más orientado a seguir una historia, más en la linea del Cave Story original, pero manteniendo las plataformas, los puzles y los disparos. Probablemente, si tiene el éxito que quiero, podría contratar a gente para que me eche una mano, porque necesitaré a alguien que me ayude con los gráficos, y me gustaría pagarle a Caleb por su música.

Es muchísimo trabajo, ahora que lo he escrito, pero bueno, como siempre digo: "...pero hay que intentarlo". Poco a poco.
La limpieza del código me puede llevar de una a tres semanas, y la reestructuración creo que un par de semanas más. Con eso hecho, poco habrá que programar (enemigos, bosses y cosillas sueltas). Corregir los fallos va a ser lo más duro, pero va a ir entre medias. El grueso del trabajo se lo va a llevar los gráficos y el diseño de niveles. Una vez terminado el nivel 4 como estaba planeado en la v1.4, sería cuestión de seguir con el nuevo nivel de Egipto o el nivel 2, ya se irá viendo.

En fin, de momento, ya he reorganizado la carpeta del proyecto: he copiado lo que tenía hecho, he organizado los contenidos extra en otras carpetas, he sacado los gráficos temporales a una carpeta de desarrollo de gráficos, y ya tengo los ficheros de código dentro de la carpeta src con sus respectivas subcarpetas. Empieza la reescritura. Deseadme suerte ^^U

[Drumpi]

Acabo de empezar y ya me he llevado la primera en la frente :(

He podido reidentar y ordenar unos cuantos ficheros: el sistema de música, el de los logos al principio, e incluso he separado un par de includes en cuatro diferentes cada uno (no sé por qué tenía el código de los logos en el mismo fichero que el de los créditos y la pausa).
Pero cuando me he puesto a probar los créditos porque había una cosa que no entendía bien del código, me ha surgido un fallo catastrófico, de esos de ventanita de Windows y de que se cerrará, con código de excepción c0000005 (que no sé cuál es).
He revisado el código y no se hace nada raro, en ese momento sólo hay 3 procesos de control activos, el de los créditos, y 20 que muestran los gráficos de los créditos. Pensaba que era cosa de la música pero no.
Entonces he probado con Bennu r263 y no se ha producido ningún error.

Os subo el pedazo de código que supuestamente da error, a ver si veis algo que yo no, y si no, puedo mandarle el proyecto a Splinter. Sí, se que está sucio, pero por suerte la parte de los créditos es un acceso casi directo (logos, menú, y ya los créditos), y ya más o menos esa parte está saneada, pero cualquiera diría que es aquel famoso bug gráfico que apareció en las últimas versiones de Bennu, porque por punteros no es: hasta ahora no he visto ninguno (y debería haber usado ya al menos un par, la verdad).

[Drumpi]

Diario de a bordo. Fecha estelar 518.191 cuarto y mitad:

Cuando me embarqué en esta misión, sabía que sería larga, que debía armarme de paciencia, y trabajar sin ninguna prisa ni atisbo de nervios. 45 ficheros de código comenzaron la misión, 54 son ahora y 30 me ha parecido contar que ya he reidentado. Pero no nos engañemos, 54 son ahora, pero muchos más van a ser al final, esta plaga está lejos de ser controlada y pronto se van a reproducir siendo muchísimos más.

De momento está siendo una tarea sencilla, pues de los menús y los créditos poco tengo que cambiar. Algo si voy a tener que alterar respecto a los ficheros de guardado, que hasta ahora almacenaban el nivel y la pantalla donde se quedó el jugador en el último punto de salvado, pero la futura inclusión de puntos de guardado va a cambiar esto, porque si antes los niveles tenían nivel y pantalla o nivel y punto de guardado, ahora van a ser tres los datos que voy a necesitar almacenar... y va a ser mejor así, es más homogéneo, pero también va a requerir cambiar bastantes cosas del comportamiento de algunos eventos y de la carga. Y si definitivamente añado elementos de muerte instantánea (pinchos, caidas o aplastamientos), tendré que añadir a la muerte la habilidad de encontrar el último checkpoint de salvado y retroceder el nivel hasta ese punto.

Pero en nuestro camino ya nos hemos encontrado con dos agujeros negros. Uno de ellos ha sido PUT_SCREEN, que no ha querido centrar las imágenes que le pasábamos, y ahora parece que una función interna está provocando un acceso no válido, que es responsable de que no pueda ver funcionar los créditos si uso pantalla a doble resolución.
Estoy replanteando seriamente downgradear la nave a la anterior revisión estable que dispongo, la r265, si el ingeniero de máquinas, maese Astilla, no encuentra solución, porque esto tiene que seguir adelante.

Estoy a punto de entrar en las aguas más turbulentas de la misión, los procesos más tochos de todo el código (el prota, los eventos y los bosses) y los más delicados (la carga de niveles, que contienen muchas inicializaciones, y necesitan una reescritura A FONDO), por lo que todo va a ir más despacio y los ficheros se van a multiplicar una cosa bárbara.

La hoja de ruta sigue en pie. Daba como mínimo una semana, y aun no es Sábado, pero seguramente necesite esas tres semanas para una buena limpieza.
Del desarrollo nuevo aun no he hecho nada, estoy viendo si tengo que tocar algo del código, pero de momento no he pasado de crear valores constantes. En un futuro necesitaré alguien que compruebe que no se ha roto nada con la limpieza, así que si hay algún voluntario para hacer de betatester, que se lo vaya pensando, preferiblemente alguien que conozca el juego y se lo haya pasado alguna vez.

Por mi parte, cierro el diario por hoy, voy a reponer fuerzas, y mañana otro ratito más de limpieza, a ver si hago tres o cuatro ficheros más.

[SplinterGU]

veamos a ver si podes mantener la nave upgradeada

[Drumpi]

Enésimo día desde la invasión zombie:

Los ánimos en el bosque andan decaidos. No hay señales de vida más allá de los árboles desde que la noria de la feria acabó por los suelos por circunstancias misteriosas, los zombies escasean, Ramón se esconde para evitar ayudarme en la caza y la tia buena aun no ha sacado la ropa de verano.

Lo cierto es que escribo tras una maratón de casi tres horas de "limpieza" sin pausa, habiendo dormido apenas 6 horas justo antes de una mañana de paseos por la ciudad, así que el aire es un poco menos alegre del habitual.
Sí, con el Echo sigo de limpieza. He cogido el código detector de durezas de los enemigos, y he convertido unas 2000 lineas y pico en 4 ficheros de unas 500 de media, y uno más que los "incluye" a los 4; eso me simplificará navegar por este código para arreglar cualquier problema. La pega es que el prota tiene otro trozo de código muy similar (casi un copia y pega), y eso va a ser un día y pico de modificar código.

Así que me lo he saltado. Estoy con el fichero de enemigos, que contenía unas 4000 líneas de código (¿o eran más?) con unos 21 procesos diferentes, que están acabando en ficheros separados. Algunos enemigos sólo necesitaron 100 líneas (mas el include de la detección de durezas, si usaban físicas), pero otros como el guerrillero o la araña han sido más de 400/500 lineas de código :S
La buena noticia es que ya me quedan 5 enemigos por sacar del fichero (entre ellos, el super guerrillero, otro mastodonte de código), y que he podido optimizar algunas cosillas sin importancia, pero que espero ayuden a darle al juego ese empujoncito extra de cara a los 50fps estables.

Y ¡POR FIN! ya le he añadido la señal para indicar cómo coger los objetos. Llevaba queriendo implementarlo desde la primera versión, pero por una cosa u otra, siempre se ha ido retrasando y no lo ponía. Aprovechando que limpiaba los procesos de los items, le he añadido unas 4 líneas que controlan la creación y destrucción de este indicador, que es un proceso nuevo que cambia entre 2 gráficos, mientras sigue al prota. Los gráficos no son nada del otro mundo, pero creo que son suficiente para saber que hay que ulsar abajo :D

A ver si termino con los enemigos y me puedo dedicar a otros dos ficheros mastodónticos: los eventos (aka "el fichero gordo que incluye eventos, jefes de zona, y alguna función de salvar en plan cutre y matar enemigos atrasados para mejorar rendimiento") y el fichero del prota.
Después de eso no debería quedar mucho por limpiar. Serían los procesos que llaman al nivel, las armas del prota y poco más. El primero puede ser un problema porque es el que tengo previsto modificar entero, no me gusta el sistema de almacenamiento de los FPG_ID en memoria, ni cómo se llama al nivel, y aun tengo que hacer la separación entre sub-niveles y checkpoints, pero estaba esperando a tener todos los ficheros abiertos en notepad++ para poder hacer las búsquedas de variables cómodamente.

Y quedo a la espera de la nueva revisión de Bennu para probarla, aunque no sé si tendré ánimos de hacerlo en la Wiz ^^U

En fin, por hoy voy a dejarlo, que estoy cansado y oigo lamentos quejumbrosos de hambre, no sé si hay un pequeño batallón de "come-sesos" con ganas de tragar plomo, o es el "Chuache" que se está quejando de nuevo de cenar alubias en lata. ¡RAMÓN!

[SplinterGU]

vamos a ver si preparo el entorno y compilo la ultima revision.

[Drumpi]

Pues nada, parece que tengo un virus y... no, el ordenador está bien: con Drumpi dentro no se acercan a menos de 40000mm. Soy yo, que parece que el día de "carpintería creativa" no me abrigué bien, y entre el fresquito que hacía y que estuve sudando, pues... Hoy es el día que más fuerte me está pegando...

Pero no hablemos de mi... Hablemos de lo que hago, o intento hacer.
A pesar del dolor de cabeza y el malestar general, he conseguido hacer limpieza de las más de 2000 lineas de código del prota. De nuevo he separado la lógica de detección de durezas del código principal en 4 "cómodos" ficheros. Y como bonus, el código de las armas del prota, las colisiones de los disparos (bastante sencillitas, porque van en línea recta) y los tiles animados... Sí, había tiles animados ¿no habeis visto las fabulosas cascadas del final del nivel 4-2? ¿no? ¿ES QUE NADIE SE HA PASADO EL M...?

...(Ufff, mi cabeza). Bueno, pues estoy con el fichero de eventos ¡Mi madre! 4000 líneas. Ya he separado el código de Ghyppo... el hipopótamo fantasma del nivel 1-3, y estoy teniendo problemas con el dragón: entre la gripe y sus más de 1100 líneas, con mucho código que reidentar, se me pasan horas sólo con este bicho. Estoy viendo que hay mucho código repetido entre sus 6 estados * 4 sub-estados (de media), pero no sé si de verdad está repetido, hay ligeras diferencias, y no quiero cargar más el código añadiendo comprobaciones extra o llamadas a funciones con posiblemente 10 parámetrs o más :S Al menos no hasta que se me pase la gripe y tenga ya el código listo para trasterar con comodidad.

Ya he alcanzado los 97 ficheros en la carpeta SRC, y aun me quedan 3 jefes más dentro de los eventos (aparte de los propios eventos), teóricamente me faltan 12 ficheros por limpiar, pero también me quedaban 15 hace tres días y tenía 80 y pico ficheros de código.

COF, COF. Seguiremos informando... mientras queden aspirinas.

[Fede]

Drumpi, te tengo dicho que no dejes la medicación.  ;D

Por lo demás tómatelo con calma. :)

[Drumpi]

Bueno, no hay mucho que contar, pero no tengo sueño (bueno, un poco sí, UUUUAAAAHHHHHZZZZZZ!!!!!!)

Pues nada, los bosses ya están cada uno en su rinconcito. No veas con el dragón de la leche, he tenido que separarlo en dos ficheros y aun así uno de ellos no ha podido tener menos de 700 líneas.
También he separado los eventos, incluso me ha dado por coger el evento 3-1 (el de las naves) y separar el código en otro de boss, que hasta ahora, ese combate era tratado en el programa como evento, no como mid-boss.
He estado repasando los includes que me quedan por limpiar, y me queda la carpeta de selección de nivel y el include principal que controla el desarrollo de la partida normal (aka game.inc), porque esta tarde le he metido mano al motor de scroll tileado. Era una versión antigua, pero no hay grandes cambios entre una y otra: funcionar funciona, y tengo aun previsto cambiarlo por el motor que tengo que arreglar.

De todas formas me he dado cuenta de que probablemente gran parte del rendimiento se me esté yendo en un enorme SWITCH que tengo incrustado en el código. Primero tengo un IF que comprueba si el tile está entre 1 y 150, y hace las tareas normales de añadir a la lista enlazada. Luego tengo un if que hace lo propio con los valores entre 151 y 999, en cuyo caso, hace un switch con unas 40 posibles reacciones diferentes (crear enemigo, crear tile especial, lanzar evento...). Y un último if con cualquier valor >=1000 para tiles optimizados (una mejora de la v1.3, que analiza el mapa en busca de tiles repetidos en espacios contiguos, y los cambia por versiones 2x2, 2x1 o 1x2 del mismo tile que se crean en runtime, reduciendo el número de tiles no nulos, y por tanto, procesos).

Bueno, eso no sé cómo optimizarlo. De momento voy a terminar la limpieza, que hoy he cogido el código de algo que tenía pendiente para el nivel 2, y me va a llevar un rato. Luego a ver qué tal está la carga de los niveles, porque el game.inc tiene una cantidad de procesos que no corresponden ahí...

[Drumpi]

Bueno, ya puedo dar por terminada la limpieza de código.
Ha sido arduo, pero ya tengo los procesos en ficheros de no más de 500 lineas, agrupadas por categorías, y sin compartir ningún fichero tipo "misceláneo", incluyendo el game.inc, que tenía funciones de 4 o 5 cosas diferentes.
La buena noticia es que el mecanismo de carga de los niveles está mucho mejor estructurado de lo que pensaba. Aun necesita cambios para que se ajuste al nuevo sistema nivel-subnivel-checkpoint, en lugar del viejo nivel-(subnivel|checkpoint).
Otra de las cosas que necesita cambios es el sistema de salvado. Aunque el sistema actual es bueno, puede dar problemas en cuanto añada el item de guardado (a menos que se borren si se está jugando sin guardar partida), y no qeda del todo claro cuándo se guarda (depende de dos o tres procesos diferentes, según el momento: fin de nivel, evento, boss...).

El caso es que ya está todo reidentado, reordenado, y todo está más claro ahora. De momento quiero probar el juego completo con la última versión de Bennu antes de liberar nada. Ya han surgido un par de contratiempos, uno de ellos bastante grave (porque no se pueden leer los menús), y quiero solucionarlos si se pueden, antes que lanzarla con una versión antigua de BennuGD. Tengo previstas lanzar versiones para Windows, Wiz, Caanoo, y si puedo, Linux y GP2X. Ojo, sería la v1.3.1, una revisión de la lanzada para el concurso de Gecasoft, no la actual v1.4.

Estad al tanto ;)

[Fede]

Enhorabuena chico.  8)

Por cierto, ¿hay bennu para GP2X?

[Drumpi]

No me las des aun, queda mucho por hacer. Esto es sólo el principio.
En cuanto vea que realmente no he roto nada, ya se habrá dado el primer paso de la v1.4. A partir de ahí es cuando empieza el auténtico trabajo duro (sólo hemos pasado el tedioso).

Respecto a Bennu para GP2X, sí, yo mismo compilé los fuentes hace ya... pfffff. Hay una versión que funciona en las GP2X con firm oficial, y otra para firms con Open2X que va ligeramente más rápida. Se hizo así porque se compilaron con dos toolchains diferentes, y aun me ando peleando para conseguir entender qué leches hice :P Aun tengo que compilar las versiones más modernas, porque estamos hablando de r100 y pico, así que fíjate si ha llovido desde entonces.

Por cierto, si te animas con gráficos nuevos para el Echo, te puedo ir pasando betas exclusivas pa ti, con acceso a las areas nuevas LOL
Tengo pendiente usar aquellos tiles de fondo que hiciste para la fase egipcia, pero sólo si consigo mejorar el rendimiento del motor de scroll tileado, si no, no podré añadir la segunda capa.

[Fede]

Por cierto, si te animas con gráficos nuevos para el Echo, te puedo ir pasando betas exclusivas pa ti, con acceso a las areas nuevas LOL
Tengo pendiente usar aquellos tiles de fondo que hiciste para la fase egipcia, pero sólo si consigo mejorar el rendimiento del motor de scroll tileado, si no, no podré añadir la segunda capa.

Fale. Pero con tranquilidad.
No empecemos con las Drumpi-Locuras de terminarlo para algún concurso o cosa por el estilo. :)
No tengo el ánimo para meterme de gordo, pero me apetece dibujar.
...
Respecto al scroll de fondo, ¿podría ser de tiles más gordos?
Por lo que observé en el Cave History el fondo solían ser tiles bastante más gordos, además de que se tendría que repintar menos.
...
¿Y Bennu para GP32? ¿Existe?¿Sería esta consola demasiado lenta?

[Drumpi]

De momento no hay prisa, no voy a entregar nada en una fecha determinada, pero tampoco quiero extender el desarrollo durante demasiado tiempo. Mi idea es tener una base sólida, un motor ya hecho con el que poder desarrollar el "Doggy!!!" (y probablemente hacer un crowfunding para el proyecto, y poder pagarle al grafista y al músico que quiera incorporarse).

Quiero meter dos cosas de fondo:
- Primero, una segunda capa al scroll tileado. Usaría tiles del mismo tamaño y serviría para poner cosas detrás de Echo, por ejemplo, paredes en los niveles 1-2 y 1-4, dejando ver el cielo nocturno en determinadas partes. Eso no quiere decir que no se puedan usar tiles de 32x32, 32x16, o cosas así: lo bueno de este motor es que no te obliga a usar tiles de tamaño fijo. De hecho, la v1.3 incorpora una mejora que crea tiles de 32x32, 48x48, 32x48 y 48x32 usando el mismo tile repetido, y modifica el mapa de tiles para usarlos y ahorrar cálculos al reducir el número de procesos tile.
- Por detrás, un fondo con el scroll de Bennu. El tamaño de los gráficos no importaría aquí, pero deben ser cíclicos o a pantalla completa. Ejemplos: en el nivel 1-1 seguiría estando el cielo estrellado fijo, pero quiero meter tres capas de nubes en scroll cíclico horizontal, similar a la fase nocturna de Cave Story
http://s16.postimg.org/e3l9v3vh1/screenshot_1380535086.png
El nivel 1-2 sería simplemente el fondo de ladrillos del castillo, y el nivel 3 sería un único gráfico de 3000*240 que se desplaza más léntamente que el scroll normal, pero dejando ver ciudades en ruinas, o el cañón sobre el que se pasa en la zona del puente.

El Cave Story siempre usa tiles de 16x16, lo que pasa es que para determinados fondos usa imágenes más grandes.

Ya Bennu para GP32 no sé si hay port. Yo no la tengo (y me gustaría) y no recuerdo que lo hubiera. Si bien hay algún rastro en mi cabeza de que Splinter tenía una GP32 y que no pudo portarlo. El rendimiento lo veo muy complicado, no imposible porque el Echo funciona en GP2X medianamente bien (lo cual fue una sorpresa, porque fue un port hecho por mi, sin optimizaciones ni nada), pero estaríamos muy limitados en memoria porque la mayor parte se la llevaría el propio Bennu.