Colisión Entre Sprites Rotados

[AgeR]

 A raíz de lo que comentaba ALRAZ en otro post, y dado que quiero hacer un pequeño engine/framework para juegos 2D......

Me interesaría saber si hay alguna librería que gestione la rotación y colisión de sprites. Supongo que la respuesta es no, pero bueno, es por ver si puedo ahorrarme algo de trabajo  :P .

En principio voy a usar SDL, y por lo que he visto ni siquiera tiene funciones para rotar surfaces (me equivoco?).

No estoy muy puesto en juegos 2D, así que invoco a los expertos.  :lol:

Se suelen usar rotaciones o se tira de "frames" para simular la rotación del bicho/personaje/cosa?
Siempre será más suave la rotación...

[[EX3]]

 Que yo tenga entendido se rota la imagen en si y no debe traer mucho coste cuando lo implementan sistemas como Fenix, que usan SDL (que por cierto, yo daba por echo que SDL tenia funciones para rotado de imagenes :ph34r:) y los juegos desarrollados en el van fluidos.

Salu2...

[ALRAZ]

 SDL en sí no trae funciones para rotar y reescalar surfaces, por ay anda una librería que hace eso por ti.

Yo lo que estoy haciendo es usar open gl para esos propósitos, porque me parecía demasiado "time consuming" el hecho de tener que crear una surface nueva cada que queremos rotar una que ya tenemos. Además, SDL tampoco trae alguna forma de "invertir" las surfaces (espejado horizontal y vertical).
Tampoco trae forma de detectar colisiones entre surfaces  :angry:


[edit]
creo que la librería para rotar/reescalar surfaces se llama SDL_rotozoom o algo así (está en la página de SDL)

[AgeR]

 Gracias a ambos!!! SDL no permite las rotaciones etc, pero sí hay librerías externas que lo facilitan.

Creo que la mejor opción es usar SDL_gfx. Además parece que me facilitará el tema de colisiones por pixel, ya que crea un nuevo surface y puedo comparar con este (a costa de una bajada en el rendimiento, claro).

A dormir que ya es hora XD

[gdl]

 Estoy con ALRAZ, lo mejor es usar OpenGL. Así te aseguras que los cálculos se hacen en la GPU y no en la CPU. Además, verás que el OpenGL está muy trillado y tienes muchísimas cosas allí (blending, shaders, occlusion query, etc.).

[Sacrifai]

 Además no tienes que luchar con el tema de las resoluciones  :D  .

[Lord Trancos 2]

Creo que la mejor opción es usar SDL_gfx. Además parece que me facilitará el tema de colisiones por pixel, ya que crea un nuevo surface y puedo comparar con este (a costa de una bajada en el rendimiento, claro).

Hay q ver q mania tiene la gente con hacer colisiones a nivel de pixel :P
No te valdria definir un grupo de circulos por cada sprite y comprobar colisiones entre esas esferas?
A efectos practicos (jugando), creo que no se notaria mucho la diferencia a usar colision por pixel...

[zupervaca]

 yo te recomiendo usar opengl (o directx) si vas a rotar imagenes ya que la mayoria de las librerias te crearan otro surface con la imagen rotada

solo una cosa, ¿si usais sdl que parte de un motor 2d desarrollais? sdl tengo entendido que te da lectura de imagenes, sonido, etc ademas de la posibilidad de multiplataforma

saludos

[[EX3]]

 

Hay q ver q mania tiene la gente con hacer colisiones a nivel de pixel :P
No te valdria definir un grupo de circulos por cada sprite y comprobar colisiones entre esas esferas?
A efectos practicos (jugando), creo que no se notaria mucho la diferencia a usar colision por pixel...

Tb es cierto, las colisiones a nivel de pixel son necesarias para muy muy pocas cosas contadas y que como dice Lord Trancos 2 con colision de esferas puedes lograr de forma muy precisa, casi tanto como a nivel de pixel, y con un coste de rendimiento infimo. La colision por pixel solo lo veria util para aventuras graficas para definir los sectores del escenario y eso se podria hacer por mapas de durezas leyendo el pixel segun la posicion indicada o usar mascaras de bits.

Salu2...

[ALRAZ]

yo te recomiendo usar opengl (o directx) si vas a rotar imagenes ya que la mayoria de las librerias te crearan otro surface con la imagen rotada

