XNA y C # frente a los 360 en el procesador de pedidos

Después de leer esta queja , creo que probablemente tengan razón (ya que Xenon y CELL BE son muy sensibles al código ignorante ramificado y de caché ), pero he oído que la gente también está haciendo juegos bien con C #.

Entonces, ¿es cierto que es imposible hacer algo profesional con XNA, o solo faltaba el póster lo que hace que XNA sea la API asesina para el desarrollo de juegos?

Por profesional, no me refiero en el sentido de que puedes ganar dinero con él, sino más bien en el sentido de que los juegos más profesionales tienen modelos físicos y sistemas de animación que parecen estar fuera del alcance de un idioma con barreras tan definidas para los intrínsecos. . Si quisiera escribir un sistema de colisión o un motor de dinámica de fluidos para mi juego, no creo que C # me ofrezca la oportunidad de hacerlo, ya que el generador de código de tiempo de ejecución y la falta de intrínsecos se interponen en el rendimiento.

Sin embargo, muchas personas parecen estar bien trabajando dentro de estas limitaciones, haciendo sus juegos exitosos pero aparentemente evitando cualquiera de los problemas por omisión. No he notado que ningún juego de XNA haga algo complejo que no sea lo que ya proporcionan las bibliotecas o los sombreadores. ¿Es esto evitar las dinámicas de juego más complejas debido a las limitaciones de C # , o simplemente a las personas que se concentran en hacerlo ?

Honestamente, no puedo creer que la guerra de IA pueda mantener tantas unidades de IA sin algún enfoque orientado a datos, o algunos trucos sucios de C # para que funcione mejor que el enfoque estándar, y supongo que esa es en parte mi pregunta también, cómo ¿la gente ha hackeado C # para que pueda hacer lo que los codificadores de juegos hacen naturalmente con C ++?

OK, solo para hacer algunos agujeros en esa diatriba que vinculaste:

• "C # se basa en un intérprete" Just In Time "" - incorrecto - es un compilador JIT . Después de que un método se JIT una vez , el código compilado se reutiliza para cada invocación. El código compilado es casi tan rápido como el código nativo precompilado.
• "La CPU Xenon es un procesador" en el lugar " : ¿quiere decir" en orden "? - Y: "La CPU Xenon no tiene predicción de rama" . Él implica que esto significa que la compilación JIT produce naturalmente código incorrecto que debe ser reordenado por la CPU y causa muchas ramificaciones, lo cual es una tontería absoluta . El mismo consejo de rendimiento para ejecutar en esta arquitectura de CPU se aplica tanto a C ++ como a C #.
• "[JIT] requiere un enjuague constante en el 360" : incorrecto, el código compilado se puede guardar en caché como cualquier código compilado normalmente. (Si se refiere al lavado de la tubería, vea el punto anterior).
• "los genéricos [...] usan la generación de código" : los genéricos son JITted como todo lo demás y, como todo lo demás, el código JITted es rápido. No hay penalización de rendimiento por usar genéricos.
• "todas las partes sexys del lenguaje [...] requieren una predicción de rama ..." : ¿cómo no se aplica esto también a C ++? - "... o [...] generación de código in situ" - ¿quiere decir JITting? ¿Mencioné que es rápido? (No entraré en todos los lugares donde el CLR de escritorio usa la generación de código real , ¡una función que no es compatible con Xbox 360!)
• "[C # no tiene] las bibliotecas masivas [de C ++]" , ¿excepto, por ejemplo, XNA? Y muchos más . (Aún así, este es un punto un tanto justo).

XNA en Xbox 360 se ejecuta en una versión modificada de .NET Compact Framework CLR. No tengo dudas de que no está a la altura de la versión de escritorio. El JITter probablemente no sea tan bueno, pero tampoco creo que sea malo . Me sorprende que no haya mencionado el recolector de basura que es terrible en comparación con el CLR de escritorio.

(Por supuesto , de todos modos no deberías golpear al recolector de basura en un juego desarrollado profesionalmente , así como debes tener cuidado con las asignaciones en cualquier juego de nivel profesional).

(Para una discusión técnica real de .NET Compact Framework, quizás comience con esta serie de artículos: Descripción general , Compilador JIT y GC y montón ).

