Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'OpenGL'.

  • Buscar Por Etiquetas

    Añade etiquetas separadas por comas.
  • Buscar Por Autor

Tipo de Contenido


Foros

  • Contacto con el staff
    • Novedades / Anuncios del foro
    • Sugerencias
    • Problemas relacionados con el foro
  • Zona general de charla
    • Presentaciones
    • Charla
    • Zona de Humor, Curiosidades y Otros
    • Mascotas Vagos
    • Noticias del Mundo
    • Tecnología
    • Ayuda y consultas de carácter general
  • Zona GNU/Linux
    • Ayuda, consultas y soporte GNU/Linux
    • Distribuciones GNU/Linux
    • Repositorios. Software GNU/Linux
    • Personalización
    • Raspberry Pi
    • Arduino
    • Manuales / Tutoriales / Guías GNU/Linux
    • Programación
    • Noticias GNU/Linux
    • Hablando de GNU/Linux
  • Zona Gaming
    • Juegos GNU/Linux
    • Noticias Gamer
    • Charla Gamer
  • Zona Móvil
    • Ayuda y soporte para dispositivos móviles
    • Apps Móviles
    • Manuales / Tutoriales / Guías Móviles
    • Roms para dispositivos Móviles
    • Noticias sobre dispositivos Móviles
    • Hablando sobre dispositivos Móviles
  • Zona Mozilla
    • Ayuda, consultas y soporte Mozilla
    • Aplicaciones Mozilla
    • Roms Firefox OS
    • Manuales / Tutoriales / Guías Mozilla
    • Noticias Mozilla
    • Hablando de Mozilla
  • Microsoft
    • Papelera del Foro

Encontrar resultados en...

Encontrar resutados que...


Fecha de Creación

  • Start

    Fin


Última Actualización

  • Start

    Fin


Filtrar por numero de...

Joined

  • Start

    Fin


Grupo


Página Web


Diaspora


Pump


GNU Social


Google +


Twitter


Facebook


Xmpp


Skype


Steam


Desura


MediaGoblin


Youtube


Vimeo


Picasa


Flickr


Email


Lugar


Intereses

