Mostrando entradas con la etiqueta windows. Mostrar todas las entradas
Mostrando entradas con la etiqueta windows. Mostrar todas las entradas
martes, 17 de marzo de 2015

Entrevista a Santiago Gonzalez

0 comentarios
 
Nombre: Santiago Gonzalez
Nacionalidad: Argentino
Reside en: Buenos Aires
Empresa: Independiente

¿Hace cuanto q empezaste a desarrollar videojuegos?

Hace 19 años aproximadamente, a la par de programar, también me la pasaba dibujando en 2d y 3D, por eso tengo tanta facilidad en hacer lo que ahora hago y hace 3 años, empece a desarrollar juegos en 3D, antes los hacia en qbasic, obviamente en 2d.

¿ Paralelamente a lo que haces tenés o tuviste trabajo?
Sí, trabajé casi siempre por mi cuenta, haciendo renders para arquitectos
eso mas o menos me mantiene, aunque bajo mucho estos años, por eso aposte a los juegos,
algunos de mis trabajos se encuentran en santiago3d.com.ar

¿Qué estudios tenes?
Me recibí de Técnico Naval, luego intenté estudiar arquitectura y programación, pero no dure ni un año en esas carreras.

¿Cómo aprendiste a programar y a modelar?
Todo empezó con la Commodore, mi vieja me enseño sobre los diagramas de flujo y basic. siempre me interese por lo que hacian las computadoras y se ve que me interesaba tanto que aprendí solo, probando, no había internet en esa epoca, tambien sera que le dedicaba muchas horas a la compu en esas epocas. supongo que soy autodidacta, de los que no leen los manuales.

¿A qué tecnologías apostaste para desarrollar juegos en éste último tiempo ?

Siempre fui fierrero, me gustan las PC, como toda mi experiencia en juegos, es de juegos en pc, me tire por la plataforma mas amigable que conozco, tampoco había muchas opciones para mi, intente hacer juegos en C, en Visual, en DIV, y nunca me gustó. Un dia un amigo me mostro Blitz3D, y vi que en mi caso particular, tenía mucho potencial por que podía combinar mi experiencia en 3D más los años de basic que había programado, por eso hago juegos para Windows, cuando haya plata, podré pasarlos a consolas u otros sistemas operativos, ahora el presupuesto es  $0.

¿Con qué problemas te topaste en el proceso de creación de videojuegos?

Con todos!. Primero tuve que aprender el lenguaje, cosa que me lleva casi 3 años, esto significaba encontrarte con muros cada vez que hacias algo. También me pasó que aprendía tantas cosas, que todo lo que había programado era obsoleto, asi que un proyecto lo hacía 2 o 3 veces, también fué complicado aprender a modelar y texturar adecuadamente para los juegos.
Ahora estoy dandome cuenta de que aprendi miles de cosas estos años, estoy todos los días sentado, resolviendo problemas y creando diferentes tipos de juegos para encontrar nuevos problemas y aprender a solucionarlos. Hoy por hoy veo que lo mas difícil es limar todos los detalles, y la parte de comercialización, además del tema de la plata y la falta de contactos.


¿Qué metas tenés respecto a lo que estás haciendo actualmente?

La principal meta es poder dedicarme al 100% a los videojuegos, como profesión y sustento, otras metas son:

- Saber hacer buenos juegos, como eran los que yo jugaba en los 90's, tener aceptación de los usuarios
- El año pasado, pude presentar en expoeva, y me propuse en diciembre, 1 año para poder terminar varios desarrollos, que la comunidad conozca mis proyectos, y establecer alguna estrategia para salir adelante.

