¿STEAM para linux?

Mientras que se decidan a sacarlo para linux puedes usar Steam con Cedega. Aquí tienes un manual de cómo hacerlo.

Ya, si lo he usado mucho tiempo, pero desde que cambiaron la interfaz ya no me funciona

Pon la última versión de Cedega, la 4.4.3.

Va de miedo

Dudo horrores que saquen un Steam para Linux. Y si lo sacan, olvidate por lo menos de jugar al HL2 y/o cualquier juego con motor Source (es 100% DirectX). Aunque el HL1, como está basado en el motor del Quake 1, y tiene soporte gráfico OpenGL por defecto (el sonido no sé como irá), sería más sencillo de portar, pero aun así dudo que lo hagan nunca...

Yo también dudo que lo hagan, pero simplemente una versión Linux de Steam y HL2 daría un grandísimo empujón al mundo de los juegos en Linux...

Lo que da verguenza es que Valve sí que ha sacado un Steam para linux: la versión server.

Como tantas otras compañías de juegos, se aprovechan de la cuota de mercado de linux en lo que se refiere a servidores, pero a los que queremos jugar que nos den

Esto se soluciona comprando solo (solo!) aquellos juegos con soporte para Linux/Mac.

Pero claro, comentaselo a unos cuantos millones de jugadores, a ver que te dicen...

See ya!!!

Sin base de usuarios, sin unos drivers a la altura de los de windows ( *cough* Ati *cough* ), sin DirectX... yo no esperaría una versión cliente de Steam en esta década. Y tal y como está de reñida la industria del videojuego y teniendo en cuenta que no hablamos de ONGs, veo su decisión de lo más lógico.

Quién quiere directx teniendo opengl, sdl y openal?

¿No sería más lógico desarrollar juegos usando librerías multiplataforma? El coste de portar cualquier juego a cualquier plataforma sería mínimo. Mira los de Id: opengl, openal y ansi C (entre otras cosas)... con un par

kornshell escribió:¿No sería más lógico desarrollar juegos usando librerías multiplataforma? El coste de portar cualquier juego a cualquier plataforma sería mínimo

Sí, eso es lo que cualquier mente con un poquito de vista en informática habría decidido hacer... Lo que pasa es que la mayoría de los que toman las decisiones las toman en base única y exclusivamente al dinero.
Yo, intentaría preocuparme de que mi software tuviera un poquito de calidad y de utilizar herramientas que me facilitaran flexibilidad. Dudo mucho que compañías tan grandes como algunas de los juegos no se puedan permitir esto... pero simplemente se la patina.

En fin.. lo voy a dejar aquí, que sé que luego tengo que acabar pidiendo perdón...

Salu2!

Lo unico que OpenGL necesita es mas soporte para actualizarse mas a menudo, que anda que no ha habido que esperar tiempo para las ESPECIFICACIONES de OpenGL 2. Por lo demas es tan capaz de crear grandes motores como lo podria ser DirectX.
Y si, la verdad es que lo de ATI es una puta verguenza, no me vuelvo a comprar una en la vida.

FuckingFreaky escribió:Sí, eso es lo que cualquier mente con un poquito de vista en informática habría decidido hacer... Lo que pasa es que la mayoría de los que toman las decisiones las toman en base única y exclusivamente al dinero.

Viven de ello

FuckingFreaky escribió:Yo, intentaría preocuparme de que mi software tuviera un poquito de calidad y de utilizar herramientas que me facilitaran flexibilidad.

Yo intentaria reutilizar todo lo que tuviese para conseguir esa flexibilidad, y si ya tengo motores con calidad, gente preparada para desarrollar con una determinada libreria y lenguaje, contratado el soporte de mis aplicaciones y demás no lo movería ni un dedo para seguir vivendo de ello "sin más complicaciones".

FuckingFreaky escribió:Dudo mucho que compañías tan grandes como algunas de los juegos no se puedan permitir esto... pero simplemente se la patina.

