Hola. Llevo un par de horas renegando con esto. El problema es que no se respeta el orden logico( o por lo menos el que yo espero) de la ejecucion pero si saco los fades funciona correctamente.
Process Scr_Game()
begin
loop
if(change_map != 0)
say("a");
fade(0,0,0,16);
while(fading)
frame;
end
if(Map_id = loadmap("maps/map"+change_map+".txt"))
fade(100,100,100,16);
say("b");
while(fading)
frame;
end
say("c");
change_map = 0;
else
say("exit");
Endgame = 1;
end
end
frame;
end
end
La salida comentando los fades es:
a
b
c
pero con los fades es:
a
a
b
c
exit
Lo que me parece raro es que repite el "a" a lo cual le encuentro poco sentido por que despues del "a" viene un "if else" en el cual ambos miembros tienen un say (despues de "a" deberia seguir "b" o "exit"),
y de igual modo antes del "exit" deberia haber un "a" y no un "c".
¿El orden en el que escribe say no siempre es el orden en que ha sido llamado?¿o es un problema con los fades?
corrijo.. Tenia varios procesos iguales. Se creaban "if(key())" .. lo borro en un rato
evidentemente eso no tiene que ver con los fades, pone un ejemplo completo, mira que dentro de while (fading) tenes un frame, lo cual switchea a otro proceso... no se que haces en otros procesos... hasta que no termina el fading, no cargas el mapa...
mira, no eh trabajado tanto con problemas similares, pero observé esto.
if(change_map != 0) esto me hace pensar que change_map sería una variable de tipo int o float, o alguna numérica al menos, pero luego quieres unir cadenas de string en Map_id = loadmap("maps/map"+change_map+".txt"), aquí deberías poner itoa(change_map), para que lo cargue, (puedes intentar quitando los if's). Esa podría ser la falla.
Prueba así:
(corregido un end y la cadena)
[code language="bennu"]
Process Scr_Game();
begin
loop
if(change_map != 0)
say("a");
fade(0,0,0,16);
while(fading)
frame;
end
if(Map_id = loadmap("maps/map"+itoa(change_map)+".txt"))
fade(100,100,100,16);
say("b");
while(fading)
frame;
end
say("c");
change_map = 0;
end
else
say("exit");
Endgame = 1;
end
frame;
end
end[/code]
corregido sólo cadena
[code language="bennu"]
Process Scr_Game();
begin
loop
if(change_map != 0)
say("a");
fade(0,0,0,16);
while(fading)
frame;
end
if(Map_id = loadmap("maps/map"+itoa(change_map)+".txt"))
fade(100,100,100,16);
say("b");
while(fading)
frame;
end
say("c");
change_map = 0;
else
say("exit");
Endgame = 1;
end
end
frame;
end
end[/code]
y puedes también probar así:
corregido sólo el end
[code language="bennu"]
Process Scr_Game();
begin
loop
if(change_map != 0)
say("a");
fade(0,0,0,16);
while(fading)
frame;
end
if(Map_id = loadmap("maps/map"+change_map+".txt"))
fade(100,100,100,16);
say("b");
while(fading)
frame;
end
say("c");
change_map = 0;
end
else
say("exit");
Endgame = 1;
end
frame;
end
end[/code]
Gracias. Ya lo habia solucionado. De todas formas, se que es poco ortodoxo sumar cadenas con numeros ¿Pero es realmente necesaria la conversion en este caso?
je je, sinceramente, cuando yo escribía en el div mezclaba cadenas y texto (actualmente si hago las conversiones, para evitar errores, por eso no se si funcione en el fenix, supongo que sí, pues su ya lo solucionaste...), pero como en éste caso no te funcionaba, por eso agregué esta función, para ver si se acomodaba. Bueno, ¡¡¡suerte en tu proyecto!!!
Bueno este problema aparentemente esta solucionado, pero tengo otro q parece mas grave. La verdad es que desde hace 4 horas estaba tratando de aislarlo. El sintoma era que despues de cambiar 6 veces de mapa el programa moria. Ademas de esto, si bien compilaba siempre, cambiando de lugar los "say", o agregando más, a veces moria antes de comenzar el juego.Con "moría" me refiero a :
bgdi.exe ha detectado un problema y debe cerrarse.
Bueno como dije, logre aislar mi problema. Consiste en que creo los fpgs a partir de imagenes cargadas con load_png (que contienen la animacion completa), a las cuales con map_block_copy las convertia en imagenes simples.La cuestion es que este codigo que es un resumen de lo que hago cada vez que cambio de mapa ocasiona que la ejecucion termine.
Program DataBase;
private
fpg;
imagen;
archivo;
i;
end
begin
set_fps(24,1);
set_mode(640,480,16);
for(i = 0;i<700;i++)
fpg = fpg_new();
archivo = load_png("images\Pj\0000.png");
imagen = new_map(64,64,16);
fpg_add(fpg,2,0,Archivo);
fpg_add(fpg,1,0,imagen);
map_block_copy(fpg,1,0,0,2,0,0,64,64,0);
unload_fpg(fpg);
unload_map(0,archivo);
unload_map(0,imagen);
frame;
end
end
Nose si estoy haciendo algo incorrecto. Si en vez de 700 uso 500 como valor maximo para i, funciona correctamente (no probe otros valores). Saludos
En la ultima version beta, hay un error con los mapas, y este sucede si se usan mas de 1000 mapas (carga/descarga) no se si este sera el caso, pero es posible...
no veo el sentido que que agreges los mapas a un fpg, es mas, te lo desaconsejo, es mas lento que usar el mapa directamente, un png en memoria no es mas que un map en memoria...
el unico formato que realmente se soporta internamente son los map, los demas son importaciones/exportaciones, desde y hacia maps.
No veo el motivo de agregarlos al fpg y luego hacer el map_bloc_copy, yo aprobecharía que cuando los cargas están en la misma librería con lo cual puedes hacer facilmente un map_block_copy(0,etc,etc) a la libreria 0 que seguro que es más rápida.
Otra cosa, y esto ya es un gusto personal, yo cambiaria tu for por un from, que es más cómodo visualmente (o más bonito)
[code language="bennu" options="singleline"]from i=o to 699[/code]
Es lo mismo que tienes tu pero más corto y facil de entender.
Por cierto, splinter, dices que es un error de cargar 1000 mapas en memoria, o, a lo largo del programa, aunque descargues los mapas, cuando has ejecutado 1000 veces el load_map da error?
Los acomodo en fpg para tener las cosas mas o menos ordenadas. Es un fpg por cada clase de enemigo (obviamente con diferentes sprites). Lo bueno de esto es que hay solo un proceso "enemigo", al cual con cambiarle la variable "file", cambia de clase, pero no es necesario modificar el nº de graph, ya que se respeta cierto orden en todos los fpgs del mismo tipo.
De todas formas, lo del map_block_copy no es definitivo. La idea es que los fpgs ya esten armados, y en vez de este codigo solo se carguen y descarguen librerias (solo que asi es mas facil XD).
¿Habria problemas con cargar y descargar librerias? (con respecto al tema de los 1000 maps)¿o solo pasa si se cargan mapas individualmente?
PD:¿Se elimino save_fpg() ?
Edito: Me acabo de dar cuenta de que tampoco esta en fenix. La verdad nunca la habia usado.
Quote from: Danielo515 on September 21, 2008, 01:16:56 PM
No veo el motivo de agregarlos al fpg y luego hacer el map_bloc_copy, yo aprobecharía que cuando los cargas están en la misma librería con lo cual puedes hacer facilmente un map_block_copy(0,etc,etc) a la libreria 0 que seguro que es más rápida.
Otra cosa, y esto ya es un gusto personal, yo cambiaria tu for por un from, que es más cómodo visualmente (o más bonito)
[code language="bennu" options="singleline"]from i=o to 699[/code]
Es lo mismo que tienes tu pero más corto y facil de entender.
Por cierto, splinter, dices que es un error de cargar 1000 mapas en memoria, o, a lo largo del programa, aunque descargues los mapas, cuando has ejecutado 1000 veces el load_map da error?
si, es una estupides en el reuso de ids, que se activa cuando se usan todos los elementos ya reservados, y previamente a reservar un nuevo espacio de tamaño... inicialmente se reservan 1024... bueno, ya esta corregido en mi entorno de desarrollo, lo anuncio hace ya unos cuantos dias...
Quote from: Packo_z007 on September 21, 2008, 01:41:27 PM
Los acomodo en fpg para tener las cosas mas o menos ordenadas. Es un fpg por cada clase de enemigo (obviamente con diferentes sprites). Lo bueno de esto es que hay solo un proceso "enemigo", al cual con cambiarle la variable "file", cambia de clase, pero no es necesario modificar el nº de graph, ya que se respeta cierto orden en todos los fpgs del mismo tipo.
De todas formas, lo del map_block_copy no es definitivo. La idea es que los fpgs ya esten armados, y en vez de este codigo solo se carguen y descarguen librerias (solo que asi es mas facil XD).
¿Habria problemas con cargar y descargar librerias? (con respecto al tema de los 1000 maps)¿o solo pasa si se cargan mapas individualmente?
PD:¿Se elimino save_fpg() ?
Edito: Me acabo de dar cuenta de que tampoco esta en fenix. La verdad nunca la habia usado.
Si, habra problemas... el save_fpg, se elimino hace mucho tiempo... se va a agregar pronto...
Adjunto librerias con las correccion, supongo que funcionara, creo que no cambie ninguna estructura que afecte a estas funciones... pruebenlo y me comentan... si me confirman que funciona lo subo al site de descargas como fix.
Acabo de probar lo que subiste:
Ahora el juego muere despues de dos cambios de mapa(antes eran 6), y el codigo de ejemplo ese que subi se cierra con 192 repeticiones del for.
Quote from: Packo_z007 on September 21, 2008, 04:29:35 AM
Program DataBase;
private
fpg;
imagen;
archivo;
i;
end
begin
set_fps(24,1);
set_mode(640,480,16);
for(i = 0;i<700;i++)
fpg = fpg_new();
archivo = load_png("images\Pj\0000.png");
imagen = new_map(64,64,16);
fpg_add(fpg,2,0,Archivo);
fpg_add(fpg,1,0,imagen);
map_block_copy(fpg,1,0,0,2,0,0,64,64,0);
unload_fpg(fpg);
unload_map(0,archivo);
unload_map(0,imagen);
frame;
end
end
De todas formas no urge una solucion. No te preocupes.
evidentemente hay un error, en mi caso lo hace 138 veces... vamos a revisar... gracias...
Ahora si...
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).
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.
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
"aGordito 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.
lo siento, mi error... ahi va la correccion...
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?
ignora las prioridades despues del primer frame? y eso?
yo creo que no...
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?
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...
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
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...
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.
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...
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
INSTANCE_MIN_PRIORITY -2048
INSTANCE_MAX_PRIORITY 2048
edit: si incluidas
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..
raro, lo vere luego...
igual, usa timer[0] en vez de un contador de frames...
ya veo que pasa... luego lo corregire, gracias...
ya podes bajar del site betas, el patch para las prioridades.
Esta perfecto Splinter.. muchas gracias
;)
gracias a vos... segui asi probando que vamos a dejar esto un relojito suizo...
De nuevo yo.. En la ultima version con todos los fixes hay problemas s_sleep (freeze aparentemente funciona bien). En el proyecto completo deja al proceso con grafico negro.En este que adjunto no hay modificacion en el grafico (no subo todo por que supongo q es el mismo bug). En ambos casos el estado cambia (deja de ejecutarse).Funciona correctamente en la wip 8 sin fixes. Adjunto un ejemplo.
eso es correcto, con sleep el proceso se va a dormir, o sea, deja de ejecutarse y se esconde, hasta que lo despierten... igualmente veo algo mal, que si el proceso no cambia sus coordenadas, el grafico sigue quedando en pantalla, eso esta mal, deberia esconderse...
si lo que queres es hacer una pausa la señal es frezee, sleep es para mandarlo a dormir... y con mandar la signal a son, solo afectas a tu primer hijo, si queres hacerlo con todos tus hijos, deberias hacer signal sobre id, con s_*_tree... y un sigaction con ignore para ti...
pero en los 2 casos el proceso sigue en memoria, y deja de "ejecutarse" temporalmente pero sigue vivo...
ya esta solucionado el tema de que no se oculte el grafico si el proceso esta dormido y si no tiene cambios... subire un parche nuevo mas adelante, no es un error severo, gracias...
igualmente confirmame que el comportamiento que describo no es el que tenes, porque de ser asi, quizas hay otra lib que faltaria actualizar aunque dudo porque la que interactua con los procesos a nivel render es la que puse en los updates...
Lo que pasa en este ejemplo corto es que no habia cambios en el grafico al dormir un proceso (era igual q un freeze). Por otro lado no sabia que se cambiaban las coordenadas.. pensaba q se le asignaba graph 0.
Ahora, en el proyecto completo no solo no se "esconde" sino que el grafico se transforma en negro (o no se transforma y deja un cuadrado negro en pantalla)... En la wip 8 sin fixes funciona bien. Subo el proyecto completo mas 2 capturas (con y sin pausa).
http://rapidshare.com/files/147718102/Ejemplo.rar.html
PD: Si es para hacer una pausa. Cuando lo estaba programando me equivoque y puse sleep en vez de freeze. De todas formas el sleep es el q funciona mal.
PD2: Con respecto al tema de las variables son, father, bigbro y small bro.. ¿Son solo lectura? (por curiosidad)
no, no cambian las coordenadas...
tu ejemplo, me limpia toda la pantalla y es correcto, porque mandas a todos los procesos a sleep... no falla el sleep es correcto que limpie todo grafico dormido de la pantalla... quizas haya alguna dll que necesite subir, voy a probar con la version wip8 y poner los updates que subi, quizas me falta subir alguno mas... a mi me funciona perfecto tu ejemplo... por otro lado, con pausa no tenes que usar sleep, sino freeze...
no es que pone el grafico a 0, es que limpia la region usada por el grafico...
Si se que manda todos los procesos a dormir en vez de freezarlos. Y en la version que original uso freeze y no sleep como es logico, pero con sleep me parecio q se comporta raro. Repito q con la wip 8 efectivamente limpia la pantalla.. pero con los fixes 1,2,3 y 4 no.
¿Viste las capturas?
si, entonces alguna libreria que me falto subir... a mi me funciona bien... con la ultima...
probado, efectivamente no es la ultima librender... con la ultima librender va bien... no es que pone el grafico en negro es que borra solo algunas zonas y no todas... pero en la ultima esta corregido... con el proximo parche la subire...
Hola. Mira este ejemplo.
Program Ejemplo
private
word pointer puntero;
word array[] = 1,2,3,4,5,6,7,8,9,10,11,500,2000,7000,8000,35000,60000;
I;
end
begin
puntero = &array;
for(i = 0;i < sizeof(Array) / sizeof(array[0]);i++)
say(puntero[i]);
end
repeat
frame;
until(key(_esc))
let_me_alone();
end
Salida:
1
2
3
4
5
6
7
8
9
10
11
500
2000
7000
8000
4294936760
4294961760
ya lo probe, el problema esta en el rellenado del array, luego busco en que parte del codigo esta el problema... por lo visto es un error que se arrastra desde fenix... ya lo probe... y tengo una idea de donde esta... pero ahora mismo no me puedo ocupar de eso...
en unas horas quizas lo pueda revisar...
muchisimas gracias...
Ja ja ja, este es el hilo de los bugs. Bueno, pues me gustaría comentar algo que no se si es un bug, creo que es un problema con el dibujado de algunos gráficos grandes. En un principio pensé que era un problema de performance de mi juego, pero no, ya que tengo 6 procesos que cubren la pantalla como si fueran un solo gráfico (es decir, están pegaditos y parece un gráfico grande). El problema es que cuando aparecen los 6 a la vez en pantalla se dibuja el mapa a cuadraditos, dura un segundo, y al principio pensé que unos procesos ivan retrasados con respecto a otros, pero mis procesos son cuadrados más grandes.
Luego observé el mismo comportamiento con otro proceso con un único mapa cuyo size=400 para que ocupe toda la pantalla, e igual, se dibujó a cuadraditos. Es una cosa que aparece unas veces sí y otras no. En la última versión que he subido de radartrafico a veces pasa con la niebla y la lluvia. Se activan pulsando control+4 y control+6 respectivamente. Lo podeis probar, pero puede que no aparezca dicho error.
que queres decir con que se dibuja a cuadraditos? y pueden ir retrasados unos con respecto a otros si no tienen prioridad asignada... imagino que estaras usando la wip9, no?
Quote from: Packo_z007 on September 25, 2008, 08:59:38 PM
Hola. Mira este ejemplo.
Program Ejemplo
private
word pointer puntero;
word array[] = 1,2,3,4,5,6,7,8,9,10,11,500,2000,7000,8000,35000,60000;
I;
end
begin
puntero = &array;
for(i = 0;i < sizeof(Array) / sizeof(array[0]);i++)
say(puntero[i]);
end
repeat
frame;
until(key(_esc))
let_me_alone();
end
Salida:
1
2
3
4
5
6
7
8
9
10
11
500
2000
7000
8000
4294936760
4294961760
ya esta solucionado el problema, habia una serie de cosas...
1) era el usar un direccionamiento con una variable ("i" en este caso) en arrays de tipo diferente al int..
2) no era el mismo problema pero me lo tope al probar esto, es que habia una serie de fallas en algunos operadores con diferentes tipos de datos que no sean int...
ya corregi todo esto, espero no haber arruinado otra cosa, hasta donde probe todo en orden...
Luego subo un fix... ahora me voy a dormir un ratito que en 3 horas tengo que trabajar...
Gracias. Por lo visto no dormis nunca.. Ya bajo el fix.Lo probare mañana. Un saludo
ahora si lo subi... y cambie el nombre a los paquetes porque no entraban en el list del directorio...
si, tengo un problema con el dormir... ultimamente no nos llevamos muy bien...
Quote from: SplinterGU on September 26, 2008, 01:05:09 AM
que queres decir con que se dibuja a cuadraditos? y pueden ir retrasados unos con respecto a otros si no tienen prioridad asignada... imagino que estaras usando la wip9, no?
No, no, retrasados irian siempre si no tuvieran prioridad asignada, digo yo... es algo que pasa unas veces sí y otras no, además ya he comentado que pasa también con procesos que ocupan toda la pantalla con un mismo gráfico, se dibuja a cuadraditos. Lo único es que tiene size 400. Los otros son 6 cuadrados, gordos, y se dibujan a cuadraditos que son aproximadamente una cuarta de lo que es cada cuadrado, por lo que no es que unos procesos aparezcan antes que otros, de hecho suelen aparecer todos a la vez pero a todos les falta algún cacho, que no tarda en dibujarse. Es algo de un segundo o así.
anoche detecte un error en los graficos al hacer size mayor a 100, donde los graficos tienen a tener una forma cuadrada, recortando parte del grafico... imagino que te referis a eso... ya lo corregi, como tambien corrigi otros errores referentes a la paleta en 8 bits, el usar fade_off y fade_on sin un frame intermedio, y otros mas, con trasparencias, blendop en 8 bits y esas cosas...
Quote from: SplinterGU on September 27, 2008, 02:09:14 PM
anoche detecte un error en los graficos al hacer size mayor a 100, donde los graficos tienen a tener una forma cuadrada, recortando parte del grafico... imagino que te referis a eso... ya lo corregi, como tambien corrigi otros errores referentes a la paleta en 8 bits, el usar fade_off y fade_on sin un frame intermedio, y otros mas, con trasparencias, blendop en 8 bits y esas cosas...
Aaaaaaaaaaaaaaa, ahora entiendo porqué no conseguia hacer funcinar los fade_on y off, se quedaba la pantalla en negro, y es que no había ningun frame en medio!! pero por lo que veo ya está solucionado.
No, no es que se recortara parte del gráfico, el gráfico acaba saliendo bien,pero primero aparece 3/4 partes del grafico en cuadraditos y luego el gráfico completo, es cosa de menos de un segundo, pero se ve. También pasa con procesos con size=100.
no se entonces de eso, no lo vi nunca... si usas un size a 400 es logico que eso pase, ya que no hay suavizado en el zoom, es zoom... pero en 100 si me extraña...
para un uso correcto del fade_off y fade_on, tenes que poner un "while (fading); frame; end" tras cada una de las instrucciones anteriores...
o por lo menos esperar a que fading valga cero para hacer el siguiente fade... ya que sino no se aprecia el efecto...
Hola. Aca dejo un bug nuevo.Funciona correctamente en fenix.
[code language="bennu"]Program ejemplo;
begin
set_fps(24,1);
set_mode(320,240,16);
pr1();
repeat
frame;
until(key(_esc))
let_me_alone();
end
process pr1();
private
grafico;
end
begin
grafico = graph = new_map(40,40,16);
map_clear(0,graph,65535);
loop
if(key(_1))
graph = 0;
elseif(key(_2))
graph = grafico;
end
say(graph);
frame;
end
end[/code]
Saludos.
Quote from: Packo_z007 on September 28, 2008, 09:07:37 PM
Hola. Aca dejo un bug nuevo.Funciona correctamente en fenix.
[code language="bennu"]Program ejemplo;
begin
set_fps(24,1);
set_mode(320,240,16);
pr1();
repeat
frame;
until(key(_esc))
let_me_alone();
end
process pr1();
private
grafico;
end
begin
grafico = graph = new_map(40,40,16);
map_clear(0,graph,65535);
loop
if(key(_1))
graph = 0;
elseif(key(_2))
graph = grafico;
end
say(graph);
frame;
end
end[/code]
Saludos.
fixed! gracias...
de nada... Aca dejo otro mas :
[code language="bennu"]Program ejemplo;
begin
set_fps(24,1);
set_mode(320,240,16);
rojo();
blanco();
repeat
frame;
until(key(_esc))
let_me_alone();
end
process blanco();
private
grafico;
end
begin
x = 160;
y = 120;
z = 0;
graph = new_map(40,40,16);
map_clear(0,graph,65535);
loop
if(key(_left))
x--;
end
frame;
end
end
process rojo();
private
grafico;
end
begin
x = 160;
y = 120;
z = 100;
graph = new_map(100,100,16);
map_clear(0,graph,rgb(255,0,0));
loop
frame;
end
end[/code]
Edito: Por si sirve el dato, lo probe en fenix y funciona bien.
pone una descripcion del error, asi no tengo que estar adivinando que pasa... gracias...
ya veo el error, bueno, me retiro a dormir que manana tengo que trabajar, luego le buscare solucion... gracias...
solucionado, gracias...
el problema estaba en que cuando cambia la z, se reordena, y se reinserta en una lista de objetos listos para ser dibujados, pero por un "<" donde debia ir un ">", producia que el objeto que cambiaba si su z era mayor a la anterior se pusiera por delante de los objetos de la misma z anterior, pero solo hasta que ese objeto sea redibujado (por algun cambio)... en este caso, el que cambia desde su creacion (cuando se crean, se crean con z=0) era el que tenia z 100 que se ponia por delante de los que tenian z = 0...
hola, :)creo que aquí van los bugs ¿verdad?, lo que pasa es que los float funcionan de una forma extraña. Dejo aquí un proyecto para la clase de álgebra, eh intentado escribir un número de 3 enteros, el punto y 2 decimales, sin embargo no lo logro, pues después del primer decimal escribe otros números, si se usa un sólo entero las cosas mejoran, pero para resolver ecuaciones los decimales son importantes ;). No se si el bug ya se conocía. :)
http://rapidshare.com/files/154441377/resolutordeecuaciones.rar.html (http://rapidshare.com/files/154441377/resolutordeecuaciones.rar.html)
A propósito, que bueno que los procesos ya no se tiene que declarar, y... ¿los proyectos con bennu wip 2 para pasarlos a la nueva versión, tengo que quitarle todos los declares o se soportan.?
Quote from: Prg on October 16, 2008, 02:19:07 AM
hola, :)creo que aquí van los bugs ¿verdad?, lo que pasa es que los float funcionan de una forma extraña. Dejo aquí un proyecto para la clase de álgebra, eh intentado escribir un número de 3 enteros, el punto y 2 decimales, sin embargo no lo logro, pues después del primer decimal escribe otros números, si se usa un sólo entero las cosas mejoran, pero para resolver ecuaciones los decimales son importantes ;). No se si el bug ya se conocía. :)
http://rapidshare.com/files/154441377/resolutordeecuaciones.rar.html (http://rapidshare.com/files/154441377/resolutordeecuaciones.rar.html)
A propósito, que bueno que los procesos ya no se tiene que declarar, y... ¿los proyectos con bennu wip 2 para pasarlos a la nueva versión, tengo que quitarle todos los declares o se soportan.?
Bien, es el eterno problema con los numeros flotantes, los numeros de punto flotante no se representan en C con real precision...
los numeros de punto flotante no son tan precisos como uno espera...
quizas te conviene trabajar con la string y luego cuando le das a calcular convertirlo en float...
Por otra parte, no quites la declaracion de los procesos, es conveniente tenerla...
PD: Tremendo avatar... :)
QuoteBien, es el eterno problema con los numeros flotantes, los numeros de punto flotante no se representan en C con real precision...
los numeros de punto flotante no son tan precisos como uno espera... quizas te conviene trabajar con la string y luego cuando le das a calcular convertirlo en float..
entiendo, ¿No hay doble precisión o algo así?... entonces voy a intentar transformar hasta el final la cadena de texto a float para ver si mejora.
QuotePor otra parte, no quites la declaracion de los procesos, es conveniente tenerla...
que bueno que me dices, porque ya pensaba borrar todos los declares... ¿y el private tiene que seguir estando en el declare?
Quote
PD: Tremendo avatar... :)
:D Muchas gracias, representa la universalidad del bennu, y su brillante futuro :)
gracias por la confianza...
:)
Joer Prg que pasada de avatar! :) Una de karma pa ti!
cierto, otro karma...