Bennupack Dreamcast DEVKIT 2017

[SplinterGU]

El nuevo dreamcast incluira esto...  todavia en pruebas...



+ SDL 1.2.15
+ PNG  1.6.32
+ MIKMOD 3.3.11.1
+ Zlib 1.2.11
+ arreglos de memoria
+ se arreglo la funcion  exec("program.bin");   mod_sys
+ mejoras internas
+ nueva libreria fake sdl mixer del  (Author: arcadenea, https://github.com/arcadenea/fake_mixer)
+ arregladas las funciones del modulo mod_mem,  (mem_total and mem_available)
+ bootdreams 2.0 (win10 arreglos) exclusivo del pack



Por el momento seguimos en la optimizacion de la memoria...
segun los test de malloc   

+ cuando liberas memoria el sistema operativo KOS  siempre te dice que te queda la misma
memoria libre, segun veo eso en otros sistemas operativos es normal ese comportamiento .. (queda un remanente fantasma)

+ la DC tiene 16MB de RAM (incluyendo bennu y kos cargados queda en 12 MB libres) 
entonces en el test alojamos 5MB 10 veces usando malloc y free y los resultados son que si libera memoria , aunque siempre
dice que queda 7MB siempre .. mirad pantallazos




+ si el DC se pone rebelde ahora se arreglo la funcion de bennu...  exec("externo.bin") donde
puedes ejecutar un programa externo, (para resolver mas los limites de memoria) para juegos grandes...

+ y las mejoras citadas al comienzo

l1nk, no se que funcion estas usando para saber la memoria libre, pero quizas no esta dando la memoria libre, sino el bloque (contiguo) mas largo disponible... pensa que puedes no ser el unico alocando y liberando memoria, y entre tu alloc y free, puede quizas existir otro alloc de otra parte del codigo, y ahi se genera una fragmentacion...

proba allocar todo lo que te dice que tenes libre, hace luego el testeo de memoria, luego libera y luego testea otra vez la memoria disponible...

algo asi como (pseudocodigo)

Code Select Expand


mem = malloc(12000);
if ( !mem ) say ("no se ha podido hacer el malloc"); end

say("memoria libre antes del free: " + memorialibre());

free( mem );

say("memoria libre despues del free: " + memorialibre());

mem = malloc(12000);
if ( !mem ) say ("no se ha podido hacer el malloc"); end

say("memoria libre antes del free: " + memorialibre());

free( mem );

say("memoria libre despues del free: " + memorialibre());


[Ryo Suzuki]

Qué gran trabajo  l1nk3rn3l!!

A ver si se consigue que se pueda liberar la RAM, finalmente.

También la posibilidad de "saltar" cargando otro file puede ser muy bueno, no solo para eso sino para la posibilidad de hacer algo parecido a un menú que ejecute varios homebrew de BennuGD diferentes desde la DC.

Lo que no entiendo muy bien, dices .bin. ¿Sería otro 1st_read.bin? Yo pensaba que cargarías otro .dcb diferente. No me queda claro...

Ánimo! Lo esperamos!

[Drumpi]

Sé que esto es algo viejo, pero quiero aportar mi granito de arena.
Lo mismo ya lo sabeis, pero existen SO que no liberan la memoria, como Android. Estos SO consideran que la memoria vacía es memoria desaprovechada, por lo que lo qe hacen es marcar esa zona de memoria como "aprovechable", no como "libre", y siguen consumiendo la memoria libre con nuevos programas. Es cuando se quedan sin memoria cuando hacen uso de esa memoria "aprovechable". ¿Por qué se hace así? Porque si en algún momento necesitamos volver a ejecutar el programa, o usar algo que habíamos cargado recientemente... ¡ya está en memoria!, no hace falta volverlo a cargar, y eso, con los CDs como almacenamiento masivo, es mucho tiempo de ahorro.

Puede que la medición de memoria libre sólo tenga en cuente la memoria sin usar, y no la memoria marcada como "aprovechable". De ahí que siga marcando la misma cantidad siempre, pero que no se registre ningún cambio a la hora de (volver a) cargar un fichero a memoria.

[l1nk3rn3l]

Que pena con los que postearon , no sabia que habia una actualizacion del post,
El foro deberia tener al comienzo los post mas recientes y despues todo el temario como esta,

asi seria mas facil chekar cuales post son nuevos , Bueno lo que me comenta el Maestro Splinter
la respuesta es parecida a la del colega  Drumpi (la zona no esta ocupada , pero no se reporta como libre)

De todas maneras en la practica puede ser fragmentacion , ya que algunos sistemas operativos viejos
no tenian un gestor de memoria como los kernel actuales...

Bueno para no profundizar aquí esta la respuesta que me dieron la gente de dreamcast
http://dcemulation.org/phpBB/viewtopic.php?f=29&t=104419&sid=3009e7224861beae8c5e5e5f7dddab95

El Port de dreamcast no se ha tocado , ya que otros proyectos como BennuPhoton requerían mas atención, ya que no existían,

[Ryo Suzuki]

El problema sigue estando ahí y entiendo lo que comentáis de que cuando has cargado algo y luego lo liberas de memoria de cara a mostrar la memoria libre no conste aunque en teoría sí sea utilizable.

La historia viene que debe haber algún bug o algo porque en la práctica no es utilizable esa memoria "aprovechable", ya que si intentas cargar algo digamos encima de esa memoria ya no puede y se cuelga. Realmente solo podemos usar la RAM que tenemos al principio e independientemente de que intentemos liberar assets luego y aunque no constase numéricamente como RAM libre de nuevo es que en realidad no puedes cargar nada más así que la RAM solo puede usarse una sola vez.

Esto limita muchísimo las posibilidades de hacer algo, ya que nos quedan algo así como 10 megas de RAM y estamos "condenados" a solo poder usar eso.

Espero que se pueda solucionar tarde o temprano, porque creo que es muy importante. A las malas que se pudiera lanzar otro .dcb o algo por el estilo para poder modular los proyectos al estar condicionados por una RAM no liberable.

A ver si puedes echarle un ojo l1nk3rn3l. Gracias y un saludo!


P.D: Esto debe ser alguna cosa del port de BennuGD a Dreamcast porque en KOS no sucede...

[KeiDash]

Buenas a todos.

Perdón por revivir este post pero alguien ha encontrado solución al tema de liberar la memoria de la dreamcast?

Me acabo de topar con el problema y me ha bloqueado el desarrollo al completo :-/

[SplinterGU]

segun estuve viendo con alguien hace un tiempo, creo recordar que el tema de la DC es que realmente no posee funciones de free/alloc nativas manejadas por el sistema... la aplicacion hace uso de la memoria a su gusto... y parece que la implementacion que se esta usando (ajena a bennugd) o no esta completa o tiene algun bug...

pero puede que me equivoque...

[KeiDash]

segun estuve viendo con alguien hace un tiempo, creo recordar que el tema de la DC es que realmente no posee funciones de free/alloc nativas manejadas por el sistema... la aplicacion hace uso de la memoria a su gusto... y parece que la implementacion que se esta usando (ajena a bennugd) o no esta completa o tiene algun bug...

pero puede que me equivoque...

Pues vaya, que problema!

Por lo que dices Splinter, según comentas ¿Esto pasaría en cualquier lenguaje orientado a Dreamcast? Según comenta Ryo en un post anterior, esto en KOS no pasa.

¿Se les ocurre alguna posible solución para poder proseguir? Se podría rescribir de alguna manera la memoria para poder seguir trabajando? Me acabo de ver muy limitado para poder trabajar la verdad, aunque entiendo que esto es solo mi problema :D

La verdad es que no se me ocurre nada ahora mismo, porque por ejemplo los FPG en ningún momento tengo acceso a la posición de memoria, solo su ID para usarlo posteriormente. Si ruviera acceso a su posición en memoria podría sobrescribirla..

[JaViS]

Me parece haber leido que el problema era que la memoria quedaba muy fragmentada tras cagar y descargar recursos en DC, si ese es el problema, quizas se podria probar cargar los recursos necesarios despues de descargar absolutamente todo de memoria. De modo que se ordenen los datos en ram y te permita acceder al espacio necesario

[KeiDash]

Me parece haber leido que el problema era que la memoria quedaba muy fragmentada tras cagar y descargar recursos en DC, si ese es el problema, quizas se podria probar cargar los recursos necesarios despues de descargar absolutamente todo de memoria. De modo que se ordenen los datos en ram y te permita acceder al espacio necesario

A nivel de código en BennuGD, el problema es que las funciones para descargar elementos de memoria (como el caso de UNLOAD_FPG() ), no funcionan, por lo que a través de esta vía no se pueden descargar todos los elementos de la RAM ¿Existe otra vía para descargar la RAM?

[JaViS]

ah bueno, si ya eso no funciona, no se me ocurre como solucionar ese problema.


por ahi podes optimizar el tamaño de tus recursos. Las imagenes se pueden reducir mucho en tamaño bajando la cantidad de colores, a los sonidos se les puede bajar el bitrate, etc

[KeiDash]

Si cierto es

Poder se podría, pero pienso que limita mucho el desarrollo de algo de nivel medio/alto en bennuGD, tendrías que estar siempre limitado a usar elementos de muy baja calidad para reducir la carga en memoria...una pena la verdad.

Voy a intentar optar por la vía de trabajar a 8bits de color para intentar reducir la carga en ram en ese sentido, pero se me va de las manos el proyecto que estoy desarrollando.

En caso de que aún así no pueda, tendré que intentar migrar todo a KOS..

Me he quedado muy apenado la verdad :'-(

Gracias por las respuestas

[SplinterGU]

me corrijo, me confundi con n64... perdon...

igual no me hagan caso...

[JaViS]

No te desanimes tanto, tomalo como un desafío, pensá en la magia que tenían que hacer en ese tiempo para portar un arcade a esa consola.


La optimizacion de los recursos es una tarea divertida y te vas a sorprender de la calidad que podes conseguir comprimiendo de forma inteligente.

[KeiDash]

No te desanimes tanto, tomalo como un desafío, pensá en la magia que tenían que hacer en ese tiempo para portar un arcade a esa consola.


La optimizacion de los recursos es una tarea divertida y te vas a sorprender de la calidad que podes conseguir comprimiendo de forma inteligente.

Si pudiera reducir el tamaño de las imagenes para trabajar con paletas de 8 bits en el FpGEit estaría genial, pero hasta dia de hoy no he sido capaz de hacerlo.

Ahi podría reducir considerablemente la ram