SDL 1.3

[josebita]

ademas, tengo que pensarlo en ventanas, agregar soporte multiples ventanas de render, y elegir incluso en cual se dibuja tal o cual proceso... seguramente lo manejare como regions.

Tiene sentido, sí, siempre que sea similar a regiones y no mediante regiones :)

lo que me preocupa es el tema de las colisiones pixel perfect... no lo pense mucho, desconozco el api de la nueva sdl, pero si tenes alguna idea al respecto, soy todo oido y ojos.

Lo he pensado. Se puede convertir una textura en pixmap, pero es lento. Para las colisiones pixel-perfect habría que hacerlo y creo que es importante tenerlo, pero en muchas aplicaciones quizás bastara (desde el punto de vista del usuario) con collision boxes/círculos/elipses, tal y como lo tienes implementado ahora.
No sólo eso: otras cosas como map_get_pixel se volverían lentas... Es algo que me parece feo. Quizás sería práctico dejar al usuario elegir si el pixmap que carga va como GRAPH o como textura, en función del uso que le vaya a dar. El usuario haría algo tipo:
png_load("mi.png", GRAPH_PIXMAP); // el segundo parámetro sería opcional y por defecto indicaría textura
Y bennu sabría que debe cargar el PNG en RAM.

Y realmente éstos no ralentizaría el renderizado en juegos tipo plataformas, donde el mapa de durezas no suele ser el mismo mapa sobre el que el prota camina.

[SplinterGU]

lo de regiones, estoy pensando al igual que usamos regiones ahora, tanto para dibujar como para scroll y demas.

si quito el render por software no vamos a poder hacer el collision pixel perfect desde RAM, por otra parte me parecio leer que todo el manejo incluso de pixel de las texturas en sdl2 estaba optimizado y se podia hacer desde la gpu.

en todo caso, si se hace manejo de pixel en los mapas, seran basicas, no habra escalado, ni rotaciones por software, la idea es quitar el blitter definitivamente.

en esto tambien quedaran atras algunas viejas plataformas, asi esta dicho en el link que has puesto de sdl2.

en fin, tengo que pensar muchas cosas.

[Erkosone]

Yo creo que ante este punto de inflexión es un buen momento para plantearse adoptar chipMunk como motor de colision poligonal por defecto en el lenguaje.
Es rápido y funciona casi a pixel perfect ya que todo lo que se puede vectorizar se puede calcular la colisión.


De verdad que yo me iría olvidando ya del pixel perfect, el camino no es otro que avanzar hacia la aceleración por GPU, y si eso implica perder el colisión clásico a nivel de pixel.. pues que mas da=?


Lado A de la balanza:
- colisión a pixel perfect. LENTISIMA.
- renderizado por software sin ningún tipo de aceleración.
- posibilidad de map_put_pixel etc etc..
- juegos pixelados, lentos etc..


Lado B de la balanza:
- colisión poligonal [rápida].
- aceleración por hardware mediante GPU.
- no posibilidad de map_put_pixel etc etc.. [que seguro que se puede de algúna manera].
. juegos con gráficos suavizados, juegos rápidos.


Vaya que por mi le pueden dar morcilla al map_put_pixel XD..

[josebita]

Yo creo que ante este punto de inflexión es un buen momento para plantearse adoptar chipMunk como motor de colision poligonal por defecto en el lenguaje.
Es rápido y funciona casi a pixel perfect ya que todo lo que se puede vectorizar se puede calcular la colisión.


De verdad que yo me iría olvidando ya del pixel perfect, el camino no es otro que avanzar hacia la aceleración por GPU, y si eso implica perder el colisión clásico a nivel de pixel.. pues que mas da=?


Lado A de la balanza:
- colisión a pixel perfect. LENTISIMA.
- renderizado por software sin ningún tipo de aceleración.
- posibilidad de map_put_pixel etc etc..
- juegos pixelados, lentos etc..


Lado B de la balanza:
- colisión poligonal [rápida].
- aceleración por hardware mediante GPU.
- no posibilidad de map_put_pixel etc etc.. [que seguro que se puede de algúna manera].
. juegos con gráficos suavizados, juegos rápidos.


Vaya que por mi le pueden dar morcilla al map_put_pixel XD..

