new articles on the wiki

[handsource-dyko]

Ok. I looks fine to me.

[SplinterGU]

Understood So, while Start_fli only returns if it was successfull,  Fli_start returns a "fliID", used for all fli_*functions. I'm going to uptade the wiki today.

Ooook. So it's still only one fli animation instance?

No  I just tested it and unlike Start_fli, Fli_start can be used to start several animations. Then you can stop them individually using the flicID. 

Splinter, sos groso, sabelo.

I think there is a bug or something, though.  Short after stopping the animation I get always  " *** glibc detected *** borrar: double free or corruption (!prev): 0x089541d8 *** "

btw

Like with mode 7 and scrolls there exist two versions, a simple one and a more sophisticated variant where the scroll or the mode 7 can blitted on a map.

It seems are they the same thing now, although following the new "standard" only the MODE7_* ones should be used.
    FUNC( "MODE7_START" , "IIIIIIII"    , TYPE_INT , modm7_start2 ),
    FUNC( "START_MODE7" , "IIIIIIII"    , TYPE_INT , modm7_start2 ),

    FUNC( "MODE7_START" , "IIIIII"      , TYPE_INT , modm7_start  ),
    FUNC( "START_MODE7" , "IIIIII"      , TYPE_INT , modm7_start  ), 

    FUNC( "MODE7_STOP"  , "I"           , TYPE_INT , modm7_stop   ),
    FUNC( "STOP_MODE7"  , "I"           , TYPE_INT , modm7_stop   ),

can you send me the sample that you have this glibc errors?

[Kloppix]

It was with the example I put in http://wiki.bennugd.org/index.php?title=Fli_end, but better check your e-mail.

[SplinterGU]

thanks!

[SplinterGU]

It was with the example I put in http://wiki.bennugd.org/index.php?title=Fli_end, but better check your e-mail.

hehehe, sure that it will crash... you are free it twice...

right code

Código: [Seleccionar]

Import "mod_video";
Import "mod_key";
Import "mod_flic";

private
  int iAnimation1;
end

begin
  set_mode(640,480,32);
  iAnimation1=Fli_start("lata.flc",50,50);
  //iAnimation1=Fli_start("SPFXDEMO.FLI",50,50);

  while(! key(_esc))
    if(key(_s))Fli_end(iAnimation1);iAnimation1=null;end
    frame;
  end
end


[Kloppix]

 I never would have imagined that you have to assign NULL to the Fli_ID after Fli_End! I'm adding this to the Wiki as well.

[DCelso]

I never would have imagined that you have to assign NULL to the Fli_ID after Fli_End! I'm adding this to the Wiki as well.

Kloppix it is not neccesary. It is a cheat to evade to free more that one time your fli object. So your  explanation in the wiki pages is not correct.
In this code when you press the key "s" the loop while runs the instructions of key "s" several times, because is a loop and you are not using a "on key press method" only are using "is quey pressed" method.
try this another code to understand it.

Código: [Seleccionar]

begin
  set_mode(640,480,32);
  iAnimation1=Fli_start("lata.flc",50,50);
  //iAnimation1=Fli_start("SPFXDEMO.FLI",50,50);

  while(! key(_esc))
    if(key(_s))
           while (key(_s)) frame; end;  // loop to wait to release the key s.
           Fli_end(iAnimation1);           
     end
    frame;
  end
end
Or this other one

Código: [Seleccionar]

begin
  set_mode(640,480,32);
  iAnimation1=Fli_start("lata.flc",50,50);
  //iAnimation1=Fli_start("SPFXDEMO.FLI",50,50);
   frame;
     Fli_end(iAnimation1);           
   frame;
end

So,  only use if(key(_s)) is not enough to do things that you need run once.

[SplinterGU]

DCelso, quizas deberiamos hablar en castellano, porque parece que se pierde info de lo que se quiere decir.

el ejemplo de kloppix no esta mal... lo que pasa es que simplemente llama muchas veces a la funcion fli_stop, necesita algun control para no hacerlo tantas veces o simplemente setear el indentificador a NULL para que si entra nuevamente en la funcion, el control interno que tiene la funcion haga que no se realice ninguna operacion al respecto.

[Kloppix]

Bueno, en realidad ese ejemplo no es el de la Wiki sino un ejemplo que le envié a Splinter. Aunque en la Wiki tenía la misma confusión.

Ahora si entendí por que se le asigna NULL. Voy a hacer unas pruebas y corrigo el código (es el mismo para fli- *start,*frame, *end y *reset). También tengo que corregir entonces una parte de la descripción. Muchas gracias DCelso y feliz cumpleaños! Ví que cumpliste este mes antes de resucitar

[SplinterGU]

kloppix no es necesario que lo pongas a NULL, pero si es necesario que el identificador que le pases a las funciones sea un identificador valido, si ya lo cerraste, como si tambien le mandas verdura, vas a obtener un crash... por eso al ponerle NULL estas diciendo que no esta inicializado y el control interno pasa.

podria haber hecho otro metodo y buscar los identificadores en una tabla interna, pero esto seria muy poco performante... aunque probablemente cambie todo el sistema donde devuelven punteros por otra cosa interna mas segura... eso posiblemente lo haga cuando prepare la version 64bits.

[Kloppix]

Splinter, tras la explicación de DCelso entendí lo que me escribiste por email perfectamente

Creo que para evitar futuros dolores de cabeza, debería ser costumbre resetear el identificador tras Fli_end(). Lo puse como recomendación en la Wiki. http://wiki.bennugd.org/index.php?title=Fli_end Cualquier error, incluyendo el código, háganlo saber.

[SplinterGU]

no solo con fli, con toda variable donde guardamos id de mapas, archivos, identificadores de procesos, etc.

[DCelso]

Exactisimo todo lo que dijiste SplinterGU. Es justo lo que puse en mi post en inglés, quizás en un inglés paupérrimo como indicas, pero mi intención era la de aclarar las cosas para tener la documentación lo más fiel posible. Quizás no te haya gustado que puse la palabra cheat a lo de hacer el null, y no es la adecuada, quería simplemente decir eso mismo que dices tu, que ponerla a justo después del end es un "truco" para hacer que no vuelva a llamarse a fil_end con el id anterior y así la función fli_end no intente volver a liberar el recurso y puse un ejemplo de como resolver el error sin necesidad de hacer null, por lo que reitero que todo lo que dijiste es cierto, quien va a saber más de esto que tú .

[DCelso]

.. podria haber hecho otro metodo y buscar los identificadores en una tabla interna, pero esto seria muy poco performante... aunque probablemente cambie todo el sistema donde devuelven punteros por otra cosa interna mas segura... eso posiblemente lo haga cuando prepare la version 64bits.

Totalmente de acuerdo, es una pérdida de rendimiento, tal como está va de lujo, además no siempre le vamos a poner las cosas mascadas al programador ¿no?

[MisterN]

Gee, I dont understand english, and this is the english board.