Bueno, je je, creo que el título del post es bastante ilustrativo.
El caso es que el otro día quise ahorrarme algunos frames de animación a base de modificar ciertos valores de ángulos de personajes, cuando me acordé de los dientes de sierra que se generaban. ¿No hay ninguna forma de evitarlos? Es un problema que se arrastra desde div2 y no se si se ha solucionado ya, si hay alguna técnica para minimizarlo o qué.
Poder se puede, porque con cualquier editor de imágenes puedes rotar lo que sea sin ver esos píxeles chungos, ahora, lo complicado que sea no lo se.
Si hay respuesta, gracias por darla.
Si usas gráficos en 16 bits no hay forma de evitarlo, ya que no es posible tener ciertos píxeles que tomen un alpha que lo evite.
Puedes probar usando gráficos en 32 bits, seguro que el resultado mejora.
Iva a decir, jolín, que os a dado todos con que uso 16 bits!!! Pero luego me he dado cuenta de que eso tiene sentido para mí que soy el factor común en todos mis hilos :P
Si, estoy en 32 bits, todo lo que estoy consultando (colores transparentes, dientes de sierra, fpgs...) todo trabajo con 32 bits para una máxima calidad gráfica, y aún así, se ven los dichosos dientes de serrucho.
Gracias por tu respuesta.
lo de evitar los dientes de serrucho va a estar complicado, porque es culpa de trabajar con sprites de resoluciones muy pequeñas, prueba a exportar desde inkscape las imágenes el doble de grandes y a poner en los procesos de código bennu la variable size a 50, a ver si así se nota menos al ser bennu quien te haga el rescalado, sino la opción más directa es agrandar tu pantalla y todos tus sprites al doble, es decir, si trabajas en bennu a 320x240, pues trabajar en 640x480 con todos tus sprites al doble de tamaño exportados desde inkscape directamente (con esto me refiero a que no vale ir a gimp y rescalar tu imagen png al doble, porque tu imagen ya está pixelada y al ampliarla se pixelará mas aún)
Quote from: DCelso on October 04, 2010, 03:29:45 PM
lo de evitar los dientes de serrucho va a estar complicado, porque es culpa de trabajar con sprites de resoluciones muy pequeñas, prueba a exportar desde inkscape las imágenes el doble de grandes y a poner en los procesos de código bennu la variable size a 50, a ver si así se nota menos al ser bennu quien te haga el rescalado, sino la opción más directa es agrandar tu pantalla y todos tus sprites al doble, es decir, si trabajas en bennu a 320x240, pues trabajar en 640x480 con todos tus sprites al doble de tamaño exportados desde inkscape directamente (con esto me refiero a que no vale ir a gimp y rescalar tu imagen png al doble, porque tu imagen ya está pixelada y al ampliarla se pixelará mas aún)
Hombre, la idea es buena, la probaré a ver, pero e problema es que mis sprites ya son enomres, 112px mide media pierda de uno de ellos o sea que imaginate, si lo pongo al doble deja de ser jugable. Pero probaré a eso, exportarlos gigantemente gigantes y ponerlos a a mitad de su tamaño a ver que pasa.
umn, entonces a esas resoluciones quizás no debería de verse tanto el efecto, algo hace mal tu inkscape en la exportación., nose , necesito el svg, como ya te he comentado varias veces
Quote from: DCelso on October 04, 2010, 03:29:45 PM
lo de evitar los dientes de serrucho va a estar complicado, porque es culpa de trabajar con sprites de resoluciones muy pequeñas, prueba a exportar desde inkscape las imágenes el doble de grandes y a poner en los procesos de código bennu la variable size a 50, a ver si así se nota menos al ser bennu quien te haga el rescalado, sino la opción más directa es agrandar tu pantalla y todos tus sprites al doble, es decir, si trabajas en bennu a 320x240, pues trabajar en 640x480 con todos tus sprites al doble de tamaño exportados desde inkscape directamente (con esto me refiero a que no vale ir a gimp y rescalar tu imagen png al doble, porque tu imagen ya está pixelada y al ampliarla se pixelará mas aún)
eso no va a ayudar, por el contrario lo va a empeorar, bennugd no hace suavizado al escalar.
la cosa es usar alphas a nivel pixel y no escalar los graficos, eso hara que se vea sin serrucho.
Quote from: SplinterGU on October 04, 2010, 04:15:44 PM
Quote from: DCelso on October 04, 2010, 03:29:45 PM
lo de evitar los dientes de serrucho va a estar complicado, porque es culpa de trabajar con sprites de resoluciones muy pequeñas, prueba a exportar desde inkscape las imágenes el doble de grandes y a poner en los procesos de código bennu la variable size a 50, a ver si así se nota menos al ser bennu quien te haga el rescalado, sino la opción más directa es agrandar tu pantalla y todos tus sprites al doble, es decir, si trabajas en bennu a 320x240, pues trabajar en 640x480 con todos tus sprites al doble de tamaño exportados desde inkscape directamente (con esto me refiero a que no vale ir a gimp y rescalar tu imagen png al doble, porque tu imagen ya está pixelada y al ampliarla se pixelará mas aún)
eso no va a ayudar, por el contrario lo va a empeorar, bennugd no hace suavizado al escalar.
la cosa es usar alphas a nivel pixel y no escalar los graficos, eso hara que se vea sin serrucho.
Perdona splinter, me estás diciendo que si en los bordes pongo distintos valores alpha (y los cargo con load_png pa que funcione bien) no saldrán dientes de sierra al rotarlos?
al rotarlos!?!?!
ja, no lei esa parte, no, eso lo dudo mucho, creo que rotar siempre dara dientes de sierra, a menos que haya suavizado, cosa que no hay.
edito: quizas si tenes una buena cantidad de pixels alphas, y usas resoluciones altas (por lo menos de 1024x768 para arriba) quizas no tengas serruchos.
De esto hablé yo cuando estaba con mi juego de cartas...
¿Y la conclusión fue...?
Yo creo que esto es algo importante a implementar en bennu que se debería (bajo mi opinión por supuesto) poner en una parte alta de la pila, ya que si no podemos rotar absolutamente nada nos quedamos sin una parte importante de la animación, programación de enemigos intros menús etc.
Un saludo.
La solución fue hacer las rotaciones con un editor de gráficos que tenga buenos filtros (o mejor aún desde el mismo svg si lo tienes) y tener imágenes en en todas las rotaciones posibles que pueda tener tu juego, normalmente se usan 4 diagonales.
Vamos a ver, no se le pueden pedir peras a un olmo. Esto es así por usar 2D a bajas resoluciones, en 2D por lo general se usan imágenes planas, una imagen plana solo son pixeles correlativos de distintos colores, no puedes pretender que una función de giro sepa que tienes a un tío y te gire sus pies bien, es un giro a nivel de pixel con las limitaciones que eso lleva, por ejemplo una línea recta si la vas girando en 2d a poca resolución no puedes pretender que siempre sea una línea recta porque los pixeles son finitos y de tamaño definido en diagonales de ángulo distinto a 45º no verás una línea recta nunca, para evitar estos efectos existe lo que se denomina "sprite art" que es el arte de dibujar con pocos píxeles y hacer que se intuya o reconozca muy bien un objeto y esto lleva su tiempo aprenderlo por el hombre y es mucho a base de prueba-error.
La cosa cambiaría si hablasemos de imágenes vectoriales en las que guardamos fórmulas para dibujar los distintos componentes de un objeto, de esta forma al girar la imagen, se recalcularían todos sus pixeles a partir de su fórmulas y el giro sería cuasi-perfecto, pero aún así limitado por la resolución de tu sprite, no puedes pretender dibujar un círculo en una imagen 2x2 pixeles, porque te parecerá un cuadrado o un punto muy gordo :D.
En 3D esto es menos preocupante porque siempre tratamos con modelos y al ser fórmulas para dibujar polígonos podemos poner resoluciones grandes de pantalla cada vez se verá mucho mejor el objeto, pero aún así está la limitación del pixel, si ponemos una resolucion muy pequeña de pantalla como 320x200 pues veremos todos nuestros polígonos pixelados, pero es culpa de la limitación impuesta por el pixel.
Como conclusión en 2d y 3d si usas por ejemplo resoluciones muy grandes para tu sprites (1240x1024 o superiores) el efecto serrucho (o pixelado) al girar será menor e incluso inapreciable, pero necesitarías una máquina muy potente para correr dicho juego.
En mi opinión la solución sería tirar de vectorial o bien añadir filtros gráficos tanto al usar size como al usar angle. Ya veis que los programas de dibujo actuales rotan y escalan mucho mejor usándolos, el código no debería ser muy difícil de encontrar, otra cosa ya es integrarlo en el motor sin restar nada a la sencillez actual de uso que tiene.
Creo que el tema de escalados y rotaciones van metidas en la SDL, por lo que para tener un algoritmo mejor habría que reescribir la función en C. Además, si se le aplican efectos de suavizado, antialiasing, y demás, la función se vuelve compleja y se pierde rendimiento.
Un caso muy curioso lo vi el otro día usando potochof y su herramienta "giro libre": cuando cogí un brazo y lo iba rotando decía "vaya porquería que va a salir, se está cargando la imágen y voy a tener que usar un ángulo forzosamente", porque se veía como una rotación similar a la usada en Bennu, pero al soltar y aceptar, se suavizó y el resultado quedó bastante bien (no para pixelart, pero sí para un sprite). Lo que quiero decir es que usaba un algoritmo de rotación muy básico para previsualizar, y a la hora de aceptar, usaba un algoritmo que tradaba un tiempo apreciable.
Yo también creo que el algoritmo de rotación es un poco basto (no probé la última modificación) pero dicho algoritmo lo he visto en otros programas, como el Graphics Gale, pero no podemos quejarnos si lo comparamos con las versiones de videoconsolas, que hasta que no aparecieron las rotaciones por HW (chip SuperFX)...
Quote from: DCelso on October 04, 2010, 10:39:49 PM
La solución fue hacer las rotaciones con un editor de gráficos que tenga buenos filtros (o mejor aún desde el mismo svg si lo tienes) y tener imágenes en en todas las rotaciones posibles que pueda tener tu juego, normalmente se usan 4 diagonales.
Exacto, y usar la variable local xgraph... muy bien DCelso, haciendo los deberes...
Quote from: DCelso on October 04, 2010, 10:39:49 PM
Vamos a ver, no se le pueden pedir peras a un olmo. Esto es así por usar 2D a bajas resoluciones, en 2D por lo general se usan imágenes planas, una imagen plana solo son pixeles correlativos de distintos colores, no puedes pretender que una función de giro sepa que tienes a un tío y te gire sus pies bien, es un giro a nivel de pixel con las limitaciones que eso lleva, por ejemplo una línea recta si la vas girando en 2d a poca resolución no puedes pretender que siempre sea una línea recta porque los pixeles son finitos y de tamaño definido en diagonales de ángulo distinto a 45º no verás una línea recta nunca, para evitar estos efectos existe lo que se denomina "sprite art" que es el arte de dibujar con pocos píxeles y hacer que se intuya o reconozca muy bien un objeto y esto lleva su tiempo aprenderlo por el hombre y es mucho a base de prueba-error.
La cosa cambiaría si hablasemos de imágenes vectoriales en las que guardamos fórmulas para dibujar los distintos componentes de un objeto, de esta forma al girar la imagen, se recalcularían todos sus pixeles a partir de su fórmulas y el giro sería cuasi-perfecto, pero aún así limitado por la resolución de tu sprite, no puedes pretender dibujar un círculo en una imagen 2x2 pixeles, porque te parecerá un cuadrado o un punto muy gordo :D.
En 3D esto es menos preocupante porque siempre tratamos con modelos y al ser fórmulas para dibujar polígonos podemos poner resoluciones grandes de pantalla cada vez se verá mucho mejor el objeto, pero aún así está la limitación del pixel, si ponemos una resolucion muy pequeña de pantalla como 320x200 pues veremos todos nuestros polígonos pixelados, pero es culpa de la limitación impuesta por el pixel.
Como conclusión en 2d y 3d si usas por ejemplo resoluciones muy grandes para tu sprites (1240x1024 o superiores) el efecto serrucho (o pixelado) al girar será menor e incluso inapreciable, pero necesitarías una máquina muy potente para correr dicho juego.
el mayor problema es la CPU que se necesitaria, esto se podria hacer facil con aceleracion por hardware (opengl/directx), pero actualmente no lo tenemos.
Quote from: Drumpi on October 05, 2010, 12:59:16 AM
Creo que el tema de escalados y rotaciones van metidas en la SDL, por lo que para tener un algoritmo mejor habría que reescribir la función en C.
por el contrario, SDL no soporta rotaciones ni escalado de forma oficial, hay unos modulos que se sugieren al estilo SDL_mixer, pero son horriblemente lentos y sin optimizacion.
si existiese algo ya implementado en SDL y con buena performance, dejaria de hacerlo desde BennuGD.
Quote from: Drumpi on October 05, 2010, 12:59:16 AM
Además, si se le aplican efectos de suavizado, antialiasing, y demás, la función se vuelve compleja y se pierde rendimiento.
exacto, se pierde mucho rendimiento.
Quote from: Drumpi on October 05, 2010, 12:59:16 AM
Un caso muy curioso lo vi el otro día usando potochof y su herramienta "giro libre": cuando cogí un brazo y lo iba rotando decía "vaya porquería que va a salir, se está cargando la imágen y voy a tener que usar un ángulo forzosamente", porque se veía como una rotación similar a la usada en Bennu, pero al soltar y aceptar, se suavizó y el resultado quedó bastante bien (no para pixelart, pero sí para un sprite). Lo que quiero decir es que usaba un algoritmo de rotación muy básico para previsualizar, y a la hora de aceptar, usaba un algoritmo que tradaba un tiempo apreciable.
exacto! en tiempo real no se puede hacer un algoritmo con suavizado por software, no en un juego.
Quote from: Drumpi on October 05, 2010, 12:59:16 AM
Yo también creo que el algoritmo de rotación es un poco basto (no probé la última modificación) pero dicho algoritmo lo he visto en otros programas, como el Graphics Gale, pero no podemos quejarnos si lo comparamos con las versiones de videoconsolas, que hasta que no aparecieron las rotaciones por HW (chip SuperFX)...
el algoritmo de bliteo de BennuGD (rotacion y escalado), es lo mas rapido que existe por software, yo no he visto nada mas rapido sin usar acceleracion (llamese directx u opengl)
El bliteo ese lo usé un par de veces y no me gustó mucho la verdad... Pero si es la opción que queda de momento nos aguantaremos :P
Quote from: Windgate on October 05, 2010, 06:46:22 AM
El bliteo ese lo usé un par de veces y no me gustó mucho la verdad... Pero si es la opción que queda de momento nos aguantaremos :P
a que te referis? que bliteo? donde lo usaste?
si te referis al de bennugd, lo usaste vos y lo usa todo el mundo que usa bennugd con angulos o size.
la verdad no te entendi.
Quote from: SplinterGU on October 05, 2010, 12:29:40 PM
Quote from: Windgate on October 05, 2010, 06:46:22 AM
El bliteo ese lo usé un par de veces y no me gustó mucho la verdad... Pero si es la opción que queda de momento nos aguantaremos :P
a que te referis? que bliteo? donde lo usaste?
si te referis al de bennugd, lo usaste vos y lo usa todo el mundo que usa bennugd con angulos o size.
la verdad no te entendi.
Perdón, confundí el término, me refería a este difuminado/suavizado de la mod_effects:
http://wiki.bennugd.org/index.php?title=Blur
De hecho la captura es de las pruebas que hice con ello, intentaba evitar en lo posible las pérdidas al escalar y rotar "poco" un mapa.