El riesgo es alto, el coste también y no vas a sacar mucho más de lo que ya sacas.

Aquello que no te puede dar beneficio sólo te puede dar pérdidas.

kornshell escribió:Quién quiere directx teniendo opengl, sdl y openal?

Microsoft

De toda formas opino que si los hiciesen mas multiplataforma, tendrian aun mas usuarios compradores

Salu2!

xatafi escribió:Viven de ello

Como todos. No conozco a nadie que pueda vivir sin dinero (alguno habrá). Eso no da pie para no hacer bien tu trabajo, ¿no? No les estoy pidiendo que se mueran de hambre, sino que hagan las cosas bien.

xatafi escribió:Yo intentaria reutilizar todo lo que tuviese para conseguir esa flexibilidad, y si ya tengo motores con calidad, gente preparada para desarrollar con una determinada libreria y lenguaje, contratado el soporte de mis aplicaciones y demás no lo movería ni un dedo para seguir vivendo de ello "sin más complicaciones".

Yo, obviamente, me refería a antes de iniciar un juego. Ahora sería una monstruosidad pasar un juego como HL2 hecho con directx y tal a otra forma distinta. Me refería a hacer las cosas bien desde el principio precisamente por eso, porque llegados a ese punto, ya no hay vuelta atrás.

xatafi escribió:El riesgo es alto, el coste también y no vas a sacar mucho más de lo que ya sacas.

Pos lo mismo que arriba: me refería a algo desde un inicio, no una vez que ya se ha llegado a ese punto.

xatafi escribió:Aquello que no te puede dar beneficio sólo te puede dar pérdidas.

Si lo hicieran bien desde el principio igual hasta tendrían más ganancias.

Un saludo!

ID no se arruinó por seguir standards multiplataforma al hacer el quake3, de hecho ahí tienes: uno de los motores más usados para otros juegos (y por tanto uno de los que han reportado más beneficios a los creadores a través de las licencias).

Ahora mismo, teniendo el código fuente del quake3 libre, puedes ver que lo único que necesitas para compilarlo en otra plataforma es cambiar un par de lineas. Coste del port = cero, y todo por hacer las cosas bien desde el principio.

Si tienes en cuenta que incluso para id software que sí hacen las cosas así desde un inicio sacar sus versiones de Linux no les supone ningún beneficio económico extra, como ha sido admitido por ellos mismos y probados por el hecho de que los binarios para Linux salen después de todos sus lanzamientos, puedes hacerte a la idea de lo que van a hacer quienes desde luego no se distinguen precisamente por liberar el código de sus motores bajo la GPL.

Para ellos, "hacer las cosas bien" no incluye que el juego sea multiplataforma porque a todos los efectos sólo hay una plataforma de juegos (excluyendo consolas, claro está): Windows. Y eso no quiere decir que no hagan las cosas bien, sino que actúan de forma lógica. Si no lo hacen así, no es que no vayan a sacar juegos para Linux, es que se van al garete y ni para Linux, ni para Windows, ni para la Master System.

Bueno, pero el tema es que en el último año ha crecido mucho la comunidad linux, y ya están apareciendo webs dedicadas exclusivamente al tema de videojuegos en linux, como: http://www.phoronix.com ó http://www.linuxjuegos.com

Además, ahora mismo ID ya no vende juegos para linux, sino que te compras el juego para windows y luego usas el cliente para linux, así que la única forma de saber cuantos usuarios de linux han comprado el juego es mirar cuantas veces se ha descargado el cliente linux, pero a su vez, como el cliente se distribuye rápidamente a traves de los mirrors ... es muy dificil saber cuantos han sido ...

Solo hay que meterse en los foros de videojuegos para ver la cantidad de hilos que hay sobre linux y saber que si armamos tanto ruido (aunque sea sólo en los foros), será que somos unos cuantos ¿no?

Además, hay que tener en cuenta a toda la peña que usa Cedega.

No digo que seamos mayoría ni mucho menos, simplemente que estamos creciendo, y que ya es hora de que nos tengan en cuenta !

