Ver la versión completa : Patrones de Diseño de Software aplicado a los Videojuegos
DMusta1ne
29/10/2007, 13:13
Vamos a ver, este curso pasado estudié una asignatura, Ingeniería del Software II, donde veíamos los conocidos "Software Patterns" (Singleton, Façade, Factory Method,...) y los GRASP. Y viendo el otro día que alguien preguntaba en un hilo antiguo de como hacer una gravedad de tipo Castelvania, y pense que al igual en que en la programación orientada a objetos, en la programación de videojuegos hay muchos problemas recurrentes que tienen soluciones que se pueden repetir y sintetizar de manera que puedan adaptarse a las situaciones del problema en concreto bla bla bla.
En fin, ¿No existen patrones de diseño para videojuegos?, es decir algo como, el patrón gravedad, o el patrón menu, o el patrón guardar partida, etc etc.
Evidentemente no serían patrones a nivel extricto porque cuando se desarrolla videojuegos se depende mucho del lenguaje, por lo cual mas que patrones sería un idiom, pero bueno.
PD: Por cierto, si este hilo no esta en el lugar adecuado, no me importa que lo muevan, si me decís donde esta xD
DarkDijkstra
29/10/2007, 14:07
Asi como tal el "patrón gravedad" no me suena, pero se que en algún libro (ahora no me acuerdo cual, lo puedo buscar, creo que era de Computer Gaming Gems) exponen varios patrones de diseño "orientados a videojuegos", para rutas de inteligencia artificial, o "factorías" especializadas en texturas, modelos 3d... etc
Y luego en algún otro libro (ese ya no me acuerdo como se llamaba exactamente, ni lo he leido ni nada) que por lo visto estaba centrado en crear juegos de rol y similares, supuestamente comentaban técnicas de programación (y asumo que patrones de diseño) aplicadas a ese tipo de juegos.
Viendo que hay gente que parece dominar el tema de los patrones de software ... me podéis recomendar un libro (o varios) y/o documentación online al respecto?
Es que estoy encallado en la asignatura de Ingeniería del Software II desde hace mucho más de lo que me hubiera gustado, y no consigo superarla :(
Un poco de ayuda sería de agradecer :D
mortimor
29/10/2007, 14:59
Los patrones de software comunes pueden aplicarse facilmente a los videojuegos. En el caso de los menus existen patrones aplicados al diseño de interfaces, por ejemplo (Wiseman escribio sobre este tipo de patrones algo). Los videojuegos pueden facilmente adecuarse a un patron de modelo-vista-controlador, lo cual es muy comun (ver libro de programacion en XNA de McGrawHill si no me equivoco de editorial).
Para patrones genericos y aprender como funcionan hay varios libros interesantes como "UML y Patrones", "Java2 y patrones",...
El caso especifico de simular una gravedad no seria un problema de aplicar un patron u otro, sino de como implementar el determinado algoritmo dentro de los patrones elegidos para el diseño de la aplicacion. Desde el punto de vista del diseño, tener una metodologia solida es fundamental (segun el proyecto se puede usar desde XtremeProgramming u otra evolutiva hasta UP o alguno mas agil desde el punto de vista de un desarrollo siempre forzado), los patrones no son la panacea y en muchos casos acaban consiguiendo que la aplicacion sea mas pesada, algo nada bueno en aplicaciones de tiempo real "relajado" (como los videojuegos).
Con experiencia suficiente es presumible que la aplicacion de patrones en los diseños sea mas eficiente, pero esta claro que lo que suele primar es la correccion y la velocidad antes que las presumibles ventajas (reutilizacion, encapsulamiento, control de daños...) de un determinado patron.
En fins... un tema que daria para escribir hojas y hojas. Ojala estuviera por aqui mi paisano y forero Nestruo, que hizo su proyecto de fin de carrera entorno al mundo de los videojuegos y en parte se pego con las metodologias y patrones aplicados a los videojuegos.
dr_bacterio
29/10/2007, 15:56
No es lo que pides pero esta relacionado, yo actualmente me estoy leyendo un libro que explica paso a paso como crear una libreria 3D utilizando patrones de diseño para hacerla lo maximo de portable y customizable. En el futuro espero poderlo aplicar a la GP2X. Si te interesa , el titulo es:
Linux 3D graphics programming / by Norman Lin.
ISBN 1-55622-723-X (pbk.)
© 2001, Wordware Publishing, Inc.
Enga saludos :brindis:
Si lo que buscas es el modelo basico comun sobre el que se diseñan los videojuegos y sus algoritmos... pues yo te diria que buscaras por teoria de automatas mas que por patrones de software. La estructura de automata finito se repite hasta la saciedad en los videojuegos, desde el paso por menus hasta el render o la IA.
Para implementar los automatas finitos o la IA de un juego, es mejor hacerla usando el "Patron Estado", se simplifica todo, tienes cada estado separado, nada de switch enormes...
Lo primero: soy ing. electronico, osea que programando tengo alguna idea, (pero no mucha). Eso si de control de procesos, estados y demas voy guapamente.
Lo segundo: Eso de "patrones estado" tiene toda la pinta de ser un metodo proveniente del metodo de diseño de programas para automatas y armarios electricos GRAFCET.
Es un metodo de programacion simple, sencillo y que para menus, IAs y demas (deberia) funciona(r) de vicio.
PD: muy interesante el hilo!:lol:
No se si lo lei en GameDev o en Gamasutra... habia un articulo sobre la implementacion de automatas para videojuegos (nada de enormes switches), en ingles eso si, y con codigo c++, muy bien explicado. Si lo encuentro pongo el enlace.
He aqui una pequeña introduccion... (aunque el metodo no tenga mas es muy potente, he trabajado con, os lo aseguro...
Link a wikipedia (http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_GRAFCET)
A ver si os ilumina!
DMusta1ne
30/10/2007, 12:47
Me alegro mucho de que el hilo halla tenido acogida. Y dada la situación, veré si podría coger alguna asignatura sobre teoría de autómatas ya que veo que tiene una aplicación automática con la IA.
Gracias a todos :)
no se no se
Si con un grafcet vas que chutas...
no se no se
Si con un grafcet vas que chutas...
Con grafcet puedes hacer un programa para el PC?
dr_bacterio
30/10/2007, 23:08
hacerlo no, pero diseñar la estructura si ....
Puedes diseñar partes de la estructura de los menus, de la IA, incluso mas cosas ingame... solo hace falta imaginacion y pelearse con las cosas...
yo los pinitos que me estoy haciendo en fenix tienen un control de flujo de programa tipo grafcet.
Fenix es muy agredecido en este sentido, ya que funciona exactamente como un automata:
una vez en el loop ejecuta codigo interminablemente, por lo que se puede implementar dentro de un loop una estructura diseñada en grafcet, y luego traducirlo a fenix:lol:
cualquier duda me preguntais (aunque hace mas de un año que no lo uso en serio en automatas)
DMusta1ne
31/10/2007, 10:48
Le he hechado un vistazo al enlace del wiki k has puesto Jurk, y la verdad es que es un lenguaje esquemático bastante interesante, y se ve rápido su aplicación en la programación. No obstante no he podido evitar acordarme de otro lenguaje parecido (aunque su orientación no es exactamente la misma, este esta mas orientado a describir el comportamiento de un sistema digital) que estudie en la facultad ya hace unos añitos. Os invito a que le echeis un vistazo (http://www.dte.us.es/tec_inf/itig/etc2/material/ETC2_0304_sistemas2-asm.pdf) y a ver si nos os parecen realmente parecidos.
Por cierto, tambien se me ocurrió que podríamos hacer un idiom sobre Fenix, es decir. Crear patrones de diseño orientados específicamente a Fenix, precisamente para resolver esos problemas recurrentes de los que hablabamos antes: gravedad, menús, carga de partidas, caga de mapas. Podíamos empezar cada uno colgando trozos de código de como solemos implementar estas soluciones, y entre todos ver errores de opimización, abstraer la solución para que sea mas flexible, etc...¿Que os parece la idea?
Lo he mirado...
Eso es el sistema de diagramas de flujo clasico de programacion de microcontroladores y PCs. La verdad es que lo que tu propones es, la programacion en si, tal y como yo la entiendo. Doy clases de tecnicas digitales (entre otras) en una academia, y siempre digo a los alumnos lo siguiente:
"Progamar no es saber C, Pascal o ensamblador... es ordenar acciones. Lo demas es pura gramatica"
Lo que tu has propuesto no es un lenguaje de programacion, ES PROGRAMAR.
En lo que respecta al grafcet y lo que tu propones, hay una difenrecia de base:
- Grafcet es un metodo que pasa por toda el codigo cada ciclo... se repite incesantemente (ejecutando lo que tenga que ejecutar en cada momento). Reejecuta el codigo infinitamente.
- El diagrama de flujo no se repite necesariamente. Para que se repita necesita de bucles.
Por todo esto veo mas viable utlizar algo tipo grafcet en Fenix, ya que dentro de la instruccion LOOP se realizan los calculos antes de redibujar la pantalla. Y como sabreis LOOP se ejecuta infinitamente. El metodo de diagrama de flujo es mejor para lenguajes tipo C, pascal... que no reejecutan el codigo necesariamente.
Espero que se entienda toda esta chapa que os he soltado.:lol::brindis:
DMusta1ne
31/10/2007, 12:41
Desde luego tienes razón en lo que dices. Lo que si es cierto es que a mi me facilita mucho la comprension de grafcet el haber estudiado antes diagramas de flujo ya que siguen un mecanismo bastante similar. Muchas gracias por dar a descubrir esta poderosa herramienta ;)
Mmm... que estudios has cursado "Mr Megadez?":brindis:
DMusta1ne
31/10/2007, 13:31
Estoy haciendo 2º-3º de Ingeniería Técnica de Informática de Gestión en la Universidad de Sevilla.
Por lo que he estudiado ya me vale que no haya hecho ni un juego, ni una app ni na xa la gp2x, pero es que soy un tio difuso (tengo muchas aficiones entre ellas la música como melómano y como compositor/guitarrista), tambien hay que tener en cuenta de que soy muy vagooooo xD
(_=*ZaXeR*=_)
31/10/2007, 14:22
Viendo que hay gente que parece dominar el tema de los patrones de software ... me podéis recomendar un libro (o varios) y/o documentación online al respecto?
Es que estoy encallado en la asignatura de Ingeniería del Software II desde hace mucho más de lo que me hubiera gustado, y no consigo superarla :(
Un poco de ayuda sería de agradecer :D
El mejor libro que puedes buscar es el de Craig Larman no recuerdo el nombre.
El caso especifico de simular una gravedad no seria un problema de aplicar un patron u otro, sino de como implementar el determinado algoritmo dentro de los patrones elegidos para el diseño de la aplicacion. Desde el punto de vista del diseño, tener una metodologia solida es fundamental (segun el proyecto se puede usar desde XtremeProgramming u otra evolutiva hasta UP o alguno mas agil desde el punto de vista de un desarrollo siempre forzado), los patrones no son la panacea y en muchos casos acaban consiguiendo que la aplicacion sea mas pesada, algo nada bueno en aplicaciones de tiempo real "relajado" (como los videojuegos).
No es mas cierto porque no puede, los problemas que plantea no son aplicables a patrones de programacion, porque estan en un nivel de abstraccion del software superior a la implementacion (que es a lo que pertenece el tema de menus, gravedad...) Si le buscamos una semejanza, seria remotamente a los Idioms, precisamente porque se encargan de resolver temas especificos de la implementacion.
Pogramar juegos usando patrones de diseño puede ser totalmente contraproducente, es mas, la programacion de juegos usando lenguajes de POO ya lo es de por si. Es dificil sacarle el maximo rendimiendo a un hardware limitado con estas practicas de programacion. Los patrones de diseño son algo que se deben aplicar a sistemas de gestion, o aplicaciones de gran tamaño en las que un buen diseño ahorra horas de implementacion, de errores, pruebas...
DMusta1ne cuantos años llevas en la carrera?
DMusta1ne
31/10/2007, 14:36
DMusta1ne cuantos años llevas en la carrera?
Los suficientes como para que me de verguenza decirlos xDDD
Y de lo que dices sobre que lo que se propone en este hilo es mas cercano a los idioms ya lo he dicho yo. No obstante mi idea no era crear/utilizar patrones de diseño al uso, porque no es lo mismo hacer un menu en C++ que con Fenix por ejemplo. Yo lo que proponía era mas bien tomar la idea de los patrones de diseño para hacer un "idiom"( entrecomillado ) por ejemplo para Fenix, con las soluciones mas correctas tanto sintacticamente, como en aprovechamiento de la memoria y la reutilibilidad (conciliando estos recursos no funcionales ya que se sabe que los rnf se llevan mal entre ellos), de manera de que cada vez que alguien aprenda a programar en dicho lenguaje, disponga de un arsenal de código que pueda ajustar a la medida de su videojuego. No estoy hablando en absoluto de utilizar Fachadas, Decoradores etc, di por supuesto de que hablabamos de otro nivel de abstracción.
Por cierto, porque la pregunta de cuanto tiempo llevo en la carrera?
edit: Como ves no hablo de crear un idiom, sino de un arsenal de código.
Saludos
(_=*ZaXeR*=_)
31/10/2007, 14:54
Pero es que no serian siquiera Idioms, aunque se acercan a la implementacion.
Los Idioms son soluciones a la implementacion de los patrones de diseño para cada lenguaje de programacion concreto, y dado que no hay mucho patron que aplicar, tampoco puedes crear un Idiom.
Bueno tu dale saludos de mi parte a Neira, Benavides...
Los suficientes como para que me de verguenza decirlos xDDD
me siento re identificado xD.
pues yo vi teoria de automatas, y maquinas te turing bla bla, y con respecto a lo de no hacer juegos con "poo" no se.. yo como q lo veo mas facil, es mas ahora estaba haciendo un arkanoid en java ^^ (100% diseño Orientado a Objetos) en fin...
(_=*ZaXeR*=_)
31/10/2007, 23:39
Es mas facil, pero se le saca menos rendimiento a la maquina. En un PC a penas se nota, pero imaginate en una portatil.
entonces cual es el mejor paradigma de programacion para el diseño de juegos? o es una especie de combinacion?
DMusta1ne
02/11/2007, 14:34
entonces cual es el mejor paradigma de programacion para el diseño de juegos? o es una especie de combinacion?
Supongo que es mas bien que tipo de videojuego, y a que máquinas lo quieres llevar. Con un lenguaje imperativo y hardcoding esta claro que sacas mas partido a la máquina a coste de restar portabilidad. Una buena opción son las SDL, portables y sacan partido a la máquina suficiente. Con la poo est claro que pierdes velocidad. Tampoco soy un coder experto como para aconsejarte.
es q sinceramente a la hora de diseñar me parece muchisimo mas "natural" la programacion orientada a objetos, y eso q yo empeze programando de forma imperativa. si algun "coder experto" puede explicar porque se pierde mas velocidad con Poo, estaria bien q lo explique :P
Cualquier software y sobretodo los juegos se les puede aplicar patrones como los que estudiastes en esa asignatura. Hay libros y libros que hablan sobre el tema, para que veas, y si tienes interés, te pongo un link que te demostrara el interés que tiene la gente en este tema:
http://www.gamedev.net/reference/list.asp?categoryid=66
En este lugar recomiendan libros como:
http://www.gamedev.net/columns/books/bookdetails.asp?productid=468&CategoryID=17
mortimor
03/11/2007, 11:50
Por lo que yo entiendo, lo que se propone en realidad es crear un repositorio con soluciones especificas para problemas abituales en la programacion de videojuegos: menus, algoritmos de gravedad, calculo de rutas y colisiones,...
El problema radica en que ese tipo de problemas puede depender mucho de la estructura de nuestra aplicacion determinada. Creo que lo mas a lo que podria aspirarse es a conseguir una serie de ejmplos bien clasificados y documentados. Supongo que los que habeis investigado ya como crear vuestros juegos en GP2X os habreis dado cuenta de que disponer de codigo de otras personas suele ser la clave para no perder el tiempo buscando soluciones a problemas comunes.
¿Hay alguna seccion en el wiki de gp2x con este objetivo? Si no la hay deberia crearse una :)
La mayoria de problemas que mencionais aqui creo que no tienen que ver con patrones de diseño, sino más bien con un algoritmo concreto:
Una gravedad es implementar una ecuación de física de... 1ro de ESO?
Un menu hay mil formas distintas de implementar, desde la forma del menú en si, como de los distintos subniveles que va a tener, etc... No creo que exista una única forma de implementar para todos los casos de forma eficiente.
Buscar caminos cortos entre dos puntos es el famoso Algoritmo de Dijkstra o algoritmo de caminos minimos... En la wikipedia lo podeis encontrar con implementaciones en varios lenguajes.
Colisiones? Bounding box y luego pixel perfect? No tiene mucho más lio que eso...
Lo que proponeis es un recopilatorio de ejemplos de algoritmos recurrentes en la programación de videojuegos, y aunque puede ser interesante si se hace un buen trabajo, ya hay bastantes sitios de ese tipo como para echarlos de menos.
Que un lenguaje orientado a objetos de mejor o peor resultado depende de lo que se optimice el codigo y de lo bueno que sea el compilador.
Cuando estuve haciendo mi engine 3D para la GP32 las primeras versiones eran puro C, luego una fritura mixta de C,asm y C++ (un caos)... y al final solo C++ (menos el raster en asm). Realmente note la diferencia de velocidad con respecto a los algoritmos que utilice, no sobre los lenguajes. Evidentemente para optimizar el codigo de raster con textura a 7 ciclos por pixel tienes que meterte en ASM, sin embargo para el 99% del codigo el C++ es mejor. Y entre C y C++... pues la diferecia basica es que el C++ te da mas herramientas para mantener el codigo ordenado y con una estructura logica, en C, al menos yo, siempre acabo mezclando todo y asm para codificar un juego entero como que ni me lo planteo.
PD: Casos aparte son Java o .Net
PD: Casos aparte son Java o .Net
Pero en este caso el problema es q son lenguajes interpretados, y NO es un problema del paradigma de programacion (q son dos cosas muy distintas) de hecho ninguno de los dos lo respeta a rajatabla, ya me parecia muy raro/absurdo q se pierda velocidad por ver a los tipos de datos como objetos, de hecho en lenguajes como java si uno declara todo como "static" se obtiene algo muy similar a la programacion imperativa, y no creo q eso mejore el rendimiento.. o si? en fin si me equivoco q alguien me corrija entonces :brindis:
P.D creo q si hablamos de diseño de video juegos, para mi "Poo is the way to go" (por lo menos si no vas a meter mano en asm y esas cosas...)[wei2]
de hecho en lenguajes como java si uno declara todo como "static" se obtiene algo muy similar a la programacion imperativa
??? Supongo que te refieres a que "le quitas" la orientacion a objetos. Ya que el java es un lenguaje imperativo, (le tienes que decir que hacer y como se hace) como el C, C++, C#, Pascal... otra cosa son esos abortos (en mi opinion) de haskel, prolog... errr.... porras no me acuerdo de mas :D
Un consejo, hay que optimizar los algoritmos no el codigo.
Por supuesto en cosas muy concretas, como una rutina para pintar lineas si lo haces en ensamblador ganaras bastante. Pero me refiero, que hay gente que se pica mucho en hacer cosas en ensamblador, cuando el algoritmo que estan aplicando es una mierda.
??? Supongo que te refieres a que "le quitas" la orientacion a objetos. Ya que el java es un lenguaje imperativo, (le tienes que decir que hacer y como se hace) como el C, C++, C#, Pascal...
perdon, pero si no me equivoco tanto c++ como java son orientados a objetos, y pascal (si hablamos del viejo pascal) y c, son imperativos, tanto como c++ como java tiene "soporte" (por llamarle de alguna manera xD) para programar orientado a objetos.
o te refieres al hecho de q estos lenguajes son "derivados" de otros imperativos y por eso consideras la parte de objetos como un "extra" ??
Perdonar que os corrija, pero todos los lenguajes nombrados son imperativos: C, C++, Java y .NET? (C#). Solo que unos estan orientados a objetos y otros no. Por ejemplo, un lenguaje no-imperativo es PROLOG.
Otra cosa que tengo que añadir, aunque no hayais dicho en ningun momento lo contrario, es que da igual que un lenguaje de programación no este orientado objetos, se puede modular igual, solo que el codigo quedara más o menos bonito.
Perdonar que os corrija, pero todos los lenguajes nombrados son imperativos: C, C++, Java y .NET? (C#). Solo que unos estan orientados a objetos y otros no. Por ejemplo, un lenguaje no-imperativo es PROLOG.
Otra cosa que tengo que añadir, aunque no hayais dicho en ningun momento lo contrario, es que da igual que un lenguaje de programación no este orientado objetos, se puede modular igual, solo que el codigo quedara más o menos bonito.
bueno es verdad, yo solamente estaba pensando en si alguno permitia el uso o no de objetos/clases y bla bla y de los mencionados "solamente" lo hacen c++, java y .NET, a proposito hay diferencias entre "codigo modulado", y "codigo orientado a objetos", en fin volviendo al tema creo q la programacion orientada a objetos es la ideal para hacer juegos (por lo menos para alguien q no sea experto...) en fin solo un punto de vista.
... en fin volviendo al tema creo q la programacion orientada a objetos es la ideal para hacer juegos...
Eso es lo que queria decir aunque me enrolle mas de la cuenta.
Y hacer un repositorio de algoritmos ya programados para la GP2X? Por ejemplo en Fenix, etc.
Os habeis ido de mi ambito de control...
Se que me hablais en noruego, pero solo entiendo palabras sueltas de noruego...:brindis:
Vosotros a lo vuestro!!!:brindis:
(_=*ZaXeR*=_)
06/11/2007, 23:38
Pero en este caso el problema es q son lenguajes interpretados, y NO es un problema del paradigma de programacion (q son dos cosas muy distintas) de hecho ninguno de los dos lo respeta a rajatabla, ya me parecia muy raro/absurdo q se pierda velocidad por ver a los tipos de datos como objetos, de hecho en lenguajes como java si uno declara todo como "static" se obtiene algo muy similar a la programacion imperativa, y no creo q eso mejore el rendimiento.. o si? en fin si me equivoco q alguien me corrija entonces :brindis:
P.D creo q si hablamos de diseño de video juegos, para mi "Poo is the way to go" (por lo menos si no vas a meter mano en asm y esas cosas...)[wei2]
Caballero, .net es compilado. Y el problema de java no es ser interpretado (esto se puede solucionar) sino la cantidad de memoria que consume.
De seguro que halb cuando programo su engine en C++ no lo usaba plenamente como POO, en el que todo son clases con una jerarquia de herencias y una infinidad de objetos instanciados, haciendo uso de collections que son precisamente uno de los elementos vitales en una estructura orientada a objetos.
Cualquier lenguaje de programacion POO se puede usar de forma que su programa no cumpla con el paradigma de la POO.
De todas formas, si esto te parece absurdo, no hay mas que hablar, a programar se ha dicho.
Caballero, .net es compilado.
mmm seguro? entonces como logra independencia de hardware? :confused:
Y el problema de java no es ser interpretado (esto se puede solucionar) sino la cantidad de memoria que consume.
es verdad, pero el hecho de q sea interpretado tambien le resta velocidad o no?
Cualquier lenguaje de programacion POO se puede usar de forma que su programa no cumpla con el paradigma de la POO.
creo que en smaltalk NO se puede, y eiffel tampoco (de este no estoy 100% seguro).
De todas formas, si esto te parece absurdo, no hay mas que hablar, a programar se ha dicho.
hey! no te lo tomes a mal lo q dije, no era mi intencion hacerme el "superado", al contrario creo q tengo mucho de aprender de alguien como vos, simplemente posteo, para expresar mi opinion, y si esta equivocada q me corrigan, despues de todo lo mejor q tiene esto es aprender :brindis:
y con lo q habias dicho de perder eficiencia tenias razon, si uno es 100% purista se pierde eficacia (hoy me presentaron un ejemplo de esto, con el lenguaje smalltalk) aunque creo q si alguien se va a poner a "codear" no puede representar el 100% de las cosas como objetos (por lo menos no de una manera "natural") salu2!
(_=*ZaXeR*=_)
07/11/2007, 01:12
.net consigue independencia de la plataforma debido a que usa un compilador (CLR creo recordar que se llamaba) que traduce todo el codigo de cualquier lenguaje de programacion de los soportados, a un codigo intermedio (MISL o algo parecido era su nombre). Gracias a esto tambien puedes programar en VB.NET y traducir todo el codigo a Java o a C#. Desde este codigo intermedio se pasa al codigo maquina de la maquina mediante un segundo compilador que trabajo bajo demanda, es por esto que la primera vez que se ejecuta una aplicacion .net tarda mas que la segunda, dado que en esta primera ejecucion se esta compilando el codigo.
< - >
A ver, hace bastante que no uso .net, asi que por si he errado en algo, pongo una explicacion que creo es correcta 100%
El CLR es el verdadero núcleo del Framework de .NET, entorno de ejecución en el que se cargan las aplicaciones desarrolladas en los distintos lenguajes, ampliando el conjunto de servicios del sistema operativo (W2k y W2003).
La herramienta de desarrollo compila el código fuente de cualquiera de los lenguajes soportados por .NET en un código intermedio (MSIL, Microsoft Intermediate Lenguaje), similar al BYTECODE de Java. Para generar dicho código el compilador se basa en el Common Language Specification (CLS) que determina las reglas necesarias para crear ese código MSIL compatible con el CLR.
Para ejecutarse se necesita un segundo paso, un compilador JIT (Just-In-Time) es el que genera el código máquina real que se ejecuta en la plataforma del cliente.
De esta forma se consigue con .NET independencia de la plataforma hardware.
La compilación JIT la realiza el CLR a medida que el programa invoca métodos, el código ejecutable obtenido, se almacena en la memoria caché del ordenador, siendo recompilado de nuevo sólo en el caso de producirse algún cambio en el código fuente.
uff rarisimo lo q hace, pèro por lo visto termina siendo compilado. en fin no sabia! gracias por aclarar.
El comportamiento de .net y java es exactamente el mismo. Ninguno de los dos es interpretado ni compilado sino una mezcla de las dos cosas ya que al compilar se genera un código intermedio (MSIL en .net y Java bytecode en Java) que se interpreta en un programa a parte, que este si depende de la plataforma (Maquina Virtual en Java y CLR en .net).
Es decir, funcionan en .net así:
(Archivo en C#, J#, VB.net...) -> COMPILADOR -> (Fichero MSIL (este es el que se distribuye)) -> CLR(este lo tenemos instalado en nuestro ordenador dentro del .Net Framework) -> (Lenguaje máquina)
y en java:
(Arcivo java .java) -> COMPILADOR -> (Archivo java bytecode .class, este es el que se distribuye) -> MAQUINA VIRTUAL (igual que el CLR de .net) -> (Lenguaje máquina)
(_=*ZaXeR*=_)
07/11/2007, 14:12
El codigo intermedio MSIL en .net se compila a posteriori, es ejecutable. En Java, el bytecode debe ser interpretado por la JVM, no es ejecutable.
Son diferentes.
En .net hay dos compilaciones, una para traducir el codigo Java, C#, C++... a MSIL y a posteriori bajo demanda y no toda la aplicacion a la vez, es compilado a codigo nativo, mientras que en Java el bytecode es traducido a codigo nativo por el JVM.
Para poder ejecutar el lenguaje intermedio de Microsoft (MSIL), primero se debe convertir éste, mediante un compilador Just-In-Time (JIT) de .NET Framework, a código nativo, que es el código específico de la CPU que se ejecuta en la misma arquitectura de equipo que el compilador JIT. Common Language Runtime proporciona un compilador JIT para cada arquitectura de CPU compatible, por lo que los programadores pueden escribir un conjunto de MSIL que se puede compilar mediante un compilador JIT y ejecutar en equipos con diferentes arquitecturas. No obstante, el código administrado sólo se ejecutará en un determinado sistema operativo si llama a las API nativas específicas de la plataforma o a una biblioteca de clases específica de la plataforma.
http://msdn2.microsoft.com/es-es/library/ht8ecch6(VS.80).aspx
Nathrezim
07/11/2007, 14:17
Ya, pero las maquinas de java acturales, segun creo recordar, llevan una serie de optmizaciones que una vez que la primera vez que se encuentra con una instruccion la interpreta, pero las siguientes veces la ejecuta en codigo nativo, si no java seria insufriblemente lento.
(_=*ZaXeR*=_)
07/11/2007, 15:59
Ya, pero las maquinas de java acturales, segun creo recordar, llevan una serie de optmizaciones que una vez que la primera vez que se encuentra con una instruccion la interpreta, pero las siguientes veces la ejecuta en codigo nativo, si no java seria insufriblemente lento.
A ver, yo no estoy diciendo que JAVA o .NET sean lentos, de hecho no he hablado de velocidad en ningun momento aunque sea un factor de los que carezcan. Lo unico que he dicho es que es contrapoducente la POO para hacer juegos, dado que se trabaja para hardware limitado a el cual es dificil sacarle el maximo rendimiento.
El tema de JAVA y .NET no forma parte de mi argumento, es mas, lo han sacado como casos excepcionales de lenjuajes de programacion/frameworks que si son contraproducentes (puesto que la excepcion confirma la regla) para decir que la POO en general no lo es. Y ademas estos casos son excepcionales en contradiccion a lo que yo digo, porque son interpretados.
Precisamente lo que defiendo es que la mala eficiencia de la POO en los videojuegos no se debe a la lentitud, y que concretamente el caso excepcional que ellos han nombrado de .NET no es interpretado sino compilado, y tambien he dicho:
Caballero, .net es compilado. Y el problema de java no es ser interpretado (esto se puede solucionar) sino la cantidad de memoria que consume.
Con lo que resalto que el "problema" de la interpretacion del codigo es secundario.
Si quieres llevo mas al extremo que los casos excepcionales de lenguajes de programacion no validos para hacer juegos motivados por ser interpretados, no son tales, y es que creo recordar que existe un compilador por ahi de JAVA que pasa todo a codigo nativo.
En definitiva, este yo o no en lo cierto (que posiblemente tengo que estar bastante confundido porque que soy el unico que lo piensa :confused:), lo que comentas no hace mas que apoyar mi teoria. Y vuelvo a resaltar que ni yo he sacado el tema de JAVA y .NET ni los estoy comparando para defender que .NET sea mejor.
Nathrezim
07/11/2007, 16:14
En definitiva, este yo o no en lo cierto (que posiblemente tengo que estar bastante confundido porque que soy el unico que lo piensa :confused:), lo que comentas no hace mas que apoyar mi teoria. Y vuelvo a resaltar que ni yo he sacado el tema de JAVA y .NET ni los estoy comparando para defender que .NET sea mejor.
Yo no he dicho que por el hecho de usar la POO se reste rendimiento a una aplicación, solo he dicho que java no es lenguaje 100% interpretado.
Se puede llegar al mismo codigo maquina compilando una fuente POO y otra de cualquier naturaleza. De hecho la unica diferencia funcional que hay entre un lenguaje POO y otro estructurado es el polimorfismo dinámico, que no tengo ni idea de cuanto penaliza el rendimiento al usarlo.
El codigo intermedio MSIL en .net se compila a posteriori, es ejecutable. En Java, el bytecode debe ser interpretado por la JVM, no es ejecutable.
Son diferentes.
En .net hay dos compilaciones, una para traducir el codigo Java, C#, C++... a MSIL y a posteriori bajo demanda y no toda la aplicacion a la vez, es compilado a codigo nativo, mientras que en Java el bytecode es traducido a codigo nativo por el JVM.
http://msdn2.microsoft.com/es-es/library/ht8ecch6(VS.80).aspx
Y por preguntar, ya que yo no lo se ¿Cual es la diferencia de que el CLS sea el que traduce el código intermedio o que sea la JVM? No entiendo la diferencia si en los dos lo que se distribuye es un código intermedio que despues lo traduce otro programa en nuestro ordenador. ¿Te refieres a que en C# se pasa a codigo nativo antes de ejecutarse y en java se va interpretando según se va ejecutando?
Este hilo creo que no va de como compila cada lenguaje (pero que cada cual aporte lo que le de la gana, sin acritud)... yo lo unico que quise explicar es que la programacion orientada a objetos no quita rendimiento de por si, si no por entenderla mal, usar malos algoritmos o un mal compilador. La mayoria de compiladores de C++ permiten trabajar a muy bajo nivel asi que pueden exprimir el hardware sin problema (y paso de entrar en purismos de que si eso no es POO, creo que sobran)
Quiza lo del repositorio de algoritmos seria bueno (aunque ya hay muchos por ahi, ciertamente). Desarrollarlos como diagramas de flujo ayudaria mucho a entenderlos. Y aunque por ejemplo, un menu sea simple, un diagrama de flujo explicando como funciona es muy util para quien quiera aprender.
Este hilo creo que no va de como compila cada lenguaje (pero que cada cual aporte lo que le de la gana, sin acritud)... yo lo unico que quise explicar es que la programacion orientada a objetos no quita rendimiento de por si, si no por entenderla mal, usar malos algoritmos o un mal compilador. La mayoria de compiladores de C++ permiten trabajar a muy bajo nivel asi que pueden exprimir el hardware sin problema (y paso de entrar en purismos de que si eso no es POO, creo que sobran)
Quiza lo del repositorio de algoritmos seria bueno (aunque ya hay muchos por ahi, ciertamente). Desarrollarlos como diagramas de flujo ayudaria mucho a entenderlos. Y aunque por ejemplo, un menu sea simple, un diagrama de flujo explicando como funciona es muy util para quien quiera aprender.
100% agree, y de hecho (repitiendolo por decima ves ya) para DISEÑAAAAAAAAAAR, un video juego , la POO se me hace mas natural, estaria bueno (si no es mucha molestia para ti halb) q muestres un diseño por arriba de clases q usaste en tus juegos, y un pseudo algoritmo principal(algo muy por arriba), para q se den cuenta a q nos referimos con que es lo mejor para el DISEÑOOO (sin hacer incapie en la implementacion),
Bueno chico, que ya se lo que es diseño, solo hablaba de eso porque la conversación había derivado hacia eso.
En cuanto a como diseño yo los juegos siempre utilizo casi la misma estructura, una jeraquía principal en la que se representa cualquier cosa visual del juego y todas las clases heredan (con mas o menos niveles) de una clase sprite encargada de linkar con mi "motor" (o librería, porque es demasiado simple para llamarlo motor) que hace poco porté a GP2X. Despues, creo unas clases controladoras, que son las encargadas de controlar cada una una rama diferente de la jerarquía (CtrlPersonaje, CtrlGUI, CtrlEnemigos, CtrlDisparos,...) que mediante una lista enlazada (alguna no la necesitan), polimorfismo y un carro de funciones abstractas de la jerarquía controlan todos los enemigos, el nivel, los disparos y demas. Estas clases son en su mayoría singleton para tener acceso a esos datos desde cualquier parte del juego (en la IA de cada enemigo, por ejemplo).
En cuanto al flujo de la aplicación lo suelo hacer mediante una clase Aplicación (Controla el estado de la aplicación y va dando paso a lo que debe según lo que devuelvan los estados en los que se encuentra). Controla la clase Juego (encargada de todo el juego), Menu (encargada de controlar todos los aspectos del menú) y Cine (Encargada de mostrar las animaciones, hasta ahora se limita a mostrar una serie de imágenes con un texto que se va poniendo en la parte inferior).
Todo esto con un diagrama se entiende facilmente, pero la verdad, estoy perezoso hoy para ponerme :D .
(_=*ZaXeR*=_)
08/11/2007, 13:36
Yo no he dicho que por el hecho de usar la POO se reste rendimiento a una aplicación, solo he dicho que java no es lenguaje 100% interpretado.
Se puede llegar al mismo codigo maquina compilando una fuente POO y otra de cualquier naturaleza. De hecho la unica diferencia funcional que hay entre un lenguaje POO y otro estructurado es el polimorfismo dinámico, que no tengo ni idea de cuanto penaliza el rendimiento al usarlo.
Yo no he dicho que tu hayas dicho eso, solo digo que al intentar decirme que Java no es 100% interpretado, no estas diciendo nada en contra de mi postura sino todo lo contrario.
Del tema de compilacion, interpretacion... a ver no se que mas puedo decir si ya he puesto un estracto de la web de microsoft. Quiza haga mal creyendome lo que me dicen, pero segun ellos .Net se compila a medida que se va haciendo uso de los metodos, y esa compilacion queda guardada en cache como codigo nativo, y a la segunda vez que se ejecuta el metodo directamente se tira de ese compilado. De esta forma la aplicacion llega un momento en la que esta completamente compilada y no tiene ni que esperarse a nada. Creo que esta clara la diferencia con JAVA.
Sobre de si el hilo va o no acerca de como compila un lenguaje u otro, pues creo que esto no es ningun offtopic dentro del tema en cuestion. Creo que influye directamente en la adecuidad de POO o no.
Seriamente, yo no soy capaz de ver eficiente un juego diseñado con POO. Harian falta infinidad de clases e interface para hace un juego basiquisimo. Clases para los enemigos que heredarian la IA de otra clase que tendra un arbol de decisiones que seran otras clases, esas clases enemigos implementara una interfaz comun, necesidad de usar fabricas, collecciones para almacenar los enemigos instanciados, buscar dentro de la coleccion un enemigo concreto para usar sus metodos y modificarlos o eliminarlos, otras clases para renderizar, otras para capturar eventos, clases para los menus que implementen otra interface comun.... etc etc etc
Incluso usando un lenguaje de programacion orientado a objetos, se puede hacer una implementacion que daria mucho mejor rendimiento, si reducimos el problema a una clase main, otra para enemigos con un simple array donde introducirlos y otra mas para el personaje jugador. Resultado has usado un lenguaje de POO pero no has programado orientado a objetos.
Pero vosotros sabreis si lo que quereis es DISEÑAAAAAAAR, o hacer software eficiente. Yo siempre he creido que la POO era para facilitar la lavor en aplicaciones de embergadura, porque para cosas de poca chicha era contraproducente, es mas, las creia que las cosas tan ligadas a la descripcion de un comportamiento fisico carece de abstraccion no tenia sentido ni hablar de clases, porque se trata de implementar algoritmos y punto.
A mi tambien me gustaria ver el diagrama de clases de halb, porque intuyo que no es POO sino un batiburrillo que incluye alguna clase, y en caso contrario me valdria para ver cuan equivocado estoy.
Se puede usar POO para hacer juegos, si, arriba he puesto un ejemplo de como se haria, es eficiente? Yo estoy convencido de que no. Es contraproducente? Yo creo que si.
hey tranquilo, xD! en fin, si piensas q es tan mala la poo, que recomendarias vos, para alguien como DMusta1ne, que al fin y al cabo es el interesado :brindis:
Pogramar juegos usando patrones de diseño puede ser totalmente contraproducente, es mas, la programacion de juegos usando lenguajes de POO ya lo es de por si. Es dificil sacarle el maximo rendimiendo a un hardware limitado con estas practicas de programacion. Los patrones de diseño son algo que se deben aplicar a sistemas de gestion, o aplicaciones de gran tamaño en las que un buen diseño ahorra horas de implementacion, de errores, pruebas...
Eso es completamente falso, empezando por la POO.
Si has trabajado simplemente con cualquier motor, verás que se usa la POO ampliamente, y es normal, porque facilita mil veces más la estructura en un proyecto tan tocho como puede ser un videojuego.
Es falso que se le saque menos rendimiento a la máquina, lo que hay que hacer es conocer las consecuencias de las construcciones que usas, y lo que tienes que evitar.
Es una falacia muy extendida de c++, por ejemplo.
Y luego, dentro de la programación OO, pues los patrones de diseño son una ayuda más.
Fíjate cómo será que yo no descubrí los patrones de diseño en la facultad, sino por un desarrollador de videojuegos ;)
Para mi EL libro de PD es el de los autores denominados Gang of Four:
Design Patterns:Elements of reusable object-oriented software. (http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1195405480&sr=8-1)
Lo tienes traducido al español.
Pero uno que te los explica de forma muy muy muy sencilla (a veces incluso ridículamente sencilla es este (http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1195405480&sr=8-2)
Los ejemplos son en Java, y no muestra todos los patrones que trae el anterior libro pero es mucho más sencillo de leer y, sobre todo, de tener una visión de más perspectiva acerca de la utilidad de los patrones.
Los Idioms son soluciones a la implementacion de los patrones de diseño para cada lenguaje de programacion concreto, y dado que no hay mucho patron que aplicar, tampoco puedes crear un Idiom.
Los ídioms en realidad son soluciones recurrentes a una funcionalidad que no se encuentra en el lenguaje, pero que se puede implementar en él, al margen de los PD.
No necesitas usar patrones de diseño para encontrar la utilidad de los traits o policies en C++, por ejemplo, que si son idioms.
Y por último, Java tiene un compilador JIT como .NET, pero aún así Java sigue siendo más lento y ocupando más memoria que .NET (no se muy bien por qué):
Y por preguntar, ya que yo no lo se ¿Cual es la diferencia de que el CLS sea el que traduce el código intermedio o que sea la JVM? No entiendo la diferencia si en los dos lo que se distribuye es un código intermedio que despues lo traduce otro programa en nuestro ordenador. ¿Te refieres a que en C# se pasa a codigo nativo antes de ejecutarse y en java se va interpretando según se va ejecutando?
En .NET el código siempre se compila a un lenguaje llamado CIL (common intermediate language, antes conocido como MSIL), que es una especie de ensamblador genérico:
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size 11 (0xb)
.maxstack 8
IL_0000: ldstr "Hello world"
IL_0005: call void [mscorlib]System.Console::Write(string)
IL_000a: ret
} // end of method Program::Main
Luego, ese código se carga en un entorno de ejecución en el que un compilador JIT(Just In Time), traduce ese código genérico, a código nativo de la máquina
Esto todo viene especificado por el CLI (Common Language Infraestructure) y el CLR es la implementación de MS de el CLI. El CLR concretamente lo implementa haciendo que el código IL se compile a código nativo bajo demanda, aplicando incluso optimizaciones dependientes del procesador de tu máquina, por lo que en .NET y no se interpreta (que podría ser interpretado, ya que el CLI no especifica cómo ha de traducirse el código IL a nativo) Es decir, si tienes una librería de la que usas dos funciones, CUANDO LLAMES A DICHAS FUNCIONES POR PRIMERA VEZ, se compilaran a código nativo de forma transparente, y sólo esas dos funciones, no la librería entera.
En Java el proceso es casi idéntico, cambiando IL por bytecode y CLR por máquina virtual. Java también es compilado, aunque al igual que .NET puede existir implementaciones interpretadas. De hecho en Java las primeras implementaciones de la máquina virtual interpretaban el bytecode, y no lo compilaban, por lo que eran lentas de cojones.
Y por último, Java tiene un compilador JIT como .NET, pero aún así Java sigue siendo más lento y ocupando más memoria que .NET (no se muy bien por qué):
Efectivamente, las máquinas virtuales Java hace ya bastante tiempo que hacen compilación bajo demanada (Just In Time) De un modo similar a lo que hace .NET.
Y respecto a la velocidad... creo que .NET por muy multiplataforma que sea está más optimizado para funcionar en Windows (razones obvias) igual que en sus tiempos las aplicaciones Java corrían mucho mejor sobre Solaris.
Estoy pensado que seguramente una KVM si interpreta el bytecode, y por eso son tan lentos los juegos para móviles (en general)
¿Sabes algo de eso?
Estoy pensado que seguramente una KVM si interpreta el bytecode, y por eso son tan lentos los juegos para móviles (en general)
¿Sabes algo de eso?
Antes de que lo hicieran Open Source, había dos implementaciones de la KVM. La "clásica" o implementación de referencia, que era semi-abierta (la famosa licencia de Sun) y cuyo código fuente estaba disponible. Esta KVM interpretaba los bytecodes. Luego estaba la implementación HotSpot que era cerrada y bastante más cara que si tenía precompilador de código. Así que cada fabricante podía optar por una u otra.
Desde la liberación de código de Sun creo que ahora las dos versiones son abiertas (no estoy muy seguro), pero supongo que la HotSpot requiere un aparato más potente.
Dynamic, Adaptive Compiler
In general, Java virtual machines with a compiler are an order of magnitude faster than those with only an interpreter. For that reason, the CLDC HotSpot Implementation includes a dynamic compiler to provide fast bytecode execution. A well-known problem with compiling bytecodes into native instructions is that the generated code takes four to eight times as much space as the original bytecodes. Adaptive compilation alleviates this problem by only compiling methods that are recognized as “hotspots,” i.e., the most frequently used parts of the application. The CLDC HotSpot Implementation dynamic compiler finds the hotspot by running a statistical profiler. To minimize the amount of compiled code, the CLDC HotSpot Implementation virtual machine includes an
optimized interpreter used for infrequently executed methods.
Había dejado el hilo un poco de lado, pero me ha sorprendido la afirmación de que .NET es compilado O_O
Yo programo en .NET y aseguro que no lo és. Si ejecutas una aplicación .NET sin el runtime te va a petar. Y ese runtime no es más que una cosa parecida a la máquina virtual de java. De hecho, la idea de .NET es la misma que la de java.
En Java el proceso es casi idéntico, cambiando IL por bytecode y CLR por máquina virtual. Java también es compilado, aunque al igual que .NET puede existir implementaciones interpretadas. De hecho en Java las primeras implementaciones de la máquina virtual interpretaban el bytecode, y no lo compilaban, por lo que eran lentas de cojones.
Gracias por la aclaración. Eso es lo que yo creía, que basicamente actuaban igual y que basicamente son una mezcla entre interpretado y compilado, pero como por aquí me decían que no, que uno era compilado y el otro interpretado pues po eso preguntaba, por si estaba yo equivocado.
Había dejado el hilo un poco de lado, pero me ha sorprendido la afirmación de que .NET es compilado O_O
Yo programo en .NET y aseguro que no lo és. Si ejecutas una aplicación .NET sin el runtime te va a petar. Y ese runtime no es más que una cosa parecida a la máquina virtual de java. De hecho, la idea de .NET es la misma que la de java.
Pues yo también estoy programando en .NET, y te aseguro que sí es compilado. Igual que Java. Pero claro que sin el runtime no funciona, porque la compilación se ejecuta al vuelo, en el momento de la ejecución.
No es algo nuevo, la dynarec(DYNamic RECompilation) que se ve en muchos emuladores es básicamente eso si no estoy equivocado (pero mucho más jodido claro :P)
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions Inc. All rights reserved.