Avances, Diario de...

[SplinterGU]

free, a vos te funciona el ejemplo que acabas de subir, a mi me da un hermoso "segment violation"... diablos!

maldito 1280x800! que chistoso que sos...

[SplinterGU]

como dice drumpi, repite mapas de cualquier tamaño...

cambia la linea de start_scroll por esta

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

ahora, lo que no me queda muy claro en base a que dibuja el indoor... ya que si lo pones a 0, deja un hueco en medio... de que dimensiones? ni idea, parece que la dimension del grafico de fondo.

el m7 de div funcionaba igual?

[FreeYourMind]

start_scroll !? me lo dices a mi, no hay scroll en el ejemplo...

[SplinterGU]

ya entendi, si es 0, el parametro del indoor, parece que dibuja la pantalla (que esta vacia), si le pongo un grafico inexistente o si pongo -1, entonces solo dibuja el piso completo.

creo que esto es un bug, voy a revisar el codigo.

pero si pones la linea siguiente

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

vas a obtener lo que preguntabas

[SplinterGU]

me confundi, quise decir start_mode7, como podras ver puse start_mode7 en la linea que tenias que cambiar.

[SplinterGU]

era un bug, quedaba curioso si pones un grafico de fondo, pero evidentemente es un bug feo... ya lo acabo de corregir... no voy a generar version nueva por esto, por ahora usen -1 si no quieren que un grafico aparezca.

creo que por esto es que el color que mencionaba drumpi de fondo no aparecia.

[FreeYourMind]

Ya estoy contento gracias, con algo mas de curro y buena elección se van a conseguir paisajes de ensueño xD

[SplinterGU]

ahora si funciona el color de fondo si no hay grafico... antes tambien funcionaba, pero el no hay grafico era -1.

como dije, por ahora no genero ejecutables nuevo, es un bug menor.

[KeoH]

homme .. creo q ya voy entendiendo lo de dibujar el scroll/modo7 en un mapa xD la verdad esq se pueden hacer virguerias con eso xD. Pero aumentar el size de ese mapa ... no es a lo que yo me refería con un zoom en un scroll .. aunq se puede aprovechar xDD

[SplinterGU]

entonces no se a que te referias, los que pidieron zoom en el scroll era para emular lo que hacian las consolas, donde hacian zoom del juego...

pero bueno, siento no haber sido de ayuda... habra que currarselo con tiles...

[Drumpi]

Okis, de acuerdo con lo de la retrocompatibilidad. Y sí, más o menos se entiende lo de las regiones, si las trasladamos de coordenadas de pantalla a coordenadas del mapa, pero no sabía que se podían especificar valores de región fuera de pantalla.

Lo que yo me refería con el mapa exterior es que en algunas pruebas que hice, los mapas exteriores de 16x16 sólo representaban los primeros 8x8 pixels antes de repetir, pero aun no estoy seguro de ser un fallo mío o no. Cuestión de probar en el ThunderBlade Maker con tiles de distintos tamaños (es más, creo que si se carga el mapa 01 se puede ver que los cuadrados exteriores del juego son más grandes que los de dentro del mapa, pese a usar el mismo FPG y mapa).

Aparte de eso, en teoría, 10 scrolls sí pueden ser suficientes (hablamos de 20 planos de scroll) pero si nos metemos en juegos a pantalla partida...
Por ejemplo, crear un efecto como el de los fondos de Sonic, que usan varios planos de scroll para conseguir ese efecto de profundidad, es fácil para un jugador: 4 scrolls = 8 planos. Pero si tenemos 2 jugadores necesitamos 8 scrolls, y a partir de ahí hay que sacrificar recursos o planteárselo de otra forma (ojo, que se puede hacer).
Y en modo7... Vale, soy el único que se plantea juegos de plataformas o de carreras con varios niveles de altura, pero como tenga que hacer un juego para 4 jugadores me puedo ir olvidando de recorridos de más de dos plantas, o que tengan más que suelo y techo. Pero bueno, eso es cosa mía ^^U

Era simple curiosidad. Según veo en el código, basta con recompilar cambiando el valor de una constante para tener más, para un juego específico no sería difícil crear un módulo personalizado (a no ser que se me haya pasado por alto algún otro valor por ahí que controle el máximo de M7 disponibles, que es por lo que preguntaba).

[SplinterGU]

tienes razon, se me escapo eso... las regiones no pueden ser mas grandes que la pantalla, diablos! tengo que pensar como resolverlo.

se me ocurre que tal vez las regiones se puedan definir de cualquier tamaño, solo se limitarian al momento de usarlas... pero quisiera pensar de que forma impactaria esto, si afectaria en algo o no... bueno, por ahora se limite al tamaño de region maximo igual al de la pantalla.

lo del tamaño del mapa de outdoor, aceptó mas grandes que lo que decis, creo que puede llegar hasta 64x64, aunque no lo se.

la cantidad de scrolls, puedes recompilar el codigo y tener tu propio modulo con la cantidad que quieras.

[SplinterGU]

bien, creo que en principio no habra problemas de quitar el limite de region al limite de pantalla... o sobrecargar la funcion y si existe 2 parametros extra, definira el limite del mapa donde va a funcionar...

