¿Cómo mantengo mi personaje centrado en la pantalla?

Estoy haciendo un juego similar a Legend of Zelda: Link to the Past (acción-aventura 2D de arriba hacia abajo). Quiero que el personaje permanezca centrado en la pantalla cuando se mueve.

Actualmente, cada vez que el jugador quiere moverse, muevo todo el mapa en la dirección opuesta. Esto funciona, pero a medida que agrego más objetos al mundo, moverlos todos se vuelve más complicado.

¿Hay una mejor manera de abordar esto?

2d camera movement

— asbumste
fuente

Crea una cámara y muévela. Esencialmente, todo se dibujará con un desplazamiento basado en la posición de la cámara. Mover el universo para mover a tu personaje es un poco excesivo para el profesor Farnsworth.

— MichaelHouse

+1 por hacer referencia a su referencia de su futura futurama: P

— Pomo de la puerta

@ Byte56 Gracias, eso está cerca de lo que estoy haciendo, así que podría mantenerlo como está. Pero eso tiene mucho sentido. ¿Quieres poner eso en una respuesta para que pueda aceptarlo?

— asbumste

¿Qué subsistema de renderizado estás usando?

— bobobobo

Respuestas:

La forma típica de manejar esto es crear un objeto de cámara. La forma más simple de una cámara es solo una posición. Esta cámara simple define el "centro" de la vista actual. Por lo tanto, no modifica todas las posiciones de sus mosaicos / entidades, solo resta las coordenadas de la cámara de las posiciones al dibujar. En esta situación, la cámara no se "mueve".

Si bien la cámara y su personaje compartirán una posición la mayor parte del tiempo, es posible que aún desee tenerlos como valores separados, por lo que puede, por ejemplo, evitar que la cámara se mueva cuando llegue al fin del mundo, pero permita que jugador para continuar moviéndose.

Una cámara un poco más avanzada se mueve. Todas las entidades y mosaicos se dibujan sin desplazamiento y la posición desde la que está procesando los cambios. Esto es muy similar a la cámara más básica, y aún puede realizar muchas de las mismas optimizaciones para renderizado selectivo (solo invocando drawlo que la cámara puede ver), en ambos. Es esencialmente una forma diferente de pensarlo.

— MichaelHouse
fuente

Hola Byte, he implementado lo que dijiste con éxito ... creo. Pero ahora me encuentro con problemas ... ¿puedes ayudar a echar un vistazo? Un tipo dijo que en realidad no necesito ninguno cam variables... y ofreció un método alternativo ... stackoverflow.com/questions/18199373/…

— Growler

Lo miraré más tarde, por ahora te sugiero que lo preguntes en el chat .

— MichaelHouse

No, esta es la forma incorrecta de hacerlo.

¿Cómo vas a hacer la detección de trampas? ¿Qué pasa cuando el jugador llega a los bordes de las paredes? ¿Su sistema de visualización funcionará para mazmorras o tendrá que volver a escribir una parte significativa del código?

El mundo es geometría. El jugador es geometría. El mundo no se mueve. El jugador lo hace. Establezca la posición de la cámara para centrarse en el reproductor. Siempre . Y eso es todo lo que hay que hacer.

No tratar de conseguir la suposición con "oh si me deslice el mundo, entonces se dará la apariencia de que el jugador se está moviendo". Simplemente complicará las matemáticas con sistemas de coordenadas extraños al final del día.

Es cierto que el renderizado de OpenGL en realidad funciona "arreglando la cámara para apuntar hacia abajo - z, y transformando y girando toda la geometría del mundo para que se ajuste al volumen de la vista canónica", pero no debes pensar de esa manera al programar . gluLookAttiene parámetros nombrados eye, looky uppor una razón, por lo que puede pensar en términos de un sistema de coordenadas sensible.

— bobobobo
fuente

Uno de los errores más grandes que cometí con un sistema GL UI que estaba desarrollando fue intentar trabajar en coordenadas canónicas ([-1,1]) "para hacerlo más simple". Todos los objetos de la pantalla tenían coordenadas en [-1,1]. Este fue un gran error, estaba constantemente tratando de pensar en este rango [-1,1], convirtiendo entre píxeles y NDC, volviendo a convertir. Cuando renuncié a esta idea de trabajar en NDC y simplemente trabajé en píxeles y me convertí a NDC justo antes de renderizar como se suponía , había una gran diferencia en lo fácil que era pensar en posicionar elementos en la pantalla, procesar eventos de entrada, etc.

— bobobobo