Avances, Diario de...

[SplinterGU]

podes hacerlo en windows o linux.

[Drumpi]

es un modulo del kernel, hay que hacer llamadas ioctl para usarlas, por lo que veo del codigo del mame4all, es un modulo que cachea memoria, creo, no estoy seguro, que cachea el area de memoria alta.

por otro lado, el mame4all, tiene un codigo que accede a la memoria alta directamente, haciendo unas funciones de alocacion de memoria a lo bruto, simplemente dando direcciones de memoria alta por bloques y marcandolas en un array interno en el mismo codigo... lo que me hace dudar en que pasaria si otro programa que este corriendo en background hace uso de esta memoria alta o si incluso lanzamos otro programa con exec (por ejemplo de bennugd)... tengo que revisar mejor el codigo, pero en principio diria que esto haria desastres, ya que dichas funciones de alocacion no las controla el kernel sino el programa.

deberia preguntar a chui o franxis.

A eso era a lo que me refería.
En principio creo que no hay ningún programa en segundo plano, al menos, no recuerdo que haya ninguno desde el firmware. Otra cosa es que se lo haya ejecutado el usuario, y no recuerdo tampoco ningún programa que trabaje en segundo plano... bueno, a lo mejor uno de apagado de pantalla o de capturas de pantalla.
De todas maneras, creo que esa memoria se usaba/reservaba para OpenGL, por lo que sólo la usan programas en búsqueda de memoria extra o algo más de rendimiento.

Vamos, que creo que la usan porque hay un muy bajo índice de riesgo :P
Pero no está de más preguntar.

[FreeYourMind]

Por fin he podido probar 4 juegos Bennu en Dingoo con el gmenu.

Todos los juegos se salen al menu despues de cargar los recursos (lo se por el tiempo de carga y porque en 2 de ellos tengo el mensaje loading... en pantalla).
Despues de salir al menu este se congela, la unica forma de que mi dingoo vuelva a resucitar es haciendo reset...

[SplinterGU]

es un modulo del kernel, hay que hacer llamadas ioctl para usarlas, por lo que veo del codigo del mame4all, es un modulo que cachea memoria, creo, no estoy seguro, que cachea el area de memoria alta.

por otro lado, el mame4all, tiene un codigo que accede a la memoria alta directamente, haciendo unas funciones de alocacion de memoria a lo bruto, simplemente dando direcciones de memoria alta por bloques y marcandolas en un array interno en el mismo codigo... lo que me hace dudar en que pasaria si otro programa que este corriendo en background hace uso de esta memoria alta o si incluso lanzamos otro programa con exec (por ejemplo de bennugd)... tengo que revisar mejor el codigo, pero en principio diria que esto haria desastres, ya que dichas funciones de alocacion no las controla el kernel sino el programa.

deberia preguntar a chui o franxis.

A eso era a lo que me refería.
En principio creo que no hay ningún programa en segundo plano, al menos, no recuerdo que haya ninguno desde el firmware. Otra cosa es que se lo haya ejecutado el usuario, y no recuerdo tampoco ningún programa que trabaje en segundo plano... bueno, a lo mejor uno de apagado de pantalla o de capturas de pantalla.
De todas maneras, creo que esa memoria se usaba/reservaba para OpenGL, por lo que sólo la usan programas en búsqueda de memoria extra o algo más de rendimiento.

Vamos, que creo que la usan porque hay un muy bajo índice de riesgo :P
Pero no está de más preguntar.

no me referia a que haya uno, sino que podria en un futuro existir uno que corra en background y adios a todo... no me parece una solucion limpia eso que se esta usando.

[SplinterGU]

Por fin he podido probar 4 juegos Bennu en Dingoo con el gmenu.

Todos los juegos se salen al menu despues de cargar los recursos (lo se por el tiempo de carga y porque en 2 de ellos tengo el mensaje loading... en pantalla).
Despues de salir al menu este se congela, la unica forma de que mi dingoo vuelva a resucitar es haciendo reset...