Voy a intentar escribir menos que antes.

FuckingFreaky escribió: Yo, obviamente, me refería a antes de iniciar un juego. Ahora sería una monstruosidad pasar un juego como HL2 hecho con directx y tal a otra forma distinta.

Aunque lo comiences desde 0, no puedes estar 'n' meses dando cursos de formación a una plantilla que ha hecho varios juegos en DX o en lo que sea para que se cambien a otra cosa. El cambio es costoso, y conozco a un puñado de personas que les cambias el Eclipse por el NetBeans y no saben qué hacer.

kornshell escribió:ID no se arruinó por seguir standards multiplataforma al hacer el quake3, de hecho ahí tienes: uno de los motores más usados para otros juegos (y por tanto uno de los que han reportado más beneficios a los creadores a través de las licencias).

Creo que Rockstar se ha forrado tambien con la saga GTA, y el juego de PS2 y el de XBOX dudo que tengan 3 líneas de código iguales. ID se habrá forrado a base de vender los juegos y el engine, no por hacerlo multiplataforma.

xatafi escribió:Creo que Rockstar se ha forrado tambien con la saga GTA, y el juego de PS2 y el de XBOX dudo que tengan 3 líneas de código iguales. ID se habrá forrado a base de vender los juegos y el engine, no por hacerlo multiplataforma.

No me refería a que el éxito de id fuese debido a usar librerías multiplataforma, sino a que a pesar de ello triunfan. O sea, que puede que los beneficios merezcan o no la pena, depende a quién preguntes, pero tampoco hay desventajas si te lo planteas por ese camino desde el principio.

kornshell escribió:Quién quiere directx teniendo opengl, sdl y openal?

Amen.

Lo unico que OpenGL necesita es mas soporte para actualizarse mas a menudo, que anda que no ha habido que esperar tiempo para las ESPECIFICACIONES de OpenGL 2. Por lo demas es tan capaz de crear grandes motores como lo podria ser DirectX.
Y si, la verdad es que lo de ATI es una puta verguenza, no me vuelvo a comprar una en la vida.

Sobre esto tengo un comentario: OpenGL está sobradamente actualizado. Es más... puedes utilizar cosas que con Direct3D no puedes. Y esto gracias a las extensiones. El problema es que obviamente cada hardware cambia, y tendrías que tener soporte para cada hardware. Por ello se creó las ARB, extensiones estándard que funcionan en todas las tarjetas. Estas previamente pueden haber sido del tipo NV (nvidia), ATI... pero que al ser muy útiles o reimplementadas en otros pasan a formar parte de OpenGL ARB. En Direct3D es diferente: ellos implementan algo y los demás lo tienen que seguir si no se quieren quedar a tras. En este último caso la "innovación" viene por parte de M$, y por mucho que una tarjeta X pueda hacer algo, si M$ no tiene ganas, no funciona.

Actualmente no se utiliza ni el 70% del potencial de OpenGL 1.4 (con sus extensiones ARB). En Doom 3 no utilizan ni VBO... y el soporte para estas está desde las Geforce 2. ¿Porqué? porque la gente tiene libertad de implementarlo como le da la gana. En D3D todo el mundo lo hace igual, todo (o casi) está preparado.

OpenGL no necesita "mejorar" o "actualizarse" más rápidamente... necesita que la gente sienta interés, y lo único que quiere es beneficio rápido. De ahí la filofía algo contraria "Estará acabado cuando lo esté" de John Carmack.

No me refería a que el éxito de id fuese debido a usar librerías multiplataforma, sino a que a pesar de ello triunfan.

En parte, el gran éxito de los motores de id es su... portabilidad. Y esta es tan grande gracias a cumplir al dedo los estándares y programar de forma estructurada y no intrusiva.

Creo que Rockstar se ha forrado tambien con la saga GTA, y el juego de PS2 y el de XBOX dudo que tengan 3 líneas de código iguales. ID se habrá forrado a base de vender los juegos y el engine, no por hacerlo multiplataforma.