el tema de las metas genera mucha presion a veces, yo hago todo solo y no cuento con dinero para invertir en esto, entonces tengo una carrera contra el tiempo, para salir adelante con todo esto. Cuando descanso de la compu los fines de semana, estoy pensando en que otros juegos puedo hacer, como podría comercializarlos, o a quién podría interesarle esto que hago, pero dejando de lado el estress que genera todo esto, veo que en unos pocos meses desarrolle muchos proyectos, y veo que la gente en los foros simpatizan con estos proyectos, también veo que solo logre mas de lo que muchas empresas hacen en un par de meses, por ej, en noviembre empece con bloody desert, y algunos ya lo comparan con juegos AAA, también recibo muchos mails de gente que me ofrece ayuda, alentando o simplemente para saludar o felicitar, entonces eso es un gran impulso para seguir adelante.

¿Algún consejo para los que quieren empezar a desarrollar videojuegos?

Sí, muchas veces veo que la gente recomienda lenguajes de programacion a los que quieren empezar, y yo creo que cada persona debe buscar el lenguaje que le sea mas comodo. Si haces algo realmente bueno, cuando lo termines, podes pasarlo a otras plataformas y muchos que recién empiezan, no logran avanzar por que no buscan un lenguaje apropiado.
Otra cosa importante, es saber inglés, saber un poco de todo, arte, gráficos, programación, comercialización y mucho sobre videojuegos.







www.indiesoft.com.ar
www.indiesoftargentina.blogspot.com
Leer entrada
martes, 10 de marzo de 2015

Competición Wiideojuegos 2015

0 comentarios
 
La competición WIIDEOJUEGOS 2010 es la primera edición de un concurso de programación financiado por la Universidad Politécnica de Madrid (UPM) y organizado por el Grupo de Investigación en Agentes Inteligentes y Computación Ubícua (AICU) con el objetivo de diseñar y desarrollar un videojuego para plataformas PC (Windows o Linux) o Mac utilizando el mando de control remoto de la consola Wii de Nintendo® (wiimote) mediante conexión bluetooth como interfaz de usuario.
Los participantes, si así lo desean, recibirán un mando wiimote con el accesorio wii motion plus y un adaptador USB de bluetooth previo pago de una fianza de 60€. Esta fianza se reembolsará al finalizar la competición tras la devolución del material entregado.
Se premiarán los videojuegos más originales y creativos que utilicen como interfaz de usuario un wiimote utilizando estándares abiertos como las librerías OpenGL o wiiuse.
Los equipos de estudiantes interesados deberán rellenar una ficha de inscripción y presentar una propuesta de videojuego según las bases de la competición.
Los estudiantes de la Escuela Universitaria de Informática que se matriculen en la asignatura de Gráficos por Computador o en la de Entornos Virtuales, con su participación en la competición tendrán convalidados los créditos prácticos de dichas asignaturas.



¿Quién puede participar?
Ante la gran cantidad de consultas respecto a quién puede participar en la competición, la organización del concurso desea aclarar que no hay ninguna limitación geográfica. El único requisito para participar es ser estudiante de grado o de posgrado.
Da igual estar estudiando una diplomatura, licenciatura, ingeniería técnica, ingeniería superior, doctorado, master, etc., etc. La universidad, instituto, academia o institución donde se realicen los estudios puede ser pública o privada. Pueden participar estudiantes de cualquier carrera: informática, telecomunicaciones, industriales, bellas artes, etc.
Pueden participar estudiantes de cualquier país, aunque no residan en España: de México, de Islandia, de China, de Australia, etc., etc. Teniendo en cuenta, eso sí, que los idiomas oficiales de la competición son el español y el inglés. Y en caso de que saliera ganador alguno de éstos, el premio sería enviado por correo postal a su lugar de residencia, sea cual sea.

La página es http://aicu.eui.upm.es/wiideojuegos/doku.php
El blog donde encontrarán información sobre el concurso http://wiideojuegos-upm.blogspot.com/
Leer entrada
sábado, 28 de mayo de 2011

Stage 3D APIs (Molehill)

0 comentarios
 
Bueno hoy nos toca hablar de lo que se viene dentro de muy poco, capaz no sea noticia nueva para algunos pero seguramente para muchos sí.



¿Que es Molehill?

