Bueno, el tema es un poco extraño... y una vez analizado... ojala sea fallo mio y no un bug de Bennu.
El error solo se produce cuando hay DOS jugadores, con UN jugador va bien. Este es el código para DOS jugadores:
En Proceso Simulador():
.....
set_mode(800,600,16);
define_region(1,0,0,800,300);
define_region(2,0,300,800,600);
.....
En Proceso Jugador(int jugador);
.....
If (jugadores == 1)
start_scroll(0, mapa_pista, 102, 0, 0, 0);
scroll[0].camera=id;
Else
start_scroll(jugador, mapa_pista, 102, 0, jugador, 0);
scroll[jugador].camera=id;
End
.....
Como se ve en las Capturas... El scroll[1] que es del Jugador 1, nunca produce ese error visual (cuando juegas con un sólo jugador en scroll[0] tampoco se produce el error), únicamente el error se produce en el scroll[2]. Al principio creía que era por un xadvance(); que contienen las luces anti-niebla (que las coloca delante del coche, porque coge las coordenadas x e y del jugador), probé con advance(); pero seguía saliendo el error; entonces quite los xadvance para que salgan las luces anti-niebla directamente en las coordenadas x e y del jugador (encima de él), pero mi sorpresa es que también se produce el error, sin usar advance() ni xadvance() y viendo que scroll[0] y scroll[1] salen bien... algo está pasando.
El inconveniente del scroll[2] es que como la esquina superior izquierda es la de region 2 igual tiene algo que ver, porque yo uso este código:
En proceso luces_anti_niebla(int jugador):
.....
region=jugador;
angle=father.angle;
If (jugadores == 1)
x=father.x-scroll[0].x0;
y=father.y-scroll[0].y0;
Else
x=father.x-scroll[jugador].x0;
y=father.y-scroll[jugador].y0;
If (jugador == 2)
y+=300;
End
End
.....
No estoy seguro si ese "y+=300;" esta influyendo en el error al sroll[2], pero esa línea tengo que ponerla porque sino pone las luces del Jugador 2 donde está la region 1.
Aunque los segundos pone una 16" y otra 25" es lo que he tardado en capturar cuando se veía mal y cuando se veía bien.
SON CAPTURAS CASI SEGUIDAS Y EL ERROR NO SALE SIEMPRE:
CAPTURA CON ESE ERROR:
(http://s1.subirimagenes.com/fondosycapturas/1451109rallymortalerror1411.jpg)
CAPTURA SIN ESE ERROR:
(http://s1.subirimagenes.com/fondosycapturas/1451113rallymortalerror1411.jpg)
con el error te referis al recuadro ese transparente que se ven los bordes?
bueno, eso es evidente no es error del scroll, pero puede ser otra cosa... podrias señalar con un circulo de color o un cuadrado los defectos de la imagen que decis, si es que no es el recuadro.
preguntas:
- Eso es un grafico cargado desde disco? o es un mapa creado manualmente?
- Que tipo de grafico es? que dimensiones tiene? que profundidad de color?
- Que profundidad de color es tu juego?
- Que version de bennu estas usando?
El error, me refiero a que no encajan las luces donde deberían... entonces un lado se sobrepone (produciendo más blanco)... y el otro no sale nada (dejando ver la pista sin niebla).
Intentare está tarde hacer un paquete externo del juego para que todas esas preguntas y muchas más se puedan probar en tiempo real.
Mientras tanto puedo decir:
Preguntas:
1. Ambas cosas (la niebla es un new_map de 16Bits y las luces son un graph de un fpg)
2. Es lo que se ve en pantalla (la niebla las dimensiones de region1 o region 2, son equivalentes) a 16Bits
3. 16Bits.
4. Bennu WIP 15 update2 (la más reciente creo)
sinceramente no me doy cuenta donde deberian estar las luces...
Creo que el error que dice es el que se ve en la pantalla que el cuadro no encaja exactamente y queda algo desplazado. :S Osea que pinta todo de negro con un rectangulo para poder variar el dibujo interior. En el interior tiene una parte con blanco para iluminar. Pero al no casar bien el rectanbulo se le añade el reborde ese que se ve feo.
Eso es lo que he entendido yo :S
eso mismo dije yo, si era el recuadro y segun dice TYCO no es eso... no entiendo el problema...
XD es lo que dice animanegra, lo que debería hacer es lo que hace el otro jugador, poner las luces sin esa especie de borde (que parece un botón).
No se ve el error en el otro jugador, creo que es evidente en las capturas, cual esta bien y cual mal. Un jugador lo hace bien y el otro lo hace mal.
Pero lo dicho, voy intentar hacer un paquete para descargar y ver el error en ejecución (tiempo real).
y estas operaciones las haces con procesos diferentes? o sea, 1 proceso pone 1 grafico con un flag luego otro encima con otro flag?
de ser asi, tienen seteado priority con valores unos por encima de otros? o todos usan la misma prioridad (campo "priority"), lo mismo para la z...
no olvidar tambien al padre con respecto a estos procesos, todo esto si se hace con procesos...
He probado este código una y otra vez, cambiado parámetros como: priority, z, etc...
Haber si es que hago yo algo mal, ya no lo sé, me vuelvo loco buscando el fallo, cualquier ayuda será bien recibida.
Por cierto en Bennu WIP-2 he tenido que poner: "bgdc -Ca _Pruebas_.prg" en cambio en Bennu WIP-15c2 con "bgdc _Pruebas_.prg" me compila perfectamente... y si hago un "bgdc" para ver la ayuda dice bien claro:
-C options Specify compiler options
Where options are:
a Enable automatic declare functions
1) esta mal pasar el father a un proceso por parametro, el father no debe ser cambiado por otro proceso, es un error...
2) los procesos deben ser del tipo c_scroll, y no hay que hacer eso de "if (jugador ... ) y+=..." todo eso puede hacer que las x e y no sean exactamente igual, y mas si usamos algun advance...
en un rato te paso un algoritmo de como deberia ser...
EDIT: Quiero aclarar que las rotaciones no son 100% precisas, segun el angulo el grafico parece como temblar, esto es porque hay diferencias de 1 pixel en el centro o en el tamaño, segun sea el angulo, esto es debido a si bien ahora no hay corrupcion de graficos, ahora al usarse mayor precision en los calculos, el centro de los graficos rotados no es exacto por ser los pixels valores enteros y no decimales. No se si se entiende.
1) No se debería cambiar lo sé, pero hice pruebas a ver si realmente funcionaba, y parece que sí, aunque como dices no se debería hacer supongo, es un cambio fácil.
2) Mira eso de ctype=c_scroll en el proceso luces no me he dado cuenta te puedes creer??? Creo se debe a que antes usaba otro método para crear la niebla y lo cambie para que consumiera menos recursos (hacia map_clone en cada frame y subía mucho el consumo), ya que no usaba un proceso luces, lo hacia todo desde el proceso niebla();
A pesar de todo esto... no es extraño que sólo suceda en el scroll[2] y no en el scroll[1]??? y en la WIP-2 tampoco suceda??? a mi me ha parecido extraño.
Mañana haré más pruebas y estudiaré ese código, ahora es tarde, me retiro por hoy.
es por las correcciones de las rotaciones para que no queden graficos de un triangulo o una linea larga de 1 pixel...
igual el ejemplo, hay que depurarlo, porque si pones un objeto sobre otro, se ve la parte de la niebla del recuadro del ultimo coche... no se si se entiende, pero cuando pongas uno sobre otro lo vas a ver...
Aca va el codigo polenta.
pudiste probar esto? dame por lo menos una alegria el dia de hoy....
jeje ayer casi no tuve tiempo de probar/hacer nada, lo he mirado y a ver si después de comer puedo probarlo y adaptar lo que necesite en el Rally, pero a simple vista... el proceso iniciar_niebla(); no debería estar con ctype=c_scroll; por si el JUGADOR llega al borde del scroll... la imagen de la niebla no estará en el centro... y no cubrirá la pantalla correctamente.
Pero ya te digo que es a simple vista, sin leer el código en serio, lo dicho, después de comer espero comunicaros algo (en 3/4 horas).
Este código no me gusta nada, porque ya tengo un gráfico grande para el fondo... y si luego tengo que poner otro gráfico igual de grande para la niebla eso va a consumir mucho digo yo; el gráfico de la niebla con que sea igual que el tamaño de la region[jugador] es suficiente, y será mucho más performance y consumirá menos cpu y demás, por eso yo la niebla no la meto en ctype=c_scroll; y por eso uso x=father.x-scroll[jugador].x0; (para cuando llega el jugador a las esquinas la niebla siga estando centrada en la region[jugador])
mapa_blanco=new_map(map_info(0,fondo,g_width),map_info(0,fondo,g_height),16);
/* Niebla principal, debe ser del mismo tamaño del mapa total */
x = map_info(0,fondo,g_width)/2;
y = map_info(0,fondo,g_height)/2;
Que conste que aún no he comido.
Bueno el tema de la Niebla ha mejorado en su código interno sin hacer map_clone. Doy por cerrado el tema.
menos performante no es, al contrario debia serlo al revez, quizas si ocuparia mas memoria, pero no tiene que ser menos performante, al contrario tendria que ser mas performante que el codigo que tenias...
y al usar distintos metodos no es seguro que no te salga ese recuerdo, aunque si ahora haces lo mismo que te pase, pero sobre un recuadrito chico, entonces la cosa si puede ir mejor...
pero bueno, si solucionaste el tema, perfecto.
Se que este tema lo dimos por Cerrado. Pero Vista la eficiencia de subsanar bugs (cosa que me alegra)... me pregunto si el "Archivo Adjunto" de este post anterior: http://forum.bennugd.org/index.php?topic=305.msg3523#msg3523 también podría ser subsanable a medio o a corto plazo. :)
el tema del recuadro, no?
si es ese, tengo pendiente ver porque se corre 1 pixel, creo que es el centro y la precision de los floats, estuve haciendo pruebas, pero necesito debugear mas...
como se ve, ahora no se deforman los mapas al rotarlos y hacerle zoom, pero parece que se corre un pixel, no se bien aun cuando... quizas solo sea problema de que un pixel no se puede dividir al medio, y los centros de mapas de ancho o alto par no tienen un medio inequivoco.
Si, el tema del recuadro... pero que extrañamente sólo afecta en el scroll[2] que está en la región2 también. Ya que el scroll[1] que está en la región1 no se ve nunca ese "recueadro", es como si no le afectara el bug.
si mal no recuerdo no es que sea el scroll[2], eso ya lo vimos, da la casualidad que por las coordenadas que usas te sucede en el scroll[2], pero no tiene que ver con el scroll.
Estoy teniendo problemas con el start_scroll, ocurre si antes de la llamada del proceso que hace el start_scroll he borrado y vuelto a cargar el FPG que utilizo en el scroll, lo raro es que le paso el id del FPG y en los demas procesos si salen bien las imagenes del fpg que lo utilizan, lo que demuestra que esta bien cargado y que el id tambien lo pillá bien.
El scroll lo utilizo de esta forma en un proceso:
start_scroll(FPG_Principal, 0, 4, 0, 0, 3); // Scroll
WHILE(movim == 0);
scroll[0].x0 -= 1; // Scroll 1
scroll[0].y0 += 1;
IF (key(_esc) OR exit_status == 1) exit("", 0); END
FRAME;
END
el FPG_Principal lo he cargado en el main, despues he llamado un proceso que ha hecho el unload y load de nuevo del FPG_Principal. Si no llamo este proceso intermedio, el scroll funciona bien (pone el grafico 4 en movimiento), pero si llamo el proceso intermedio (unload/load del fpg), depúes al llamar el scroll no sale imagen, en una rara ocasión la imagen ha salido pero no se movia...
A ver que puede ser, algo mal en los parametros o que ?
Bueno, igual ultimamente ando cansino con mis dudas, igual os dejo unos tiempos para tranquilizar el ambiente.
Lo mismo es que te has equivocado en los parámetros del START_SCROLL, porque el primero es un número del 0 al 9 que indica el número de scroll a usar, el FPG va en el segundo, el gráfico del scroll en el tercero, el del fondo en el cuarto, region en el quinto es la región y el sexto los flags.
estas seguro que el primero no es el fpg ? (ha sido justo lo que cambie, de 0 a id del fpg)
En el manual de osk era lo que ponia, lo consulte para quitar dudas.
100% seguro, mira la wiki de bennu y la doc de Fenix si no me crees. A menos que Splinter haya creado algúna función de sobrecarga que no conozca.
Que te creo hombre, encima que tiene sentido por los cambios que hice, pero podrias mirar el manual de osk ?