Bennu Game Development

Hola a todos:

Yo no sé lo que me pasa pero desde hace ya mucho tiempo no consigo que me funcione el modo7 de forma decente (entendiendo por decente como lo que podía dar de sí Fenix en su tiempo). Ya tuve mis más y mis menos en la fastuosísima adaptación a videojuego de la última (y única) aventura peliculera de nuestro mangaka pelopincho favorito.

Pues nada, ahora quiero usar de nuevo el modo7 y no me va, ni a 16 ni a 8 bits. Busco en la documentación y no hay nada. Los ejemplos del bennupack no se descomprimen (estoy en ello de nuevo). Las wikis de Fenix están igual...

En fin, a ver si podeis echarme una mano. Os adjunto código básico (basado en ejemplos de documentación), import con todas las librerías y FPGs de pruebas.

Wow: 22 visitas, 3 descargas y ni una respuesta. Sabía que la cosa era complicada, pero no a este nivel. Voy a tener que prescindir del nivel en modo7 :(

es que si no das detalles de que no te funciona, dudo que alguien responda.

modo7 solo funciona en 8bits... por ende no va a funcionar ningun fpg de 16 ni de 32.

creo que tu problema estaba en tu fpg y sus gráficos. mira el ejemplo que te pongo

edit
__________________________________
observo que si usas "scale_mode=scale_nofilter;", almenos en mi pc no se pinta nada, creo que eso, que tienes un modo de video de 16 bits y un fpg de 16 bits era el problema de tu codigo. saludos.

Vaya, pues era eso, prg. Había estado probando en modo 8 bits y 16 bits, incluso pensé que era cosa del scale_mode, pero por lo visto no quité esa linea en 8 bits, así si va.

Pero bueno, me extraña que no funcione el modo 16 bits con el modo7, me parecía recordar que se hizo un apaño en Fenix 084b para que funcionase, y como en mi cabeza aun tenía esa imagen del modo7 con transparencias tan bien hechas...

El día que entienda cómo funciona, lo arreglo, porque le hace falta mucho, pero que mucho repaso.
En fin, al menos ahora podré seguir trabajando, solo que en PC se verá "algo pequeñito" ;D

Muchas gracias a ambos, en especial a prg que ha dado en el clavo (no te sientas celoso, splinter ^^U).

Siento no poder ayudar, pero es que me mareo con modo 7 y todo lo que simule 3D por ordenador  ;D

yo nunca vi un modo7 mas alla de los 8bits.

creo que han dicho que hay un tema con las Z, pero no se si es en relacion con DIV o que funciona mal, no recuerdo, ahora si lo vas a usar, si algo anda mal, avisa.

No, hubo problemas con las z en Fenix porque las z de los m7, al igual que las de los scrolls no funcionaban, y se quedaban con su z por defecto. Eso se arregló, pero no se hizo nada respecto a horizon, que marca la posición vertical de la linea del horizonte, que no funciona.

Aun tengo que hacer más pruebas, pero por ejemplo, un segundo m7 puesto de techo tapa completamente los procesos c_m7 que están por encima de él, pese al color transparente. O también que hay problemas con el posicionamiento y el tamaño de los procesos c_m7 (si la height del proceso es 0, este no está pegado al suelo).

Pero claro, estos son cambios tan gordos que requiere dedicarse a ellos, y no te voy a hacer perder el tiempo si estás con otra cosa. De momento trato de "parchear" como puedo, a ver si consigo algo "decente", ya he conseguido poner el proceso que se maneja usando coordenadas de pantalla y una posición concreta de la cámara.

trata de no parchar nada en el prg

¿Eing? no entiendo.
Si lo que dices es que trate de hacer funcionar el modo7 tal cual, es imposible. Si lo que quieres es que me ponga a trastear con el código en C, no tengo conocimientos ni tiempo de adquirirlos para arreglarlo. Ten en cuenta que esto es para el concurso, que sólo le dedico una hora diaria máximo, y que sólo tengo hasta el 1 de julio.

Ya avisé que iba a hacer una chapuza, que presentarme en estas condiciones es una locura, pero ahí estamos ;D
Aun así, espero que podamos dejar el pabellón bien alto.

digo que si tienes algun problema lo reportes, no que lo emparches desde tu codigo porque asi no se logra avanzar en el producto para nada, y seria una cuestion egoista, "mientras a mi me funcione no importa".

solo digo, no emparches, reporta.

¿Otra vez? ¬¬U creo que ya dejé claro en el último ejemplo que te mandé al respecto, las deficiencias del modo7.

Yo si quieres te hago una lista (otra vez) de los fallos del modo7, pero es para nada hasta que no salga alguien con conocimientos del tema. Cuando se diga de arreglarlo, yo digo lo que falla, pero no pidas los errores cuando estas liado con otra cosa (¿no estabas con la migración a OpenGL?).
Además, ya lo he dicho: me quedan dos semanas y poco para terminarlo :S

quiero que el reporte sea a consciencia, resultado de pruebas reales que hagas en tu desarrollo, no quiero un reporte diferencias DIV (si seria interesante, pero no puede ser considerado BUG pues pueden ser particularidades de cada lenguaje) y tampoco quiero un reporte como el que inicio este hilo, donde no fue un BUG sino un fallo tuyo.

por favor no me corras con eso de "estas liado en otras cosas", mis otra cosas son "BennuGD" linea oficial!

lo que quiero que se entienda cuando digo estoy en otras cosas, es que no puedo dedicarle a ayudar a todo el mundo en sus codigos, ya que estoy mucho tiempo resolviendo cosas de los demas y luego ni soy mencionado, y no es que me interese el credito, sino que se entienda porque demoro en avanzar en el lenguaje, esto es, cada 1 que ayudo (debugeo su codigo, ayudo a crear algoritmos, corrijo sus codigos y otras cosas mas) no es al unico que se lo hago, la mayoria pide cosas... y no me molesta, pero para la mayoria parece que no estoy haciendo nada o que no hago nada para los usuarios.

bennu es mi responsabilidad y mi ocupacion si hay que corregir algo, hay que hacerlo, si esperas que alguien mas corrija el modo7 entonces olvidate. Para corregirlo, no se trata de saber del tema o no, se trata de hacer un buen reporte del bug.

el opengl esta suspendido de momento, porque no se puede hacer todo lo que hace bennu con opengl.

Bueno, como quieras, yo pensé que andabas demasiado liado para ponerte con el modo7.

Obviamente, los problemas no son cosas como el que tenía yo en el primer mensaje, que era cosa mía, lo sé. Son cosas como las que te he comentado en el PM, y que no son cosas "que tenía DIV y no Fenix/Bennu".

-Procesos "target" que tiemblan al hacer advance, porque estos se situan en el centro del pixel del plano abatido, que abarca más de un pixel de pantalla, y no coincide con el centro de la pantalla. No encuentro el hilo donde lo comenté, supongo que tendrás por ahí el código que te mandé la última vez.
-Los procesos en c_m7 no se situan en el suelo pese a tener height=0.
-Los procesos en c_m7 tienen un tamaño muy pequeño. No digo que ocupen los mismos pixels de ancho que el propio m7, pero que un sprite de 32x32 se vea a 8x8 a 10 pixels de distancia (ocupando, según el suelo, 2 pixels de ancho) se me antoja demasiado.
-El modo7 toma ANGLE como el ángulo hacia el que está mirando sobre el plano (para girar a izquierda y derecha) pero sigue funcionando para rotar el sprite.
-La transparencia del modo7 no tiene en cuenta los procesos con c_m7 y un segundo m7 puede tapar un sprite (en los ejemplos que venían en Fenix se ve perfectamente).
-m7[0].color no funciona, o al menos no he conseguido que funcione.
-m7[0].horizon no funciona, y esto lleva así desde la primera versión de Fenix porque nadie sabía cómo implementarlo.
-Los márgenes de altura de los procesos c_m7 (altura máxima y altura mínima) son MUY limitados. Creo que +-128 pixels, frente a la altura que se le puede poner a m7.height (int),

Y el punto de rotación del modo7 tampoco coincide con el punto del proceso que hace de camera, pero esto supongo que es debido a que dicho proceso no está en el suelo.
En el PM tienes un ejemplo, y en el código que te mandé hace 5 meses tienes más. No tengo tiempo material para mandarte ejemplos más específicos, pero si me lo recuerdas en un par de meses, te hago todos los que quieras.

NOTA: no es mi intención parecer desagradable. Si lo ha parecido, significa que necesito URGENTEMENTE salir de casa :D :D :D

Si, por lo que más quieras, sal a la calle.  ;D ;D ;D ;D

Tu numero de 'smileis' a descendido drásticamente.  ;D ;D

drumpi, he puesto el suelo en el suelo y el proceso en el suelo tambien (cero), y tambien qe el centro sea el proceso.

tenes un error conceptual en lo que estas haciendo, quizas debido a que las variables tampoco tienen nombres muy amigables.

sin embargo creo que algunas cosas estan al reves, por ejemplo, alturas negativas ponen los m7 arriba, lo mismo las z, z negativas dibujan por detras, creo que eso esa al revez, pero no estoy seguro, tengo que mirarlo con detenimiento.

te copio aca el codigo modificado de lo que me mandaste por pm, aun tengo que ver cosas como el color, para ver como se usan.

lo del proceso que vibra necesita correccion, ahora me pongo a ver que es.

con respecto al modulo, he visto cosas que hay que corregir, como variables demas que nunca se usan y fue por copy&paste.


program test_mode7;

GLOBAL
   int graficos1;
   int color;
BEGIN
   //scale_mode=scale_nofilter;
   set_mode(320,240,8);
   set_fps(50,0);

   graficos1=load_fpg("graf2.fpg");
   say(itoa(graficos1));

   start_mode7(0,graficos1,1,0,0,64);
   start_mode7(1,graficos1,2,0,0,64);
   //m7.color=rgb(0,128,255);
   m7[0].color=127;
   m7[0].camera=id;

   m7[0].height=1; //A cierta altura del fondo
   m7[0].distance=0; //A cierta distancia del fondo original
   m7[0].focus=256;

   m7[1].color=123;
   m7[1].camera=id;

   m7[1].height=-32; //A cierta altura del fondo
   m7[1].distance=0; //A cierta distancia del fondo original
   m7[1].focus=256;
   m7[1].z=m7[0].z+1;

   ctype=c_m7;

   //cflags=1;

   resolution=100;
   //coche(graficos1);
   //file=graficos1;
   //graph=3;
   write_int(0,0,0,0,&color);

   coche2(graficos1);

   while (!key(_esc))
       color=map_get_pixel(graficos1,2,x/resolution,y/resolution);
       if (key(_up)) x+=100; end
       if (key(_down)) x-=100; end
       if (key(_left)) y-=100; end
       if (key(_right)) y+=100; end
       if (key(_c_minus) && m7[0].height>9)
           m7[0].height--;
           m7[1].height--;
       end
       if (key(_c_plus))
           m7[0].height++;
           m7[1].height++;
       end
       if (key(_w)) advance(100); end
       if (key(_s)) advance(-100); end
       if (key(_a)) angle+=2000; end
       if (key(_d)) angle-=2000; end

       if (key(_f1)) m7[0].focus--; end
       if (key(_f2)) m7[0].focus++; end
       if (key(_z)) m7[0].distance--; end
       if (key(_x)) m7[0].distance++; end
       if (key(_c)) m7[1].height--; end
       if (key(_v)) m7[1].height++; end
       frame;
   end
   stop_mode7(0);
   let_me_alone();
END

process coche (file)
begin
   x=160;
   y=201;
   graph=3;
   signal(id,s_freeze);
   frame;
end

process coche2 (file)
begin
   y=100;
   graph=3;
   ctype=c_m7;
//    cnumber=0;
//    z=m7[0].z-2;
   height=0;

   resolution=100;

   loop
       /*while (x<320)
           x++;
           frame;
       end
       while (x>0)
           x--;
           frame;
       end*/
       x=father.x;
       y=father.y;
       xadvance(father.angle, 1000);
       //height=m7[0].height-9;
       frame;
   end
end


te copio el codigo para que lo compares, si me pongo a explicar va a ser largo e innecesario, ya que lo puedes ver por comparacion.

saludos

Estuve trabajando bastante en el asunto, el problema de la vibracion es que tu camara no es un proceso c_m7 (a mi ya no me pasa desde que lo puse como c_m7).
Luego he encontrado y corregido un par de cosas, como ser que el centro de la rotacion no estaba posicionado correctamente, ya esta corregido, aun sigo teniendo el grafico que no se pone en el suelo.

y con respecto a los height de los planos creo que estan al revez, un positivo pone el plano por debajo y un negativo por arriba, no se si esto deberia ser asi o esta mal.

pero ya tengo un m7 mejor, en prueba, debere por unos dias pararlo, porque ahora tengo trabajo por hacer.

Huy que emoción novedades en el modo 7... Recuerdo que me puse a usar Bennu3D cuando ví que el modo 7 no me ofrecía lo que quería, la verdad era complicadete, cualquier descarga para ver lo que andáis haciendo se agradecerá :D

solo probando en linux.

igual no creo que te ofrezca gran cosa el modo 7, es poner planos horizontales con perspectiva, y dibujar procesos (que no rotan sobre si mismo, salvo como rotan en 2d) puestos en perspectiva 2d (o sea, se ven mas grandes o mas chicos y mas arriba o mas abajo)

Hombre, un modo7 siempre es un aire retro interesante, que bien aprovechado se pueden hacer cosillas en pseudo3D sin necesitar mucha máquina :)
Ahí está el Kario, Wacky Weels, Street Racer o el bonus de Sonic CD.