Molehill es un conjunto de APIs aceleradas por hardware que van a ser integradas en ActionScript, en Adobe Flash player y en Adobe AIR. Sí como lo leen, muy pronto en vez de comprarse un need for speed seguramente lo jueguen online sin necesidad de bajarse nada!.

Integrar estas APIs van a permitir un renderizado 3D de alta gama en la plataforma Adobe Flash. Molehill esta basado en DirectX 9 en Windows y en OpenGl 1.3 en MacOs y Linux. En plataformas móviles como es Android Molehill se basará en OpenGL ES2. Técnicamente las APIs de Molehill son verdaderamente 3D, programables por GPU y basadas en shaders, y expondrá características que los desarrolladores de Flash siempre desearon y nunca pudieron obtener (hasta ahora), como vértices programables y fragment shaders, con los que se pueden realizar o habilitar diferentes técnicas como, vertex skinning, para la animación de los huesos, así como también z-buffering nativo, stencil color buffering, cubo de texturas, y más.

En terminos de performance, Adobe Flash Player 10.1 (el actual), renderiza miles de triángulos, éstos no son z-buffered,  aproximadamente a 30Hz.Con las nuevas APIs 3D, los desarrolladores pueden esperar cientos de miles de triángulos a ser renderizados en una resolución de alta definición (HD), en pantalla completa a unos 60Hz. Molehill hará esto posible para entregar una experiencia 3D sofisticada a través de casi todas las computadoras y dispositivos conectados a internet. Al final de éste artículo se pueden observar los videos de aplicaciones hechas con Molehill, los cuales nos dan una dimensión de lo que estamos hablando.

¿Cómo funciona Molehill?

Hasta acá nos podemos dar una idea de que es Molehill pero, ¿cómo funciona exactamente?.
Las APIs existentes de 2.5D de Flash Player que se introdujeron en Flash 10, no estan en desuso como muchos piensan. Molehill las aprovechará para ofrecer una solución al renderizado 3D avanzado que requieren una aceleración de GPU completa. Dependiendo del proyecto a realizar el usuario eligirá el API a utilizar.

Recientemente se ha introducido el concepto de "Stage Video" en Flash Player 10.2 disponible en su versión beta en Adobe Labs.
El Stage Video se basa en el mismo diseño, permitiendo una aceleración completa del hardware para el video, desde la codificación hasta la presentación.Con este nuevo modelo de rendering, Adobe Flash Player no presenta los frames de video o el buffer 3D dentro del display list, pero sí los presenta en una textura situada detrás del escenario pintada por el GPU. Esto permite a Adobe Flash Player pintar directamente en la pantalla, el contenido que se encuentra en la memoria de la placa de video. Ya no va a ser necesario volver a leer, cada vez que se quiera traer frames desde el GPU para ubicarlos en la pantalla a través del display list del CPU.

Como resultado, porque el contenido 3D se sitúa detras del escenario o del stage de Flash player y éste no forma parte del display list, los objetos Context3D y Stage3D no son display objects u objetos que se puedan visualizar en otras palabras. Por lo tanto hay que recordar que no se puede interactuar con ellos como cualquier DisplayObject, las rotaciones, los blend modes, los filtros y muchos efectos no pueden ser aplicados.

La siguiente figura ilustra la idea


Por supuesto, como se puede observar, el contenido 2D puede superponerse con el contenido 3D sin problenas, pero lo contrario no es posible. Sin embargo se proporcionará una API que va a permitir plasmar el contenido 3D en un bitmap si es necesario. Desde el punto de vista de las APIs de ActionScript, el desarrollador interactua con dos objetos principales, los objetos Stage3D y Context3D. Con esto solicita a Adobe Flash Player un contexto 3D y un objeto Context3D que será automaticamente creado al indicarselo.