solo una cosa, ¿si usais sdl que parte de un motor 2d desarrollais? sdl tengo entendido que te da lectura de imagenes, sonido, etc ademas de la posibilidad de multiplataforma

saludos

Me podría repetir la pregunta...?  :blink:


te refieres a qué parte del motor hay que programar...?

[Sacrifai]

yo te recomiendo usar opengl (o directx) si vas a rotar imagenes ya que la mayoria de las librerias te crearan otro surface con la imagen rotada

solo una cosa, ¿si usais sdl que parte de un motor 2d desarrollais? sdl tengo entendido que te da lectura de imagenes, sonido, etc ademas de la posibilidad de multiplataforma

saludos

Me podría repetir la pregunta...?  :blink:


te refieres a qué parte del motor hay que programar...?

Yo diría que se refiere a que hay que programar ya que SDL te da funciones para todo y multiplataforma. Ager yo programaría muchas cosas del motor: clases para sprites, mejorar ciertas cosas que ahora requieren de muchas funciones y lo principal, funciones para la lógica de los juegos.

[AgeR]

 Caramba, cuantas respuestas! Gracias a todos!

Bueno, el tema es que quiero hacerme un pequeño framework para jueguecillos 2D perdiendo el menor tiempo posible.
Sé que con OpenGL todo me sería bastante más sencillo, el problema es que quiero un framework que me permita ejecutar los juegos en cualquier ordenador bastante antiguo. He visto que con SDL un jueguecillo funciona perfectamente en los ordenadores de mi universidad (pentium 2, 32/64 Mb RAM, Tarjeta gráfica de 2Mb). Esto con OpenGL sería imposible.  :rolleyes:

Estaba pensando en usar directamente DX7 y demás, pero quiero evitarme complejidades innecesarias, así que me he decidido por las SDL, y más sabiendo que existen librerías adicionales que me facilitarán mucho las tareas (sdl_image, sdl_gfx, sdl_mixer, etc).

zupervaca : Precisamente como ya está casi todo "hecho", quiero dedicarme a hacer managers de sprites, sonidos... colisiones, gui, etc...

Sobre colisiones a nivel de pixel, pues no, no es estrictamente necesario, pero considero que es más genérico que ir asignando a cada sprite unas áreas de colisión. Igual se pierde algo de eficiencia, pero creo que compensa con una mayor velocidad de desarrollo de los juegos.

No sé, vuelvo a decir que no estoy muy puesto en estos temas  :ph34r:  

[zupervaca]

 

zupervaca : Precisamente como ya está casi todo "hecho", quiero dedicarme a hacer managers de sprites, sonidos... colisiones, gui, etc...

es que normalmente estas cosas se desarrollando directamente con un juego, no todos los juegos necesitan lo mismo, algunos pueden necesitar jerarquias de sprites otros no, etc por ejemplo para hacer el juego de diablo 2 se hacen sprites con jerarquias para que al mover el padre se muevan los demas, para un juego que no le haga falta esto seria meterle funcionalidad extra que no usaria, otros le hara falta un orden concreto de los sprites a otros les dara igual, etc mientras mas funcionalidad le metas mas lento ira y muchas veces no le hara falta, y tienes que darte cuenta que un simple if para saber si se activa una funcionalidad o no puede ser el suficiente para que el juego vaya fluido o no

bueno solo comentarte eso, cada uno luego puede plantearse los proyectos que quiera y siempre puedes aprender algo nuevo, pero por mi experiencia de hace muchos años te puedo decir que muchas veces nos ponemos a hacer motores para luego no usarlos, yo te aconsejo otro planteamiento, y es que hagas un juego directamente usando el sdl, opengl o lo que mas te guste  ;)  

[javiel]

 me meto en el post para ver si alguien puede informarme de alguna web que hable del trabajo con OpenGL para 2D. ¿sabéis de artículos o libros que hablen sobre esto?

gracias a todos

[zupervaca]

 yo no conozco libros como dije antes, pero te puedo decir que para 2d tiene funciones especificas, pero si quieres aprovechar el opengl bien bien, te recomiendo usar dos triangulos para cada sprite 2d que hagas asi podras usar todo tipo de operaciones blend

saludos

pd: yo sobre opengl se poquiito, se mas de directx osea que tampoco me hagas mucho caso