No he tenido tiempo de mirar lo que pusistes, Splinter, lo siento: mi equipo del concurso requiere que atienda otras peticiones más urgentes, y la librería ncurses hace cosas raras emitiendo por el telnet del puerto serie :S

En teoría, height indica la altura respecto al modo7, positivo arriba (creo, no he mirado la ayuda de div), y Z funciona igual que siempre en los m7: más negativo, más por encima se dibuja, en los procesos creo que va ligado la Z a las coordenadas X e Y (¿o era la altura del modo7?).
Lo siento, últimamente no pienso con claridad. ^^U

Tu tómate tu tiempo, a las malas, cambio el objetivo del nivel o cambio el nivel directamente, pero vamos, aun tengo más cosas por hacer de cara a final de mes ;)

El modo 7 tiene que estar si o si.

Vale, he probado el código, y siguen los problemas de temblores. Si bien el proceso coche2 ahora si tiene un tamaño adecuado (tendré que jugar con focus) sigue teniendo los problemas que comentaba con el cambio de altura: en cuanto he levantado la cámara, el proceso coche ha "subido" durante los primeros pixels y al quedarse a media atura ha dejado de hacerlo, y al atravesar el techo ha aparecido el "segundo" coche2 (el eco para el segundo modo7).
También he visto que el techo se dibuja por detrás del suelo, dando un efecto extraño, por lo que las z de los modos 7 estaban bien definidas... y aun así se siguen tapando los procesos por encima del techo: no se ven hasta que m7