Pero muchos se preguntarán ¿Qué pasa si mi tarjeta de video es incompatible? ¿Obtendré una pantalla negra sin poder visualizar nada?. Flash Player aún retornara un objeto Context3D, usando un sistema de respaldo de software internamente por lo que todavía se tendrán todas las características de Molehill y de las APIs pero ejecutandose en el CPU. Para lograr esto se cuenta con un muy rapido rasterizer de CPU de TransGaming Inc. llamada “SwiftShader”. La buena noticia es que incluso cuando se ejecuta en software, SwiftShaderes 10 veces más rápido que el rasterizer de vectores disponible en Flash Player 10.1, por lo que se espera un rendimiento importante incluso cuando se ejecuta en modo software.

La belleza de las APIs de "Molehill" reside en que no hay que preocuparse por lo que está pasando internamente. ¿Estoy trabajando bajo DirectX, OpenGL o SwiftShader?, ¿Debería usar una API diferente para OpenGL cuando estoy en MacOS y Linux u OpenGl ES 2 cuando estoy en una plataforma para móviles?. No, todo es transparente para el desarrollador. El desarrollador programa usando una sola API y Flash Player se encargará de hacer ésto por él internamente y de hacer la traducción detrás de la escena.

Es importante recordar, que las APIs de "Molehill" no usan lo que se llama una función fija de pipeline, sino que usan una función programable de pipeline, lo que significa que el desarrollador deberá trabajar con vértices y fragmentos de shaders para mostrar algo en pantalla. Para ésto, se podrá cargar, en la tarjeta gráfica, los shaders puros y de bajo nivel AGAL  (“Adobe Graphics Assembly Language”) bytecode como Bytearray. Como desarrolador se tienen dos maneras de hacer esto, escribir los shaders en ensamblador, lo que requiere un avanzado conocimiento de como trabajan los shaders, o de como usan un lenguaje de alto nivel como Pixel Bender 3D, el cual expondrá una forma más natural para programar los shaders y compilar el bytecode AGAL apropiado.

Para representar triángulos, se necesita trabajar con los objetos VertexBuffer3D e IndexBuffer3D pasando coordenadas de vértices y de índices, y una vez que los vertex shaders (los vértices de los shaders) y los fragments shaders (los fragmentos de los shaders) estén listos, se podrán subir o cargar en la tarjeta gráfica a través de un objeto Program3D. Basicamente un vertex shader se encarga de la posición de los vértices utilizados para dibujar los triángulos mientras que un fragment shader maneja el aspecto de los píxeles utilizados para dar textura a los triángulos.

La siguiente figura ilustra la diferencia entre los tipos de shaders:



Más explicitamente al hacer un programa en donde utilizamos lo explicado anteriormente al crear shaders podemos llegar a algo como ésto:

La idea de éste artículo no es meternos en la programación de Molehill pero si alguno esta interesado en como programar este tipo de cosas puede encontrar un poco de código acá: http://www.bytearray.org/?p=2555 (aclaro que está en inglés).

Entonces, ya se ha hablado de los objetos que se pueden utilizar en Molehill como ser Stage3D, Program3D, Texture3D, etc. Veamos un gráfico para tener una idea más clara de como está establecido esto jerárquicamente y como interaccionan entre los objetos:


Como se puede observar, las APIs de Molehill son de muy bajo nivel y exponen características avanzadas para los desarrolladores que quieran trabajar con 3D. Por supuesto, algunos desarrolladores preferirán trabajar con frameworks de alto nivel, los cuales exponen APIs listas para usar. Adobe se encargará de eso, también.

Construyendo montañas con Molehill

Muchos desarrolladores de ActionScript 3 perferirían trabajar con una luz, una cámara y un plano en vez de con un vertex buffer y shaders bytecode. Así que para asegurarse de que todos puedan disfrutar del poder de Molehill, se está trabajando activamente con frameworks 3D tales como Alternativa3D, Flare3D, Away3D, Minko, Sophie3D, Yogurt3D y más. Hoy en día la mayoría de estos frameworks tienen implementado Molehill y estarán disponibles cuando Molehill esté diponible en una próxima versión de Adobe Flash runtimes.


