andoba escribió:Creo que no estamos hablando de que haya que programar en ensamblador para tener un buen resultado, si no a que para ejecutar cualquier código hoy en dia se programe de forma que haga falta tener detrás quince interpretadores, máquinas virtuales, CLR, .NET, etc... ¿Realmente hace falta tener tantísimas capas entre el ordenador y tu software? Está todo demasiado sobredimensionado.
Me encanta la exageracion haha, que entiendo por donde vas pero "no" hay "tantisimas" capas, por ejemplo si usas lua junto a opengl o sdl y en vez de usar un jit (compilado durante la ejecucion) puedo hacer un precompilado y despues solo voy a necesitar un maquina virtual/interprete, "una" capa tengo y al usarse un codigo intermedio es un lenguaje que permite facil portabilidad entre plataformas.
Todo tiene sus cosas buenas y malas. El control de memoria en C/C++ si se practica puede ser total pero tambien programar en C++ es un baile sobre pinchos y meter la gamba es bastante facil y el depurado es mucho mas dificil que en lenguajes de mas alto nivel. El poder especificar el tipo concreto de las variables y estar forzado a ello en la declaracion sirve para optimizar pero tambien cierto es que el tipado dinamico es una gloria bien usado. En relacion a la no necesidad de compilacion de ciertos lenguajes, es comodisimo para implementar la opcion de realizar mods o para motores, pues la base estara programada a bajo nivel pero los scripts y variables de entorno las modificaras cuando quieras que no cambio, compilo, pruebo, cambio, compilo... lo que ayuda a poder centrarte en el problema antes el que este mucho mejor, parece una tonteria pero el que todo sea "ya!" es importantisimo para no "perder el hilo".
Por ejemplo, de uno de los que mas conozco y el que estoy usando habitualmente desde hace cosa de un año, en Lua lo que puedo hacer con las arrays/diccionarios no se hace en c++ ni loco, literal. Que igual dando muchas vueltas puedes conseguir algo similar, seguro pues muchos caminos o todos llevan a roma pero uf... en este apartado lua es cosa fina fina. Si no se me cree, que puede ocurrir xD hacer unas pruebas y ya me direis. Que los tiempos de ejecucion aun siendo muy rapidos dentro de los lenguajes de su tipo, no se pueden comparar con C++? seguro

pero la claridad del codigo, las pocas lineas y el facil mantenimiento me da que no se los llevara C++...
andoba escribió:Dudo mucho que juegos como el SSF2HD o el Outrun 2 estén programados en .NET, la verdad. Que estén en la tienda online no implica que estén programados con XNA.
Mismamente Fez esta hecho en xna tirando de C# y a mi me parece una puta obra de arte y no veo tirones ni falta de rendimiento...si he escuchado de algun bug pero es otro tema
![carcajada [carcajad]](/images/smilies/nuevos/risa_ani2.gif)
. Que parece que hay una lucha encarnizada contra .net y la mayoria de la gente que conozco que lo ha probado a fondo, hostia! en vb.net para prototipos de aplicaciones y desarrollo rapido es dios (claro esta limitado a windows), asp .net es impresionante para desarollar paginas web o aplicaciones web y C# con xna para juegos va fino fino. Que no es multiplataforma? objective-c tampoco lo es y no veo a la gente despotricando de el a cada segundo...sera por ser de apple
andoba escribió:Unreal tira de UnrealScript pero tiene detrás un motor de juego (que no gráfico, ojo, de juego que abarca desde los gráficos a la música, IA, conectividad, físicas...) de los mejores programados de la industria, robusto como una roca y programado en lenguajes de bajo nivel. Y sobre todo, enfocado a videojuegos, cosa que lenguajes como Java o .NET no están enfocados a juegos si no a un uso más general.
Cierto pero como ya he dicho igualmente opengl (openal aun tengo que probarlo) y directx no estan desarrolladas por mindunguis y "aunque sea una capa intermedia" es una "capaza" que te ahorra muuuucho trabajo base que a la hora de hacer un juego no te importa, que no es lo mismo hacer un juego que hacer un motor...hacer un boli usar el boli...ya que mola el ejemplo del boli xDDD
andoba escribió:El problema no es utilizar OpenGL, OpenAL, Direct3D o cualquier otra librería, está bastante claro que nadie va a ponerse a hacer un motor gráfico accediendo directamente a los registros de la GPU como los juegos DOS. El problema es que desde que tu línea de código llega hasta Direct3D, no pasan 3 o 4 librerías previas, si no decenas y interpretadores por el medio...
Y una vez mas "decenas"...ains que exagerau hijo
![loco [looco]](/images/smilies/nuevos2/borracho.gif)
y que problema hay en usar opengl mas alguna otra libreria para tcpip mas otra para anuncios/publicidad (por decir algo a boleo...)? el juego va estable? el programador ha conseguido lo que queria y para la plataforma que queria? objetivo cumplido! que ese juego no te va en un pentium3, lo siento...