proba sin sonido... a mi me revienta en la carga de un simple wav.

[FreeYourMind]

No uso wav's en ninguno...

[SplinterGU]

No uso wav's en ninguno...

dije que PRUEBES sin sonido y que A MI (A MI) se me caia al cargar un WAV.

[MythomizeR]

No uso wav's en ninguno...

dije que PRUEBES sin sonido y que A MI (A MI) se me caia al cargar un WAV.

Eso en mi pueblo es lo que se dice RECALCAR y lo demás es tontería X-D

Bueno, yo también iba a postear -de hecho lo estoy haciendo- para decir que también he hecho rular Dingux Bennu...

He rulao el galaxian del APÁGAME-&-VÁMONOS y OK, aunque claro, nada de sonidos además de que los textos del principio no se visualizan...
También probé una ultraminidemo consistente en dibujar 3 box de 3 colores en pantalla y claro, también OK, :-)

Además probé otra mini demo que carga un .ogg reproduciéndolo en background mientras se producen 3 efectos básicos sobre un graph -traslación, rotación y escalamiento- y no llega ni siquiera a visualizar nada en pantalla saliéndose al frontend del gmenu2x y, finalmente, quedándose bloqueado... pero ya supongo yo que se deberá al ya conocido problema actual con los timers, pues supongo que la reproducción de .ogg y demás se apoya en ello, y/o a la carga de alguno/s de los recursos...

En cuanto a rendimiento, no he tenío más tiempo para probar... gran trabajo y gracias Splinter ;-)

Seguiré probándolo luego...

[SplinterGU]

No uso wav's en ninguno...

dije que PRUEBES sin sonido y que A MI (A MI) se me caia al cargar un WAV.

Eso en mi pueblo es lo que se dice RECALCAR y lo demás es tontería X-D

Bueno, yo también iba a postear -de hecho lo estoy haciendo- para decir que también he hecho rular Dingux Bennu...

He rulao el galaxian del APÁGAME-&-VÁMONOS y OK, aunque claro, nada de sonidos además de que los textos del principio no se visualizan...
También probé una ultraminidemo consistente en dibujar 3 box de 3 colores en pantalla y claro, también OK, :-)

Además probé otra mini demo que carga un .ogg reproduciéndolo en background mientras se producen 3 efectos básicos sobre un graph -traslación, rotación y escalamiento- y no llega ni siquiera a visualizar nada en pantalla saliéndose al frontend del gmenu2x y, finalmente, quedándose bloqueado... pero ya supongo yo que se deberá al ya conocido problema actual con los timers, pues supongo que la reproducción de .ogg y demás se apoya en ello, y/o a la carga de alguno/s de los recursos...

En cuanto a rendimiento, no he tenío más tiempo para probar... gran trabajo y gracias Splinter ;-)

Seguiré probándolo luego...

gracias... si, no se si sera la falta de inicializacion de los timers (que quizas se inician solos junto a otro sistema SDL) o a que la mixer quizas no va.

[Drumpi]

no me referia a que haya uno, sino que podria en un futuro existir uno que corra en background y adios a todo... no me parece una solucion limpia eso que se esta usando.

Como si al programar en microcontroladores existiesen "soluciones límpias" ;D
Cuando los recursos escasean y se necesita optimizar todo lo posible, el libro de estilo tiene vacaciones indefinidas :D

[FreeYourMind]

Como es el mapeo en la Dingoo Splinter ?
He visto que la cruceta si va, pero no los botones 'L' y 'R'.

[SplinterGU]

no me referia a que haya uno, sino que podria en un futuro existir uno que corra en background y adios a todo... no me parece una solucion limpia eso que se esta usando.

Como si al programar en microcontroladores existiesen "soluciones límpias" ;D
Cuando los recursos escasean y se necesita optimizar todo lo posible, el libro de estilo tiene vacaciones indefinidas :D