La mayoría de los desarrolladores de éstos frameworks estuvieron en Max, ya por el 2010, presentando sesiones de como implementan Molehill con sus respectivos marcos.
Se espera que los desarrolladores construyan sus motores basandose en Molehill, por lo que, tanto los desarrolladores 3D avanzados, así también como aquellos que no desarrollan o no saben desarrollar en 3D, se beneficiarán con Molehill.



Algunos videos de demos que se desarrollaron con la version Beta de Molehill:








Fuente: ActionScript Experiment
Leer entrada
miércoles, 14 de julio de 2010

Porque Direct3D > OpenGL? otras 10 razones

0 comentarios
 
Ya que estamos en la polemica... hay que hacer lo opuesto tambien!

1) Direct3D viene con Windows,

OpenGL viene con el driver. A las versiones de los drivers de OpenGL que vienen con windows, se les saca el soporte de OpenGL a proposito.
En la practica esto no afecta tanto, ya que en USA, Europa, etc casi todas las PCs son de marca, y los OEM les instalan los ultimos drivers
disponibles. Pero en el "tercer mundo" no es tan asi..

2) OpenGL 2.0 No esta disponible en Intel GMA.

Intel no provee soporte de OpenGL 2.0 en sus drivers de Windows (pero si soporte de Directx9c). Solo llega hasta GL 1.4.
En Mac, intel SI provee soporte de GL2, y el driver semioficial/opensource de X11 (Linux) tambien lo soporta, asi que el hardware no es el problema. Probablemente una decision politica de parte de Intel, o algun arreglo con Microsoft. Esto es un problema importante, dado que todas las notebooks y PCs OEM que vienen con procesadores Intel, vienen con GMA.

3) OpenGL >1.1 no viene con Visual Studio.

Microsoft no provee practicamente soporte para OpenGL, todo en windows se hace con extensiones. Por suerte existe GLEW, pero no se actualiza tan seguido. DirectX viene con el DXSDK.

4) Direct3D implementa los nuevos features primero.

El orden usualmente es
a) Direct3D saca una nueva especificacion
b) NVidia/ATI implementan hardware
c) OpenGL hace su version

Aunque en esta ultima iteracion, OpenGL 4 se adelanto a nvidia, pero nunca se sabe..

5) Direct3D define muy bien lo que soporta el hardware

En teoria OpenGL tambien, mediante extensiones, pero en la practica, Nvidia implementa muchos mas fetures en OpenGL
de lo que la placa soporta, y los emula por software, lo que lo hace inusable, y bastante complicado de adivinar que feature
no usar en que placa, para evitar que todo vaya a 1fps.

6) Direct3D compila los shaders siempre igual.

Si el shader compila en Nvidia, va a compilar en ATI. En OpenGL se supone que es lo mismo, pero ATi se queja de mas cosas que Nvidia, lo cual hace bastante dificil escribir shaders que compilen en todas las plataformas.

7) Direct3D9 soporta instancing, OpenGL no.

El hardware SM3 en Direct3D9 soporta instancing, en OpenGL no. Si bien multiples llamadas a glDrawElements/Arrays son baratas en OpenGL, se empieza a volver costoso pasando los miles de elementos, (ej: al dibujar pasto).

8) Direct3D9 viene con muchisimos ejemplos oficiales.

La calidad de la documentacion de D3D y GL es bastante debatible, pero lo cierto es que D3D esta lleno de ejempos que vienen con el SDK, y con licencias permisivas. Si bien en GL hay bastante, encontrar en internet es mas complicado. En D3D es mas comodo y se pierde menos tiempo. En general la mayoria de los papers de game developes son en D3D, y la mayoria de los papers cientificos son en GL.

9) Direct3D viene con mas herramientas para debugear Direct3D

PIX, mejor soporte de FX composer, D3DDebug, etc.

10) Direct3D Impulsa a la industria

Gracias a que Microsoft impulsa a la industria con D3D e impone el ritmo,
sigue saliendo nuevo hardware e Intel/ATI/NVidia se ponen de acuerdo.
Cuando OpenGL era el estandar, cada placa tenia sus propias extensiones
que no estaban soportadas en las demas, haciendo programar juegos mas complejo.
(Ej, ATI truform, Nvidia con Combine4, etc).