• .height>=0.
  
  PD: comprobado, la variable local height no tiene ningún efecto sobre la altura de un proceso con c_type=c_m7, y z tampoco.

Buenas noticias: la variable local HEIGHT si que tiene efecto, sólo que prece que está mal calibrado: en la prueba que he hecho, con el m7[0].height=9, la posición correcta sería con height=-170 (a ojo, haciendo rotaciones cerca de él y comprobando que no se movía del pixel), pero con el m7[0].height=4 aproximadamente sería una HEIGHT=0, y con m7[0].height=0 no hace ni caso. Parece que a partir de m7[0].height=60 se comporta de forma más lineal, por lo que es posible que haya alguna función tangencial o exponencial por ahi mal calculada.

Esto probando con esto:
[code language="bennu"]program test_mode7;

GLOBAL
    int graficos1;
    int color;
BEGIN
    //scale_mode=scale_nofilter;
    set_mode(320,240,8);
    set_fps(50,0);
   
    graficos1=load_fpg("graf2.fpg");
    say(itoa(graficos1));
   
    start_mode7(0,graficos1,1,0,0,64);
    //start_mode7(1,graficos1,2,0,0,64);
    //m7.color=rgb(0,128,255);
    m7[0].color=15;
    m7[0].camera=id;
   
    m7[0].height=9; //A cierta altura del fondo
    m7[0].distance=12; //23; //A cierta distancia del fondo original
    m7[0].focus=256; //128;
   
    m7[1].color=15;
    m7[1].camera=id;
   
    m7[1].height=-6; //A cierta altura del fondo
    m7[1].distance=12; //23; //A cierta distancia del fondo original
    m7[1].focus=256; //128;
    m7[1].z=m7[0].z-1;
    ctype=c_m7;
    //cflags=1;
   
    resolution=100;
    coche(graficos1);
    //file=graficos1;
    //graph=3;
    //write_int(0,0,0,0,&color);
   
    coche2(graficos1);
   
    while (!key(_esc))
        color=map_get_pixel(graficos1,2,x/resolution,y/resolution);
        if (key(_up)) x+=100; end
        if (key(_down)) x-=100; end
        if (key(_left)) y-=100; end
        if (key(_right)) y+=100; end
        if (key(_c_minus) && m7[0].height>9)
            m7[0].height--;
            m7[1].height--;
        end
        if (key(_c_plus))
            m7[0].height++;
            m7[1].height++;
        end
        if (key(_w)) advance(100); end
        if (key(_s)) advance(-100); end
        if (key(_a)) angle+=2000; end
        if (key(_d)) angle-=2000; end
       
        if (key(_f1)) m7[0].focus--; end
        if (key(_f2)) m7[0].focus++; end
        if (key(_z)) m7[0].distance--; end
        if (key(_x)) m7[0].distance++; end
        if (key(_c)) m7[1].height--; end
        if (key(_v)) m7[1].height++; end
        frame;
    end
    stop_mode7(0);
    let_me_alone();
END

process coche (file)
begin
    x=160;
    y=201;
    size=200;
    graph=3;
    signal(id,s_freeze);
    frame;
end

process coche2 (file)
begin
    x=100;
    y=100;
    graph=3;
    ctype=c_m7;
    cnumber=0;
    z=m7[0].z-2;
    height=-170;
   
    //resolution=100;
    loop
        /*while (x<320)
            x++;
            if (key(_o)) height--; end
            if (key(_p)) height++; end
            frame;
        end
        while (x>0)
            x--;
            if (key(_o)) height--; end
            if (key(_p)) height++; end
            frame;
        end*/
        if (key(_o)) height--; end
        if (key(_p)) height++; end
        /*x=father.x;
        y=father.y;
        xadvance(father.angle, 1000);
        height=m7[0].height-9;*/
        frame;
    end
end[/code]

Acercate al coche2 que está parado en medio, gira la cámara con A y D y verás lo que te digo de mantenerse en el pixel (también es verdad que el centro del triángulo no está a los pies de este) y haz pruebas cambiando la altura del coche2 con O y P a distintas alturas del modo7 (+ y - del teclado numérico).

ya lo del centro esta corregido, cuando tanga tiempo tengo que resolver lo del height, y ajustar eso, es correcto lo que decis, esta descalibrado, eso era lo que intente decir, por si no se entendio

Tus tests son de gran utilidad para mejorar el modo 7, muchas gracias Drumpi.

Quote from: blostec on June 16, 2010, 09:29:06 AM
Tus tests son de gran utilidad para mejorar el modo 7, muchas gracias Drumpi.

Ojalá fuera un test, en estos momentos es una de mis pesadillas :D :D :D
Si todo va bien, lo vereis en un par de semanas en vuestras WIZ (si Anarchy permite publicar, si no tendréis que esperar al resultado). Por bien se entiende que nos de tiempo y que funcione bien (eso incluiría las correcciones de bennu si le da tiempo a Splinter a sacar una nueva versión en 7 días).

cuando cierra el concurso?

El concurso acaba el 30 de julio, pero yo me voy todo el mes de vacaciones, por lo que no voy a poder programar, así que debo tener toda la parte de código lista para el día 1, luego que se las arreglen mis compañeros de fatigas para sustituir todos los gráficos de los FPG y los sonidos y músicas ^^U

dudo que yo en 7 dias tenga esto listo, ya que los proximos 10-15 dias tengo que trabajar a toda maquina, para hacer una entrega.

No importa, de momento lo hago a ratos. Sólo me falta conseguir que los otros coches puedan saltar de un modo7 al otro y listo. Si tengo re recurrir a alguna argucia gráfica, pues nada, se hará, aunque sea sólo cambiar el cnumber para que hagan un "salto fantasma".

Por cierto, lo del cnumber no lo entiendo: lo pongo a 0 y se ese proceso en ambos modos7, y si lo pongo a 1 se ve en el m7[1] y no en el m7[0]. Tendré que mirarlo.

si se comporta como el scroll, 0 es en todos, y luego los numeros son los planos

Definitivamente hay un bug en los modos 7 con el cnumber:

Con el código tal cual, con cnumber=0 se ve en todos los modos7, si pongo C_0 (1) se me ve en el modo7 del techo, el modo7 número 1, y si pongo C_1 (2) deja de verse.
Ahora, he cambiado el modo7 número 0 por el 1, y el 1 por el 2 (vamos, que en lugar de ejecutar los modos7 0 y 1, ahora lo hago con 1 y 2), y C_0 me lo pone en el modo7 del suelo y C_1 me lo pone en el del techo, y si pongo cnumber a 0 se me ve en ambos.

Sospecho que se tomó el valor 0 como "dibuja en todos los scrolls" y no se acordaron de que el modo7 número 0 existe a la hora de asignar un bit a cada uno. Se supone que cnumber se usa como flags sobre en qué scroll/modo7 debe dibujarse, no lo he mirado en scroll, pero definitivamente hay un planteamiento mal hecho en el modo7, los bits se han desplazado:

Actualmente:
0= dibujar en todos
1= dibujar en modo7[1]
2= dibujar en modo7[2]
4= dibujar en modo7[3]
8= dibujar en modo7[4]
3= dibujar en modo7[1] y modo7[2]
5= dibujar en modo7[1] y modo7[3]

Recomendado:
0= no dibujar (o dibujar en todos)
1= dibujar en modo7[0]
2= dibujar en modo7[1]
4= dibujar en modo7[2]
8= dibujar en modo7[3]
3= dibujar en modo7[0] y modo7[1]
5= dibujar en modo7[0] y modo7[2]
...
default= hx000003FF ó 0

drumpi, eso funciona bien, lo que te dije me parece que no esta bien es el height, si cambias el height vas a ver que se ven los que decis no se ven.

esto es y debe ser:

0 todos

luego los bits de c_number son:

1 = m7[0]
2 = m7[1]
4 = m7[2]
8 = m7[3]
16 = m7[4]
32 = m7[5]
64 = m7[6]
128 = m7[7]
256 = m7[8]
512 = m7[9]
1024 = m7[10]

referencia:

            if ( LOCDWORD( mod_m7, i, CNUMBER ) && !( LOCDWORD( mod_m7, i, CNUMBER ) & ( 1 << ( n - 1 ) ) ) )

n es el scroll a dibujar, ahi barre todos los procesos, y en caso de que esa condicion se cumpla, descarta ese proceso.

Quiero que cojas el modo7.prg que adjunto y subas la cámara, y te acerques (no demasiado) al proceso coche2 que está quieto en el centro de la escena, abras la consola y le asignes diversos valores a coche.cnumber.
Luego haz lo mismo con modo7b.prg.

Con el primer código verás dos coche2 a distinta altura con cnumber a 0, y en la parte de arriba con cnumber a 1, y desaparecerá con cnumber=2.
En el segundo tambien verás ambos coches con cnumber a 0, pero si lo pones a 1 lo verás en el de abajo, y con 2 en el de arriba.
Siempre perfectamente alineados con el suelo de dicho modo7, ya que NO CAMBIAMOS HEIGHT.

A ver si de verdad estoy equivocado.

que mezcla te estas armando...

0 son todos los m7
c_0 es el primer m7 (m7[0])
c_1 es el 2do m7 (m7[1])

y asi...

seguis sin definir el proceso coche sin ctype.

estas cometiendo varios errores en tu ejemplo lo que no te permite ver claramente los problemas, no digo que no los haya, pero estas diagnosticando mal.

No, no me estoy equivocando: coche no usa ctype=c_m7 porque si hago eso, al avanzar con ángulo, tiembla, y eso no está bien visto. Es un arreglo provisional mientras se soluciona, sobre todo para no meterte prisa.

Y te digo que, según mis pruebas y en eso no me equivoco:
c_0 es m7[1]
c_1 es m7[2]
c_2 es m7[3]
etc...
Comprobado con esos dos códigos, porque coche 2 aparece a altura 0, y no por debajo del scroll, porque si no, con c_2, en modo7b.prg debería verse y no lo hace
O con c_1, que no se ve en mode7.prg y sí en mode7b.prg a la altura del modo7-techo.
A menos que hicieses correciones a partir de la r131.

drumpi, a ver si me escuchas...

para que el proceso este dentro del m7, tiene que ser tipo c_m7, te guste o no, sino no esta dentro del m7, que vibre es otra cosa, pero si haces lo que queres entonces no pretendas que funcione.

el objeto vibra porque la camara va moviendose, entonces se aleja minimamente del objeto que sigue.

coche no lo estas poniendo dentro del sistema m7, y tampoco tiene c_number, el coche2, esta metido en el scroll c_1, o sea, m7[1] por eso es que no lo ves en el otro scroll, ya he probado los c_number, correctamente usados y correctamente seteadas las estructuras y funciona a la perfeccion.

mas alla de todo esto, no estas teniendo en cuenta los puntos de control del grafico, por eso tampoco se coloca sobre el piso, luego los height estan mal seteados, lo mismo que la distancia, son con respecto a la camara.

puf, ya me confundiste, c_0, c_1, c_... son de scroll, no de m7.

jejeje, parece que igual esta mal tambien el cnumber... :D

ya lo acabo de corregir, el "-1" de la linea que puse arriba estaba demas... :D :D :D

ya tengo el m7 corregido!

por lo menos lo de la altura, y demas... voy a probar un poco mejor.

ya actualice el svn, aca esta el programa de ejemplo, por favor drumpi, fijate bien como setee cada cosa en el codigo.

Okis, mañana hago la prueba con la nueva versión, a ver qué tal va.

Pero sigues empeñado con poner coche en el modo7 ¡yo no quiero que "coche" esté en el modo7 :D! y coche2 no es el proceso al que sigue la cámara.
Aun con todo y con eso, con mi r131, los dos procesos "coche" se pintan por encima del techo, en lugar de en el suelo, que es lo que trataba de decirte: tienen cnumber=1, y si intentas que se vean en el suelo, deberías poner cnumber a 0, y eso hace que salgan en todos los modos 7.

Ya digo, mañana pruebo con la nueva versión y te cuento lo que vea ;)

por favor, prueba esta version y luego vuelves a decir todo, pero por favor contesta y comenta como te fue, porque ahora que subi version se te acabo la actividad frenetica.

objetos que no son c_m7, son objetos que estan fuera del modo7, no tienen ni perspectiva (tamaño), ni estaran en el suelo, ni estaran volando ni nada, estaran fijos en la pantalla o moviendose en unas coordenadas que no tienen relacion con los objetos ni planos del modo 7, pero no me vuelvas a decir que el coche no esta en el piso si usas un objeto que no es c_m7, porque nada tiene que ver con el modo 7, son 2 sistemas diferentes.

con el ejemplo, solo te estoy mostrando, que el objeto esta centrado, en el suelo, que se dibuja en los planos correctos y que funciona perfectamente.

y si me lees cuando escribo, veras cosas como que dije que corregi tambien un comportamiento del uso de cnumber.

Ahora sí, con esta nueva versión va de LUJO: el temblor se ha reducido al mínimo (hay que estar con la lupa para notarlo), las alturas van perfectas y el cnumber funciona correctamente :)
¡¡¡YA TENEMOS UN MODO7 DIGNO DE BENNU!!!