Já! ¿sabes la de juegos de PS2 que utilizan el engine de Q3? ¿y de PC? Precisamente el engine vende porque es muy fácil crear con prácticamente el mismo código-arte pasar de una plataforma a otra. Lo mismo que con el engine del UT. Además... crear una versión de Linux de sus engines es solo una demostración de lo fácil que se puede portar, y lo hacen por eso.

El trabajo realizado para portar GTA a PC y XBOX fué costoso temporalmente, pero no únicamente por programar. Han tenido que rehacer muchos modelos para aumentar su detalle y redibujar texturas. El resultado es un juego mucho más detallado en PC y XBOX que en PS2... o al menos esa es la sensación que me dá al jugar. No se cuanto tiempo han destinado en reprogramar, pero si han tenido que modificar muchas cosas, mal planeado.

La gente vive de lo que gana. Pero creo que se están perdiendo muchos valores. La gente ya no avanza ni investiga, sigue caminos fáciles, ya creados... porque saben que al final hay buenas cantidades de dinero. Aunque, curiosamente, los que se arriesgan suelen triunfar.

Creo que apostar por los estándares multiplataforma, como OpenGL, a corto plazo se le saca beneficio. Obviamente, la perícia del programador también influye mucho.

Saludos!

Ya estabas tardando en aparecer Ruro... .

Y yo, que no sé nada de programación de videojuegos y muy poquito de programación en C, pregunto... ¿Qué define que un código sea más o menos portable? El otro día hablábamos de que las GTK eran muy portables, igual que ahora con los juegos... Y mi pregunta es esa... ¿qué hace que un juego sea más portable qué otro? ¿Qué diferencias ó qué hay que reprogramar para pasar de un sistema a otro?
No sé si es sólo cuestión de cumplir estándares, ó si hay alguna complicación más, porque si no... no lo entiendo.

Gracias! Salu2!

FuckingFreaky escribió:¿Qué define que un código sea más o menos portable?

Básicamente un codigo es portable cuando cumple con los estandares y no se excede en el uso de la API del sistema operativo (o mejor, no hace uso de ella), entre otros. Algo así como que es "autosuficiente".

El problema para mi de OpenGL es que funciona a base de extensiones, por eso decia lo de desactualizado, porque pelao se ha quedado anticuado, pero con extensiones esta al nivel de DX9 eso en ningun momento lo pongo en duda.
Creo que deberia ponerse como plataforma estandar algo un poco mas avanzado de lo que hay ahora, no me he leido las especs de OpenGL2 pero parece que sera un gran avance, pero no hay que estancarse y actualizar la base mas a menudo, estaria bien una vez por cada generacion de tarjetas graficas.
En mi opinion se usa mas DirectX que OpenGL, aparte de los posibles maletines y el hecho de que los programadores esten mas acostumbrados a esa API, porque esta mucho mas centralizado, mientras que las extensiones de OpenGL es un poco mas dificil seguirles la pista, no se si se me entiende.

Rurouni escribió:OpenGL no necesita "mejorar" o "actualizarse" más rápidamente... necesita que la gente sienta interés, y lo único que quiere es beneficio rápido. De ahí la filofía algo contraria "Estará acabado cuando lo esté" de John Carmack.

Crei que eso lo decian los del Duke Nukem

FuckingFreaky escribió:Y yo, que no sé nada de programación de videojuegos y muy poquito de programación en C, pregunto... ¿Qué define que un código sea más o menos portable? El otro día hablábamos de que las GTK eran muy portables, igual que ahora con los juegos... Y mi pregunta es esa... ¿qué hace que un juego sea más portable qué otro? ¿Qué diferencias ó qué hay que reprogramar para pasar de un sistema a otro?
No sé si es sólo cuestión de cumplir estándares, ó si hay alguna complicación más, porque si no... no lo entiendo.