Fuente: http://www.adva.com.ar/foro/index.php?topic=7006.0
Leer entrada
miércoles, 30 de junio de 2010

Porque OpenGL > Direct3D? 10 razones.

0 comentarios
 
El Sr. Engine ha recorrido un larguisimo camino, y la verdad es que finalmente se empieza a sentir que falta poco.
Aca hay una escena de prueba en progreso (todavia no esta terminada), lo mejor de todo es que por como esta programado, y gracias a hacks que solo se pueden hacer en OpenGL (no en Direct3D) esto corre de forma safable hasta en una geforce 6100.



No hay nada precomputado (lightmaps/ambientmaps/etc), todo es en tiempo real.
En gran parte, gracias a OpenGL. Porque?
Primero a todo cabe recordar que estoy refiriendome a GL 2.1 vs Directx9 (D3D10 y GL3 son casi identicos), pero si uno quiere hacer algo que corra en todas las computadoras, no se puede usar Directx10 o GL3 de cualquier forma Lengua

1) Batching

Las llamadas a funciones de GL son infinitamente mas baratas que en D3D, primero por no tener que usar objetos sino porque los comandos se batchean en userspace y luego se envian al driver. (en Direct3D casi todo va directo al driver). Esto permite hacer cambios de materiales/shaders/binder arrays/etc con bajo costo.

2) Built-in uniforms

OpenGL 2.1 tiene todo el estado del fixed pipeline accesible, todas las luces, materiales, etc. Esto permite, con un poco de esfuerzo, no usar uniforms y crear shaders extremadamente chiquitos, maximizando la posibilidad de usar conditonal compilation, ya que el estado es persistente aun al cambiar entre shaders (algo asi como bindable uniforms en placas antiquisimas), y el cambio entre shaders es casi gratis (gracias al batching y a que no hay que subir uniforms), se pueden dibujar ej, multiples luces en un pase y cambiar entre combinaciones de luces a una performance enorme.


3) Fast/deferred shader compiles

La compilacion de shaders en OpengL es rapidisima. Sencillamente rapidisma. Principalmente porque el compilador solo pasea el codigo y luego
hace el resto de la compilacion on-demand (cuando el shader se usa). Se puede compilar cientos de shaders en pocos segundos.
En D3D, la compilacion comparativamente es mas lenta ya que hay varios pasos: a) Compilacion a assembler (D3DX) b) Subir el assembler c) El assembler de D3DX decompilado por el driver y recompilado optimizado para la placa (ya que los video card vendors optimizan cada uno para su placa). En la teoria, D3D permite guardar shaders precompilados, lo que agiliza el proceso, pero en la practica, este ultimo paso hace que no sea demasiada la diferencia.

4) Persistent attributes/texcoords

Los texcoords y los attributes son persistentes. Esto quiere decir que siempre estan aunque no se bindeen (el ultimo valor queda puesto). En contraste, Direct3D9 prohibe crear shaders que usan un texcoord/ que no esta bindeado en el streamsource. Sencillamente el shader no funciona.
Esto es horrible, porque no permite a un engine tener una separacion entre geometria y material sin tener que compilar una version del shader que use los mismos arrays que tiene la geometria.

5) Readable/Writable Depth Buffer

