XBOX 360: C# o C++, he aquí el dilema

menuda parrafada macho... tu eres albanil ,no?? xDD mira la verdad es que no me e enterado de na xD mis conocimientos en programacion son nulos,pero ya que entro y lo leo pues pongo algo que casi me tirao 10 minutos entre que me calentaba el coco pa intentar enteder algo xD..

salu2

daba palo leerselo entero pero hay un foro de la 360 xD

Creo que preguntas en el sitio equivocado yo tampoco me lo he acabado.

Mejor preguntale a los que diseñaron la consola.... Es que algunos haceis unas preguntas.....

yo si que lo he leido enterito y me ha parecido muy interesante. lo que no veo claro es como despues de todo esto aún preguntas! si deberíamos preguntarte nosotros a tí!

suerte con una respuesta que te sea más útil

Por lo que pone aqui XNA se basa en Visual Studio 2005 Team System, que se basa en .NET Framework, así que supongo que tirarán de C#

Gracias por vuestras respuetas. La verdad es que no sé muy bien cómo encontrar un foro de programadores que sepan de este tema, y como aquí hay (habemos) mucho friki, pos pensé que a alguno se podría haber planteado el mismo dilema que yo. Admás me da mucha pereza traducirlo al inglés y colarlo en un foro internacional.
Güeno, lo dicho, perdonad por la rallada. Si encuentro la solución a tales cuestiones metafísicas la pondré por aquí, porque no me podréis decir que sería una pasada que se pudieran ejecutar los programas .NET en la consolita ¿eh?

interesante, yo opino que todas estas maquinas virtuales generan mucha compatibilidad pero no dejan de ser una capa mas, lo cual implica un rendimiento peor. Para ciertas aplicaciones eso puede no importar pero en un videojuego el rendimiento maximo al hardware es crucial

aunque claro, a medida que pasan los años, esos programas java que eran muy lentos pues ya no lo son tanto, quizas con la megacpu de la x360 el meterle .net de por medio no supone tanto problema

la verdad es que como la x360 tenga .net por debajo estaremos viendo como se planta cara a los dispositivos que ejecutan java

entre la x360 y los pocketpc y los smartphones windows mobile el señor Gates se lo quiere comer todo, veremos que tal le sale... yo apuesto a que bien

pues imagino que los juegos seran prograados usando C++ por una sencilla razon. Si todas las consolas fuesen a llevar disco duro a lo mejor hasta me lo podria plantear, pero tu piensa que la maquina virtual que usa .NET ocupa muchiiiiiiiisimo, y eso meterlo en la consola sin disco duro la verdad es que no lo veo demasiado viable.

Chichu escribió:pues imagino que los juegos seran prograados usando C++ por una sencilla razon. Si todas las consolas fuesen a llevar disco duro a lo mejor hasta me lo podria plantear, pero tu piensa que la maquina virtual que usa .NET ocupa muchiiiiiiiisimo, y eso meterlo en la consola sin disco duro la verdad es que no lo veo demasiado viable.

En realidad una máquina virtual ocupa relativamente poco, alrededor de 5 MB, que bien podría incluirse en el propio DVD si es que fuera necesario. A esto habría que añadirle las bibliotecas XNA (lo que ahora es DirectX Managed) que ocuparían casi igual para .NET que para la biblioteca nativa. El .NET Framework para Windows ocupa entre 20 y 30 MB pero eso es porque incluye un montón de Wrappers y de bibliotecas que no se usarían en una consola, aunque si fuera necesario tampoco sería tan descabellado de meter un "monstruo" así en los propios DVDs.
No obstante yo pienso que como bien dices se debería tener Disco Duro sobre todo para las aplicaciones que no fueran juegos.
Y también me inclino a pensar a que se programe en C++ más que nada por temas de rendimiento, aunque la máquina virtual de .NET es muy superior a la de Java y con el tiempo permitirá una optimización de código similar si no en algunos casos superior a la que se permite por compilación directa a código máquina.
En resumen, aunque todo esto no sea más que una suposición, creo muy razonable que .NET pueda ser instalada en aquellas consolas que tengan disco duro, o usada desde los propios DVDs.
Un beneficioso efecto colateral de esta tecnología es que además de que los programas (incluidos los juegos) serían usables desde PC y XBOX 360, sería muy sencillo realizar una futura consola compatible con esta, ya que el código se compilaría in situ a su futuro hardware.
Siento mucho por continuar con la rayada... jeje