Pues basicamente un codigo es portable cuando es estandar y no usa funciones propias y/o exclusivas del sistema operativo y/o APIs propietarias no estandars y/o cerradas.
En este caso tenemos juegos programados por un lado para Windows solamente, usando DirectX que es una API cerrada y sin version para Linux, normalmente un juego bien programado con DX solo usara funciones propias de la API de DirectX y muy pocas de Windows. Un juego programado usando OpenGL, si tenemos en cuenta que OpenGL esta disponible para muchas plataformas, usara llamadas a funciones OpenGL qeu son iguales en todas las plataformas, y para hacer un port solo hay que cambiar las llamadas a sistema que suele ser una parte minima del codigo. Luego coges el codigo, lo compilas en tu plataforma y ya esta.

Bien, para que un software pueda ser considerado portable lo primero que se debe hacer es definir muy bien la estructura de alto nivel. Es decir, definir muy bien las funciones que vamos a utilizar dentro de nuestro programa (abstracción) y separar muy bien las partes que no tengan nada que ver las unas con las otras (modularidad).

Ejemplo: Podeis crear una función que se llame "PonPixel( x, y )", la cual debe estar pensada para que no nececesite modificaciones a la larga. Es decir, hemos de asegurar que cuando creemos nuestra versión para windows, programando previamente en linux, no necesitemos modificar la función para llamarla "PonPixelWin( x, y )", con la consiguiente modificación en todos los softwares. Dentro de PonPixel no puede haber nada relacionado con, por ejemplo, el sistema de ventanas... eso ya lo hará la función encargada de pintar la pantalla con el mapa generado por un conjunto de "PonPixel".

El ejemplo es muy chorra, pero es, como su nombre indica, para ejemplificar.

Otro punto que se debe hacer es programar correctamente. Esto es una obviedad, pero no es tan habitual. Se necesita tener las ideas muy claras y depurar mucho. Que no aparezca ni un solo "warning" puede ayudar mucho. Los "warnings" son advertencias del compilador. No todos pueden dar lugar a error, pero merecen ser tomados en cuenta.

El tema de los estándares tiene el siguiente fundamento: deben cumplirse en todos los sitios por igual. Es decir... si dice que soporta OpenGL 2, el sistema/hardware en cuestión DEBE implementar de manera correcta las especificaciones de este. De otra forma el comportamiento de las aplicaciones sería muy distinto de uno a otro. Otro tema relacionado con este es que podemos llegar a conocer como funcionan los estándares hasta el punto de poder hacer una implementación al 100% de ellos, ya sea por soft o por hard. Si una tarjeta de video no tiene software OpenGL para esta, no hay nada que nos impida implentarla. Eso si, siguiendo las normas que nos imponen. Los estándares son eso: normas.

¿que hace que SDL sea tan portable? SDL no es que sea portable en si mismo, si no que las aplicaciones que usan las SDL son portables a una plataforma concreta en el primer momento que las SDL están portadas a esta plataforma. Esto es debido a lo que comentaba el primer punto: utilizamos abstracciones de una API sobre el software/hardware. Si programamos para Windows... la Win32 API es, a parte de horrible, muy sobrecargada y demasiado enlazada al sistema. En sistemas ANSI la entrada y la salida son las mismas. Solo fijaros en la función "main" de una y de otra. En aplicaciones windows tienen 5 parámetros de entrada, los ANSI 2. La API de Win32 es un estándard de facto... como lo son las SDL en el tema multiplataforma. Los estándares de verdad los definen consorcios (conjunto de empresas y usuarios expertos), y se modifican tras procesos largos en los que se estudia y reestudia cada posible cambio. Ahora las SDL están sufriendo un cambio de estructura de gobierno, pasando de ser una aplicación creada por una persona y mantenida por una comunidad a empezar un proceso de estandarización... será largo, pero se está empezando dentro de las mailing lists. A mi me gustan las SDL ya que te olvidas de la sintaxis de un SO o hard concreto, y te dedicas a programar el programa en cuestión... no entiendo como a la gente le gusta pelearse con la API de Windows para encasillarse en ella, y esto es una opinión personal.