Los depth buffers se pueden bindear como textura y leer en OpenGL, y no solo eso sino que se filtran aun en el hardware mas viejo (siempre y cuando sean potencia de 2!). Que permite esto? hacer muchisimas cosas en hardware viejo que nada mas se puede hacer en Directx10, vista+, como por ejemplo


  • Recuperar la posicion de un fragment




  • Shadow maps super baratos (solo escribir a un depth buffer), mas baratos aun usando un depth buffer de 16 bits




  • ESM (Exponential Shadow Maps) baratisimos en hardware antiquisimo, aprovechando que se pueden leer/escribir usando gl_FragDepth para blurear, y filtrar




  • ZClipping de particulas, con borders fadeados




  • SSAO superbarato (lee del depth buffer / escribi al shadow buffer)




  • DOF superbarato





  • 6) read/write buffers y CopyTexSubImage

    Algunas tecnicas requieren hacer copias de buffers. GL provee read/write buffers, para hacer esto sin tener que usar shaders/geometria, lo cual tambien es considerablemente mas rapido.
    GL Permite habilitar/deshabilitar la escritura a diferentes componentes de un framebuffer. Esto esta _buenisimo_, por ejemplo para guardar datos en componentes en diferentes pases. Tecnicas que me resultaron barbaras usado esto fueron glow send en el canal alpha (y bloquearlo cuando se dibujan objetos con transparencia) y especialmente util para tecnicas como dual paraboloid shadow mapping o PSSM, porque puedo guardar los datos (depth) en una sola textura si quiero, ayudar un monton al cache y liberar texunits.

    8) Built-in TC

    En Direct3D existen formatos comprimidos de textura, pero hay que subir los datos a mano comprimidos, o tenerlos ya guardados. Si bien se esta poniendo de moda en DirectX10 hacer la compresion a DXT,BC,etc en un shader en el momento de subir la textura. OpenGL hace la conversion automaticamente (al pedirselo) aun en placas antiguas.

    9) Built-in memory Management

    En Direct3D hay diferetes tipos de memoria (pools) a donde van los arrays, las texturas, etc. Cada uno tiene diferentes restricciones. Si uno elige enviarlo a la memoria de video, entonces la textura o el array no se pueden recuperar.. y si llega a ocurrir un devicelost (que sucede tan solo al resizear una ventana Cheesy), se pierde todo! Algunos engines manejan todo a mano, pero la verdad es que es un bajon tener que preocuparse donde esta cada cosa, asi que Direct3D ofrece una opcion MANAGED, que guarda una copia en memoria de sistema del recurso. Si alguna vez se preguntaron porque los juegos de D3D ocupan tanta memoria, esa es la respuesta . Windows Vista virtualiza la memoria de video para evitar eso cuando el hardware lo provee. OpenGL en cambio sube y baja los recursos de memoria de video cuando es necesario y hasta provee algoritmos de LRU en hardware antiguo, el programador no se tiene que preocupar donde va todo, o a lo sumo proveer hints de uso.

    10) OpenGL es un estandar 

    OpenGL es un estandar, se puede programar/ejecutar en linux, windows, mac, celulares, tabletas, etc.

    Fuente: http://www.adva.com.ar/foro/index.php?topic=7005.0
    Leer entrada
    martes, 4 de mayo de 2010

    Tutorial Xna (Introducción) por Argade

    0 comentarios
     
    Bueno gente les comento primero que nada que en este momento del blog voy a empezar a hacer un tutorial en español desde 0 para poder programar en Xna, asi que seguramente voy a tardar un poco mas en hacer los post y dejando de lado un poco las noticias, asi que si hay algun bondadoso que tenga ganas de ofrecerse para postear alguna que otra noticia en el blog, bienvenido sea.
    Bien empecemos por lo basico
    ¿Qué es Xna?
    XNA es una API desarrollada por Microsoft para el desarrollo de videojuegos para las plataformas Xbox 360 , Windows y Zune.
    ¿Qué es una API?
    Según las siglas significa "interfaz de programación de aplicaciones". Una interfaz de programación representa una interfaz de comunicación entre componentes de software. Osea en definitiva una API es un conjunto de "llamadas" a ciertas bibliotecas. Y ¿Para qué me sirve una API?, bueno básicamente en esas bibliotecas a las cuales llamamos existen funciones que nos facilitan mucho las cosas, por ejemplo necesitamos iniciar el modo de video de la placa, sin una API tendríamos que estar usando ensamblador para llamar a interrupciones de video para poder iniciar el modo de video.
    En definitiva algo asi:

    #include  getch(), clrscr()
    #include  MK_FP, geninterrupt()
    #include memset()
    unsigned char *pantalla = (unsigned char *) MK_FP(0xA000, 0);
    void SetMCGA()
    {
    _AX = 0x0013;
    geninterrupt (0x10);
    }
    void SetText()
    {
    _AX = 0x0003;
    geninterrupt (0x10);
    }

    Si tuvieramos una API que llame a una biblioteca que tenga la función esta definida, seguramente haríamos algo asi:

    InicializarVideo(Resolucion)

    Conclusión resumimos 14 líneas en 1 sola.Tal vez no sea tan complicado inicializar el modo de video, pero si tendríamos que cargar modelos y texturas 3D podrían ser muchisimas líneas resumidas en una sola o en un par en su defecto.

    Como ibamos explicando Xna técnicamente es un Marco de Trabajo (Framework), basado en .NET Framework 2.0 y al igual el .NET Framework 2.0, éste corre sobre el CLR, aunque en una implementación que provee un manejo optimizado para la ejecución de videojuegos.
    Resumidamente y muy por encima un Framework es un entorno de trabajo que nos reune todas las funciones que llaman a las bibliotecas para poder programar más comodamente en lo que tengamos que hacer.
     Hasta acá todo muy lindo pero muchos se preguntarán que es el CLR, bién El Common Language Runtime o CLR (Lenguaje común en tiempo de ejecución) es el componente de máquina virtual de la plataforma .Net de Microsoft.  Es la implementación del estándar Common Language Infrastructure (CLI) que define un ambiente de ejecución para los codigos de los programas. El CLR ejecuta una forma de código intermedio (bytecode) llamada Common Intermediate Language (CIL, anteriormente conocido como MSIL -- Microsoft Intermediate Language), la implementación de Microsoft del CLI.
    Los desarrolladores que usan CLR escriben el código en un lenguaje como C# o VB.Net. En tiempo de compilación, un compilador.NET convierte el código a MSIL (Microsoft Intermediate Language). En tiempo de ejecución, el compilador en tiempo de ejecución (Just-in-time compiler) del CLR convierte el código MSIL en código nativo para el sistema operativo. Alternativamente, el código MSIL es compilado a código nativo en un proceso separado anterior a la ejecución. Esto acelera las posteriores ejecuciones del software debido a que la compilación de MSIL a nativo ya no es necesaria.
    Para que se vea un poco mejor entonces lo que se hace es lo siguiente: Nosotros tenemos nuestro código en un lenguaje como C#, VB.NET o cualquier otro lenguaje .NET, cuando le damos play, para que ejecute el código de fuente, el programa se compila, al compilar el programa se convierte el código en C# o en el lenguaje que lo hayamos hecho en un lenguaje intermedio entre el C# o el lenguaje que hayamos utilizado y el código de máquina o código nativo, luego mientras se ejecuta el código de fuente (osea el programa ya compilo y está corriendo), se convierte lo que quedo en el lenguaje intermedio al lenguaje nativo "en tiempo de ejecución".


    Hasta acá vamos bien, entonces el funcionamiento de todo el sistema seria

    Capas de XNA - Las diferentes capas de XNA, vistas de arriba a abajo, el XNA game studio utiliza la  funcionalidad del xna framework, y éste a su vez se basa en el .net framework. Por último están las  plataformas a las que van destinadas nuestras aplicaciones, windows, Xbox 360 o zune.


    En otras palabras, XNA es una plataforma de desarrollo de videojuegos sobre DirectX, en la cual disponemos de cierta funcionalidad ya integrada lo que nos permite centrarnos en la parte de qué queremos hacer en nuestro juego y no en el cómo hacerlo.
    Para verlo gráficamente:


    Framework de XNA - Los recuadros verdes se corresponde con la funcionalidad que ya viene de "serie" con el framework.

    Bueno en este momento ya tendríamos una idea de que es XNA y de como funciona, en el próximo Capítulo vamos a ver lo que necesitamos instalar para poder comenzar con la acción.
    Leer entrada