Encontramos 41 resultados

  1. Shiba87

    GDC 2017

    Ya tenemos disponibles los vídeos de las conferencias la Game Developers' Conference 2017, que se celebró desde el de 27 Febrero hasta el 3 de Marzo en la ciudad norteamericana de San Francisco y en la que Vulkan, la nueva API gráfica del grupo Khronos, fue una de las protagonistas principales, así como también la realidad virtual, que parece estar en boca de todos estos días. Entre las novedades de la conferencia pudimos conocer las nuevas extensiones y el progreso de Vulkan, la versión 2.0 de WebGL, OpenXR el estandar para realidad virtual WebGL, WebVR y gITF Desarrollo de realidad virtual multiplataforma Desarrollo de juegos para móviles con Vulkan Vulkan en el escritorio. Profundizando Unificación de Vulkan. Pasado, presente y planes de futuro https://www.khronos.org/news/press/khronos-reveals-api-updates-new-workgroups-at-gdc
  2. Croteam, el estudio Ruso tras la saga Serious Sam o el galardonado The Talos Principle, ha seguido los pasos de otros estudios, liberando el código fuente de Serious Engine. Si bien no se trata de la última versión de su motor gráfico, sino de la que se utilizó para Serious Sam: The First Encounter y Serious Sam: The Second Encountermás, es un primer paso hacia iniciativas de desarrollo más abierto, como el actual enfoque de Epic Games o lo que en su día quiso hacer ID antes de ser desmantelado por Bethesda. Esto sin duda resultará muy interesante para desarrolladores de juegos Indie, que ahora tienen una alternativa más a la hora de crear algún proyecto, aunque no demasiado ambicioso a nivel gráfico, o simplemente para todos aquellos que sientan curiosidad y quieran echarle un vistazo o, simplemente, experimentar un poco. Puede encontrarse en GitHub bajo Licencia GPLv2 https://github.com/Croteam-official/Serious-Engine http://www.croteam.com/serious-sam-source-code-released/
  3. Hace tiempo hice algo parecido, pero no tan exhaustivo, ya que por aquel entonces el panorama no se acercaba ni remotamente a lo que tenemos ahora e lo que se refiere a rendimiento gráfico y videojuegos. El propio Martin Gräßlin ya propuso un sistema para mover las aplicaciones que demandan un alto rendimiento gráfico fuera del servidor gráfico donde se encuentra corriendo el entorno de escritorio para evitar la sobrecarga y el consumo extra de recursos que supone tener corriendo un escritorio debajo de la aplicación que estamos ejecutando. Especialmente si se trata de un videojuego a pantalla completa. Interactuando directamente con libuniput y el servidor gráfico, sin compositores u otros intermediarios del entorno de escritorio, mejoraríamos, en teoría, el rendimiento y evitaríamos una serie de problemas típicos de los compositores y gestores de ventanas. Nvidia, por su parte, ha ido aún más allá y ya tienen un sistema que permite, gracias a EGL, renderizar contenido gráfico OpenGL (y suponemos que Vulkan también) no sólo sin entorno, sino prescindiendo también del entorno gráfico. Esto abre un mundo de posibilidades y podría ser la clave para la futura migración de X11 a Wayland, además de suponer un antes y un después para grandes servidores y granjas de equipos que se utilizan para renderizar gran cantidad de datos 3D. Aunque en nuestro caso no vamos tan lejos, sí que resulta un tema muy interesante de cara al día a día. Es lógico que el entorno gráfico tenga cierto impacto en el rendimiento, no es ninguna novedad, especialmente ahora que muchos exigen sí o sí contar con aceleración gráfica únicamente para mostrar las ventanas. Las preguntas que nos haríamos en este punto serían ¿Cuánto?¿Qué diferencia existe entre los diferentes entornos disponibles? Pero sobre todo ¿Prescindir de entorno gráfico es realmente una opción que realmente compensa a la hora de jugar a cualquier videojuego? Me encantaría contar con más medios y hardware para poner a prueba la teoría, pero tendremos que conformarnos con mi actual equipo, que ya tiene unos cuantos años a sus espaldas, pero que aún le queda guerra que dar Por supuesto las pruebas se harán sobre Debian ¿Dónde si no? Y si no me muero en el intento, habrán 7 contendientes: Enlightenment 0.20.3, Cinnamon 2.2.16, Mate 1.8.1, Xfce 4.12.1, Gnome 3.14, KDE 5.4.3 y el séptimo adversario a batir será nuestro veterano servidor X11 corriendo a pelo Las pruebas a superar, como no podía ser de otra manera, son puramente gamer y bastante exigentes, especialmente para mi GTX 560 Ti que ya empieza a mirarme mal He intentado que fueran lo más variadas posibles, aunque dadas las limitaciones y ciertos problemas que han aparecido durante el proceso, no puedo jactarme de ofrecer una fiabilidad mínimamente aceptable, aunque sí una buena muestra que nos pueda poner al tanto de un par de cosas Equipo de pruebas Tests GPU Test Creo que con el nombre de este Test basta para saber de qué se trata. GPUTest se compone de un gran número de tests OpenGL que cubren un amplio espectro en lo que se refiere a probar las capacidades de nuestra GPU GiMark Plot3D FurMark TessMark Triangle Pixmark Piano Pixmark Volplosion Resumen El resumen no deja lugar a dudas, sin entorno gráfico gozamos de cierta ventaja a la hora de renderizar contenido. Cinnamon por su parte, no ha salido muy bien parado de este GPUTest, siendo el entorno que ha quedado último en 6 de las 7 pruebas. Para el resto de entornos los resultados son más variados y sin mucho que destacar. Unigine Valley El motor gráfico Unigine Engine es un clásico entre las pruebas de rendimiento gráfico y, a la espera de la inminente llegada de los nuevos Benchmarks Unigine 2.0, tendremos que conformarnos con dar unas cuentas vueltas por el Valle virtual creado por los rusos. Se repite la misma situación que en el caso anterior, con Cinnamon en la cola, aunque esta vez KDE también se nos ha desinflado un poco. Por supuesto, al correr el Benchmark sin entorno gráfico tenemos un extra aunque esta vez es mínimo. Hay que tener en cuenta que la capacidad del hardware de prueba es limitado, los valores que arroja son relativamente bajos y, probablemente, con un equipo que pudiera correr el test de manera más holgada obtendríamos mayores diferencias Metro Last Light Redux En un primer momento quería incluir un mayor número de juegos reales y recientes, pero finalmente me he decantado por el último título de 4A Games, principalmente por la facilidad que ofrece a la hora de realizar pruebas con él. Este test ha puesto las cosas del revés. Xfce ha arrebatado a Cinnamon el título del más lento, aunque no por mucho, y observamos un desplome importante en la prueba realizada sin entorno gráfico. Podríamos estar ante la excepción que confirma la regla, pero la explicación es algo más sencilla. Nos encontramos ante el primer problema a la hora de realizar los test. En este caso, para poder realizar la prueba de Metro Last Light Redux, era necesaria la intervención del Cliente de Steam, que corría en segundo plano cuando se ejecutaba desde un entorno gráfico, pero que al lanzarlo directamente sobre las Xs, el la ventana de Steam se ha interpuesto, colocándose delante de las imágenes de prueba y saboteando así el resultado final. Unreal Engine 4 Matinee No podía faltar la mayor creación de Epic Games. Los demos de UE4 son de sobra conocidos y en este caso me he decantado por la espectacular escena de lucha Matinee para poner en apuros a mi tarjeta gráfica Este test es, sin lugar a dudas, el más extraño de todos, poniendo todo patas arriba y, en esta ocasión, sin ninguna excusa por mi parte. Es muy curioso ver a Gnome y KDE disputándose los puestos de cabeza con Mate, mientras que Enlightenment, que hasta ahora había estado siempre arriba, pierde algo de fuelle. Una vez más, Xfce nos deja un sabor amargo quedando otra vez por detrás de Cinnamon. Por último, de las siete pruebas, la que se ha realizado sin entorno gráfico ha quedado justo a la mitad, dejándome sin saber qué pensar. Aunque si observamos de cerca la línea de tiempo vemos que los resultados han sido muy irregulares con picos y valles muy acusados (o inverosímiles como en el caso de Cinnamon), con mínimas y máximas exageradas. Lo único que podría sacar en claro de este test es que, dada su "inestabilidad", se trata de una prueba que no nos permite sacar ninguna conclusión clara acerca del rendimiento. Pejiguero que es uno, cuando ya casi había hecho limpieza de toda la basura que he tenido que meter para hacer los test, he tenido una idea feliz Me he puesto a probar de nuevo con UE4 y he descubierto algo que también es muy interesante. El perfil de phoronix test suite para los demos de Unreal Engine no incluye ninguna opción adicional, sólo la ejecución básica. Eso significa que cuando he realizado los test, matinee se estuvo ejecutando de la manera más "conservadora" posible, que viene a ser el modo GLSL 150, OpenGL del año de maricastaña. Esta vez sólo he comparado E20 con la ejecución sin entorno gráfico y no pienso hacer ninguno más, de momento . La línea de tiempo y los valores de pico muestran de nuevo mucha inestabilidad, pero en contra del sentido común, al subir las opciones al máximo forzando la ejecución con GLSL 4XX (OpenGL 4.x), el rendimiento ha aumentado entre un 15% y un 20% "Conclusiones" Como no me he cansado de repetir, las limitaciones nos impiden ir más allá de algo más bien anecdótico para poner en apuros a mi equipo, pero al menos hemos podido comprobar que, efectivamente, el entorno gráfico tiene cierto peso en lo que a rendimiento gráfico se refiere. Establecer un ranking de entornos con tan pocos datos sería aventurarse demasiado. Sin embargo, parece que los pesos pesados del escritorio Linuxero, Gnome y KDE se mantienen más o menos en la media de la tabla, mientras que Cinnamon tiene que trabajar más en lo que se refiere a rendimiento gráfico. La gran sorpresa ha sido Xfce, pues el sentido común nos podría hacer pensar que un escritorio de este tipo debería rendir mejor que sus compañeros mucho más grandes y pesados y, sin embargo, lo hemos visto aparecer a menudo en los puestos de cola, siendo varias veces el último de todos. Insisto una vez más en que lo que he mostrado aquí ha sido mi muy limitada experiencia con un hardware muy concreto y tan sólo unas pocas pruebas, pero de vez en cuando no está de más comprobar las cosas por uno mismo
  4. Este año, como muchos sabemos, ha sido probablemente el punto álgido en la historia de GNU/Linux en lo que respecta a videojuegos. Hemos visto casi duplicarse el número de títulos nativos y "nativos" con respecto al años pasado, han sido lanzados Steam OS y Steam Machines, así como los esperadísimos periféricos de Valve, tenemos Vulkan, la nueva API gráfica del grupo Khronos a la vuelta de la esquina, Nvidia ha empezado tímidamente a abrirse con los desarrolladores de nouveau, AMD parece que por fin se ha comprometido en algo con AMDGPU... en definitiva, un año de grandes cambios que no han dejado indiferente a nadie. Sin embargo, como tantas veces hemos comentado, durante el mismo periodo, ahora mismo estamos en un punto de inflexión. Las cosas están cambiado para mejor, pero aún nos queda mucho camino por recorrer antes de cantar definitivamente ¡Victoria!. Los desarrolladores de Hardware, los problemas de la industria del videojuego, las horrendas políticas y decisiones de Microsoft, pero sobre todo la gran apuesta de Valve, han sido los detonantes que nos han llevado hasta donde estamos hoy. Este primer impulso, esta apuesta declarada y sincera, cual efecto dominó, ha hecho que poco a poco se vayan sumando y participando más estudios, portadores, desarrolladores, fabricantes, testers... una auténtica revolución digital que en breve supondrá un antes y después no sólo para GNU/Linux, sino para la industria del videojuego en General. Pero como ya dije, aún quedan muchísimas cosas por hacer y, por supuesto, grandes detractores que intentarán que no les pisen el negocio empleando para ello los medios que hagan falta. Debemos ser conscientes de cómo es la situación actual y, aunque muchos no podamos ser de gran ayuda, siempre podremos aportar nuestro granito de arena para ayudar a que sigamos avanzando. El estado de los juegos "nativos" para GNU/Linux Mucho se ha hablado de este tema, de hecho, no hace mucho que Ars Technica publicó un sesgado y manipulado estudio comparativo al respecto aclamando la supremacía de otro sistema que es el que mayormente paga sus facturas y que, si bien no podemos decir que es del todo falso, sí que hay que saber interpretarlo para poder sacar conclusiones coherentes a partir del mismo. EN primer lugar debemos tener en cuenta que la industria del videojuego, aunque parezca lo contrario, se mueve muy lentamente y aunque ya tenemos a nuestra disposición una nueva generación de hardware y consolas, los títulos con los que nos están abasteciendo siguen siendo más de la generación anterior que de esta. Los motores gráficos de "nueva generación", Unreal Engine 4, Cryengine 4, Unigine Engine 2, Source 2... apenas se han utilizado en un par de títulos o no se han usado en absoluto, por tanto, los desarrolladores de videojuegos que quieren expandirse a otras plataformas se ven en la tesitura de no contar con motores gráficos de antigua generación que no fueron diseñados con ese fin. Llegados a este punto hay varias opciones, actualizarse a los nuevos motores, rediseñar por completo el motor gráfico utilizado y optimizarlo para hacerlo funcionar con OpenGL o, la más recurrida, hacer alguna chapuza para salir al paso. Dado que los videojuegos que ya llevan unos años en el mercado no son susceptibles de ser rediseñados o recibir una actualización completa de su motor gráfico, la opción más clara para estudios y desarrolladores es realizar alguna chapuza que les permita conseguir su objetivo de ser multiplataforma sin perder demasiado tiempo y dinero en el intento. Incluso para los títulos lanzados recientemente o a punto de ser lanzados se cumple esto último, porque si bien son novedades, su desarrollo se remonta años atrás, cuando aún no se pensaba en el desarrollo multiplataforma. De hecho, en la industria actual existen vicios muy feos a la hora de desarrollar software, que podrían resumirse en: Trabajar únicamente para la plataforma más limitada/desfavorable y hacer ports y adaptaciones una sobre otra para el resto de las plataformas a las que se aspire. Es decir, que actualmente los usuarios de Play Station 4 ven títulos fresco y recién desarrollados para su plataforma, los usuarios de Windows reciben un port de esta versión, con sus limitaciones y sus chapuza y nosotros recibiríamos un tercer refrito de ésta última, sumando limitaciones de los dos anteriores o, en el caso de ser un título que también aparezca en OS X, cuyo soporte poara OpenGL es muy limitado, recibiríamos el 4º port extremadamente capado y limitado. Por mucho potencial que tenga GNU/Linux, por mucho que haya mejorado en tema de drivers, APIs, frameworks... la realidad es esta y hasta que la industria no se adapte a los nuevos tiempos tendremos que ser transigentes con algunas cosas y ser conscientes que en la mayoría de los casos no vamos a poder disfrutar de una experiencia 100% plena en comparación con otras plataformas. Irónicamente, dada la "calidad" de los desarrollos actuales muchas veces pasará desapercibido para la mayoría Dentro de los ports o adaptaciones tenemos un amplio abanico de posibilidades, entre los que destacan los siguientes: Ports realizados por el propio estudio Este tipo de adaptación es realizada por el propio estudio que desarrolló el juego originales, aunque no necesariamente por el mismo equipo de desarrolladores, y los medios empleados para realizar la tarea varían enormemente según el caso. Desde un equipo profesional completo dedicado a dicha tarea a contar con un único becario en prácticas que tiene que lidiar con todo el trabajo. Como ya dijimos antes, en ningún caso se llevará a cabo el rediseño del título para trabajar en una nueva plataforma bajo otras APIs, simplemente se modificarán las partes que sean necesarias y se utilizarán algunas capas de abstracción para aquellas donde no resulte rentable. Para esto existen herramientas como ToGL, IndirectX y otras muchas que ayudan a los desarrolladores a transformar las partes que ha sido diseñadas exclusivamente para DirectX en su equivalente OpenGL de manera sencilla y prácticamente automática. Evidentemente, aunque el resultado siempre serán binarios nativos, esta conversión no 100% eficaz y siempre tendrá un impacto mayor o menor en el rendimiento gráfico final. Un claro ejemplo de esto son los títulos de Valve, Left 4 Dead 2, Half Life 2, Dota 2... cuyas adaptaciones ha sido realizada por los creadores original y que ya nos han mostrado en más de una ocasión que su rendimiento incluso ha mejorado y ya en algún caso como Dota 2 se han atrevido a actuliazar el motor gráfico a uno de nueva generación. Pero insisto en que no siempre es así Ports subcontratados Esta es, sin duda, la opción más recurrida últimamente. Estaríamos ante la misma situación que en el caso anterior, un port nativo en el que se emplean algunas herramientas de conversión que no son del todo eficaces, pero que es realizado por un estudio que no tiene nada que ver con el desarrollo original. Este sería el caso de Feral Interactive, Aspyr Media o de grandes veteranos como Ryan Gordon o Timothee besset, que son subcontratados para obrar la magia de llevar un software a otras plataformas. Este método tiene sus ventajas, ya que son equipo de expertos que se dedican en exclusiva a este trabajo, pero al mismo tiempo ocurre que son personas al desarrollo original y están forzados a trabajar con código escrito por otros (cono todo lo que eso implica). En general este tipo de ports suelen ser bastante aceptables, no sólo por la experiencia que tienen los que lo realizan, sino porque una vez lanzado seguirán teniendo alguien que los respalde y corrija posibles problemas. Ejemplos en este caso tenemos Middle earth: shadow of Mordor, Grid Autosport, Alien Isolation, Sid Meier’s Civilization: Beyond Earth, Borderlands Pre sequel... títulos muy logrados que si bien no podemos esperar que estén 100% optimizados podemos estar seguros que al menos funcionaran bien y nos permitirán jugar de manera adecuada. Otro ejemplo opuesto de este tipo de ports lo tenemos con Batman arkham knight, un título que ha dado muchísimo de que hablar este año, no sólo por ser el cierre de la exitosa saga desarrollada por Rocksteady Studios, sino por haber sido portado a Windows de manera tan horrible y nefasta por Iron Galaxy Studios,que acabó siendo retirado del mercado, para ser relanzado recientemente en un estado no muy diferente al del primer port, que fue llevado a cabo desde un desarrollo exclusivamente PS4 (OpenGL) a WIndows (DirectX) y cuya adaptación para GNU/Linux iba a dejarse en manos de un tercer estudio, Feral Interactive, que ya ha dicho que no se ensuciarán las manos con semejante esperpento y seguirán trabajando a partir del original para intentar traernos una versión jugable, posiblemente durante el segundo trimestre de 2016. Este caso es posiblemente el más representativo que podemos encontrar de cómo funciona la industria a día de hoy y de lo que nos espera a corto/medio plazo hasta que la transición se complete. Ports ficticios Si bien ya he dicho que es muy raro ver un título realmente nativo para GNU/Linux y tenemos que resignarnos a contar con ports que son mayormente nativos pero con algunas chapuzas, en este último caso hablamos directamente de títulos que no son ports en absoluto. Otro de los métodos a los que recurren los grandes estudios a la hora de llevar su software a otras plataformas consiste en no esforzarse en absoluto por ofrecer software nativo y en lugar de ello utilizar Wrappers que hagan de intermediarios entre su software original sin modificar y la plataforma en la que quieren ejecutarlo. Sé que esto puede resultar un poco complicado de entender, pero creo que puedo resumirlo en única palabra de tal manera que todo el mundo lo entienda. WINE. No obstante, aunque es un clásico encontrar aplicaciones que dicen ser nativas y que venden como tal y que al observarlas se ve claramente como corren sobre una versión muy concreta de Wine, en la industria del videojuego quien se está encargando de esto es un Wrapper muy similar desarrollado por Virtual Programming llamado eON. Si bien para el estudio es una forma rápida y barata de llevar su software a otras plataformas y, al igual que con Wine, hay casos en los que las cosas parecen funcionar bien, lo más habitual es que este tipo de estrategias se caractericen por sufrir todo tipo de errores extraños, crasheos, fallos inexplicables y una experiencia de juego... digamos que "sorprendentemente entretenida e imprevisiblemente cautivadora" :lol: Es aquí donde debemos plantarnos y decir NO. Antes dije que había que ser algo transijentes dada la situación actual y apoyar a aquellos que hacen un esfuerzo por traernos software nativo a la plataforma del Ñu y el Pingüino. Sin embargo estaremos de acuerdo en que esto último no sólo no es un esfuerzo, sino que es directamente un engaño, por tanto no deberíamos ser partícipes para que no se perpetúe esta tendencia. Por mucho juegos que de manera "rápida" podría suponer para nosotros, el coste a pagar es demasiado elevado. Queremos juegos, sí, pero juegos con un mínimo de calidad. El renacer de las APIs gráficas Hemos hablado largo y tendido durante el último año sobre Vulkan, la API gráfica abierta, multiplataforma y a bajo nivel del grupo Khronos, que llega para sustituir a la veterana OpenGL con la intención de llevar los desarrollo gráficos al nivel tecnológico actual. Capacidad para exprimir aún más el hardware para obtener mejor rendimiento, desarrollos más sencillos, multiplataforma, bajo un estándar abierto ideado por los pesos pesados de la industria partiendo de la idea original que tuvo AMD con Mantle. Smartphones, consolas, televisores, PCs... todos se beneficiarán de este salto de gigante en lo que respecta a la industria de los gráficos renderizados por ordenador. Pero volvemos a lo mismo que hemos estado tratando desde el principio. Estamos en punto de inflexión donde todo está cambiando, pero aún no lo ha hecho. Vulkan no llegará mañana, ni dentro de un mes ni de dos, será una transición lenta y paulatina que terminará con el nacimiento de una nueva industria, nuevas formas de desarrollo y software que responderá a esta nueva tendencia, para bien o para mal, aunque todo apunta a que el cambio será positivo. Pero para eso, aún tendremos que esperar un poco más Los principales implicados Sin duda alguna quien dio el empujón definitivo que hacía falta para que todo esto ocurriera y que ha invertido muchísimo en GNU/Linux, al punto de crear su propia distribución, Steam OS y empezar a comercializar equipos destinados a jugar desde GNU/Linux, Steam Machines, a todo el catálogo disponible en su tienda de distribución digital de videojuegos Steam. El lanzamiento, que se produjo durante el pasado mes de Noviembre, fue bastante silencioso y, al mismo tiempo, fue salpicado por la polémica suscitada por muchos medios tecnológicos que distan mucho de ser imparciales y/o profesionales. Lo cierto es que tanto Steam OS como las Steam Machines acaban de nacer y aún nos queda mucho antes de ver cómo se hacen un hueco en el mercado. Aún así y a pesar de todo, las ventas ventas tanto de equipos como de periféricos han sido realmente buenas, lo que se opone frontalmente a lo dicho por tantos detractores. Otra cosa que he podido observar, que se repite mes tras mes desde hace dos años y que demuestra que el ser humano es el único animal que tropice no dos, sino inumerables veces con la misma piedar, son los artículos haciendo referencia a una ficticia cuota de mercado de jugadores linuxeros que ¡Fíjate que curiosa, sorprendente y cruel casulidad del destino! Se ha mantenido inamovible en el 1%. Hace tiempo que Valve respondió a esto de una manera clara, pero parece que muchos siguen sin enterarse y lo utilizan como dato significativo para justificar, probar o desmentirr las más disparatadas teorías. Lo cierto es que los datos que se recogen en las estadísticas de Steam son puramente anecdóticos y no pueden ser tomados al pie de la letra. La recopilación de datos se realiza de manera aleatoria a modo de "sondeo" que busca hacerse una idea de las especificaciones de los equipos de los jugadores que utilizan regularmente Steam, por lo que la inmensa mayoría de los usuarios de Steam no han sido jamás incluidos y su hardware/software es, tanto para Valve como para nosotros, un misterio. Al mismo tiempo, la propia compañía ya confirmó que, en lo que respecta a la parte específica para GNU/Linux, esto iba aún más allá y, aunque han hecho varios intentos, no han conseguido una manera eficaz de "medir" a los usuarios linuxeros, dada la inmensa variedad de distribuciones, configuraciones, versiones, etc, por lo que la mayoría de los linuxeros que, por casualidad, son contabilizados, finalmente tampoco acaban apareciendo representados en las estadísticas. Las estadísticas directas de venta tampoco son fiables, dado que están sujetas a muchísimas variables, juegos comprados antes de contar con versión nativa para GNU/Linux no cuentan, si han sido jugados durante X tiempo en otra plataforma, tampoco, si se obtuvieron a través de un medio ajeno a Steam y luego autentificados en éste tampoco les es posible saber dónde tenías pensado jugarlo al comprarlo... En definitiva, es triste ver como después de 24 años todavía sigamos erre que erre con el cuento del 1% Ampliamente conocida por todo linuxero amante de los videojuegos, la californiana es, por desgracia, la única que a día de hoy permite disfrutar en GNU/Linux de los títulos de última generación. Si bien lo hace a través de software mayormente privativo, algo que no nos agrada demasiado, es una compañía que casi siempre cumple en cuanto a rendimiento, especificaciones, soporte y la adopción temprana de nuevas tecnologías, al punto de asimilarlas antes de ser anunciadas oficialmente. Al mismo tiempo, su carácter cerrado hace que no se integre del todo en el ecosistema linuxero, tanto a nivel de usuario como entre los desarrolladores, aunque parece que durante los últimos años ha empezado a volverse más abierta, pero de manera tímida y principalmente en lo que respecta a su gama de procesadores Tegra y no tanto a sus series de escritorio Geforce y Quadro. Si bien es cierto que los precarios controladores gráficos libre Nouveau han avanzado mucho en el último año gracias a varios aportes de la propia Nvidia, a'un nos queda mucho camino por recorrer. Seguimos ante una propuesta privativa, con todo lo que ello implica, pero sin duda alguna, a la hora de rentabilizar una gran inversión como lo es una tarjeta gráfica dedicada, por ahora sigue siendo nuestra única opción. Si bien Intel se limita a ofrecer gráficas integradas en sus procesadores que no se acercan ni remotamente al rendimiento que pueden ofrecer las GPUs dedicadas, su caracter Open Source es de sobra conocido por los linuxeros que no tienen grandes necesidades a nivel de gráficos y pueden desarrollar su actividad diaria con este tipo de gráficas sin ningún problema de soporte. Los controladores para este tipo de Hardware no están a la vanguardia en cuanto a tecnología o especificaciones OpenGL, pero es que tampoco hace falta dado el uso al que están destinadas. Eso sí, al igual que Nvidia, el soporte para Vulkan está más que asegurado antes de su salida. Nos adentramos en un terreno inhóspito que hará que se levante más de una ampolla y que tampoco podremos tratar en profundidad porque no acabaríamos nunca. AMD ha sido, durante mucho tiempo, el patito feo para todos los linuxeros. Controladores privativos ineficientes a la par que problemáticos, carentes de opciones, que llegan tarde y mal, que descontinúan series relativamente recientes de hardware muy temprano dejando a sus usuarios con un palmo de narices... y una contraparte de controladores libres muy trabajados por parte de la comunidad pero que no se acercan a brindarnos el rendimiento y características que esas GPUs podrían darnos. Muchos años de mal soporte, de tener que estar saltando entre controladores privativos y libres para aspirar a poder ejecutar un tipo de aplicación u otra, de sufrir con cada salida de una nueva versión de X.org o del propio Kernel Linux por no tener soporte hasta meses o incluso años después... han sido las razones por las que, la mayoría de los linuxeros que quieren disfrutar de la experiencia de juego nativa en la plataforma de Ñu y el Pingüino, no tocarían una gráfica AMD ni con un palo. Durante el último año también han cambiado muchísimo las cosas para AMD y se ha hablado largo y tendido de su nueva propuesta, los Controladores AMDGPU, una apuesta de unificación de esfuerzo entre desarrolladores libres y privativos que viene a cambiar las cosas o, al menos, eso es lo que nos han dicho. No obstante, esto ha llegado tarde, muy muy tarde, y si en el mundo de los videojuego estamos antes un inminente cambio, en lo que respecta a AMD aún estamos empezando. AMDGPU implica grandes cambios, pero también la ruptura definitiva entre lo moderno y lo antiguo. Sólo las gráficas de nuevas generación y las que salgan a partir de ahora podrán aspirar a beneficiarse de las bondades de los nuevos controladores, algo que a priori tiene mucha lógica desde el punto de vista del desarrollo, pero que para los usuarios cuyos equipos tengan más de año y medio les sentará como una auténtica puñalada. Así todo y aunque el nuevo enfoque de los controladores de AMD supone un antes y un después, facilitará muchísimo las cosas en todos los aspectos y unificará esfuerzos, seguimos sin saber si ciertos problemas de siempre podrán o no solucionarse, entre ellos el pobre rendimiento de estas gráficas en GNU/Linux. La unificación supone mejora, sí, pero si hasta ahora ninguna de las dos partes ha conseguido un rendimiento óptimo ¿Se conseguirá con AMDGPU? Otro punto donde también ha supuesto una desilusión para usuarios y gamers es, precisamente Vulkan. AMD ya confirmó que la nueva API gráfica no será soportada den entrada por los nuevos controladores y que el soporte llegará inicialmente a través de los Catalyst (Crimson) de manera tardía y, posteriormente, comenzarán los trabajos para incorporarlo al controladores unificado. Puede sonar confuso, incongruente o incluso contradictorio, pero como ya dije antes, esto acaba de empezar y ahora mismo hay muchísimas más dudas que respuestas y, si para otras cosas que ya llevan años de desarrollo detrás aún vamos a tener que esperar, en el caso de AMD y su prometedora propuesta de futuro, la espera será aún mayor. En el caso de las APUS, si bien no serán tan fáciles de domar como las Intel, los controladores libres siempre estarán ahí para echarnos una mano y, dado que no le pedimos grandes cosas, la falta de rendimiento y características puede pasar un poco desapercibidas para usuarios de a pie. Sin embargo, a la hora de plantearse invertir una gran suma de dinero esperando obtener a cambio un rendimiento acorde... las Radeon siguen sin ser una alternativa viable y no parece que vayan a serlo en un futuro cercano. Reflexión ¿Final? Si han llegado hasta aquí, tendrán el mismo sabor agridulce que tengo yo mientras escribo esto, pero tampoco puedo maquillar las cosas para hacer ver que estamos en los mundos de Yupi o en el más profundo y frío abismo, lo cierto es que estamos justo en medio, sufriendo una dolorosa pero necesaria transición que no sabemos cuánto llevará, pero que apunta a que será algo muy positivo para la industria, para los usuarios en general, pero sobre todo para GNU/Linux. Nos quedan un par de años de incertidumbre, de grandes alegrías y tristes decepciones que nos llevarán finalmente hasta una estabilidad que esperamos que sea la que todos deseamos. Lo que no se puede negar es que el avance qe podemos apreciar hasta el momento en todos los frentes es, simplemente, espectacular, así que hagamos lo que buénamente podamos para que sigamos avanzando en el mismo sentido, aunque no sea aportando fondos o código, simplemente apoyando a quienes nos apoyan y condenando lo que haya que condenar para que las cosas mejoren. Y por último y más importante, sean críticos y no se crean la mayoría de las cosas que les cuentan, especialmente si provienen de cierto perro forero linuxero que no hace más que desvariar
  5. Aunque Nvidia no se caracteriza por ser la empresa más abierta, sí que nos suele sorprender a menudo con nuevas tecnologías, mejoras y soporte para cosas que ni conocíamos. La última gran sorpresa que nos llevamos fue la culminación de la nueva ABI OpenGL, que llevaba en el tintero varios años y que Nvidia puso en nuestras manos con la última serie de controladores 361.x En esta ocasión, Peter Messmer ha querido, a través del blog de desarrolladores de Nvidia, explicarnos cómo gracias al estándar EGL y los cambios que se han ido introduciendo en las últimas series de controladores de Nvidia, es muy sencillo desvincularse del servidor gráfico a la hora de renderizar contenido OpenGL. Si bien el principal objetivo se centra más en equipos y centros de desarrollo, en los que tener una sesión de las Xs abierta para renderizar contenido off-screen no es deseable, en el caso de los usuarios de a pié sí que nos permite imaginarnos las posibles aplicaciones de esto, especialmente en lo que podría suponer de cara a la inminente migración de X11 a Wayland. Por supuesto, no se limita únicamente al renderizado, sino que permite administrar los recursos de manera precisa, incluyendo configuraciones Multi-GPU. No seré yo quien explique el funcionamiento detallado, porque sinceramente hace rato que me he perdido, pero por lo poco que he podido entender, la cosa pinta muy, pero que muy interesante. gnulinuxvagos.es/index.php?app=forums&module=post&section=post&do=new_post&f=14
  6. GFXBench es un benchmark gráfico multiplataforma que, en su versión 4.0, ha decidido expandir aún más sus horizontes transformándose también en un benchmark OpenGL con soporte para GNU/Linux, que se suma al resto de plataformas móviles y de escritorio. La suite cuenta con varios test diferentes, Car chase, Manhattan y Manhattan 3.1, que ponen a prueba distintos aspectos de rendimiento. Además de eso, ya se preparan para la inminente llegada de Vulkan, e incluso para la API Metal de Apple Capturas Vídeo Descarga https://gfxbench.com/linux-download/ Web https://gfxbench.com/
  7. Warsow es un shooter futurista en primera persona de estilo Cel shading, frenético y adictivo. En su versión 2.0, a la espera de hacer su entrada triunfal en grandes plataformas de videojuegos online como Steam, ha sufrido grandes cambios, entre los que destacan la conversión a SDL 2.0, el cambio a licencia Creative Commons para todos los archivos multimedia, suporte para gamepads, mejoras Multi-threading, mejora del rendimiento general entre un 30% y un 50%. Así mismo, se han añadido nuevos mapas, 3 nuevos tutoriales, selección de punto de respawn, nuevas armas y contenido, así como multitud de correcciones y mejoras. Capturas Vídeo Descarga https://www.warsow.gg/download Web https://www.warsow.gg
  8. Glnemo2 es un programa de visualización 3D que muestra posiciones de partículas de diferentes componentes (gases, estrellas, constelaciones, halos de materia oscura...). Es muy útil para todos aquellos que trabajen con simulaciones de N-Cuerpos, pues es una forma simple, rápida y visual de revelar formas, áreas de mayor densidad, formación de estructuras... Ha sido diseñado con la simplicidad en mente, fácil de instalar, utilizar, con una interfaz gráfica interactiva basada en Digia (Qt5) y un motor gráfico 3D basado en OpenGL y GLSL Además cuenta con soporte para multitud de archivos de entrada: NEMO Gadget 1 y 2 RAMSES TIPSY FITS 2D y 3D FTM phiGRAPE Simulación en tiempo real gyrfalcON vía network plugin Capturas Vídeo Descarga Deb *buntu 15.10 http://projets.lam.fr/attachments/download/2333/glnemo2-1.9.0.ubuntu15.10.x86_64.deb *buntu 15.04 http://projets.lam.fr/attachments/download/2309/glnemo2-1.9.0.ubuntu15.04.x86_64.deb *buntu 14.10/14.04 http://projets.lam.fr/attachments/download/2307/glnemo2-1.9.0.ubuntu14.04.x86_64.deb Rpm Mageia 4 http://projets.lam.fr/attachments/download/2304/glnemo2-1.9.0.mga4.x86_64.rpm Mageia 5 http://projets.lam.fr/attachments/download/2305/glnemo2-1.9.0.mga5.x86_64.rpm Fedora 20 http://projets.lam.fr/attachments/download/2302/glnemo2-1.9.0.fc20.x86_64.rpm Fedora 21 y superiores http://projets.lam.fr/attachments/download/2303/glnemo2-1.9.0.fc21.x86_64.rpm OpenSuse 13 y superiores http://projets.lam.fr/attachments/download/2306/glnemo2-1.9.0.opensuse13.2.x86_64.rpm Compilar Nos valdremos de subversion para descargar el código más reciente de la aplicación svn co http://svn.lam.fr/repos/glnemo2/trunk Nos harán falta los paquetes de desarrollo de Qt5, libccfits y cmake cd glnemo2 cd build cmake .. make make install Web https://projets.lam.fr/projects/glnemo2
  9. Buenas a todos chicos, aqui estoy de nuevo, fiu, se me habia olvidado ya como hacer un post curiosete y facil de entender, con lo malo que soy yo para explicarme, asi es que llevo un rato aqui ensayando en el libreoffice, antes de postearlo. bueno, la idea en si la tengo clara y voy a intentar explicarlo de la forma mas concisa posible, para que me podais arrojar vuestro punto de vista. soy usuario de plasma 5, el problema lo he detectado a traves de este, aunque una vez detectado y tirando del hilo me he dado cuenta de que no es un problema de plasma, si no de mi sistema en general, y concretamente estoy hablando de sistema muy dispares, como son por un lado "calculate linux" basado en gentoo, y por otro lado "antergos" basado en arch. Resulta que en ambas distros, aunque tengo el driver de nvidia "correctamente" instalado, lo entrecomillo porque se supone que esta instalado y funcionando, aunque como vereis mas adelante, algo me hace sospechar que no esta funcionando debidamente. bueno, en estas distros que comento, el compositor de plasma no me deja elegir "openGL" y siempre esta en "xrender", con la perdida de calidad/rendimiento que ello conlleva. bueno, dejamos el breve resumen, y empezamos a ir colocando las capturas explicando un poco mi investigacion. 1º Como podeis ver en esta captura de manjaro/debian, donde todo funciona con normalidad, si me deja elegir el renderizado "openGL" dentro del compositor. el driver esta correctamente instalado y funcionando. 2º Como era tema del compositor/renderizado de ventanas, siempre he pensado que el problema podia ser que el driver de nvidia no estaba correctamente instalado, o en su defecto el xorg no se habia configurado correctamente. Por eso empeze a indagar y a comparar los xorg de mis sistemas, y fueron aumentando mis dudas. # nvidia-xconfig: X configuration file generated by nvidia-xconfig # nvidia-xconfig: version 355.11 (buildmeister@swio-display-x86-rhel47-07) Wed Aug 26 17:15:49 PDT 2015 Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Mouse0" "CorePointer" EndSection Section "Files" EndSection Section "InputDevice" # generated from default Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psaux" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "kbd" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Unknown" ModelName "Unknown" HorizSync 28.0 - 33.0 VertRefresh 43.0 - 72.0 Option "DPMS" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Depth 24 EndSubSection EndSection Section "Extensions" Option "Composite" "Enable" EndSection Section "InputClass" Identifier "Keyboard Defaults" MatchIsKeyboard "yes" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection Aqui podeis ver el xorg.conf de manjaro Como podeis ver, si que aparece la famosa extension “composite” “enable”. Muy bien. Veamos ahora calculate linux, aunque tengo exactamente el mismo problema en antergos. 3º Aqui podeis ver la misma pantalla de antes, del compositor de plasma, donde como veis pone “xrender” y por mucho que yo le diga “openGL 2.0 o 3.0”, no hay manera. Al volver a entrar, vuelve a poner lo de xrender. El driver de nvidia, en teoria esta bien instalado, y aparentemente funcionando. Como podeis ver, aparentemte el driver esta funcionando. Sin embargo veo muchas cosas que no funcionan como es debido. Empezando por el propio entorno grafico “plasma”, hasta un juego como 0AD, donde en debian/manjaro y demas distros donde si me funciona el “compositor” openGL, el juego se mueve por encima de 60fps, sin embargo, en antergos/calculate, el maldito juego en el maldito menu, no alcanza mas de 10fps….(no hace falta ser muy listo para darse cuenta de que algo no anda bien), y viendo que el problema de rendimiento tambien afecta a los juegos, dejo de pensar que puede ser un problema de plasma, para pensar que es mas un problema de xorg/nvidia/modulos/kernel...no lo tengo muy claro. 4º Aun asi, yo he seguido tirando del hilo, pensando que podia ser tema de configuracion, asi es que entro a editar el xorg.conf de “calculate linux”, y esto fue lo que encontre: nvidia-settings: X configuration file generated by nvidia-settings # nvidia-settings: version 355.11 (root@sandbox) Чт окт 15 15:46:58 UTC 2015 # nvidia-xconfig: X configuration file generated by nvidia-xconfig # nvidia-xconfig: version 355.11 (buildmeister@swio-display-x86-rhel47-07) Wed Aug 26 17:15:49 PDT 2015 #------------------------------------------------------------------------------ # Modified Calculate-core 3.4.1.1 # Processed template files: # /var/lib/layman/calculate/profiles/templates/3.3/3_ac_install_live/1-merge/x11-base/xorg-server/X11/xorg.conf # For modify this file, create /etc/X11/xorg.conf.clt template. #------------------------------------------------------------------------------ Section "ServerLayout" Identifier "Xorg Configured" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Mouse0" "CorePointer" Option "Xinerama" "0" EndSection Section "Files" FontPath "/usr/share/fonts/corefonts" FontPath "/usr/share/fonts/misc" FontPath "/usr/share/fonts/droid" EndSection Section "Module" Load "i2c" Load "bitmap" Load "ddc" Load "int10" Load "vbe" Load "glx" # OpenGL X protocol interface Load "extmod" # Misc. required extension EndSection Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "keyboard" EndSection Section "InputDevice" # generated from data in "/etc/conf.d/gpm" Identifier "Mouse0" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/psaux" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Unknown" ModelName "ViewSonic VX2263 Series" HorizSync 15.0 - 82.0 VertRefresh 50.0 - 75.0 EndSection Section "Device" Identifier "intelVGA" Driver "nvidia" EndSection Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "GeForce GTX 960" EndSection Section "Screen" Identifier "Monitor" Device "intelVGA" Monitor "StandardMonitor" DefaultDepth 24 Option "NoAccel" "False" Option "DRI" "True" Option "AccelMethod" "sna" SubSection "Display" Viewport 0 0 Depth 24 Modes "1920x1080" EndSubSection EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 24 Option "Stereo" "0" Option "nvidiaXineramaInfoOrder" "DFP-5" Option "metamodes" "1920x1080_60 +0+0" Option "SLI" "Off" Option "MultiGPU" "Off" Option "BaseMosaic" "off" SubSection "Display" Depth 24 EndSubSection EndSection Section "Extensions" Option "Composite" "On" EndSection ajaaaaa!! como podeis ver, el famoso “composite on”, tambien se encuentra en este archivo. Y entonces, porque no puedo activar el compositor “openGL”???? porque los juegos van como si no tuviese aceleracion grafica??? no voy a poner mas capturas, pero es que, para terminar de romper mis esquemas, si consulto el “xorg.conf” de mi debian sid, donde tambien me funciona el compositor y los juegos como es debido. Pero la opcion “composite on”, ni siquiera se encuentra entre la configuracion del xorg, ni rastro de esa opcion o alguna otra que se le parezca. Entonces fue cuando desisti, se me dejaron de ocurrir ideas, y en el basto mundo de internet estara la solucion, pero yo no se dar con las palabras magicas que me den una solucion. Me podeis arrojar algo de luz sobre este asunto??? Gracias chicos!
  10. El grupo Krhonos debe tener algún problema con las tuberías de la sede, pues ha acabado fichando al fontanero más famoso de todos los tiempos para que les eche una mano :lol: Cada vez son más las compañías, estudios y desarrolladores que ven el potencial de los estándares abiertos y unen sus fuerzas con el grupo Khronos para impulsarlos y adoptarlos. Si bien en esta ocasión ha sido una adición que no ha hecho demasiado ruido, ni siquiera un anuncio oficial todavía, es un placer ver que, estando Vulkan a la vuelta de la esquina, los pesos más pesados del mundo del entretenimiento gráfico no quieren perdérselo. No es ni remotamente el miembro más extraño, irónico e impactante del grupo, pero sí uno de los que íbamos echando en falta, especialmente cuando, hasta ahora, todas sus consolas se han beneficiado de OpenGL para cautivar a los jugadores. Ahora sólo nos queda una pregunta ¿Cómo se verá el próximo Mario con Vulkan? https://www.khronos.org/members/contributors/nintendo-co.-ltd
  11. Este mes de Agosto, desde el 9 y hasta el pasado día 13, se ha celebrado el Siggraph 2015, la feria donde los pesos pesaos de sector de los gráficos computerizados nos muestran las novedades del sector y de paso nos dejan con la boca abierta. Lamentablemente, aunque Vulkan, La nueva API gráfica abierta del grupo Khronos, fue una de las grandes protagonistas del evento, al final no ha ocurrido lo que todos esperábamos. Vulkan aún no ha sido lanzada oficialmente, peor sí que sabemos que la tendremos entre nosotros en breve, antes de que acabe el año. La siguiente fecha clave a la que apuntan todo los rumores no sólo sobre Vulkan sino con casi todo lo que tiene que ver con gráficos por ordenador, pasa a ser Octubre, cuando tendremos otro evento cumbre para Linuxeros y gamers, la salida, por fin, de las dos grandes apuestas de Valve, Steam OS y Steam Machines. Como comentábamos hace unos días, aunque no tenemos Vulkan, las APIS actuales del grupo Khronos sí que han sufrido cambios, brindándonos nuevas versiones, especificaciones y extensiones de OpenGL 2015, OpenGL ES 3.2 y la promesa de la llegada de la esperada WebGL 2.0 también antes de que acabe el año. Google e Imagination technologies nos han puesto los dientes largos, el primero al asegurar que la próxima versión de Android se beneficiará de todas las ventajas de Vulkan y el segundo, al demostrar el enorme aumento de rendimiento que esto supone: Epic Games y otros grandes del sector de los videojuegos y el entretenimiento digital también se han deshecho en elogios hacia la API y mostrado un total compromiso a la hora de adoptarla desde el mismo instante en que ésta sea oficialmente liberada. Unreal Engine 4 cuanta ya con soporte para Vulkan, al menos hasta el punto donde esta se encuentra ahora mismo y a falta de la salida de sus especificaciones finales para poder poner apunto todos los detalles. Samsung también nos ha asegurado que Tizen será una de las primeras plataformas que contarán con soporte para Vulkan. No obstante, no todo ha sido risa y jolgorio, pues nos ha pillado un poco por sorpresa la decisión tomada por la gente de Unity de no trabajar con Vulkan para centrarse en las APIs cerradas, como Metal de Apple, terminando su conferencia con un vago "no estamos trabajando en Vulkan por el momento, pero lo tendremos presente". Una decisión que no sólo nos deja estupefactos a linuxeros y gamers, sino que choca frontalmente con la decisión de Google de ir a por todas con Vulkan, siendo precisamente Android una de las plataformas donde más presencia está ganando el motor gráfico Unity últimamente. Al margen de la polémica y siguiendo con los más destacados del Siggraph, LunarG puso el punto y aparte con LunarXchange, un portal de soporte para el desarrollo centrado en Vulkan y que nace gracias al patrocinio de Valve. https://www.youtube.com/watch?v=LyyKj2LJ0E0 Aunque lo damos por hecho, también se ha hablado sobre GNU/Linux, siendo la plataforma por excelencia para las APIs abiertas y no sólo eso, también nos confirman que no habrá ningún impedimento para poder explotar Vulkan desde Wayland, X11 o cualquiera que sea nuestro servidor o entorno gráfico. Dado que parece que nos hemos convertido unos expertos a la hora de "esperar", ya sólo nos queda hacer lo que mejor sabemos porque sin duda alguna el último trimestre de este año será un no parar para gamers, linuxeros, desarrolladores y entusiastas. https://www.khronos.org/vulkan
  12. Este software y su estupenda función de grabar opengl ya son conocidos en esta comunidad http://gnulinuxvagos.es/topic/4808-captura-opengl-de-juego-de-steam-con-simplescreenrecorder/?hl=simplescreenrecorder yo personalmente no me lo pensé dos veces y decidí probar esta maravillosa función haciendo un poco el g********* en garrys mod. Seguí todos los pasos que publicó Shiba y el creador del software pero... ¡¡NO ARRANCABA EL JUEGO!! No arrancaba una vez introducido en las opciones de lanzamiento: El problema estaba causado por unas librerías faltantes (Nuestras maravillosas amigas) que impedían que el juego iniciase. Aquí os traigo la solución 1. Lo primero que tenemos que hacer es comprobar si se encuentran en la carpeta /usr/lib/ las librerías: Si se encuentran en esta carpeta podreis saltaros el siguente paso. Id al paso 3 2. Descargamos las librerías para ubuntu 12.04. Tranquilos, da igual que distro y que versión sea, funcionará igualmente. Link de descarga: https://launchpad.net/~maarten-baert/+archive/ubuntu/simplescreenrecorder/+files/simplescreenrecorder-lib_0.3.3-1%7Eppa1%7Eprecise1_i386.deb Una vez hecho esto descomprimimos el .deb Dentro del .deb nos encontraremos los siguientes archivos: Extraemos el archivo data.tar.gz Nos aparecerá una carpeta llamada usr. dentro de esta estará la carpeta lib que a su vez contendrá la carpeta i386-linux-gnu que contiene las librerías que necesitamos. Movemos los archivos (con un mv) o los copiamos (con un cp) a la carpeta de nuestro linux. 3. Ahora movemos unas cuantas librerías que steam necesita para poder usar el grabador OpenGL. Si sigue sin funcionar probad a copiar la carpeta la libreria también. Así debería funcionar. Listo Ahora... solo queda seguir los pasos para grabar: http://gnulinuxvagos.es/topic/4808-captura-opengl-de-juego-de-steam-con-simplescreenrecorder/?hl=simplescreenrecorder
  13. Ya habíamos hablado de Simplescreenrecorder, la aplicación que nos permite capturar en vídeo la actividad de nuestro escritorio, pero pocas veces reparamos en otra capacidad de este programa y es la de grabar directamente la salida de aplicaciones OpenGL, como puede ser un videojuego. Si tratáramos de grabar un vídeo de algún videojuego como si se tratara de una aplicación de escritorio sufriríamos ralentizaciones, retrasos en el movimiento debido a errores con el control, cortes en el vídeo resultante, tearing... La forma de evitar este mal y poder realizar la captura de un videojuego sin poner a trabajar nuestro hardware por encima de su capacidad y tener unos resultados óptimos es realizar la captura de la salida OpenGL. En SimpleScreenRecorder seleccionaremos el modo, marcado aún como experimental, OpenGL. Podremos seleccionar el número de fotogramas por segundo a grabar, resolución, área a grabar, así como otras opciones según nuestras necesidades. Una vez hemos configurado todo, si intentamos iniciarla grabación nos encontraremos con un error al no encontrar la salida del programa que queremos capturar. Para solucionar esto tendremos que anteponer al comando de ejecución del ejecutable del juego la orden ssr-glinject En el caso de los juegos de Steam, seleccionaremos en nuestra biblioteca el título en cuestión y abriremos sus propiedades. Como opción de lanzamiento añadimos el citado ssr-glinject de la siguiente forma: ssr-glinject %command% Es conveniente desactivar también la interfaz de Steam durante la partida para evitar posible errores desmarcando la casilla correspondiente. Ya sólo nos queda ejecutar el juego normalmente. Ahora no habrá problema para que SimpleScreenRecorder encuentre la salida OpenGL que queremos capturar y empiece a hacer su trabajo en cuanto se lo indiquemos. http://www.maartenbaert.be/simplescreenrecorder/recording-steam-games/
  14. GNU Octave es un lenguaje de alto nivel diseñado para el cálculo numérico y cuya sintaxis es muy similar a su contraparte privativa, Matlab. Aunque hasta ahora la herramienta se había limitado a una línea de comandos, a partir de su versión 4.0 la herramienta ha culminado la renovación que empezó con la 3.8, dotándola de una interfaz gráfica diseñada en Qt y que aprovecha las bondades de OpenGL. Cuenta además con nuevas clases y funciones de audio, sintaxis de programación orientada a objetos y se ha mejorado la compatibilidad con Matlab. Por supuesto, sigue siendo posible trabajar estrictamente desde línea de comandos mediante la opción --no-gui Capturas Descarga Arch pacman -S octave Debian aptitude install octave Fedora yum install octave-forge Gentoo emerge octave OpenSuse zypper in octave Web https://www.gnu.org/software/octave/
  15. Hace poco escribí sobre la inminente llegada del que posiblemente sea el mejor juego de conducción de los últimos tiempos y parece que algunos me entendieron mal, creyendo que me refería a PROJECT C.A.R.S, nada más lejos de la realidad, el verdadero rey de las carreras llega hoy a nosotros en su versión 0.9 corriendo bajo el renovado motor gráfico Antarctica. Nuevos circuitos, más Karts, físicas, editor de Grand Prix Ingame, generación aleatoria de Grand Prix, sistema de logros y otras muchas novedades nos esperan con este veloz título de conducción, como sólo SuperTuxKart sabe hacer. Capturas Vídeo Descarga http://sourceforge.net/projects/supertuxkart/files/SuperTuxKart/0.9/supertuxkart-0.9-linux.tar.xz Web http://supertuxkart.sourceforge.net/
  16. El GDC 2015 está siendo increíble, la cantidad de novedades y nuevas tecnologías que se han presentado en apenas dos días que llevamos es abrumadora, pero más lo ha sido la presentación oficial de la nueva API gráfica abierta y multiplataforma del grupo Khronos que nos acompañará durante los próximos años. Vulkan ha llegado con fuerza a San Francisco y junto a ella hacen su entrada también OpenCL 2.1 y SPIR-V, el lenguaje que ejercerá de intermediaro. Vulkan, para quien no lo conozca aún, es un estándar abierto que nos da acceso a una computación gráfica altamente eficiente en GPUs modernas. El diseño de la API, previamente conocida como OpenGL Next, ha sido llevado a cabo de manera conjunta por los mayores representantes del sector y permite a las aplicaciones un control directo de la aceleración gráfica de la GPU maximizando así la eficiencia y la predictibilidad. Vulkan nos asegura Control directo de las operaciones de la GPU, con un mínimo consumo por parte de los driver, maximizando el rendimiento Arquitectura Multi-threading-friendly para incrementar el rendimiento general del sistema. Diseñada para ser utilizada un una amplia variedad de dispositivos, incluyendo equipos de escritorio, consolas, teléfonos móviles y sistemas integrados. Hace uso del nuevo lenguaje intermedio para representación flexible de sombreado y controladores gráficos simplificados Arquitectura de capas extensible que posibilita la inclusión de herramientas innovador sin que implique un impacto en el rendimiento mientras se realiza el debbuging o el análisis de rendimiento Controladores simples para asegurar un bajo consumo, alta eficiencia y portabilidad entre los distintos fabricantes. https://www.khronos.org/assets/uploads/developers/library/overview/2015_vulkan_v1_Overview.pdf https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf Se empiezan a difundir algunos de los demos, aunque tendremos que esperar un poco más para que todo el material vaya siendo liberado, tanto especificaciones más concretas como controladores, herramientas y benchmarks. Y como el demo como tal no es que nos dé muchos datos, la comparativa del uso de la CPU corriendo el demo con Vulkan frente a OpenGL es esta: Para más detalles, la gente imagination han dedicado una entrada completa a este Benchmark, que crearon ellos mismos http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus Por supuesto no podían faltar una palabras al respecto del propio Gave Newel Y vamos a terminar con una foto "de grupo" de los que han hecho posible que desde hoy mismo podamos disfrutar de Vulkan P.D. Recordemos que la presentación oficial, aunque hoy tengamos ya todo esto en nuestro poder, es el día 5 de Marzo y es cuando Epic Games, Valve, Unity y algunos más sacarán toda la artillería https://www.khronos.org/news/press/khronos-reveals-vulkan-api-for-high-efficiency-graphics-and-compute-on-gpus https://www.khronos.org/vulkan
  17. La Document Foundation ha anunciado por fin la liberación de la versión final de LibreOffice 4.4 a la que han apodado "the most beautiful LibreOffice ever" Como podrán imaginar en esta versión se han llevado a cabo cambios notables en la interfaz de Libreoffice y en la experiencia de usuario, incluyendo un rediseño de la barra de menús, de los menús contextuales, diálogos, reglas y barras de estado para hacerlos más amigables y útiles. En cuanto a las novedades y nuevas características incorporadas, tampoco se queda atrás: Interoperatibilidad mejorada con carchivos OOXML Mejorada la calidad del código fuente en base al "Coverity Scan analysis" Soporte para transiciones OpenGL en "sistemas" Windows basados en el nuevo framework OpenGL Firmado digital de PDF durante el proceso de exportación Las fuentes libres Carlito y Caladea han reemplazado a las antiguas fuentes Microsoft C-Fonts Calibri y Cambria, eliminando el problema de fuentes al abrir archivos OOXML. Se añade un gran número de plantillas creadas por voluntarios Edición visual de las páginas maestras de Impress Mejor Control de cambios con nuevos botones en la barra de herramientas y mejora en las características de Autocorrección de Writer Mejoras a la hora de importar filtros de Microsoft Visio, Microsoft Publisher, archivos AbiWord y hojas de cálculo de Microsoft Works. Nuevos filtros de importación para Adobe Pagemaker, MacDraw, MacDraw II y RagTime para Mac Soporte expandido en lo referente a capacidades multimedia en todas las plataformas. https://documentfoundation.files.wordpress.com/2015/01/tdf-libreoffice44info.pdf http://blog.documentfoundation.org/2015/01/29/libreoffice-4-4-the-most-beautiful-libreoffice-ever/
  18. Para despedir el año el Grupo Khronos, durante el SIGGRAPH asiático celebrado durante el pasado Diciembre, nos ha hablado sobre la actualidad y el futuro de las APIs gráficas abiertas http://www.slideshare.net/slideshow/embed_code/42464487
  19. Abróchense los cinturones y mantengan el culo bien pegado al asiento porque ya tenemos en nuestras manos un gran número de demos técnicas impulsadas por el motor gráfico de Epic Games, Unreal Engine 4. De manera nativa y puramente para 64 bits, estas muestras que ha compartido Epic con nosotros pondrán a prueba nuestras equipos, exprimiendo al máximo las capacidades de nuestro hardware, al mismo tiempo que nos dejan con la boca abierta. Sólo recomiendo dos cosas, equipos antiguos o modestos mejor abstenerse y a los demás... tengan preparado un cubo, una fregona y un buen babero :lol: Elemental http://ue4linux.raxxy.com/elemental_demo.tar.bz2 Effects Cave http://ue4linux.raxxy.com/effects_cave_demo.tar.bz2 Realistic Rendering http://ue4linux.raxxy.com/realistic_rendering_demo.tar.bz2 Reflections Subway http://ue4linux.raxxy.com/reflections_subway_demo.tar.bz2 Sci-Fi Hallway http://ue4linux.raxxy.com/sci-fi_hallway_demo.tar.bz2 Sun Temple http://ue4linux.raxxy.com/sun_temple_demo.tar.bz2 Stylized http://ue4linux.raxxy.com/stylized_demo.tar.bz2 Blueprint Office http://ue4linux.raxxy.com/blueprint_office_demo.tar.bz2 Landscape Mountains http://ue4linux.raxxy.com/landscape_mountains.tar.bz2 Matinee http://ue4linux.raxxy.com/matinee_demo.tar.bz2 Shooter Game http://ue4linux.raxxy.com/shooter_game.tar.bz2 Strategy Game http://ue4linux.raxxy.com/strategy_game.tar.bz2 Vehicle Game http://ue4linux.raxxy.com/vehicle_game.tar.bz2 Platformer Game http://ue4linux.raxxy.com/platformer_game.tar.bz2 Atlantis Substance http://ue4linux.raxxy.com/atlantis_demo.tar.bz2 Couch Knights http://ue4linux.raxxy.com/couch_knights.tar.bz2 Light Room Interior http://ue4linux.raxxy.com/lightroom_interior_day.tar.bz2 Por supuesto, a través de la wiki oficial de Epic Games podremos acceder a toda la información y material disponibles sobre Unreal Engine 4 https://wiki.unrealengine.com/Linux_Support
  20. Hace un par de semanas Nvidia comenzó a trabajar en una nueva línea de controladores 343.x que hasta ahora se encontraba en estado Beta. El reciente lanzamiento de la nueva línea de tarjetas gráficas, la segunda generación Maxwell, concretamente la Geforce 980 GTX y la Geforce 970 GTX, han hecho posible que ya podamos disfrutar de la versión estable de los nuevos controladores y, en esta ocasión, incluso antes que para otros sistemas operativos. Esta nueva línea de controladores se caracteriza, aparte de por las nuevas características que incorporan, por ser el punto de inflexión en el soporte de hardware "antiguo" de Nvidia pues partir de esta serie sólo habrá soporte para las gráficas Geforce 400 o más recientes, quedando las anteriores relegadas a la serie de controladores 340.x que tendrán soporte prolongado. Evidentemente, el primer cambio a destacar será la inclusión de las dos nuevas GPUs de la compañía: Se ha añadido soporte para las siguientes GPUs:GeForce GTX 970 GeForce GTX 980 Se ha corregido un error que hacía que el ajuste "sync to vblank" no se respetase en las aplicaciones EGL. Se ha corregido un error por el que algunos programas OpenGL encontraban un problema de falta de memoria al cambiar de modo. Se ha corregido un error que impedía al controlador OpenGL de NVIDIA respetar el valor de la variable de entorno __GL_SHADER_DISK_CACHE_PATH. Se ha corregido un error por el que, en ciertas consultas y asignaciones efectuadas en la interfaz de línea de comandos de nvidia-settings, las pantallas inhabilitadas se incluían implícitamente como destinos seleccionados a falta de una selección explícita de destinos. Se ha añadido un nuevo atributo a la API NV-CONTROL para consultar el uso que se está haciendo del motor de descodificación de vídeo. Se ha corregido un error por el que la opción de intercambio de ojos izquierdo/derecho de nvidia-settings no funcionaba en determinadas configuraciones estereoscópicas. Se ha solucionado un problema de sombreadores de Unigine Heaven 3.0 que podía producir anomalías en la imagen si se activaba el teselado mediante la implementación de un perfil de aplicación que utilizase el parámetro "GLIgnoreGLSLExtReqs". Véase la documentación de la variable de entorno __GL_IGNORE_GLSL_EXT_REQS para obtener más información. Se ha corregido una fuga de memoria que se producía al destruir superficies de EGL. Se ha añadido soporte para varias pantallas EGL simultáneas. Se ha retirado el soporte de las GPUs G8x, G9x y GT2xx, así como de los chips de placa base diseñados con ellas. Las versiones antiguas del controlador 340.* seguirán incluyendo soporte para nuevos kernels de Linux y servidores X (así como correcciones para errores críticos) hasta finales de 2019. Se ha corregido un error por el que nvidia-installer podía tratar de borrar sin éxito el directorio que contiene las interfaces del módulo kernel en paquetes preparados con --add-this-kernel. Se ha modificado nvidia-installer para que registre la desinstalación en un archivo distinto del registro de instalación y para que intente eliminar las versiones anteriores del controlador utilizando el programa de desinstalación de dichas versiones, si está disponible. Como es habitual, podremos obtener el instalador oficial de dichos controladores a través de la web de Nvidia para cualquiera de los sistemas *nix soportados GNU/Linux x86 GNU/Linux x86_64 GNU/Linux ARM Solaris FreeBSD x86 FreeBSD x86_64
  21. Artículo original de Sebastian Anthony en ExtremeTech Seguimos con la saga Khronos... En Siggraph 2014, el Grupo Khronos ha anunciado tanto OpenGL 4.5 como la Iniciativa OpenGL Next Generation. OpenGL 4.5, a excepción de algunas nuevas características de Direct3D 11 de emulación para una fácil portabilidad, es su actualización anual estándar de OpenGL. OpenGL Next Generation (OpenGL NG) sin embargo, es una reconstrucción completa de la API OpenGL. La idea, al igual que la intención de AMD Mantle y DirectX 12, es la construcción de una versión completamente nueva de OpenGL que elimine gran parte de la abstracción, lo que reduciría significativamente los consumos y las ineficiencias cuando se trabaja a bajo nivel sobre el hardware de la GPU. No obstante, Khronos tiene un difícil reto por delante que superar: Mientras que AMD y Microsoft se centran en sus propias implementaciones específicas, OpenGL NG será una solución multiplataforma para todos los sistemas operativos y los fabricantes de hardware, al igual que las especificaciones de OpenGL existentes. Con más de 22 años en su haber, OpenGL (originalmente publicado por SGI en 1992) es la más antigua de las API de alto nivel de gráficos 3D todavía en uso masivo. Al igual que DirectX (que es sólo un poco más joven), OpenGL se ha ganado una elevada reputación en los últimos años. Aún más importante, OpenGL --al igual que DirectX y Direct3D-- es un API de muy alto nivel que hace que sea difícil de ejecutar de manera eficiente el código en la GPU directamente. Esto no importaba tanto en los viejos tiempos, cuando las GPU eran cosas desagradables que necesitan abstracción de alto nivel para ser programadas de forma eficiente. Pero ahora, como las GPUs son cada vez un producto más maduro y desarrollado con mayor sensatez y ampliamente documentado, los desarrolladores están pidiendo APIs gráficas que les permitan conseguir estar mucho más cerca del hardware, lo que mejoraría significativamente el rendimiento y reduciría los consumos de recursos. OpenGL NG, será rediseñado «desde abajo» y no será compatible con versiones anteriores de OpenGL. Khronos Group, que desarrolla la especificación OpenGL (y otras especificaciones relacionadas), dice que está trabajando intensamente con todos los miembros de su consorcio para desarrollar unas especificaciones técnicas para que las empleen las empresas de hardware y software. El último intento de Khronos para crear una nueva especificación, no compatible con versiones anteriores --Longs Peak--, fracasó estrepitosamente por lo que no está dispuesto a cometer los mismos errores dos veces. El paisaje ha cambiado mucho desde «Longs Peak», aunque ahora, con una variedad de APIs de bajo nivel que salen de AMD, Microsoft, e incluso Apple, parece que los desarrolladores están dispuestos a romper con los duros días de la abstracción de antaño. A propósito, Longs Peak nunca vio la luz del día ya que fue destrozado en 2007 y sustituido por el mucho más "normal" y compatible OpenGL 3.0 en 2008. En declaraciones públicas, Khronos admite que se ha fijado una tarea muy desalentadora para sí mismo. Aún así, Khronos parece contar con la mayoría de las personas adecuadas a bordo (la única omisión significativa es Microsoft). «Es agradable ver una gran cantidad de proveedores de software, tales como Valve, Epic, Blizzard, y Unity, implicados en el proyecto. El desarrollo del juego es cada vez más multi-plataforma; estoy seguro de que a los desarrolladores le encantaría dirigir OpenGL NG y tener sus juegos funcionando en la mayoría de las plataformas... Aunque, por supuesto, eso sólo funcionará si el soporte de hardware está ahí». Esto encaja perfectamente en otro punto relevante: Khronos también admite que, debido a OpenGL NG tendrá que trabajar a través de múltiples GPUs y no podrá ser físicamente a tan bajo nivel como AMD Mantle. Khronos confía en que todavía pueda ofrecer reducciones significativas de consumo y aumentar las prestaciones aun siendo multiplataforma. Teniendo en cuenta sus diferentes enfoques en alcanzar más o menos el mismo objetivo, será interesante averiguar cómo lo resuelven AMD Mantle, DirectX 12 y OpenGL NG. No parece existir una línea temporal definida para el lanzamiento de OpenGL Next Generation, pero no parece que vaya a ser pronto. Está previsto el lanzamiento de DirectX 12 hacia el final de 2015, y la opinión general es que a Khronos le gustaría desembarcar OpenGL NG más o menos al mismo tiempo, pero puede ser que se demore algo más. Muchos comentaristas y observadores sepreguntan por el destino de AMD Mantle ahora que tanto Microsoft como Khronos se han metido a fondo en la lucha. Los cambios que anuncia OpenGL 4.5 están contenidos en la documentación publicada en su lanzamiento. Aunque realmente no hay muchos salvo algunas nuevas características que ayudan a portar aplicaciones entre entornos para móviles y de escritorio, y entre DirectX 11 hacia OpenGL 4.5), y algunas limpiezas generales de API para su alineamiento y correlación para acercar a las diferentes especificaciones de OpenGL: OpenGL, OpenGL ES, WebGL.
  22. Hace algunos días Valve liberaba la capa de abstracción ToGL y parece que la cosa no termina, ahora le ha tocado el turno a VoGL, su debugger para desarrollos OpenGL. El proyecto aún se encuentra en pleno desarrollo y en estado alpha, es totalmente compatible con OpenGL 3.3 y se esperar que con OpenGL 4.x a lo largo de este año. Aún con mucho trabajo por delante, parece que Valve está cumpliendo con lo prometido en los SteamDev Days y no se guardará nada con tal de conseguir que Steam OS triunfe como plataforma de juegos Código fuente https://github.com/ValveSoftware/vogl http://richg42.blogspot.com.es/2014/03/vogl-gl-debugger-source-is-on-github.html
  23. Tomado del desarrollo de Dota2, nos llega ToGL, una pequeña capa de traducción ideada por Valve que pretende hacer más simple la tarea de traducir aplicaciones que hagan uso de DirectX a al estándar libre multiplataforma OpenGL. El código liberado, según nos comentan es para ser utilizado libremente, quien lo necesite puede tomarlo para su proyecto o modificarlo, pero al mismo tiempo dejan claro que no se comprometen a dar soporte. Entre las características que presenta ToGL están: Limited subset of Direct3D 9.0c Bytecode-level HLSL -> GLSL translator Some SM3 support: Multiple Render Targets, no Vertex Texture Fetch Aunque no vaya a solucionar el tema de la migración de títulos a GNU/Linux de la noche a la mañana, un pequeño avance siempre es bienvenido y aunque sea a cuentagotas parace que cada vez se liberan más cosas que pueden ayudar a conseguirlo https://github.com/ValveSoftware/ToGL
  24. Nvidia arranca con fuerza en esta nueva serie de controladores 334.x con la que afianza aún más su apuesta por EGL, pieza fundamental para el soporte del servidor gráfico Wayland, además de traernos otras muchas novedades Se han añadido librerías EGL 64-bit y OpenGL ES Se ha mejorado Nvidia-settings para que nos muestre un texto de ayuda y sugerencias cuando creamos perfiles de configuraciones EL directorio /proc para la GPU ha sido renombrado como /proc/driver/nvidia/gpus y el bus de localización se presenta en el formato "domain:bus:device.function" para coincidir con lspci Se ha modificado el módulo del kernel para que pueda ser cargado mediante "nvidia-modprobe" en lugar de la función de ayuda de XFree86 xf86LoadKernelModule() Se ha mejorado el soporte para las variables de entorno GL_SYNC_DISPLAY_DEVICE y VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE en ciertas configuraciones Se ha mejorado el rendimiento del driver de las Xs cuando se manejan un gran número de superficies Añadido soporte experimental para ARGB GLX visuals cuando la composición y Xinerama están habilitados simultáneamente en X.Org 1.15 Se ha modificado el comportamiento por defecto del driver para que no elimine las salidas de RandR 1.2 correspondientes a Unidades DisplayPort 1.2 en desuso y se ha añadido la opción DeleteUnusedDP12Displays para poder volver a habilitarlo. Actualizado el panel de control de nvidia-settings para permitir la selección de los dispositivos de visualización utilizando RandR y apuntar los nombres de identificación al realizar consultas dirigidas a los dispositivos de visualización específicos. El resto de cambios y los enlaces de descarga podemos encontrarlos en la página oficial de Nvidia http://www.nvidia.com/download/driverResults.aspx/73100/en-us Y ya para rematar y por si fuera poco, hace algunos días el propio Linus Torvalds tuvo a bien dirigir unas palabras hacia el fabricante de gráficas y, al igual que en anteriores ocasiones, ha acabado levantándole un dedo, pero esta vez ha sido el pulgar, especialmente por su trabajo con los controladores libres para los Tegra K1 y su acercamiento a la comunidad de desarrolladores para colaborar con Nouveau https://plus.google.com/u/0/+LinusTorvalds/posts/TQDXxxr6ixm
  25. Tras el retraso, Metro: Last Light, el título de 4A Games y secuela de famoso Metro 2033 ha llegado de manera nativa a GNU/Linux y ya puede adquirirse a través de Steam. Sin embargo, tras la alegría inicial he querido indagar más a fondo para averiguar que tan bueno es, no el juego, sino este port que han hecho a posteriori. Dado que no poseo este título he de "fiarme" de los comentarios, capturas y apreciaciones de gente que sí lo tiene y ha podido probar con sus propias manos cómo es el desempeño de Metro Last Light en GNU/Linux. De entrada tenemos algunos vídeos de muestra de los primeros minutos del juego, todos muy parecidos y bastante prometedores, suficiente para que se nos caiga la baba https://www.youtube.com/watch?v=kXU-S7pBnWM Pero... lamentablemente no es oro todo lo que reluce y ahora, con la cabeza fría, toca sopesar si verdaderamente se ha hecho un buen trabajo. Para empezar, tenemos el eterno problema, que hostiga a los linuxeros desde hace años y que se resume en 3 letras, AMD y su mal hacer a la hora de dar soporte a plataformas *nix. Tanto es así, que el retraso del lanzamiento no ha servido de nada y en el anuncio oficial así lo hacen saber, seguimos a la espera de una futura actualización de los controladores de AMD que permita disfrutar de este título porque a día de hoy es casi imposible bajo una de estas tarjetas. Según los comentarios de algunos usuarios, el desempeño de estas tarjetas es nefasto, apenas llegando a los 10FPS y presentando numerosos errores y sin poder recurrir a los controladores libres, dado que éstos aún no tienen soporte para las versiones más recientes de OpenGL exigidas por el juego. Si se dan una vuelta por los foros de soporte, por las comunidades de Steam o, sin ir mas lejos, por los mismos comentarios que han ido dejando bajo el anuncio oficial de, verán una queja tras otra de usuarios con tarjetas AMD que no pueden disfrutar del título en condiciones o que ni siquiera pueden llegar a iniciarlo http://steamcommunity.com/games/MetroVideoGame/announcements/detail/1841138399631172025 El 2º objetivo de mi ira a día de hoy es menos habitual y, a priori parece no tener ninguna relación con el asunto que estamos tratando, pero en base a las comparaciones hechas por Evil Penguin y cuyas capturas pondré a continuación, nos llevan a una conclusión que ahora trataré de explicar. Directx VS OpenGL (Y no voy a decir cuál es cual ) Aunque a primera vista parece todo correcto, si nos fijamos en detalle notamos, al menos, un par de cosas: La tessellation (No sé traducir esto) brilla por su ausencia, así que algunos relieves son casi totalmente planos en la versión GNU/Linux. Algunas sombras/iluminación no se muestran de manera correcta. Capado y acomodado, como mucho, a OpenGL 3.2/3.3 Phsyx ¿Eso qué es?¿Se come? Probablemente donde mejor se aprecie la diferencia acerca de estas dos cuestiones es en las últimas dos imágenes, que engloban todos los errores al mismo tiempo y, seguramente, algunas cosas más que yo no he visto. La conclusión a la que se ha llegado del por qué de esta limitación o falta de características de la versión GNU/Linux tiene dos componentes diferenciados y, repito, no se trata de nada oficial sino de conclusiones sacadas por los usuarios que han podido probar el título hasta ahora. El primero ya lo hemos nombrado, las limitaciones y falta de soporte de AMD, que finalmente han tenido poco menos que "ignorarse" para que el port saliera al mercado y en 2º lugar, a la "herencia recibida" (Me he sentido lo más sucio y ruin del mundo al decir esto, no sé por qué ) Y es que no debemos olvidarnos de que no es un título diseñado para ser multiplataforma sino un port hecho a posteriori, se diseñó para Windows con DirectX, posteriormente se portó a Mac OS bajo OpenGL y a partir de éste último se ha hecho un segundo port a GNU/Linux, con lo cual, en las carencias gráficas del juego están las de Mac OS y la tardanza de Apple en dar soporte a las nuevas características de OpenGL y/o hacerlo "a su manera". Por tanto, si la versión Mac OS no puede hacer frente a los efectos de Tessellation y otras características propias de OpenGL 4.X, la versión para GNU/Linux, que es una derivada de esta, evidentemente tampoco podrá y podemos dar gracias a Apple por su contribución a que esto sea así, pues mientras nosotros disfrutamos desde hace tiempo de OpenGL 4.4, salvo la última versión de Mac OS X lanzada hace muy poco que soporta OpenGL 3.3 y un poco de la 4.1, el resto de versiones siguen con la 3.2/3.3. Lo que no quita responsabilidad a los desarrolladores por haber "reciclado" código antiguo y desfasado en lugar de hacer las cosas en condiciones para este nuevo port. En cuanto a rendimiento parece que la opinión generalizada es que, quizá, rinda un poquito mejor que la versión bajo DirectX, pero no hay ninguna prueba seria que lo apoye sólo apreciaciones personales y, teniendo en cuenta lo que acabamos de decir en este tema, puede que los resultados estén falseados (No es lo mismo correr el título con todos los efectos habilitados que sólo con algunos), así que tendremos que esperar un poco más a ver si alguien se anima a hacer una comparación verdaderamente seria. SI alguno de los presentes se anima... Sin embargo y a pesar de todo lo dicho, sigue tratándose de un gran título y aunque no cumpla al 100% con la calidad prometida, no lo hace por muy poco, es un juego que vio la luz hace bien poco (2ª mitad del año) y es uno de los pesos pesados dentro de los AAA, por lo que es una gran oportunidad para los Gamers linuxeros y una prueba más del apoyo creciente de la industria hacia GNU/Linux.
×
×
  • Crear Nuevo...