Seria posible implementar un zoom como el que tiene la NeoGeo? es decir,que todo lo que se ve en pantalla se aumente o disminuya al antojo,seria posible incluirlo o estoy delirando otra vez? xD
Es imposible? :S
no se exactamente que queres hacer...
Poderse se puede hacer algo, con get_screen, colocando el gráfico según necesites y con size
por experiencia te digo que get_screen es una función muuuuuuuuuuuuuuuuuuuuy lenta, y si lo ejecutas 1 vez por frame el juego te va a ir a pedales :P
bueno, yo probado un ejemplo que me paso Pixel de eso por un error que tenia y yo lo corregi y probe, y no es tan lento... es dibujar un frame adicional.
Yo tengo este codigo (WIP11):
mapa_capturado=get_screen();
save_png(0,mapa_capturado,"\RALLY\FOTOS\FOTO_00" + itoa(contador) + ".PNG");
Cuando hace el "save_png" sufren una pausa todos los procesos (1 segundo aproximado), pero get_screen(); ella sola no es lenta, seguramente tendras algun save_png o save_map. Con "save_map" tambien hay una pausa pero mas corta que con el save_png. No es problema del "itoa(contador)" ya probe a indicar directamente "\RALLY\FOTOS\FOTO_555.PNG" e incluso parece tardar mas que con "itoa(contador)".
Con respecto al Zoom... aunque seria engorroso... se podria modificar todos los size de todos los procesos desde un proceso a parte, o usar get_screen y apliarlo luego con size, el incovenientes de este ultimo metodo es que es una imagen fija. Ahora como sugerencia para implementar a Bennu no se si seria factible.
save_png es logico sea lento, hay una operacion de escritura a disco...
con respecto a la sugerencia, no se, no es tan simple como decir ampliar y reducir... que pasaria cuando el tamaño que se requiera sea inferior al 100%? que se hace con lo que no se tiene de dibujo? y si tengo menu, bordes de recuadros, etc... esto se deberia ampliar o no? que se deberia ampliar o no? se deberia trabajar con region o pantalla completa? esto no es algo que se deba pensar a la ligera... tiene muchos aspectos a considerar... y la mejor opcion es dejar esto a control del programador del juego...
No estoy seguro pero igual se refiere a un Zoom Global tipo como el que se hace en set_mode() el "MODE_2XSCALE" pero en tiempo de ejecucion (runtime), algo asi como una variable global, estilo: GLOBAL_SIZE=100 y si varias su valor en tiempo de ejecucion pues todo se acerca mas, o se alejaria.
Ahora mismo para hacer lo que propone... yo haria eso de variar a todos el SIZE, lo malo si tienes un srcoll tendrias que pararlo y volverlo a inicar nuevamente con mas size en el grafico de fondo. un lio vamos XD
si, pero que pasa con size menores a 100? que pasa con la imagen que no se puede completar por falta de informacion, pensa en un put_screen que esta limitado al tamaño de la pantalla, si yo hago un size=50 de eso, me queda media pantalla con bordes negros y en medio el dibujito de la pantalla anterior... eso por un lado, pero tambien estan los casos donde la imagen del juego no ocupa toda la pantalla, entonces ahi hay que trabajar con regiones... una cosa diferente seria incluir eso en entorno que vaya mas alla de una screeen (por ejemplo un scroll, m7, o algo donde la informacion disponible vaya mas alla de los datos que vemos en pantalla)... podria ser algo asi como resolution pero a nivel grafico... sinceramente creo que seria un poco delirante pensar en algo automatizado sin dejar al azar muchos temas importantes (como la falta de informacion grafica)...
Bueno hacer Zoom siempre es "Aumentar", yo tengo una camara de 6 Megapixeles y tiene zoom optico de 3x, solo me aumenta, y zoom digital de 20x, y solo me aumenta. Si fuera reducir los sizes por debajo de 100 ya no seria zoom. Yo en todo momento me centre unicamente en "aumento" (zoom).
Como bien dices, tendria que ser algo como "resolution" pero a nivel grafico.
PD: ultrakobra ya no se puede quejar de que no se ha hablado del tema XD. Contestanto a tu pregunta... no es imposible... puede que sea dificil o superdificil pero no imposible, y si deliras es has perdido la cordura, y si pierdes la cordura no eres capaz de preguntar algo asi XD.
Lo de cambiar el size de todos los procesos no funciona, porque tendrías que modifiicar también su x y su y para que la proporción de las distancias sea la misma. El efecto es diferente si haces un size de todos los procesos que si haces un zoom general, puesto que los procesos se quedan en su sitio.
Pero tienes simplemente que multiplicar la distancia hasta el proceso camara la misma magnitud que mulriplicas el size y listos ¿no? Es un while recorriendo procesos y cambiando simplemente su x e y hasta que termines con todos.
A ver,veo que no se ha entendido bien,lo que dice splinter de reducir el size y franjas negras etc no es a lo que me refiero,mirad cualquier juego de pelea de neogeo que tenga zoom,y entendereis lo que os digo(art of fighting,samurai shodown,etc). :P
podes poner capturas tanto de cuando no tiene zoom (aunque sea obvio) y cuando lo tiene (con unos cuantos zoom diferentes de la misma captura sin zoom)?
Me suena que en divsite habia un ejemplo en fenix,voi a ver si lo encuentro
yeah!
Aqui se abla del tema :
http://forum.divsite.net/viewthread.php?tid=5907&page=1#pid58227
y aqui la paginja de franco pellegrini (el autor)
http://francopellegrini.elgratissitio.com/
Salu2!
capturas... please...
Hay algunos videos en youtube, por ejemplo este http://www.youtube.com/watch?v=3PSfqb3UNrg
En este juego el zoom es un acercamiento/alejamiento del punto de vista del obserador del combate, en estos tipos de juego el zoom es automático, cuando mas cerca estas de tu contrincante mas grandes se ven y cuanto mas lejos mas chichos hasta un maximo que tienen definido.
El caso es que el zoom no afecta a los status, es decir barra de vida, energcia, tiempo,etc.
Asi que creo que en este caso el zoom debería hacerlo el coder por lo que comentais, afecta al fondo y a los dos procesos de personaje. No parece automatizarse factiblemente de una forma.
Aunque se me ocurre algo como una simbiosis de lo esplicado.
Poner una variable zoom para cada region/scroll definida, al estilo size de los procesos.
poner una variable local afecta_zoom a los procesos.
El zoom solo afectaria a los procesos que pertenezcan a la region/scroll que tengan su variable afecta_zoom a true.
De esta forma y para el ejemplo, se haria una region/scroll de toda la pantalla de juego y se le pondría a true la variable afecta_zoom de los procesos de los personajes y se pondria a false para los procesos de status. Asi al poner zoom = 200 se vería todo más grande dentro de la region/scroll, que es toda la pantalla.
El caso que spliter dice de si pones zoom a 50%. dos opciones (incluso podrian ser configurables)
rellenar lo que falte (si es que falta) por los lados arriba, abajo, derecha e izquierda con transparente (negro).
Obligar que el zoom mínimo sea el que la imagen quede a resolucín de pantalla(es decir si la imagen es 1200x1000 y la resolucion seleccionda es 640x480 no dejar reducir zooms por debajo de esta, poniendo de mínimo ella)
Esta técnica enriquecería a muchos tipos de juego, ya que da un efecto de más experiencia al ver de mas cerca los golpes.
Yo personalmente veo esto como algo que el programador debe implementar, y que tampoco creo que fuera muy complicado. La técnica básicamente sería, por lo que he observado en el vídeo, partir de un zoom menor del 100% y ya cuando se acercan los combatientes entonces se pone a tamaño real (100%)...
Pero oye, que si se considera que está bien incorporar esto de serie en Bennu tampoco creo que moleste jeje, pero ya digo, es mi opinión.
Mas que rellenar los huecos al hacer zoom con el scroll, lo suyo sería lo que hace el scroll normal: no avanzar más allá del borde. otra cosa es que al hacer zoom las bandas aparezcan por ambos lados, en ese caso el zoom no debería reducirse más aunque lo intentase el programador (como cuando el proceso que hace de cámara llega a un límite: el personaje se mueve hacia el borde de la pantalla y más allá, pero el scroll ni se inmuta).
Creo que lo de hacer zoom es algo a controlar por el programador, otra cosa es en scrolls y demás, porque ahi ya no se puede hacer nada respecto a los gráficos que forman parte de los planos, pero con juegos en plan lucha, un gráfico gigante de fondo y un motorcillo de scroll propio para los personajes no es difícil de hacer.
con scrolls no seria problema, ya que se permitiria hasta lo que el mapa del scroll permita, porque con un scroll existe informacion extra del fondo mas alla de lo que se ve al 100% en pantalla, el problema es cuando no se usa scroll...
no,si yo en su dia con div2 hice algo similar,pero tuve que convertir el scroll en un proceso enorme con un punto de control en el centro abajo que cambiaba su size en funcion a lo cerca/lejos que estaban los luchadores,pero aun asi no logre hacerlo bien del todo y como podeis imaginar consumia pc que daba gusto xD
Yo creo que en Neogeo esta implementado a parte,lo unico que como buena maquina antigua estara dividido por 'layers',layer de sprites,de scroll,de interfaz,y estara hecho para que no afecte a la interfaz,solo a los sprites y al scroll.
Pues lo dicho, que salvo que se implemente en el scroll, te toca a ti hacer el zoom con gráficos gigantes (al menos, de momento) aunque ahora hay varias optimizaciones y no debería consumir tanta cpu (y creo que la diferencia con usar un scroll sería mínima).
Ten en cuenta que las recreativas usan un hardware dedicado, no te extrañe que tengan algun chip específico para hacer los escalados, u otras optimizaciones más curiosas.
Ya,pero me gustaria saber si es dificil de implementar o no...jeje
Splinter,que opinas?
Hombre igual quieres un estilo zoom a efectos... como hacia el modo8 en div2, alegarte y acercarte y todo se ve mas pequeño o grande... pero claro esto ya es logico porque es imitacion de 3d. Querras ese mismo zoom pero sin moverse alrededor ni con suelo.
Vuelvo a preguntar con respecto a la pregunta original, esto es para el modo scroll o para el modo sin scroll?
Quote from: SplinterGU on October 20, 2008, 11:26:58 AM
Vuelvo a preguntar con respecto a la pregunta original, esto es para el modo scroll o para el modo sin scroll?
Con scroll,sin scroll no saldria el grafico de fondo por los extremos de la pantalla,asi que seria imposible jeje
bueno, eso si es posible...
La cosa seria redonda si afectase al scroll y a todos los procesos ctype=c_scroll :)
yo hice algo parecido pero con modo 7...
seria bueno tener un global_size...
PC: como hace capcom con el piso ( suelo ) de street fighter ??? modo 7 tambien ??
Ya que hablamos de zoom. ¿como hacen los programas para suavizar la imágenes cuando hacen zoom? ya sea hacia dentro o hacia fuera.
Porque en div, por ejemplo, a veces al reducir, aparecían dientes de sierra, creo recordar, ( a lo mejor no).
podria ser... habria realmente que probar que ten eficiente puede ser desde software...
El suelo de capcom era un modo7 especial, porque no era el que conocemos con rotaciones y demás, símplemente desplazaba cada pixel del gráfico más cuanto más abajo está. No se como se conoce a este efecto, pero en consolas, como la MD, se simulaba en los scrolls con distintos dibujos a distintas profundidades con distinto ratio de desplazamiento (hablando en código div, sería como hacer tres scrolls, con sus dos gráficos, con scroll.ratio de 150 para cada plano respecto al anterior).
Hombre, el escalado es que se utiliza un código para suavizar el resultado, no se si has oido hablar de los filtros bilineal, SAI, etc...
Lo cual me interesaría mirar, porque hace un par de meses me hice un programa para reescalar FPGs de forma masiva, pero el reescalado que hace Fenix/Bennu por defecto con size no me gusta (se pierden pixeles y nitidez, los textos no hay quien los lea).
Si a alguien le interesa, hago una adaptación all-users.
no se a que escalado que se pierden pixels te referis... imagino que te referiras al size... porque el escalado de pantalla tiene filtros variados...
Exacto, me refiero a size y todas las funciones asociadas (map_xputnp :D)