Bugs (antes 'Fades')

[Packo_z007]

Muchas gracias. No lo puedo probar en el proyecto completo por que ya cambie el sistema para cargar/descargar imagenes (ahora cargo y descargo fpgs completos).

[Packo_z007]

Ahora tengo problemas distintos.. ¿por casualidad tenes el fix que subiste antes? (lo reemplace por el nuevo y perdi los archivos) Es para hacer una comparacion entre lo que pasa sin fix, con el viejo y con este.

[Packo_z007]

Bueno llevo un rato probando la version publicada en la wip8 y el ultimo fix. Lo mas destacable es que con el ultimo fix tengo problemas para cargar datos de un archivo (y no los habia tenido ni en la wip8 ni el penultimo fix). La cuestion es que cargo varias variables de tipo personalizado con fread, en un espacio de memoria reservado dinamicamente.
El primer elemento se carga con normalidad (es un word), el segundo, un array de chars se carga desplazado 2 bytes hacia la derecha y los demas elementos es dificil saber.. se cargan como quieren.Insisto en que solo sucede con el ultimo archivo que adjuntaste. Me vendria bien probar la version anterior para tener una referencia,por que en esa andaba bastante estable (sin tener en cuenta el tema de la carga y descarga de mapas).El procedimiento que uso para cargar datos es el siguiente (solo ilustrativo).

//declaro el tipo data_monster que es el que cargo de la estructura
type data_monster
    word id;
    char[15] name;
    etc;
end

//declaro el  array de punteros a el tipo data_monster
data_monster pointer puntero[7];

//posiciono el cursor en el numero de monstruo a cargar
fseek(file,(id_a_cargar)*(sizeof(data_monster)),seek_set);
//reservo memoria para cargar
puntero[indice] = alloc(sizeof(data_monster));
//leo los datos
fread(file,puntero[indice]);
//compruebo los datos cargados:
say(puntero[indice].name);

salida en la wip 8:
"Gordito Azul"  (  ;D )
salida con el fix
"a
Gordito Azul"

Posiblemente esto no diga mucho, pero el codigo es muy extenso.
Tambien tengo un problema con las prioridades tanto en la wip 8 como en el ultimo fix, pero lo mas probable es que sea un error mio.Lo voy a revisar mas profundamente.

[SplinterGU]

lo siento, mi error... ahi va la correccion...

[Packo_z007]

Muchas gracias. Ahora funciona correctamente. Tambien solucione el tema de las prioridades.Si no me equivoco, ignora las prioridades asignadas despues de la primera instruccion frame ¿Es normal esto?

[SplinterGU]

ignora las prioridades despues del primer frame? y eso?

yo creo que no...

[Packo_z007]

Nose si no me exprese correctamente o no entiendo el ejemplo  ;D.

Lo que decia era que si a la variable priority de un proceso le asigno el valor que quiero que tenga, despues de que dicho proceso haya llamado a la instruccion frame, se ignora esa prioridad asignada y se ejecuta en vaya a saber uno que orden.

Correcto
process a
begin
    priority = n;
    frame;
end

Incorrecto
process a
begin
    priority = n;
    frame;
end

Es un error mio por lo visto.. hice un ejemplo corto y funciona bien.

Por otro lado, ahora el primer fpg cargado recibe el valor 1 y no 0 (por eso no aparecen los graficos en el ejemplo de jerarquias que subiste). Este comportamiento me parece correcto. ¿No se supone que el fpg 0 es un fpg "especial" que no esta limitado a los 999 maps?

[SplinterGU]

el fpg 0 es el del sistema... en fenix, cuando se cargaba el primer fpg, se cargaba como 0, ahora lo tuve que cambiar por el tema del error que tuve que corregir unos posts atras, pero si bien esto es correcto, esto lo hace incompatible con lo ya existente si no se usa file especificando el fpg cargado, voy a tener que revisar a ver si puedo poner que por lo menos el primer fpg cargado sea 0, y con los graficos solamente de 0-999, si el codigo es superior es del sistema, sino es un fpg... voy a ver si puedo hacer eso sin que genere conflictos...
ummm... que raro, modifique el prg para que funcione con eso... a ver... pufff... como andamos, me confundi de ejemplo... dios mio... ahora subo el correcto...

PD: Cual es la diferencia entre los 2 codigos que pusiste? correcto-incorrecto? yo veo lo mismo o veo mal...

[Packo_z007]

Bueno la verdad no le encuentro una explicacion a este comportamiento. Si bien se como solucionarlo y no he podido reproducir el error en un ejemplo mas simple lo subo por si las moscas:
http://rapidshare.com/files/147468716/Ejemplo.rar.html
Los procesos que intervienen son el principal ("RPG.prg",394), el proceso "Monster" ("Enemies.inc",10) y el proceso "grid" ("TilesSystem.inc",25) que es el que controla el scroll.A cada proceso le puse un Say,con su respectiva prioridad
El orden correcto de ejecucion es:

Grid (prioridad -100)
Monster (prioridad -1000)
Main (prioridad -2048)

Sin embargo en el archivo de salida(que contiene el nº de frame y la prioridad del proceso que escribió) aparecen ejecutados en otro orden:
Monster (prioridad -1000)
Grid (prioridad -100)
Main (prioridad -2048)
Ademas de que esto significa que la posicion de los monstruos tiene un frame de retraso con respecto a la de Grid (Es claramente apreciable, sobre todo en el segundo mapa*)

La solucion es simplemente mover una linea:
En "Enemies.inc" esta este codigo:

linea
(21)  while(Map_id == 0)
(22)      frame;
(23)  end
(24)  priority = -1000;

Lo reemplazamos por:
(21)  priority = -1000;
(22)  while(Map_id == 0)
(23)      frame;
(24)  end

Y voilá.

*para cambiar de mapa parate sobre el cuadrado rojo

[SplinterGU]

no entiendo tu ejemplo... o que tengo que mirar... mira el codigo que puse yo, que es muy simple, vas a ver como incluso despues de ejecutar un frame podes cambiar la prioridad y esta afecta al comportamiento de los procesos... pulsa + y -  en el teclado normal (no el numerico) y veras como los procesos se comportan segun la prioridad... tambien en el ejemplo se cambia la z, pero podes comentar la linea que cambia la z si queres...

[Packo_z007]

Probe el ejemplo tuyo y anda perfectamente.. y como ya dije no pude reproducir el problema mio en un ejemplo mas corto. Pero tene en cuenta que en el proyecto competo intervienen otros factores ademas de las prioridades.. como signals. No digo que sea un bug.. se me puede estar escapando algo.. pero el comportamiento es raro.

Lo que trato de demostrar con el ejemplo es puntutalmente que el proceso "Monster" se ejecuta ANTES que el proceso grid.. a pesar de los valores de las prioridades y sobre todo q se soluciona cambiando de lugar la linea que puse en el post anterior.
Hay 2 formas de ver esto..
Primera y mas facil de apreciar.. empeza el juego y saltá (con el numero 4 del teclado). Hay se nota el frame de retraso que tienen los enemigos con respecto al mapa.

Y segundo.. en el archivo de salida ("Rpg.txt" si compilas con el bat) escribo cada frame con cada proceso la prioridad de dicho proceso y el numero de frame actual.. que es manejado por el proceso main, con prioridad -2048.

Lo logico seria que en el archivo de salida se viera en el mismo frame las prioridades en orden.

[SplinterGU]

las prioridades asumen luego del primer frame, eso es asi, porque la lista de ejecucion ya esta cargada, y no puede ser alterada hasta ser completada, luego de cada recorrida se actualizan las prioridades... ahora bien, si vos pones un frame y luego seteas la prioridad, la prioridad de ese proceso se efectivizara al 2do frame... eso es logico...
resumiendo, cuando seteas una prioridad no se reordena la lista de ejecucion hasta que esta haya sido finalizada, o sea, en el siguiente frame surtira efecto...

[Packo_z007]

Si eso es logico.. pero el problema es que no se reordena nunca..

       Prioridad          nº de Frame
Pr Ene:-1000            443
Pr Ene:-1000            443
Pr Grid:-100              443
Pr Main:-2048           443
Pr Ene:-1000            444
Pr Ene:-1000            444
Pr Grid:-100              444
Pr Main:-2048           444
Pr Ene:-1000            445
Pr Ene:-1000            445
Pr Grid:-100             445
Pr Main:-2048           445
Pr Ene:-1000            446
Pr Ene:-1000            446
Pr Grid:-100             446
Pr Main:-2048          446
Pr Ene:-1000           447
Pr Ene:-1000           447
Pr Grid:-100             447
Pr Main:-2048          447
Pr Ene:-1000           448
Pr Ene:-1000           448
Pr Grid:-100            448
Pr Main:-2048          448
Pr Ene:-1000           449
Pr Ene:-1000           449
Pr Grid:-100            449
Pr Main:-2048          449
Pr Ene:-1000           450
Pr Ene:-1000           450
Pr Grid:-100            450
Pr Main:-2048          450


El color es para diferenciar un frame del otro

[SplinterGU]

INSTANCE_MIN_PRIORITY    -2048
INSTANCE_MAX_PRIORITY     2048

edit: si incluidas

[Packo_z007]

Si le asignas un valor menor lo convierte en -2048.. te digo por q antes lo tenia en -100000 XD.. Con 2047 no cambia nada.

Repito que puede ser un error mio.. pero no queria dejarlo pasar.  Lo que me llama la atencion es la forma en la que se lo soluciona..