Muchísimas gracias por el esfuerzo, ahora sí que da gusto trabajar con él, y ten por seguro que voy a sacar un nivel dedicado a este en mi próximo juego, pero de una forma que (por lo menos yo) no se ha visto en otros juegos :P
Karma up.

PD: siendo tiquismiquis (ya que me dijiste que dijera los fallos que encontrase), aun quedaría:
-El que no funcione a 16/32 bits de color.
-Que el color exterior no funcione (me refiero a m7[tal].color que hace que si no hay un gráfico de exterior se coloree todo con él).
-Que los procesos con ctype=c_m7 no se "corten" con el modo7.
-Que falle con los escalados 2x (2x_scale, scale_nofilter...).
-No lo he comprobado, pero con el Drajon Lol, el gráfico externo, pese a ser de 64x64, sólo se dibujaban los primeros 32x32 pixels (es en el nivel 3, por si quieres mirarlo, no puedo hacerte ahora un ejemplo).
De todas formas, esto ya no me hace falta, es sólo por perfeccionar el modo7, porque también está el tema del horizon, pero esos son cambios demasiado gordos ya ^^U

PD: respondiendo a lo que no está en el modo7, ya se que sin ctype=c_m7 sus coordenadas y demás son respecto a la pantalla, lo hice para evitar el temblor. Tampoco se ven los mapas de durezas en pantalla pero están ahí, o los focos de visión de los guardias. Esto que yo hacía, también se hacía antes, para meterle animaciones al prota, efectos gráficos (rotaciones y demás) y para reducir los cálculos de un nuevo proceso de modo7 (reescalados, cálculos de ángulos de visión (xgraph), etc)... pero no tiene mayor relevancia.

buenisimo!

- 16 y 32 no funciona porque el render se hace en el mod_m7, solo necesito tiempo para codificarlo.
- el color, funciona perfectamente, proba esto:

    start_mode7(0,graficos1,1,-1,0,64);
    start_mode7(1,graficos1,2,-1,0,64);

- no se a que te referis con "no se corten con el modo7", hablame en español neutro.
- los escalados no funcionan, porque un modo 8 bits escalado es un modo 16bits. (volvemos al primer tip de esta lista)
- no puedo verlo ahora, si que quieres pasar un codigo de pruebas, lo vere para cuando tenga tiempo en unas semanas.

gracias por los comentarios.

Vale, no había caido en que el gráfico NULL ahora era el -1 ^^U
Lo de cortarse me refiero a que si un objeto se "hunde" en el modo7, parte de él se tapa, se ve "cortado".
Y lo de la prueba, como dije, tendrá que esperar, no tengo tiempo ni para respirar.

se corta? yo la prueba que habia hecho no se cortaba, y eso me rayaba, porque se supone que debe cortarlo, o sea, si tengo un plano por ejemplo de agua, y tengo un sprite que se mete en parte en el plano, este deberia verse por la mitad... fantastico si lo hace, aunque me suena que no lo hace.

Vaya, estoy más dormido de lo que pensaba ^^U
Quería decir que NO se corta, pero que debería hacerlo, actualmente es difícil seguirle la altura a los procesos del modo7 salvo que se esté girando.

si, es cierto, deberia, yo tambien note eso, pero bueno, tomemoslo ahora como una limitacion.

Pero en Div se corta o no ?
Igual os tengo que echar una mano por si hay algo que no sea identico al precioso modo7 de Div.

ni idea, tendria que instalar el DIV en un dosbox, y necesitaria tiempo.

Lo mismo digo yo al reves, tendria que probar de una vez el modo7 de Bennu  ;D

Pero vamos, si cuando lo pruebe veo que la cosa no es compatible o no funciona de igual modo, os puedo echar una mano para que así sea.

como quieras, yo ahora no tengo tiempo de seguir con esto, tengo un par de semanas de trabajo a full.

Lo cierto es que no me acuerdo si en Div se cortaba o no, creo recordar que si.

De todas formas, este modo 7 no es como el de DIV: las medidas son distintas y el suelo parecía más "suave" (aqui, de alguna forma, se nota más "límpio"). Además tenía más cosas como el cambio del horizonte y... y...
Y sin embargo, aquí tenemos modo7 con transparencia (que antes no existía), y con flags estilo procesos (espejado, TRANSPARENCIA, flag aditivo...). No he mirado si también tiene alpha, ya sería la repanocha ^^U

Lo que me fastidia mucho es que no tenga las mismas medidas, porque un port directo sería imposible, pero bueno, muy poquita gente ha hecho juegos en el modo7 de DIV... pero claro, yo hablo del intento de port que hice hace años en Fenix, quizás los cambios del cálculo de alturas sirven para facilitar mucho el port (usaba valores monstruosamente grandes para recrear el espacio, y las limitaciones de altura por el bug hacía que las rocas estuviesen muy muy muy abajo).
Yo no tengo queja alguna ahora.

Se han hecho un numero significativo, lo que pasa es que muchos estan olvidados. De todos modos tengo que refrescar la memoria y probar de nuevo el modo7 de DIV y ver de una vez el de Bennu para aclarar las diferencias. Yo sólo quiero es que se puedan adaptar facilmente estos juegos antiguos de DIV a Bennu con identico resultado como requisito minímo.

bien, he probado el juego speed de div1, y funciona, tuve que corregir algunas cosas, pero la altura esta demasiado alto, supongo que el focus tambien, luego la velocidad va lenta aunque los otros coches van de lujo, y la rotacion (xgraph) de nuestro coche no es correcta, la de los demas esta perfecta.

esto es cuestion de ajustar valores, a ver si podes dar una mano con eso, saludos.

Yo lo siento, hasta aquí puedo ayudar. Tenía pensado excluir el nivel y todo, pero gracias a estos avances y a las pruebas ya tengo la mitad del código hecho. Si finalmente me quedo en casa en Julio, quizás pueda echar una mano, si no, hasta finales de agosto no voy a estar disponible.

Ya lo dije, fallan los valores que no son 1:1 (¿es necesario llegar a eso?). De todas formas me extraña que unos procesos funcionen bien de velocidad y de xgraph y otros no, si todos están en el mismo m7 (no lo he mirado, pero es raro lo que cuentas, Splinter).

Sería interesante tener acceso al viejo código de DIV, aquel que supuestamete se filtró.

me referia a free, que si quiere ayudar a ajustar eso, fantastico.

con respecto al codigo viejo de div, no hace falta ni creo sea conveniente.

He empezado a mirar los ejemplos con Bennu, la verdad ni tenia idea de que el modo7 de Bennu no funcionase a 16/32 bits. Creo que esto seria muy importante ya que permitiria hacer suelos de modo7 mucho más realistas con gráficos de alta calidad.

Púes bien, me ha entrado el gusanillo y te voy a intentar hacer un modo7 en forma de dll que soporte estas profundidades, con nombres de funciones distintas para no entrar en conflicto con la oficial.

He estado probando el ejemplo en Bennu y Div (el mismo), la verdad hay diferencias significativas.

1 - El horizonte es más alejado en DIV, la verdad me encanta como lo pinta Bennu, igual hay opiniones divergentes, pero el de Bennu me parece mucho más logrado, ya que tiene una inclinación menor y se ve mejor la parte de abajo y de arriba.

