Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.


Mensajes - SplinterGU

Páginas: [1] 2 3 ... 825
1
Extensiones / Re:BennuPhoton (Libreria Multiplayer )
« en: Octubre 19, 2017, 07:19:03 pm »
parece que no...

2
Proyectos / Re:ZOTH Zombie Invasion
« en: Octubre 17, 2017, 03:26:39 pm »
muy bien!

3
Dreamcast (homebrew) / Re:Bennupack Dreamcast DEVKIT 2017
« en: Octubre 17, 2017, 10:35:59 am »
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)

Código: [Seleccionar]
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());

4
Mesa de Ayuda / Re:PROCESS/FUNCTION duda
« en: Octubre 16, 2017, 12:12:05 am »
esto esta para ir a un FAQ...

5
Mesa de Ayuda / Re:Segmentation Fault en fpg_save()?
« en: Octubre 16, 2017, 12:07:59 am »
bien... fixeado!

a mi no me reventaba el ejecutable, pero grababa mal el fpg... era una cuestion de casteo... me comi unos parentesis...

Código: [Seleccionar]
--- modules/mod_map/file_fpg.c  (revisión: 343)
+++ modules/mod_map/file_fpg.c  (copia de trabajo)
@@ -320,11 +320,11 @@
             for ( y = 0 ; y < gr->height ; y++ ) {
                 switch( bpp ) {
                     case    32:
-                            file_writeUint32A( fp, ( uint32_t * ) ( uint8_t * )gr->data + gr->pitch*y, gr->width );
+                            file_writeUint32A( fp, ( uint32_t * ) ( ( uint8_t * )gr->data + gr->pitch*y), gr->width );
                             break;
 
                     case    16:
-                            file_writeUint16A( fp, ( uint16_t * ) ( uint8_t * )gr->data + gr->pitch*y, gr->width );
+                            file_writeUint16A( fp, ( uint16_t * ) ( ( uint8_t * )gr->data + gr->pitch*y), gr->width );
                             break;
 
                     case    8:

ahi esta el diff

gracias por el reporte, el sample y los analisis...

6
Mesa de Ayuda / Re:PROCESS/FUNCTION duda
« en: Octubre 14, 2017, 06:31:18 pm »
a ver... si la funcion tiene frame pasa al siguiente proceso (sea cual sea este).
function solo detiene al proceso/funcion invocador, si no hay frame dentro de la funcion, esta detiene todo hasta que termine de ejecutarse.
si hay frame en la funcion, solo detiene al invocador y no a los demas.

igualmente siempre se ejecuta 1 proceso por vez, nunca se ejecutan mas de 1 por vez.

7
Proyectos / Re:Dreamcastnoid de Dreamcast para la DCJAM 2016
« en: Octubre 14, 2017, 06:21:45 pm »
gracias!

8
Mesa de Ayuda / Re:Segmentation Fault en fpg_save()?
« en: Octubre 14, 2017, 06:21:00 pm »
no pasa nada, cuando tenga la solucion aviso...

9
Proyectos / Re:Dreamcastnoid de Dreamcast para la DCJAM 2016
« en: Octubre 13, 2017, 04:44:10 am »
muy bueno! felicitaciones y gracias por difundir el proyecto!

10
Mesa de Ayuda / Re:Segmentation Fault en fpg_save()?
« en: Octubre 13, 2017, 04:30:03 am »
Bueno, ahora si voy a decir que esta bien y que esta mal :P
La función del fallo y original de bennu es esta:
Código: [Seleccionar]
int gr_save_fpg( int libid, const char * filename )

Y el problema esta aquí, en 32 y 16 (lo encontré por el parche de pixtudio)
Código: [Seleccionar]
       // /* Write the bitmap pixel data */

            for ( y = 0 ; y < gr->height ; y++ ) {
               
                switch( bpp ) {
                    case    32:
                            file_writeUint32A( fp, ( uint32_t * ) ( uint8_t * ) gr->data + gr->pitch * y, gr->width);
                            break;

                    case    16:
                            file_writeUint16A( fp, ( uint16_t * ) ( uint8_t * ) gr->data + gr->pitch * y, gr->width);
                            break;

                    case    8:
                    case    1:
                            file_write( fp, ( uint8_t * )gr->data + gr->pitch*y, gr->widthb );
                            break;
                }
            }

Básicamente, por lo que entiendo, file_write{16,32} no sabe cuando "detenerse".

Pixtudio, como parche, usa malloc(), memcpy() y free() para crear un nuevo segmento de memoria('block') de tamaño igual a gr->widthb y
luego copia gr->data alineado a ese segmento nuevo, ahora si, file_write{16,32} sabe cuando detenerse, asi se comporta igual en el case 8.
Código: [Seleccionar]
            /* Write the bitmap pixel data */

            if (bpp > 8) {
                if (!(block = malloc(gr->widthb))) {
                    file_close(fp);
                    return 0; /* No memory */
                }
            }

            for (y = 0; y < gr->height; y++) {
                if (bpp > 8) {
                    memcpy(block, (uint8_t *)gr->data + gr->pitch * y, gr->widthb);
                    if (bpp == 16) {
                        /*                        gr_convert16_ScreenTo565(( uint16_t * )block,
                         * gr->width ); */
                        file_writeUint16A(fp, (uint16_t *)block, gr->width);
                    } else
                        file_writeUint32A(fp, (uint32_t *)block, gr->width);
                } else {
                    file_write(fp, (uint8_t *)gr->data + gr->pitch * y, gr->widthb);
                }
            }

            if (bpp > 8)
                free(block);

Los problemas del parche de pixtudio:
1- malloc esta en el ámbito del for loop nmaps que itera unas ~32 veces * gr->widthb = ~232 bytes.
2- memcpy esta en el ámbito del for loop gr->height.

Mi solución es no usar malloc y usar memoria automática.
Código: [Seleccionar]

    /* Write each map */
   
    uint32_t dummy32; <--- Fuera de nmaps
    uint16_t dummy16;
   
    for ( n = 0 ; n < nmaps ; n++ ) {
    .......................................................................
    .......................................................................
   
        /* Write the bitmap pixel data */
       
        for ( y = 0 ; y < gr->height ; y++ ) {
               
                uint8_t *src = ( uint8_t * ) gr->data + gr->pitch * y;
                uint8_t *end = ( uint8_t * ) src + gr->widthb;

                switch( bpp ) {
                    case    32:
                            dummy32 = *( uint32_t * ) end;
                            *end = 0;
                            file_writeUint32A( fp, ( uint32_t * ) ( uint8_t * ) src, gr->width);
                            *end = ( uint32_t ) dummy32;
                            break;

                    case    16:
                            dummy16 = *( uint16_t * ) end;
                            *end = 0;
                            file_writeUint16A( fp, ( uint16_t * ) ( uint8_t * ) src, gr->width);
                            *end = ( uint16_t ) dummy16;
                            break;

                    case    8:
                    case    1:
                            file_write( fp, ( uint8_t * )gr->data + gr->pitch*y, gr->widthb );
                            break;
                }
            }
    .........................................................................
Básicamente, cuando file_write{32,16} recorre el bloque de memoria, se detiene en el terminador nulo 0, y para no perder el dato que ahí existía, lo guardo previamente.

Todo funciona bien con el archivo de test de gecko, con  set_mode(, , 32,) y set_mode( , , 16,).

Todo  dependerá que dicen los expertos si está aquí el bug o está en otro lado.






como que no sabe como detenerse ?!?!?!?!

el nul char no hace que se detenga.

se detiene por "gr->width", lo que has hecho con tus cambios es seguramente ocultar otro bug, con la nueva compilacion al reasignar las areas de memoria... eso pasa bastante cuando por ejemplo, compilamos algo en debug y en release... en release crashea y en debug no.

aun no tuve tiempo de ver esto... pero el poner un *end=0, no hace que se detenga el write... si fuera asi, se detendria con pixeles con valor 0.

esto no es una string que se guarda...

el problema es otro...

11
Mesa de Ayuda / Re:Segmentation Fault en fpg_save()?
« en: Octubre 06, 2017, 09:07:53 pm »
dificil sin un programa de test y pngs de test.

12
Novedades y Releases / Re:r342 liberada
« en: Octubre 05, 2017, 05:34:23 pm »
gracias folken!

13
Offtopic / Re:¡¡Ya soy oficialmente desarrollador en iOS!!
« en: Octubre 02, 2017, 02:33:50 pm »
pues felicitaciones!

14
General / Re:Algún concurso de renales a la vista?
« en: Septiembre 26, 2017, 07:57:39 pm »
uno de juegos de ingenio/puzzle, no estaria mal...

15
congrats!

Páginas: [1] 2 3 ... 825