net - public event c#
Programación de juegos y controladores de eventos (7)
En mi tiempo extra lejos del trabajo real, he estado aprendiendo XNA también.
En mi humilde opinión (o no tan humilde si le preguntas a mis compañeros de trabajo) es que la sobrecarga de los controladores del evento será abrumado por otros elementos en el juego, como la representación. Dado el uso intensivo de eventos en la programación .Net normal, yo sería el código subyacente que está bien optimizado.
Para ser sincero, creo que ir a un método UpdateCameras podría ser una optimización prematura. El sistema de eventos probablemente tenga más usos que no sean la cámara.
No he programado juegos durante unos 10 años (Mi última experiencia fue DJGPP + Allegro), pero pensé en echar un vistazo a XNA durante el fin de semana para ver cómo se perfilaba.
Estoy bastante impresionado, sin embargo, mientras sigo armando un motor de juego, tengo una (probablemente) pregunta básica.
¿Cuánto deberías confiar en los delegados y eventos de C # para conducir el juego? Como programador de aplicaciones, uso delegados y eventos en gran medida, pero no sé si hay una sobrecarga significativa para hacerlo.
En mi motor de juego, he diseñado una especie de "chase cam", que se puede unir a un objeto y luego recalcular su posición relativa al objeto. Cuando el objeto se mueve, hay dos formas de actualizar la cámara de persecución.
- Tener un método "UpdateCameras ()" en el ciclo principal del juego.
- Utilice un controlador de eventos y haga que la cámara de seguimiento se suscriba al objeto. EnMoved.
Estoy usando este último, porque me permite encadenar eventos juntos y automatizar muy bien grandes partes del motor. De repente, lo que sería enorme y complejo se dejó caer a un puñado de 3-5 manejadores de eventos de línea ... Es una belleza.
Sin embargo, si los controladores de eventos que disparan cada nanosegundo resultan ser una desaceleración importante, lo eliminaré y seguiré con el enfoque de ciclo.
Ideas?
Si pensara en un evento como una lista de suscriptores, en su código todo lo que está haciendo es registrar un suscriptor. Es probable que el número de instrucciones necesarias para lograr eso sea mínimo en el nivel de CLR.
Si quieres que tu código sea genérico o dinámico, entonces debes verificar si algo está suscrito antes de llamar a un evento. El mecanismo de evento / delegado de C # y .NET le proporciona esto a muy bajo costo (en términos de CPU).
Si realmente te preocupas por cada ciclo de reloj, nunca escribirías una lógica de juego genérica / dinámica. Es una compensación entre el código mantenible / configurable y la velocidad absoluta.
Escrito bien, preferiría eventos / delegados hasta que pueda probar que es un problema.
La única forma en que realmente sabrás si es un problema para ti es perfilando tu código, ¡lo cual deberías hacer de todos modos para el desarrollo de cualquier juego!
XNA recomienda el uso de interfaces, eventos y delegados para conducir algo escrito con él. Eche un vistazo a las clases relacionadas con GameComponent que lo configuran para usted.
La respuesta es: "Por mucho que te sientas cómodo".
Para elaborar un poco, si, por ejemplo, toma y hereda de la clase gamecomponent en una clase de controlador de cámara y agréguela a la colección Game.Component. Luego puedes crear tus clases de cámara y agregarlas a tu cámara controladora.
Hacer esto hará que el controlador de la cámara se llame con regularidad y podrá seleccionar y activar la cámara adecuada o múltiples cámaras si eso es lo que está buscando.
Aquí hay un ejemplo de esto (todos sus tutoriales son excelentes): ReoCode
Por otro lado, puede que le interese saber que Shawn Hargreaves , desarrollador original de Allegro , es uno de los principales desarrolladores del equipo de XNA :-)
La principal pregunta aquí parece ser: "¿Cuál es la sobrecarga asociada con el uso de C # delegados y eventos?"
Los eventos tienen una sobrecarga significativa en comparación con una llamada a función normal.
El uso de Delegados puede crear basura implícita y, por lo tanto, oculta. La basura puede ser una causa importante de problemas de rendimiento, especialmente en el XBox360.
El siguiente código genera alrededor de 2000 bytes de basura por segundo (a 60 fps) en forma de objetos EntityVisitor:
private delegate void SpacialItemVisitor(ISpacialItem item);
protected override void Update(GameTime gameTime)
{
m_quadTree.Visit(ref explosionCircle, ApplyExplosionEffects);
}
private void ApplyExplosionEffects(ISpacialItem item)
{
}
Siempre y cuando evite generar basura, los delegados son lo suficientemente rápidos para la mayoría de los propósitos. Debido a los peligros ocultos, prefiero evitarlos y usar interfaces en su lugar.
Es importante darse cuenta de que los eventos en C # no están en cola como eventos asíncronos (como, por ejemplo, la cola de mensajes de Windows). Básicamente son una lista de indicadores de función. Así que plantear un evento no tiene peores consecuencias de rendimiento que iterar a través de una lista de indicadores de función y llamar a cada uno.
Al mismo tiempo, tenga en cuenta que debido a esto, los eventos son sincrónicos. Si el oyente de su evento es lento, reducirá la velocidad de la clase que plantea los eventos.
Antes de analizar cuál es el impacto de un evento en términos de rendimiento, primero debe evaluar si es necesario o no.
Suponiendo que realmente está tratando de mantener actualizada una cámara de persecución y no es solo un ejemplo, lo que está buscando no es un evento (aunque los eventos también pueden ser de utilidad), si está siguiendo una probabilidad de avatar será moviéndose la mayor parte del tiempo.
Un enfoque que encontré extremadamente efectivo es usar transformaciones jerárquicas, si implementa esto de manera eficiente, la cámara no será el único objeto que se beneficie de dicho sistema, el objetivo sería mantener la cámara dentro del espacio de coordenadas del objeto que es rastreo.
Ese enfoque no es el mejor si se quiere aplicar cierta elasticidad a la velocidad y la forma en que la cámara rastrea el objeto, para eso, lo mejor es usar una llamada de actualización, una referencia y física de aceleración y resistencia básica.
Los eventos son más útiles para cosas que solo suceden de vez en cuando o que afectan muchos aspectos diferentes de la aplicación, como la muerte de un personaje, probablemente muchos sistemas diferentes desearían estar al tanto de tal evento, matar estadísticas, la IA controladora y etc., en tal caso, hacer un seguimiento de todos los objetos que tendrían que verificar constantemente si esto sucedió es mucho menos efectivo que lanzar un evento y que todos los objetos interesados sean notificados solo cuando ocurra.