Otro ejemplo sería utilizar las librerías STL para crear las estructuras internas de nuestra aplicación (arboles, grafos, vectores...), ya que estas son "estándard" y hay una normas de implementación, que se cumplirán (o deberían) en cualquier sistema. Esto nos ahorra mucho mucho tiempo en reinvención de la rueda, para cada sistema.

Y otro ejemplo más: OpenGL, a parte de implementar funciones para hablar con la pipeline gráfica, tenemos un conjunto de tipos (que en el fondo son MACROS) que substituyen a los tipos típicos: int, float, double... por GLint, GLfloat, GLdouble... esto es debido a que los tipos típicos pueden variar en la precisión a nivel de hardware. Por lo que si en lugar de los tipos típicos utilizamos los creados por la implementación OGL del sistema, nos aseguramos que la aplicación se comporte de la misma forma en uno y en otro aunque internamente cambien.

También para que algo sea portable debe DEGRADARSE. Esto significa que dependiendo del sistema en el que esté el programa debe saber como comportarse: bajar la calidad de los gráficos, el audio, las texturas, las luces, sombras... todo aquello que haga que el juego se COMPORTE de la misma forma sea cual sea la potencia del hard. Doom 3, o GTA es un buen ejemplo: en Doom 3 tenemos un sistema de LOD (Level Of Detail) tremendo, que degrada las mayas, bumpmappings, sombras... en tiempo real dependiendo de la carga del sistema; en GTA podemos ver como el frustrum se modifica en tiempo real para mostrar más o menos elementos... teniendo en PC una profundidad de cámara de kilómetros y en PS2 de escasos metros en algunas ocasiones.

Resumen: para que algo sea portable debe utilizar al máximo estándares que aseguren su buen funcionameniento allá donde vaya, usar librerias multiplataforma y saber degradarse.

Este tema está muy discutido, pero lo básico es eso.

Los señores de Raven e id lo saben bien... me sorprendieron mucho al utilizar las SDL en Q4... pasando a utilizar este: OpenGL, OpenAL y SDL. El trio portable.

El tema de las GTK lo sigo mucho últimamente: son MUY portables, pero estan algo mal pensadas. La API se ha complicado con el tiempo para acceder a nuevas características, lo cual ha hecho que incluso se ralentice y el programador se confunda. Las GTK están escritas en ANSI C 100% estándard y prácticamente nada se "apega" al hardware ni al sistema en el que esté. Los de las QT se lo han currado mucho, la API mejora con el tiempo y se hace más clara... pero tiene mucho "apego" a los sitemas portados... por lo que lo hace dificil ser portado (aunque se haga!).


Espero no haberos aburrido mucho. Saludos!


-------------
Contesto a los post que se han escrito mientras me caducaba la sesión

El problema para mi de OpenGL es que funciona a base de extensiones, por eso decia lo de desactualizado, porque pelao se ha quedado anticuado, pero con extensiones esta al nivel de DX9 eso en ningun momento lo pongo en duda.

Mucha gente cae en el mismo error: OpenGL no puede pensarse SIN extensiones. Es decir, cuando se habla de OpenGL se habla también de sus extensiones. La palabra "extensión" lleva a error: son funciones añadidas a la API 1.0. Podrían haberlo llamado OpenGL 8.0 a estas alturas como hace M$... pero han decidido hacerlo así, para diferenciar bien la API "mejorada" de la API original. Así los programas siempre serán reutilizables y mejorables. Porque lo que se busca es eso MEJORAR. Si cambias la API, los programas tienen que ser reprogramados, si simplemente le añades cosas, solo tienes que implementar los cambios si quieres las mejoraras.

Si programas en OpenGL debes aprender muy bien todas las posibilidades de este... lo que significa conocer todas sus extensiones. Y no es para tanto y vale la pena.

Resaludos!!!!