Contando que alguien de microsoft me ha dixo que el entorno de desarrollo de x360 cuesta alrededor de 25 mill de las antiguas pesetas.....

vidda escribió:Siento mucho por continuar con la rayada... jeje

No es pa tanto estas como en casa, unos lo pillaran y otros no jejeje (yo soy de los que no...)
salu2

Square-Beast escribió:Contando que alguien de microsoft me ha dixo que el entorno de desarrollo de x360 cuesta alrededor de 25 mill de las antiguas pesetas.....

¿Comorrlll? Creía que para conseguir un kit de desarrollo tenías que ser un desarrollador autorizado. A lo me jor lo que te ha dicho es el kit de desarrollo para PC, útil para hacer los primeros prototipos, pero vamos para hacer juegos de verdad se necesita por ahora una consola especialmente preparada para ello (esas negras especiales que pululan por ahí).

En cualquier caso espero que la Scene pueda hacer un trabajo similar al hecho con la actual XBOX (modding, piratting, , y que se les cuele por el emule/torrent de vez en cuando los Kits de desarrollo actualizados.

Lo mismo utilizan una medida intermedia.
En vez de utilizar el Runtime de .net podrian compilar directamente el codigo y así seria mas optimo, ya que X360 es una maquina cerrada, no le veria mucho sentido que utilizaran el runtime de .NEt si al final es lo que se utiliza claro.


Muy interesante el Hilo, la verdad, haber si los fieras del foro nos sacan de dudas.


Saludos

Molonator69 escribió:Lo mismo utilizan una medida intermedia.
En vez de utilizar el Runtime de .net podrian compilar directamente el codigo y así seria mas optimo, ya que X360 es una maquina cerrada, no le veria mucho sentido que utilizaran el runtime de .NEt si al final es lo que se utiliza claro.

También lo había pensado yo pero lo descarté por dos razones:

* La ventaja de velocidad de una precompilación a código nativo y una compilación en tiempo de ejecución no es apreciable. Por otra parte el compilador JIT de Microsoft es muy avanzado y optimiza muy bien el código (sólo tiene una pérdida de rendimiento alrededer del 15% respecto al código C++ no administrado, pero ninguna sobre compilación directa administrada). Por otro lado asumiendo esa posible pérdida de rendimiento, las ventajas del código .NET administrado serían muchas: Portabilidad total entre diferentes plataformas actuales y futuras del programa compilado [al MSIL], sin más que insertar el DVD y jugar. Futuras optimizaciones de la máquina virtual que reportarían aumentos de rendimiento para la misma aplicación. Mayor sencillez en las complicaciones internas de programación como liberación de memoria, administración de hilos, interconexión con Internet, etc.

* Con cada nueva generación de consolas es más difícil emular la anterior, por lo que no sería mala idea empezar a tomar medidas desde el principio haciendo una programación más limpia. Me explico: en windows es muy fácil emular una funcionalidad que no está presente con otra alternativa, tal era el caso de los famosos emuladores de OpenGL a través de DirectX y viceversa. Esto es porque los programas Windows se vinculan en tiempo de ejecución con las bibliotecas que van a usar; por tanto si se mantiene la interfaz de llamada, con relativa sencillez se puede cambiar la implementación de la biblioteca y hacer así que la aplicación de usuario se pueda ejecutar sin enterarse del cambiazo (así es como funciona Wine para GNU/Linux). Sin embargo los que conozcais el XBOX Developer Kit sabréis que la vinculación con la biblioteca personalizada de DirectX 8.0 es estática, es decir, en el propio archivo ejecutable están las llamadas al sistema necesarias para interacturar con el hardware, y no en bibliotecas de enlace dinámico. Esto ha forzado a realizar un emulador de XBOX para la XBOX 360 altamente complicado ya que incorpora elementos de alto y bajo nivel simultáneamente. Según palabras del desarrollador jefe ha utilizado algo de magia para conseguirlo.

Por otra parte y como aclaración aunque un programa .NET se compile a código nativo (el de PowerPC en este caso), se sigue necesitando del runtime de .NET, es decir, la biblioteca de tiempo de ejecución de .NET es de enlace dinámico, una versión muy evolucionada de las clásicas .dll de windows. Aunque vamos en la línea de lo que dice Molonator69 , también podrían haberla compilado a código nativo toda entera, con lo que incluso se podría vincular estáticamente.

No obstante y aun habiendo soltado esta parrafada, me imagino que los programas para la XBOX 360 se seguirán haciendo en C++ y con compilación directa a código máquina de PowerPC, y que las bibliotecas se vincularán estáticamente, con lo que los programadores eliminarán el indeterminismo de una capa de abstracción como es .NET, y le podrán sacar el máximo partido a la máquina.

Vamos ánimo, que alguien más de sus impresiones al respecto!!!

Saludos a tós.

Y yo digo, ¿El que se use Visual Studio .NET obliga necesariamente a usar c#?
.Net no es solo c#, hay mas lenguajes.

Sobre el tema de si se usa o no se usa. Yo creo que si hay codigo en la x360 escrito en la plataforma .net.

El dashboard, debido a que es un elemento desde el cual se accede a todo, conviene escribirlo en .net por que facilita la programación (sacaran actualizaciones seguro) y facilita la integración con nuevas funcionalidades en un futuro.

Luego tambien todo el tema de xbox-live. .Net está muy orientado a ofrecer servicios dinámicos. Los minijuegos y los chats por ejemplo, contenidos dinámicos como rankings, tienda virtual.... (se pueden crear con asp.net)

El resto, los juegos se seguiran haciendo en C++ con optimizaciones en ASM bajo la plataforma DirectX.

DirectX Managed no es mas que un añadido a la API de DirectX que facilita la escritura de código, reduce el tiempo de desarollo, se integra mejor con todo el Windows, y permite usar mas lenguajes con la misma api.

El tema de la velocidad de DirectX managed no es un factor a tener en cuenta.
El principal factor es que los programadores van a lo más práctico.

Recordar que DirectX es acelerado por hardware, y el unico factor que la hace mas lenta que la api en crudo es el de la maquina virtual (el runtime de .net)
Eso es solo un 2% mas lento que una aplicacion nativa.

supermoves escribió:Y yo digo, ¿El que se use Visual Studio .NET obliga necesariamente a usar c#?

Humm... yo no pretendía inducir a que se pensara tal cosa . Si en el tema del hilo puse C# frente a C++ fue para simplificar, en lugar de haber puesto "un lenguaje que soporte la Common Languaje Runtime de Microsoft frente a C++ no administrado". El hecho de poner C# es porque es el más representativo para eso, pero vamos, se puede programar en C++ generando código para la máquina virtual de MS, claro.

Por lo demás estoy de acuerdo contigo, y ójala sea asín .

Joer, eso kiero acavar diciendo yo algun dia xD es k kiro ser programador, pero es k buff k lio, me tragao todo el hilo entero, y os digo gracias, ya que d algo me enterao, ade+ es k toy ara en un hotel de paris (k toy de vacas ^^) y he pasao un wen rato k tendria k aver tao rayao esperando sin aser na, Asi k graccias xD.

PD: Hoy sobre las 10 de la noche tar en casa, asi k hasta dentro de 10 horitas no vre el post xD

Un Saludo

Codigo Interpetado ( Ya sea semi compilado y super optimizado ) = Enemigo de la optimizacion = Enemigo de los videojuegos de ultima generacion

Pepote escribió:Codigo Interpetado ( Ya sea semi compilado y super optimizado ) = Enemigo de la optimizacion = Enemigo de los videojuegos de ultima generacion

Poooozí .

Es por eso por lo que pienso que se seguirá con compilación directa a código máquina, pero dejo una venta abierta a una futura máquina virtual que optimice en tiempo de ejecución lo que un compilador puede hacer offline. Es más ya que un compilador JIT tiene información adicional sobre la plataforma de destino (no en el caso de la 360, que es fija), y puede seguir siendo mejorado, en ocasiones se ha argumentado que podría llegar un momento en que el rendimiento fuera superior.
Lo que es indudable (bueno, para mí), son las ventajas que ofrece: una independencia del hardware mayor, facilidades en cuanto a administración de memoria, interconexión, bibliotecas nutridas de funciones,...

El que sea managed code no implica necesariamente una grán perdida de rendimiento. El JIT de .net tiene dos modos de ejecución, uno en el que el codigo es creado segun se requiere por la ejecución del programa, y otro que compila antes de ejecutar el programa (ahead of time creo que se llama). Este segundo modo crea binarios optimizados para la plataforma nodriza con un alto rendimiento.

Ademas es una tarea que se puede hacer en segundo plano. Creo que el runtime de .Net guarda un registro de la frecuencia de uso de ciertos componentes, para precompilarlos y mejorar su rendimiento.

Aparte, DirectX managed sigue siendo directx, que es acelerado por hardware. Con lo cual, no hay una gran perdida de rendimiento.

Tambien hay que tener en cuenta que la maquina tendrá bastante potencia como para que sea un problema apreciable.

Y por otro lado, creo que en .net tambien hay algo similar a los JNI de Java. (Java native interfaces). Eso permite crear ciertas partes de un programa en un determinado lenguaje (ASM, C, C++...) para obtener un mejor rendimiento.

Sacrificar un 5% de rendimiento para obtener un 50% de reduccion de costes a la hora de programar, o hacer que sea mas sencillo para el programador, pues yo creo que merece la pena.

Sólo quería añadir sobre lo que ha dicho supermoves que quizá el principal inconveniente para que se use esta tecnología .NET es conseguir la confianza de los desarrolladores. En la actualidad no conozco ningún proyecto de videojuego "serio" que públicamente diga que la ha usado.
Lo más cercano fue la recompilación que se hizo del código fuente de Quake II con lo que según los creadores se sufrió una pérdida de un 15% de rendimiento.
http://www.vertigosoftware.com/Quake2FAQ.htm

How is the performance of the managed version?
Initially, the managed version was faster than the native version when the default processor optimization setting /G5 (Pentium) was used. Changing the optimization setting to /G7 (Pentium 4 and Above) created a native version that runs around 15% faster then the managed version.

Note, the assembly code was disabled for the native and managed versions so both versions are slower than the original Quake version.

Como no tenía otra referencia, por eso decía que la pérdida de rendimiento puede estar en esa cifra. Si alguien pudiera aportar enlaces de pruebas de rendimiento en juegos más modernos, pos mejor que mejor (diferencias entre la versión managed y no managed). Yo tengo fé en que la tecnología siga mejorando y en un futuro consiga incluso un rendimiento mayor o igual que la compilación directa.

Pues sigue soñando, por que eso nunca ocurrirá.
Obviamente, el proceso de interpretación/compilado/traducción consume recursos del sistema. Eso es de perogrullo.

Algo siempre se pierde, aunque sea un misero 0.1%, La cuestión es si con ello ganas otras ventajas que hagan merecer la pena ese proceso.

Por ejemplo, Java se usa bastante para crear programas de cálculo científico o inteligencia artificial, a pesar de que luego vayan a tener un rendimiento mas pobre que si se creara directamente con c++, la facilidad de programación merece bastante la pena.
Y añade además, el facil mantenimiento de los programas, no tener que preocuparte de gestionar la memoria, la cantidad de clases que Sun proporciona directamente para cogerlas y trabajar con ellas, la independencia (CASI) de arquitectura.....

Hay cantidad de ejemplos de este tipo en el mundo empresarial.
La gran mayoria de aplicaciones para empresa se crean usando Visual Basic.
Como lenguaje es bastante pésimo, propenso a fallar mas que una escopeta de feria (ej: lios de dll), y con un consumo de memoria bastante elevado para lo que en realidad tiene, pero oye... Visual Basic sigue dando a muchos de comer, y las empresas necesitan velocidad en el desarollo.

Olvidaos del rendimiento como única meta,. Si fuese por rendimiento se seguiria programando a pelo en ASM, y no existiria el hardware acelerador.

supermoves escribió:Pues sigue soñando, por que eso nunca ocurrirá.

"Es muy arriesgado hacer predicciones, sobre todo cuando son de futuro" - Oscar Wilde

Creo que el que una persona crea que una tecnología va mejorar en el futuro no es en absoluto descabellado. Para no mostrarte tan prepotente (y arrogante), te recomiendo que cambies esta frase por: "No estoy de acuerdo contigo, pienso que eso no va a ocurrir", con lo que se te entendería perfectamente.
Si lo dije es porque he leido mucho al respecto, he estudiado la máquina virtual a fondo y creo con razones fundamentadas que eso podría llegar a ser. Sólo es necesario que se mejore la tecnología de compilación y optimización Just In Time, y quizá se pulan un poco más ciertos aspectos de la biblioteca.

supermoves escribió:Obviamente, el proceso de interpretación/compilado/traducción consume recursos del sistema. Eso es de perogrullo.

La pérdida de rendimiento por la ejecución Just In Time de la máquina virtual de MS (y en general la JIT de Java y otras) sólo afecta a la 1ª ejecución del código por cada nueva instancia del proceso. Por ejemplo, si se tuviera un programa con un único gran bucle, en la primera iteración se traduciría todo a código máquina nativo, el resto de iteraciones no existiría tal traducción. Se estima que la pérdida de rendimiento que ocurre en esa primera iteración no es apreciable, ya que el tiempo que se empleó en cargar las páginas de memoria desde el dispositivo de almacenamiento masivo puede ser muy superior al que se emplea en la traducción optimizada del código intermedio al código máquina. Además el compilador JIT puede contar con información de tiempo de ejecución más detallada que la que podría contarse con la compilación clásica: aspectos de hardware y software.

supermoves escribió:Hay cantidad de ejemplos de este tipo en el mundo empresarial....

Si dices esto a raiz del llamamiento que hacía para que pudiéramos ver el rendimiento de las aplicaciones mediante enlaces de terceros, fíjate que recalcaba que fuera rendimiento de videojuegos y no de aplicaciones empresariales, ya que son programas radicalmente distintos internamente. Si lo decías por poner otro comentario adicional, entonces nada

supermoves escribió:Olvidaos del rendimiento como única meta.

Yo creo que aquí nadie ha dicho que el rendimiento sea la única meta, aunque eso sí es una cosa importante.
Creo que estamos de acuerdo que lo mejor de lenguajes como C#, o mejor dicho la arquitectura .NET es que el balance entre lo que se invierte en él y lo que se recoge le es muy favorable. Esto se refleja en cosas como que permite una programación más cómoda en menos tiempo con un rendimiento muy aceptable.

No te piques supermoves, que es mejor estar de buen rollo, y en el fondo pensamos parecido.

Hey, de buen royo, que para nada estoy sobre-excitado ni mosca con nadie.
Y en absoluto quise parecer ni prepotente ni arrogante.

Solo respondí a esta frase:
"Yo tengo fé en que la tecnología siga mejorando y en un futuro consiga incluso un rendimiento mayor o igual que la compilación directa"

Mi "sigue soñando por que eso nunca ocurrirá" es un formalismo (pido perdón si sonó agravante) para indicar que todo codigo interpretado es y será mas lento que el codigo ya compilado, y siempre será así. Al menos eso es lo que me enseñaron en la Uni.

Es pura lógica. Se requiere realizar un trabajo previo de traducción del programa a un lenguaje que comprenda la máquina, y ese proceso consume.
Mucho o poco, es igual, aunque sea un 0.00001%, ya es algo. Ese trabajo no tienes que hacerlo con binarios pre-compilados.

Por supuesto que con la compilación Antes-De-Tiempo (Ahead of Time), te evitas ese problema.
Compilar el managed code a un codigo nativo optimizado antes de ejecutarlo, para así mejorar su rendimiento..., pero entonces ya no estamos hablando de codigo interpretado, y además se pierden las ventajas iniciales del managed code.
Además, tendrías que realizar dicho proceso para cada programa/modulo/clase, cada vez que surja un cambio en una clase/modulo/programa que comparta.

Lo del VisualBasic es solo un ejemplo, para ilustrar que no siempre se usa lo mejor en el mundo de la informática.

Y para concluir, yo no me mosqueo con nadie. No quiero parecer prepotente ni nada por el estilo.
Pipa de la paz para todos.

supermoves escribió:Hey, de buen royo . . .
Pipa de la paz para todos.

Eso tío si hablando nos entendemos.

Sólo hacer un poco de incapié en lo que decías:

supermoves escribió:Es pura lógica. Se requiere realizar un trabajo previo de traducción del programa a un lenguaje que comprenda la máquina, y ese proceso consume.
Mucho o poco, es igual, aunque sea un 0.00001%, ya es algo.

La traducción que realiza un compilador JIT sólo es en la primera ejecución de la instancia del proceso. El resto de iteraciones del código se ejecuta código máquina sin necesidad de volver a traducir nada, por eso si la generación de código fuera más óptima que con un generador "Ahead of Time" (cosa que actualmente no ocurre), el código resultante podría llegar a ser más rápido.

P.D. ¿No habrás estudiado en la Universidad de Alcalá? que lo mismo te conozco, jeje

Hombre, eso depende de la calidad del compilador AOT, que obviamente no son grandes compiladores de momento.
Pero supongamosle que en un futuro sean comparativamente iguales en calidad del código generado a los compiladores actuales.

Si estamos usando este método de ejecución, ya digo que volveríamos a estar hablando de binarios pre-compilados, y no de código interpretado. Con lo que esta discusión no tiene sentido.Yo solo hablaba del managed code.

Por definición, todo código interpretado es mas lento.

Y tambien, por la propia naturaleza, todo código generado por una máquina es susceptible de ser mejorado por un humano (con tiempo suficiente).

supermoves escribió:Si estamos usando este método de ejecución, ya digo que volveríamos a estar hablando de binarios pre-compilados, y no de código interpretado. Con lo que esta discusión no tiene sentido.Yo solo hablaba del managed code.

Hummmm, yo esque nunca he hablado de código interpretado. Cuando se utiliza la plataforma .NET en ordenadores "grandes" a través de su lenguaje intermedio bytecode con soporte CLR, siempre se utiliza compilación justo en el momento (just in time), es decir, no interpretada, independientemente de que se use o no el código administrado. (A excepción de que se compile en tiempo de instalación).
Pero si fuera el caso de usarse código administrado además habría que sumarle la pérdida de rendimiento por las comprobaciones adicionales de tiempo de ejecución.