La forma en que es completamente inespecífico sobre su terminología hace que sea difícil incluso entender lo que quiere decir. O está en modo de despotricar o no sabe de qué está hablando.

Ahora que lo hemos eliminado, aquí hay algunas cosas que puede hacer. se pierda en mediante el uso de XNA en el 360, en lugar de convertirse en nativo :

• Acceso a la unidad SIMD / Vector para realizar cálculos de punto flotante de CPU muy, muy rápidos
• Posibilidad de usar código de idioma nativo que probablemente sea un poco más rápido que C #
• Habilidad para ser un poco más vago con la forma de asignar memoria
• Los juegos XBLIG tienen acceso a solo 4 de los 6 núcleos (pero todavía obtenemos las 3 CPU, y tampoco son núcleos completos, por lo que no nos perdemos mucho), no estoy seguro de si esto se aplica a XNA no XBLIG juegos
• Acceso completo a DirectX para hacer trucos gráficos realmente oscuros

También vale la pena señalar que estas son solo restricciones del lado de la CPU. Todavía tienes acceso completamente gratuito ejecutándose en la GPU.

Describí estas cosas en esta respuesta a lo que efectivamente es la misma pregunta que esta. Como mencioné en esa respuesta, XNA es absolutamente adecuado para el desarrollo "profesional" .

La única razón por la que evitaría es porque no puede contratar talento C #, licenciar motores C # y reutilizar el código C # existente de la misma manera que lo hace con la base existente de conocimiento de C ++. O porque también podría estar apuntando a una plataforma que no admite C #.

Por supuesto, para muchos de nosotros que no somos desarrolladores "profesionales", XNA es nuestra única opción para ingresar a Xbox 360, lo que hace que el punto sea discutible.

Para responder a sus otras preguntas:

Nada en C # le impide utilizar enfoques orientados a datos en esencia exactamente la misma forma en que se utilicen en C ++.

C # carece de la capacidad de alinear automáticamente el código en tiempo de compilación, y (sin ir a comprobarlo) estoy bastante seguro de que el JITter de CLR compacto no puede incluir métodos en línea (el CLR de escritorio sí puede). Entonces, para el código crítico para el rendimiento, es posible que tenga que insertarlo manualmente en C #, donde C ++ proporciona alguna ayuda.

Probablemente, una razón más importante por la que a menudo no se ven cosas intensivas en matemáticas de CPU como la detección de colisiones y las simulaciones de fluidos en C # es la falta de acceso a la unidad de vectores (como se mencionó anteriormente).

Tendría que definir 'profesional'. ¿Podrías hacer Angry Birds, Plants vs Zombies, etc.? Absolutamente. ¿Podrías hacer Crysis 2, COD, Halo? Lo dudo. El uso de C # solo afectará los juegos que requieren mucha CPU y también necesitan exprimir hasta el último byte de memoria (se pierde en la recolección de basura), por lo que todavía hay muchas cosas que puedes hacer.

Como herramienta de aprendizaje para las personas que están comenzando, herramienta de creación de prototipos, plataforma para escribir juegos que pueden lidiar con el intercambio, etc., es fantástico y tiene mucho poder y simplicidad, simplemente no está diseñado para hacer lo que necesariamente llama a los juegos 'AAA'. También elimina gran parte del dolor y el sufrimiento de los que las personas tienen que preocuparse con la compatibilidad y la portabilidad multiplataforma.

Si se te ocurre un juego increíble y te topas con las limitaciones de lo que puedes hacer con XNA, te sugiero que te pongas en contacto directamente con MS, si la idea es lo suficientemente buena, podrían permitirte tener un desarrollo completo. equipo.

El simple hecho es que no necesita un alto recuento de polígonos, iluminación HDR completa o la física más interesante del mundo para hacer un juego interesante, y si su plan de juego no incluye ninguno de ellos, entonces ¿por qué no ir más rápido? solución de tiempo de desarrollo?

Más juegos profesionales tienen modelos físicos y sistemas de animación.

Eso está mal. Los juegos profesionales tienen lo que necesitan para implementar su juego y lograr su aspecto artístico, y nada más y nada menos. Un juego no es más profesional porque parece más realista o tiene una física más detallada. Un juego profesional logra su juego y objetivos visuales, a tiempo, dentro del presupuesto, etc., y se envía y obtiene ganancias.