Siento el OFFTOPIC!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Si programar pensando en multiplataforma es un suicidio para las empresas de videojuegos ¿Como es posible que sólo media docena de programadores sean capaces de desarrollar un juego como Nexuiz para Windows, Linux y Mac?

Además, hoy en día tenemos PC, PS2, XBOX, Nintendo DS, PSP y las futuras PS3 y XBOX360 ... en mi opinión, no pensar en multiplataforma SI es un suicidio !

Joder Ruro, mil millones de gracias!!! Ha sido una explicación co-jo-nu...
De todo, entiendo que la parte más difícil sea la de degradarse, me equivoco?
Si al fin y al cabo el tema va de cumplir estándares, y poco más (amos, cosas que te pueden costar más esfuerzo, pero joé! si programas, programas bien!), no entiendo tantas cosas chapuceras que podemos ver por ahí. Bueno, supongo que debido a las prisas, falta de interés y demás...
Ya, por rizar el rizo una última preguntita para ti, que sé que estuviste interesado en la implementación de OpenGL para mono (OpenGL#). ¿Sabes qué rendimiento podría dar? Es que dentro de un tiempo me gustaría empezar a tocar cosas de videojuegos, en plan sencillo, y como toy tan enamorao de mono, valoraba la posibilidad de hacerlo con ello. Lo que más me tira para atrás son dos ucestiones:
- Rendimiento: Por parte del código me da más o menos igual... C#es algo más lento que C, pero con la pre-compilación de mono para generar el código nativo, espero que valga. Pero el tema de OpenGL# ya no sé cómo irá en cuestió nde rendimiento.
- Documentación: sin tener ni idea de programar nada de videojuegos y el hacerlo en C#, me d amiedo no encontrar mucha ayuda. La mayoría de la doc está basada en C/C++, y no sé si sabría "portar" esos conceptos luego a C#.

Pero vamos, que gracias por la explicación. Muy clara e instructiva!

NeoRazorX escribió:Además, hoy en día tenemos PC, PS2, XBOX, Nintendo DS, PSP y las futuras PS3 y XBOX360 ... en mi opinión, no pensar en multiplataforma SI es un suicidio !

Una buenísima afirmación.

Salu2!

Además, hoy en día tenemos PC, PS2, XBOX, Nintendo DS, PSP y las futuras PS3 y XBOX360 ... en mi opinión, no pensar en multiplataforma SI es un suicidio !

PS3 funciona con OpenGL ES... sólo con decir eso vereis la importancia de hacer bien las cosas. Aunque XBOX360 vaya con DX, los desarrolladores puede implementar OGL para esta. Pero lo importante ya no es programar en OGL o no en estos casos... sino el de modularizar bien: si se ha de cambiar a D3D o a un engine por software que sólo se cambien parte del código del engine gráfico.

FuckingFreaky escribió:Joder Ruro, mil millones de gracias!!! Ha sido una explicación co-jo-nu...

De nada!!!

De todo, entiendo que la parte más difícil sea la de degradarse, me equivoco?

Si... es el más duro... pero el que mejores resultados dá.

Si al fin y al cabo el tema va de cumplir estándares, y poco más (amos, cosas que te pueden costar más esfuerzo, pero joé! si programas, programas bien!), no entiendo tantas cosas chapuceras que podemos ver por ahí. Bueno, supongo que debido a las prisas, falta de interés y demás...

La gente se acostumbra bastante rápido a las cosas... entiendo que se acostumbren a no pensar demasiado en ciertas circumstáncias. Ojo, que no digo que no sea complicado programar en DX, pero tienes muchas cosas ya hechas.

Ya, por rizar el rizo una última preguntita para ti, que sé que estuviste interesado en la implementación de OpenGL para mono (OpenGL#). ¿Sabes qué rendimiento podría dar? Es que dentro de un tiempo me gustaría empezar a tocar cosas de videojuegos, en plan sencillo, y como toy tan enamorao de mono, valoraba la posibilidad de hacerlo con ello. Lo que más me tira para atrás son dos ucestiones:
- Rendimiento: Por parte del código me da más o menos igual... C#es algo más lento que C, pero con la pre-compilación de mono para generar el código nativo, espero que valga. Pero el tema de OpenGL# ya no sé cómo irá en cuestió nde rendimiento.
- Documentación: sin tener ni idea de programar nada de videojuegos y el hacerlo en C#, me d amiedo no encontrar mucha ayuda. La mayoría de la doc está basada en C/C++, y no sé si sabría "portar" esos conceptos luego a C#.

A ver... uhmm... C# es como JAVA en muchos aspectos, aunque tienes mayor acceso a hardware. Yo trabajaba en una implementación software de OGL para C# (Wrapper)... de esto hará 3 años... ahora hay implementacions que permiten acceder al hardware. El rendimiento de estas debe ser muy similar... para el proyecto del engine de BomberGUM (DarkPython) estoy investigando mucho de como realizar un entorno de diseño de escenarios en 3D (importando archivos de Blender) y por lo que veo puede ser bastante ágil... si se optimiza bien (que solo renderice cuando toca, vamos).

Estoy haciendo las especificaciones y modularizando la estructura del programa... te digo algo en breve para que veas como va.

¿Que tipo de juego quieres programar?

¿Casi que abrimos otro hilo, no? [;-)]

Saludos

Rurouni escribió:para el proyecto del engine de BomberGUM (DarkPython) estoy investigando mucho de como realizar un entorno de diseño de escenarios en 3D (importando archivos de Blender) y por lo que veo puede ser bastante ágil... si se optimiza bien (que solo renderice cuando toca, vamos).

Cómo te lo curras Ruro... Me encantaría verlo cuando empieces a liberar cosas de él.

Rurouni escribió:¿Que tipo de juego quieres programar?

Pues primeramente, un PCFútbol "in my way". Es algo que dentro de que no tengo ni idea, creo que es un juego más o menos fácil de hacer... Al fin y al cabo es inteligencia artificial (aunque ya digo que no tengo npi, no creo que sea mucho más compleja que la de cualquier otro juego), y mucha base de datos, nada más.
Luego más adelante y flipándome muchíiiiiiiiiiiiiiisimo, lo suyo sería hacer el motor para poder jugar partiditos... estilo FIFA ó Pro Evolution . Pero vamos, que eso de momento es algo que ni me planteo. Primero hacer cosas pequeñitas, y poco a poco, a ver si con tiempo pudiera construir ese manager. Luego... el tiempo dirá.

Rurouni escribió:¿Casi que abrimos otro hilo, no?

Hecho (no me odies mucho...).

Gracias!!!

Taluego!

Perdón por sacar a flote este hilo, pero creo que es importante

Si entras en los foros de Steam (http://forums.steampowered.com/forums/) y buscas "linux", te aparecen nada menos que 421 resultados !!!

El último de ellos se titula "Linux Steam beta", pero es solamente el source dedicated server

De todas formas, los foros arden de la cantidad de gente que pide una versión para linux de Steam y más ahora que Valve va a distribuir Darwiniana, que soporta linux.

Los foros de Darwiniana también piden a gritos una versión para linux de Steam.

Tambien me he enterado de que Valve estaba trabajando en un port para linux de half life, pero que lo abandonó para centrarse en Steam (que putada).

La verdadera importancia de Steam en linux no es por poder jugar al Counter Strike: Source en linux (que tambien es importante biggrin.gif ), sino que Steam sería la primera plataforma de distribución de videojuegos para linux, y eso es lo realmente importante.

Si estás ineresado en un port de Steam para linux, envía este modelo de email a [url=mailto:gaben@valvesoftware.com]Gabe Newell[/url] (este es su email público, para quien quiera comentarle algo):

Hello, i'm a Steam user.
I run Steam on linux with Cedega ( http://www.transgaming.com ), and i would like a Steam linux client to help developers to sell linux games.
I also want to said that i'm buying games for linux like Quake 4, and i would like to play Valve's games on linux.
bye.