No digo que no se vaya a poder hacer map_Get_pixel o map_put_pixel. De hecho, se puede sin problemas:
SDL_RenderDrawPoint
SDL_RenderReadPixels
Lo que estamos comentando es que eso, si se hace el renderer por hardware, va a ser una operación más costosa en términos de tiempo que ahora. Yo planteo que quizás esto no sea un problema tan grande dado que para la mayor parte de usos puede ser suficiente utilizar cajas de colisión rectangulares o elípticas. Incluso para mayor precisión se podrían utilizar múltiples cajas para un mismo proceso.
Pero creo que ir directamente a hacer todas las colisiones con un motor de físicas me parece exagerado. Habrá muchos juegos donde no interese tener físicas y tener el motor por detrás no haría más que perder ciclos de CPU y batería.

Dicho esto, creo que no es mala idea -en absoluto- integrar un motor de físicas en el Bennu oficial. Algo parecido a la mod_chipmunk pero bien integrado, con locales y tal (me vais a matar. Alguien hizo una capa de abstracción en Bennu que hacía justo esto ¿cómo se llamaba?).

[Erkosone]

la hizo prg y yo la simplifiqué con la physicsMotion todavía mas, el trabajo de prg es muy bueno, funciona realmente bien.

[josebita]

la hizo prg y yo la simplifiqué con la physicsMotion todavía mas, el trabajo de prg es muy bueno, funciona realmente bien.

Gracias ;)

Pues algo así pero integrado directamente en BennuGD sería brutal.

[SplinterGU]

si, fisicas es un tema que se necesita.

pero vayamos por partes, bennugd es modular, y la fisica ira en un modulo, asi que puede esperar.

de momento, creo que collisiones tipo box o circle seran las opciones para collision.

sin dudas la fisica se necesita, pero primero el render.

[JaViS]

Totalmente de acuerdo con Splinter.


A veces los motores de fisica solamente complican las cosas :
http://www.learn-cocos2d.com/2013/08/physics-engine-platformer-terrible-idea/

[josebita]

si, fisicas es un tema que se necesita.

pero vayamos por partes, bennugd es modular, y la fisica ira en un modulo, asi que puede esperar.

de momento, creo que collisiones tipo box o circle seran las opciones para collision.

sin dudas la fisica se necesita, pero primero el render.

Completamente de acuerdo, Splinter.
¿Sería posible hacer que un cuerpo pudiera tener más de una caja de colisión?

Algo como lo que explican al final de este artículo, vamos:
http://www.genbetadev.com/programacion-de-videojuegos/teoria-de-colisiones-2d-conceptos-basicos

[KeoH]

Bueno .. esta es una noticia que queria poner aparte .. pero ya que aqui se esta hablando un poco del futuro de bennu .. pos os pongo esto ... para futuros ports a consolas nuevas http://www.meristation.com/xbox-one/noticias/la-autopublicacion-en-xbox-one-sin-cuotas-sin-certificacion/45366/1892291

[josebita]

He puesto algo de información sobre todo este proceso en mi blog:
http://bennugd-mobile.blogspot.com.es/2013/08/wip-games-gpu-scaling-and-bennugd-2.html

[SplinterGU]

la xbox one viene a ser la 720? si es asi, de momento, pues bennugd no vera la luz en la consola de mi parte, por temas de que no me mola que ms joda con mi privacidad.

[SplinterGU]

joseba, descompacte el paquete, pero me da el siguiente error (o warning)

bzip2: (stdin): trailing garbage after EOF ignored

veo tambien que tu version es monolitica... no es la oficial.

lo vere.

gracias, confirmame si ese error lo ignoro o tienes que pasarme otra vez el paquete.

saludos.

[josebita]

joseba, descompacte el paquete, pero me da el siguiente error (o warning)

bzip2: (stdin): trailing garbage after EOF ignored

veo tambien que tu version es monolitica... no es la oficial.

lo vere.

gracias, confirmame si ese error lo ignoro o tienes que pasarme otra vez el paquete.

saludos.

El error lo puedes ignorar.
Y sobre la versión, es la mía sí, pero la parte interesante sobre adaptación a SDL 2 creo que funcionaría igual con la oficial. Eso sí, sólo incluye fuentes, no scripts de compilación.

Llevo tiempo intentando cambiar a la oficial, pero nunca encuentro la ocasión :)

[SplinterGU]

veo que en realidad no quitaste las dirty, simplemente las quitaste en el dump de pantalla, pero el dump al mapa interno de bennugd (pantalla) se sigue haciendo, evidentemente te mal entendi.

como sea, voy a revisar y tomar lo que pueda de tu version, grandioso!