no estoy de acuerdo, las soluciones limpias no dependen de en que o para que se programe

Como es el mapeo en la Dingoo Splinter ?
He visto que la cruceta si va, pero no los botones 'L' y 'R'.

no se te ocurrio probar los ejemplos del paquete wiz o caanoo, ni tampoco ver el jkeys.lib que hay en ellos, especificamente en la funcion  jkeys_set_default_keys(), cierto?

[FreeYourMind]

Cierto, mi unica prueba fue probar una demo ya compilada para Wiz, no he recompilado nada, preguntaba por si el mapeo de estos botones es distinto a los de Wiz.

[SplinterGU]

si, fijate el fuente, ahi tenes el mapeo.

[MythomizeR]

Bien, por fin lo tengo... me ha costado un buen trabajo...

el cambio del que hablaba se trata de un nuevo sistema con el cual es posible crear librerias para bennugd a nivel dcb.

esto es, dcbs que aportan funciones escritas en codigo bennugd.

esto nos permite liberar funciones de usuario sin necesidad de liberar codigo, asi sea por seguridad o porque queremos tener todo mas prolijo y ordenado, o simplemente porque no queremos compartir codigo.

si bien estos nuevos archivos .dcl no son mas que .dcb, pero tienen alguna que otra pequeña modificacion para hacer posible esto.

ejemplos de uso:

para crear una libreria, vamos a tomar el ejemplo de key_event.lib.

solo haremos:

bgdc --libmode key_event.lib

esto nos generara un bonito key_event.dcl, el cual luego utilizaremos en nuestros proyectos.

ahora, estos dcl tienen una limitacion, no contienen constantes ni tampoco contienen defines, por ende necesitamos un .h como el siguiente (key_event.h):

Code Select Expand


#ifndef __KEY_EVENT_LIB
#define __KEY_EVENT_LIB

#define _key_pressed    0
#define _key_down       1
#define _key_up         2

#define _key(k,ev) ((ev==_key_down)?(  _key_state[ k ][ _key_use ] && !_key_state[ k ][ _key_use ^ 1 ] ): \
                   (ev==_key_up  )?( !_key_state[ k ][ _key_use ] &&  _key_state[ k ][ _key_use ^ 1 ] ): \
                   ( _key_state[ k ][ _key_use ]))

#endif


NOTA: no se deben declarar las funciones que existan en la lib si la estamos linkeando, ya que sino dara error. Pero si es una funcion que pensamos usar como externa y no la estamos linkeando en ese momento (generar otra dcl que usara una dcl), si conviene declararla para evitar conversiones raras.

ahora para compilar nuestro programa usando la libreria previamente generada, hacemos:

bgdc -L key_event.dcl key_event_test.prg

esto nos generara nuestro dcb de toda la vida, pero incluyendo todas las funciones de la libreria.

espero que les haya gustado y empiecen a liberar y compartir cosas usando este metodo.

Bueno, esta feature hace años que la solicité y descubrí ayer que recientemente  ha sido implementada...

Porque según he leido, se pueden crear dcbs (dcls) a partir de código -funciones- escritas en BennuGD, el problema, es que si bien logro compilar la librería generándose tal archivo con extensión .dcl, lo cierto es que a la hora de crear el dcb con ésta adherida estoy obteniendo un error como de que en la línea 2 aparece "DCL" o "DCB" y que no lo encuentra, no recuerdo ahora exactamente el mensaje que me lanza el compilador, pero siempre es el mismo error...

Otra cosa, ¿el archivo de cabecera .h que contiene las constantes y #defines es solo necesario para librerías escritas con código original c, o tambien lo es para las escritas en Bennu? supongo que sea lo segundo, aunque espero que no...

SplinterGU, se agradecería que pusieras un ejemplo explícito sobre esto, a través de una librería escrita en código Bennu, aparte del ejemplo que ya has puesto donde se emplea en su lugar una dll escrita originalmente en c...

Nada más, aprovecho para saludaros X-D