2 - El de Div es mucho más rápido, aunque tambien me imagino que sea por la diferencia del punto 1, o sea, no será de rendimiento, pero si porque tenemos distancias mucho mayores y estas se recorren más deprisa (el horizonte es mucho más lejano).

3 - En div el fondo fuera del modo 7 sale verde, y en Bennu no salen cosas raras con esta, aparte de que en Bennu inicialmente empezamos encima del plano del suelo y en div este esta más afastado y tenemos un agujero en el suelo (pero esto es cosa de configurar las coordenadas iniciales).

4 - Para mi ya sólo faltaria el soporte de 16/32 bits, lo demás me parece mucho más conseguido.

Pongo dos pantallas de comparación y otra de Div que es justo lo que sale al principio con el fondo verde.

(http://forum.bennugd.org/index.php?action=dlattach;topic=1441.0;attach=1268)

(http://forum.bennugd.org/index.php?action=dlattach;topic=1441.0;attach=1270)

(http://forum.bennugd.org/index.php?action=dlattach;topic=1441.0;attach=1272)

¿Es factible/posible lo del modo7 en 16/32 bits?

Logicamente es posible, si ya existe en otros div-like.

veo que el ejemplo de DIV es menos preciso, eso se debe al foco, dale mas foco al de DIV y se acercara al de bennugd.

lo de 16 y 32 no te preocupes, yo lo hare, necesito tiempo y no quiero que sean funciones diferentes, en 1 semana tendre tiempo libre y lo hare.

yo queria ajustar el tema de los seteos, pero si dices que va mejor en bennu, me alegro pues, quedara asi.

que significa "afastado" ?

otra cosa, probaste el tema de que pasa cuando un objeto esta en una altura mas abajo del suelo? o sea, se corta el grafico o no?

Yo lo que veo son distintos valores de foco, altura y distancia, nada más.
Lo del verde del exterior también lo tiene Bennu, sólo que hay que indicar como segundo gráfico en el start_mode7 el mapa -1 en lugar de 0 (en DIV, el mapa 0 indica la usencia de este, en bennu es el -1). Sería interesante añadir al FPG un mapa de 64x64 QUE NO SEA DE COLOR PLANO para comprobar si aparece repetido en el exterior del mapa principal y SIN CORTES (lo mismo, indicar que use ese mapa como segundo gráfico en el modo7).

Supongo que el problema del modo 8bits se debe al tipo de superficie SDL donde se dibuja el modo7, que se habrá creado de 8bits en lugar del modo gráfico.

El día que se arregle lo de la altura del horizonte, lo que sería la leche sería ver algo así:
http://www.youtube.com/watch?v=rEduetMyQyk
;D ;D ;D
Ni en los sueños más húmedos, jejeje. De todas formas, mirad la primera parte de este juego, lo sencillo que es y como engancha el joio.

no, no, yo se perfectamente por que solo dibuja en 8bits, no tengo que pensar nada, solo necesito tiempo para codificarlo.

no se que decis el horizonte, el horizonte es una variable en la estructura m7, seteala al valor que quieras.

ese juego del video tiene planos con alturas, eso no lo permite el modo 7 (creo)

afastado = alejado (mi portugañol me mata  ;D).

No he visto nada que me parecierá distinto en ese video Drumpi.

Lo que estaria bien seria poder controlar la inclinación del plano en vertical (no se si es posible ya), o sea, poder ponerlo como en div, o en el juego de coches del video, etc.

el juego de ese video no es DIV... es de GBA

en DIV no se si puede eso, yo no lo recuerdo? de hacerlo, como maneja la altura? tiene un mapa adicional de alturas?

Se que es de GBA, estaba hablando en poder tener resultados similares con Bennu logicamente.

Funciones del Modo 7 de DIV al desnudo :):

  move_scroll()
  refresh_scroll()
  start_mode7()
  start_scroll()
  stop_mode7()
  stop_scroll()

move_scroll(<número de scroll>)

Descripción:

Fuerza a mover un scroll automático de forma inmediata. Esta es una función algo avanzada y por ello puede resultar difícil de comprender su propósito.

La función requiere como parámetro el <número de scroll> de 0 a 9 que se indicó en la función start_scroll() como primer parámetro cuando se inició el scroll.

Esta función se utiliza cuando una región de scroll se controla automáticamente, por haber definido el campo camera de la estructura scroll correspondiente con el identificador de un proceso.

El propósito es forzar a que se actualicen los valores (x0, y0, x1 y y1) de dicha estructura; si no se utiliza esta función estos valores no se actualizarán hasta la próxima imagen del juego.

Es decir, cuando un scroll se controla de forma automática y otro proceso necesita conocer antes de la próxima imagen el valor de las coordenadas de dicho scroll (normalmente para colocarse él en una posición acorde al movimiento del fondo) se debe hacer esto:

1 - Se inicia el scroll con start_scroll().

2 - Se crea el proceso que se utilizará como cámara y se pone su código identificador en el campo camera de la estructura scroll.

3 - A este proceso se le debe poner una prioridad muy alta, para que se ejecute antes que el resto de los procesos (poniendo en su variable local priority un valor entero positivo como, por ejemplo, 100).

4 - Justo antes de la sentencia FRAME del bucle del proceso usado como cámara se llamará a la función move_scroll().

De esta forma se garantizará que este proceso se ejecute el primero y, justo al finalizar, actualice los valores (x0, y0, x1 y y1) de la estructura scroll, de forma que el resto de los procesos puedan utilizar estas variables ya actualizadas.

El uso más generalizado de esta función es cuando en una ventana de scroll se quieren tener más de dos planos de fondo y, para ello, se crean una serie de procesos que simulen un tercer o cuarto plano, situando sus coordenadas en función de la posición exacta del scroll en cada imagen.


refresh_scroll(<número de scroll>)

Descripción:

Esta función se utiliza cuando se ha modificado un gráfico con las funciones map_put(), map_xput(), map_block_copy() o map_put_pixel() que está siendo utilizado como fondo de una región de scroll, para actualizarlo.

La función requiere como parámetro el <número de scroll> que se especificó al iniciar el scroll con la función start_scroll().

Cuando se modifica un gráfico que está siendo utilizado como fondo de un scroll no se actualiza en pantalla automáticamente, sino que hay que llamar a esta función para ello.

Una vez modificado el gráfico permanecerá así durante el resto de la ejecución del programa, a no ser que se descargue el gráfico de memoria (con unload_fpg(), unload_map() o unload_pcx()) y se vuelva a cargar, en cuyo caso se recuperará el estado original del gráfico.

start_mode7(<número de m7>,  <fichero>, <gráfico>, <gráfico exterior>,                <número de región>, <altura del horizonte>)

Descripción:

Ésta es una función avanzada que requiere que el usuario tenga cierta soltura para poder utilizarla.

Crea una ventana de visualización de un modo 7, es decir, visualiza un gráfico tridimensionalmente en un plano abatido; para conseguir este efecto se llamará a esta función con los siguientes parámetros:

<número de m7> - Se pueden crear hasta 10 ventanas de modo 7 en pantalla, con los número del 0 al 9; si únicamente se quiere crear una, lo mejor es definir la número 0. Este número será necesario posteriormente para modificar los parámetros de la ventana, pues el sistema necesitará saber cuál de las 10 posibles ventanas de modo 7 se quiere alterar.

<fichero> - Los gráficos que se pretendan abatir en la ventana deben estar en un fichero cuyo código de fichero se debe especificar aquí, como segundo parámetro de la función. Los gráficos cargados con las funciones load_map() o load_pcx() (o creados con new_map()) se utilizarán como si pertenecieran al primer fichero (el fichero con el código 0).

<gráfico> - El tercer parámetro debe ser el código del gráfico principal que se va a abatir en la ventana y debe pertenecer al fichero anteriormente indicado.

<gráfico exterior> - Aquí se puede indicar un 0 si no se quiere que se vea ningún gráfico más allá del gráfico abatido en la perspectiva, o bien un código de gráfico del mismo fichero que se mostrará en la perspectiva más allá del gráfico principal, hasta alcanzar el horizonte. Este gráfico debe ser de un ancho y alto potencia de dos, no mayor de 8192 (estas potencias de dos son: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096 y 8192), por ejemplo, podría ser un gráfico de 64 puntos de ancho por 32 de alto; este gráfico se mostrará también abatido.

<número de región> - Aquí se indicará la región rectangular de pantalla en la que se va a mostrar el modo 7. Si se indica 0 como número de región, se mostrará en toda la pantalla. El resto de regiones se deben definir previamente con la función define_región() (una región no es más que una zona rectangular de la pantalla).

<altura del horizonte> - Como último parámetro se indicará a cuántos puntos desde la parte superior de la ventana se quiere situar la línea del horizonte. Si la cámara se sitúa por encima del plano abatido, entonces no se mostrará nada por encima de la línea del horizonte (ese hueco se suele rellenar con otra ventana de scroll o de modo 7); en cambio si la camara se sitúa por debajo del plano, entonces no se mostrará nada por debajo de la línea del horizonte.

Además de la llamada a la función se deben inicializar algunos valores de la estructura global m7 para el correcto funcionamiento de la ventana. Ésta es una estructura de 10 registros (uno para cada posible ventana de modo 7) y cada registro tiene los siguientes campos:

  camera - Código identificador de la cámara
  height - Altura de la cámara
  distance - Distancia de la cámara
  horizon - Altura del horizonte
  focus - Focal de visión
  z - Plano de profundidad
  color - Color del exterior

Importante: El campo camera es imprescindible inicializarlo para que se active la ventana de modo 7 ya que, sin este campo, la ventana no puede determinar desde dónde se debe ver el plano abatido.

La cámara se situará en el plano abatido a la distancia (distance) indicada del proceso cuyo código identificador se haya puesto en camera, y mirando en su mismo ángulo (el que indique su variable local angle). La altura a la que se sitúa la cámara respecto al suelo será la indicada en el campo height.

start_scroll(<número de scroll>,  <fichero>, <gráfico>, <gráfico fondo>,                 <número de región>, <indicador de bloqueo>)

Descripción:

Esta es una función de cierta complejidad, que requiere que el usuario tenga cierta soltura (haya realizado algún programa antes) para poder utilizarla.

Crea una ventana de scroll, en la que se realizará una panorámica sobre un gráfico de fondo (el decorado del juego). Es decir, utilizando como fondo del juego un gráfico más grande que la ventana de visualización, se podrá mostrar una parte del mismo e ir desplazándolo en cualquier dirección.

Para conseguir este efecto se llamará a esta función con los siguientes parámetros:

<número de scroll> - Se pueden crear hasta 10 ventanas de scroll en pantalla, con los números del 0 al 9; si sólo se quiere crear una, lo mejor es definir la número 0. Este número será necesario posteriormente para modificar los parámetros de la ventana, pues el sistema necesitará saber cuál de las 10 posibles ventanas de scroll se quiere alterar.

<fichero> - Los gráficos que se pretendan mostrar como fondo o decorado en dicha ventana deben estar en un fichero cuyo código de fichero se debe especificar aquí, como segundo parámetro de la función. Los gráficos cargados con las funciones load_map() o load_pcx() (o creados con new_map()) se utilizarán como si pertenecieran al primer fichero (el fichero con el código 0).

<gráfico> - El tercer parámetro debe ser el código del gráfico principal que se va a mostrar como fondo en la ventana y debe pertenecer al fichero anteriormente indicado. Este gráfico suele ser el decorado principal del juego sobre el que se va a desarrollar la acción, un gráfico más grande que la ventana de visualización, que se irá desplazando en una o varias direcciones y sobre el que se situarán los gráficos del juego.

La ventana de scroll se situará inicialmente con el punto de control número 0 de este gráfico en la esquina superior izquierda, cuando se haya definido este punto en el editor gráfico.

<gráfico fondo> - Aquí se indicará un 0 si se quiere un sólo plano de scroll (un sólo gráfico de fondo), o bien otro código de gráfico si se quiere que éste aparezca como segundo plano de scroll (a mayor profundidad), detrás del plano principal. Para que se vea este plano de fondo es imprescindible que el gráfico principal (primer plano) tenga partes dibujadas con el color número 0 de la paleta, pues estas zonas transparentes serán las que permitirán ver a través de ellas el gráfico de fondo.

<número de región> - Aquí se indicará la región rectangular de pantalla en la que se va a mostrar el scroll, si se indica 0 como número de región, se mostrará en toda la pantalla. El resto de regiones se deben definir previamente con la función define_region() (una región no es más que una zona rectangular de la pantalla).

<indicador de bloqueo> - Aquí se indicará un valor que define si cada uno de los dos planos de scroll es cíclico en horizontal y vertical. Por ejemplo, un plano es cíclico en horizontal cuando al salirse del dibujo por la derecha aparece el dibujo por la izquierda. Para componer este valor se deben sumar las siguientes cantidades:

  + 1 - Si el primer plano es cíclico horizontalmente.
  + 2 - Si el primer plano es cíclico verticalmente.
  + 4 - Si el segundo plano es cíclico horizontalmente.
  + 8 - Si el segundo plano es cíclico verticalmente.

Es decir, 0 si ninguno de los dos planos debe ser cíclico, 15 (1+2+4+8) si ambos planos deben ser cíclicos en ambos ejes, 12 (4+8) si únicamente debe ser cíclico el segundo plano, etc.

Cuando un gráfico (principal o de fondo) sea más pequeño que la ventana de visualización, el sistema forzará a que su plano de scroll sea cíclico pues, en caso contrario, no se podría rellenar la ventana de scroll por completo, sin repetir cíclicamente el gráfico (en mosaico).

Además de la llamada a la función se deben inicializar algunos valores de la estructura global scroll para el correcto funcionamiento de la ventana. Ésta es una estructura de 10 registros (uno para cada posible ventana de scroll) y cada registro tiene los siguientes campos:

  x0, y0 - Coordenadas del primer plano
  x1, y1 - Coordenadas del segundo plano
  z - Plano de profundidad
  camera - Código identificador de la cámara
  ratio - Velocidad relativa del segundo plano
  speed - Velocidad máxima del primer plano
  region1 - Primera región de pantalla
  region2 - Segunda región de pantalla

Hay dos formas de programar el movimiento de las ventanas de scroll:

- Manualmente, modificando en cada imagen del juego los campos x0, y0, x1 e y1 de esta estructura (las coordenadas de los planos de scroll).

- Automáticamente, para lo que se necesita el código identificador de un proceso en el campo camera de esta estructura. Siendo a partir de entonces el sistema el encargado de realizar en la ventana de scroll un seguimiento al gráfico de este proceso.

stop_mode7(<número de m7>)

Descripción:

Elimina la ventana de modo 7 cuyo número (del 0 al 9) se pasa como parámetro. Este <número de m7> es el que se indicó como primer parámetro en la función start_mode7(), es necesario debido a que pueden haber hasta 10 ventanas diferentes de modo 7, y el sistema necesita saber cuál de ellas se está finalizando.

Al eliminar una ventana de modo 7, morirán automáticamente todos los procesos que pertenezcan en exclusiva a dicha ventana, es decir, todos los procesos que tengan su variable ctype con el valor c_m7 y no se estén visualizando en ninguna otra ventana de modo 7.

Importante: Al cambiar de modo de vídeo con la función set_mode() todas las ventanas de modo 7 (y sus procesos) serán igualmente eliminadas, no siendo en este caso necesario usar esta función (stop_mode7()).


stop_scroll(<número de scroll>)

Descripción:

Elimina la ventana de scroll cuyo número (del 0 al 9) se pasa como parámetro. Este <número de scroll> es el que se indicó como primer parámetro en la función start_scroll() y es necesario debido a que puede haber hasta 10 ventanas diferentes de scroll, y el sistema necesita saber cuál de ellas se está finalizando.

Al eliminar una ventana de scroll morirán, automáticamente, todos los procesos que pertenezcan en exclusiva a dicha ventana, es decir, todos los procesos que tengan su variable ctype con el valor c_scroll y no se estén visualizando en ninguna otra ventana de scroll.

Importante: Al cambiar de modo de vídeo con la función set_mode() todas las ventanas de scroll (y sus procesos) serán igualmente eliminadas, no siendo en este caso necesario usar esta función (stop_scroll()).

por que pusiste la descripcion de las funciones de scroll?

lo del grafico exterior lo podemos cambiar a 0, que se vea el color exterior tranquilamente.

Porque te permiten saber su comportamiento, lo detalla todo y así podrás resumir para cada una las diferencias en Bennu. Esto seria muy valioso tenerlo en la documentación de Bennu, por lo menos una descripción similar pero sobre las funciones de Bennu.

pero que tiene que ver el scroll con el modo7?

El scroll esta bien como esta, no se haran esas chanchadas como que al hacer set_mode se eliminen los scroll (ni los m7), aca las cosas que se hacen start, se tienen que hacer stop, bennu no fomentara los malos habitos de programacion. Si es que lo pusiste por eso.

Espero, por favor, que eso se entienda.

:)

No, DIV no maneja alturas, sólo digo que sería una posibilidad muy muy muy muy muy muy muy muy muy muy remota de mejora :D Obviamente no digo de meterlo, sólo era una broma. Y por supuesto, no tengo ni idea de cómo han logrado ese efecto, sólo se lo que se ve en el video: las alturas se limitan a modificar la posición de cada línea horizontal dibujada, en el juego a veces hace cosas muy raras si no tomas la rampa en el sentido en que se diseñó, sobre todo si tomas un cambio de rasante girando.

Y si, se puede modificar la variable de horizonte, pero no tiene ningún efecto (slainte dijo que no sabía cómo se implementaba eso).

Por cierto, acabo de toparme con algo que no me ha pasado desde que hacía burradas con el modo7: he provocado un overflow en las coordenadas. Tengo un proceso con resolution=100, y en cuanto paso la coordenada y=214500 el modo7 se me va a una posición (en el eje y) negativa. He hecho mis deberes, y sí, debe ser un overflow de una variable tipo INT interna (si multiplicamos por 10.000 coincide con el valor de MAX_INT).
No se si se puede hacer algo o es que yo soy muy bestia, pero esto limita los mapas a 2144x2144 pixels (se puede conseguir el doble si se saben usar otros modos7 con desplazamiento, pero no más).

[Pensando en voz alta]En todo caso, no se si esto que he pensado está bien, pero si en el m7 no se pueden usar valores DWORD para la posición, debería centrarse el mapa, porque no se aprovechan los valores negativos ¿o si? porque, estando en (0,0), en cuanto nos movamos un pixel hacia arriba o hacia la izquierda, la cámara pegaría un salto hasta MAX_DWORD. En mi caso no habría problemas porque limitaría el movimiento en el perímetro del nivel, pero en otros que la gente se iría de juerga por ahí pues tendrían problemas.[/pensando en voz alta]

Nada, yo sólo pregunto, está bien saber dónde está el límite (para saltármelo usando mi cabecita y lo que hay disponible ;D).

son dword

y bajando el resolution a 10?

Necesito dormir más ^^U
No sé exactamente cómo influye pero funciona, el valor de y no estaba desbordado ni por asomo, pero mira, el modo7 se "daba la vuelta" y el sprite seguía en su sitio (muy lejos en el horizonte).

De todas formas, 10 sufre del nefasto efecto del redondeo con advance, e incluso lo he notado en GBA dicho efecto (supongo que tendrían un valor de 15 o 20). Supongo que le pondré 50 para tener el doble de campo de juegos, total, la RAM no da para más.
Karma up.

Necesito ayuda con el modo7:

primero, quiero saber en cristiano que significa cada variable:

start a mode 7 window:
Start_mode7(m7_number,file,graph,external_graph,region,horizon);

m7 structure:
Camera: - process id for the camera
Height: - height of the camera
distance: distance of the camera from the process set under camera
Focus: perspective (FOV)
z: z depth of plane
color: color used to fill outside of mode 7 plane


ni idea de lo que cambia el height, distance y horizon...

2 -

necesito crear el modo 7 en una region, o sea, quiero una tira de y tamaño en la parte debajo de la pantalla y que el modo 7 sólo empiece de esa tira hacia arriba (no quiero el modo 7 pegado a la parte de abajo de la pantalla, pero un poco mas arriba).

3 - Quiero poner el modo 7 sin repetir la textura, quiero que la textura ocupe toda la region del modo 7 y que el modo 7 no sea mas grande que la misma, asi mismo el focus tiene que enseñar la textura en su maxima calidad cuando el modo7 esta sin movimiento.

Es para simular el suelo de SF2, usando modo7, y en algunas fases este no empieza en la margen inferiror de la pantalla, pero si un poco mas arriba.

Gracias a todos por la ayuda, asi da gusto  ;D

de nada...

height es altura de la camara
camera es el proceso al que sigue la camara
distance es la distancia del proceso camara
focus es focus
z es la z del plano
color es el color con el que se llena el fondo que no tiene grafico

m7[...].flags tienes los flags para setear lo que quieras, transluscent, mirror, etc.

para region, el 5to parametro de start_m7 es la region.

para no repetir no me acuerdo (ni lo encuentro, no se si es posible)