actualmente la out_region se ve afectada, si sobrecargo la funcion, no deberiamos tener problemas si solo la usamos para los mapas que la creamos, si solo quito el limite de la region al tamano de pantalla, entonces podriamos tener problemas con la out_Region, en el sentido de que posiblemente no estemos detectando correctamente la region.

esto de scroll/m7 sobre maps, obviamente hace que no se pueden hacer colisiones con mouse en scroll o m7 dentro de un mapa.


escucho comentarios, sugerencias, insultos, etc.

[Drumpi]

No digo que no acepte mapas exteriores al modo7 más grandes de 8x8, sino que de los 64x64 que acepta, dibuja sólo 8x8 (la esquina superior derecha). Como digo, no tengo pruebas que lo demuestren, pero recuérdamelo a partir del lunes.

Cierto que el tema de las regiones es más peliagudo de lo que parecía en principio. Soluciones, ahora mismo, no se me ocurren.
Lo más que llego a pensar es que, al igual que existen valores reservados para ID de mapas de los FPG con ID==0, y que aquellos >=1000 corresponden a mapas cargados sin FILE asociado, se tengan las 10 regiones definidas para coordenadas de pantalla, y añadir un tipo de región especial para su uso en mapas, con valores superiores a 10 (por ejemplo, a partir de 1000).
Esto también serviría para las funciones MAP_XPUT, que también usaban regiones de dibujado (y, al menos, usando la región 0, ignoraba las coordenadas de pantalla), pero claro, habría que definir un tipo de estructura interna nuevo (supongo) y control sobre si se usan las regiones de pantalla o las "libres". Lo de limitarlas o no ya sería cosa del Designer Supremo (ejem :D).
También ayudaría por el tema de las regiones del scroll en el que el proceso "camara" se puede mover sin desplazarlo.

Respecto a collision, eso ya no sé cómo funciona. En mi cabeza tenía la imagen de que se calculaba en función de las coordenadas, tanto de los gráficos como de cada uno de los pixels, y estar en un scroll o no sólo influía en el desplazamiento respecto a los gráficos con CTYPE=C_SCREEN. Vamos, que daba igual dónde se dibujase. Pero si me dices que no se pueden hacer, tu sabes mejor que nadie por qué.
Eso sí, nunca entendí las colisiones en modo7: por lo general, los choques entre procesos debían hacerse por proximidad, ya que estos no se dibujan en el "suelo", sino de pie.

Los insultos los dejaremos para otra ocasión ;D

PD: todo esto son ideas al aire. Si te sirven de inspiración, bien, si no pues nada, y si no se entiende, por favor, recordadme que no hable bajo los efectos de la "borrachera nocturna" ;D

[SplinterGU]

No digo que no acepte mapas exteriores al modo7 más grandes de 8x8, sino que de los 64x64 que acepta, dibuja sólo 8x8 (la esquina superior derecha). Como digo, no tengo pruebas que lo demuestren, pero recuérdamelo a partir del lunes.

Cierto que el tema de las regiones es más peliagudo de lo que parecía en principio. Soluciones, ahora mismo, no se me ocurren.
Lo más que llego a pensar es que, al igual que existen valores reservados para ID de mapas de los FPG con ID==0, y que aquellos >=1000 corresponden a mapas cargados sin FILE asociado, se tengan las 10 regiones definidas para coordenadas de pantalla, y añadir un tipo de región especial para su uso en mapas, con valores superiores a 10 (por ejemplo, a partir de 1000).
Esto también serviría para las funciones MAP_XPUT, que también usaban regiones de dibujado (y, al menos, usando la región 0, ignoraba las coordenadas de pantalla), pero claro, habría que definir un tipo de estructura interna nuevo (supongo) y control sobre si se usan las regiones de pantalla o las "libres". Lo de limitarlas o no ya sería cosa del Designer Supremo (ejem :D).
También ayudaría por el tema de las regiones del scroll en el que el proceso "camara" se puede mover sin desplazarlo.

Respecto a collision, eso ya no sé cómo funciona. En mi cabeza tenía la imagen de que se calculaba en función de las coordenadas, tanto de los gráficos como de cada uno de los pixels, y estar en un scroll o no sólo influía en el desplazamiento respecto a los gráficos con CTYPE=C_SCREEN. Vamos, que daba igual dónde se dibujase. Pero si me dices que no se pueden hacer, tu sabes mejor que nadie por qué.
Eso sí, nunca entendí las colisiones en modo7: por lo general, los choques entre procesos debían hacerse por proximidad, ya que estos no se dibujan en el "suelo", sino de pie.

Los insultos los dejaremos para otra ocasión ;D

PD: todo esto son ideas al aire. Si te sirven de inspiración, bien, si no pues nada, y si no se entiende, por favor, recordadme que no hable bajo los efectos de la "borrachera nocturna" ;D

drumpi, te estoy diciendo que probamos con mapas mas grandes que eso, y no dibuja solo 8x8, dibuja mapas grandes a la perfeccion, pero creo que los recorta a 64 maximo... proba el ejemplo de free.

con respecto al m7 creo que no hay colisiones sobre m7... tampoco le veo sentido.

gracias por tus comentarios.