Consejos para C++ multiplataforma

[Prompt]

Y si usas el motor del Prompt? Asi podreis ayudaros mutuamente  ;)

Mi motor no está preparado para hacer juegos directamente y tendria que "perder tiempo" explicando como usarlo. El día que termine un juego y esté toda la documentación lista, si.

[tewe76]

Quedamos en que, como yo tengo experiencia, uso VC++ pq es más productivo y mantengo el proyecto con Eclipse + CDT para compilar y modificar las cosas que sean necesarias.

Para ahorrarte disgustos, te recomiendo que desde el principio uses Eclipse + CDT.

A ver si ahora te entiendo: dices que, como IDE, es mejor el VC, pero para hacer las versiones multiplataforma no sirve (como es obvio), y tienes que "hacer cosas" para compilar tu proyecto VC en E+CDT. Pero como yo soy novato y no sé "hacer esas cosas", es mejor que use directamente E+CDT.
¿Es éso?

Si es así, supongo que podría darte la razón en el caso de que mi intención fuese publicar para multiplataforma ya. Pero no es así ni de lejos ::) . El proyecto está en pañales y mi primer objetivo es terminarlo para Windows. Pero, éso sí, intentando ir haciendo lo posible para que portarlo sea sencillo. Cuando llegue el momento de portarlo (de aquí a un tiempo, en el que supongo que ya controlaré mejor el tema de C++) ya pediré ayuda si no me aclaro.
De todas maneras es que ni el C::B ni el E+CDT me convencen, la verdad. Supongo que soy un malcriado del VB6 :P y quiero que el IDE me ayude más.

[josepzin]

Tanto Eclise como Code:Blocks tienen MUY buenas recomendaciones.

[Prompt]

Quedamos en que, como yo tengo experiencia, uso VC++ pq es más productivo y mantengo el proyecto con Eclipse + CDT para compilar y modificar las cosas que sean necesarias.

Para ahorrarte disgustos, te recomiendo que desde el principio uses Eclipse + CDT.

A ver si ahora te entiendo: dices que, como IDE, es mejor el VC, pero para hacer las versiones multiplataforma no sirve (como es obvio), y tienes que "hacer cosas" para compilar tu proyecto VC en E+CDT. Pero como yo soy novato y no sé "hacer esas cosas", es mejor que use directamente E+CDT.
¿Es éso?

Si es así, supongo que podría darte la razón en el caso de que mi intención fuese publicar para multiplataforma ya. Pero no es así ni de lejos ::) . El proyecto está en pañales y mi primer objetivo es terminarlo para Windows. Pero, éso sí, intentando ir haciendo lo posible para que portarlo sea sencillo. Cuando llegue el momento de portarlo (de aquí a un tiempo, en el que supongo que ya controlaré mejor el tema de C++) ya pediré ayuda si no me aclaro.
De todas maneras es que ni el C::B ni el E+CDT me convencen, la verdad. Supongo que soy un malcriado del VB6 :P y quiero que el IDE me ayude más.

Te digo lo que dije en un principio, sino tienes experiencia y lo vas a hacer 1º en windows y no directamente haciendo código standard y multiplataforma, vas a sufrir MUCHO y al final no compilarás mas q para windows.

[tewe76]

Te digo lo que dije en un principio, sino tienes experiencia y lo vas a hacer 1º en windows y no directamente haciendo código standard y multiplataforma, vas a sufrir MUCHO y al final no compilarás mas q para windows.

Hombre, es que justamente es por lo que abrí este hilo, para consejos sobre cómo escribir lo más estándar y mp (ya me cansé de escribir multiplataforma, que palabra más larga >:D). ¿Tanto me voy a desviar de lo estándar por usar el VC++? ??? Teniendo en cuenta que VOY a tener cuidado de no desviarme.

Quizás parezco pesado, pero es que, desde mi novatez ;), no terminas de convencerme.

[Prompt]

Te volvería a responder lo mismo, te lo digo desde la experiencia.

Es que el mismo compilador y linker no son iguales, visual studio auto gestiona ciertas cosas en el inicializador dinámico que te puede dar la puñeta por ejemplo, como a mi en esta ultima compilacion que he hecho con GCC.

Por crear una clase en un namespace, eso se inicializa antes que el mismo main, y no estan disponibles ciertas cosas, como es o prodría ser lógico. Pero el MSVC hace dios sabe que y te deja hacer esas cosas aunque dependan de otras librerias y mil cosas más...

Eso con GCC, por ejemplo da problemas. Peta nada más ejecutarlo. digamos que GCC es un compilador tonto y como tal siempre te obliga a no hacer burradas. Esto es muy bueno ya que ayuda a mantener cierta coherencia a la hora de escribir código. Por lo cual, te quitarás millones de problemas si trabajas desde el principio con Eclipse + CDT + GCC / MinGW

Ahora bien, si quieres darte la currada de mantener los 2 proyectos a la vez... allá tú, yo en tu situación no lo haría. Pero tienes que saber que quieres hacer y que propósito tienes.

[tewe76]

Vale, con ese ejemplo me he hecho más a la idea de lo que podría pasar.
Creo que lo que voy a hacer es:
1- Dar los primeros pasos en VC++ (aprovechando su ayuda contextual, etc)
2- Cuando me sienta cómodo, portar lo (poco) que lleve del proyecto a E+CDT
3- Continuar hasta el final con E+CDT

Y aquí me surjen dos dudas:
1- Si el programa me compila con E+CDT en Win, ¿es seguro que me va a compilar igual con E+CDT en Linux y Mac (sin contar con las diferencias propias de SOs, claro... me refiero al C++ puro y duro)?
2- Por lo que entiendo, en E+CDT puedes elegir si compilar con MinGW o GCC. ¿Alguna preferencia por alguno? Creo que MinGW es como una adaptación de GCC a Win, por lo que deduzco que es mejor entonces GCC... ¿o no?

[Pogacha]

Mi aporte muy personal:
Si estas apuntando a juegos casuales, olvidate de linux (no vale la pena).
Para Windows VC9.
Para Mac XCode.
Hace una abstracción del sistema operativo y APIs (si es que no lo hace el motor)
Separa codigo del juego con codigo del motor o librerias, en el codigo del juego no debe haber nada dependiente de la plataforma o api.
Todo el juego hacelo en Windows, y luego solo portalo a la otra plataforma, entre el ida y vuelta del port vas a detectar bugs y corregirlos tambien.
Saludos y suerte

[Marci]

Dejando al margen el tema del IDE (que al final termina siendo una cuestion de gustos y de usar el que te haga sentir más cómodo), una de las cosas más importantes para hacer desde el principio es lo que te ha dicho Pogacha. Siempre hay que separar el código standar (el que es multiplataforma) del código que depende del sistema operativo. En C++ puedes hacer esto de varias maneras y la verdad es que todo el tiempo que inviertas aqui va a ser tiempo bien empleado y que te va a facilitar mucho el trabajo porsterior.

Te puedo decir la forma en que yo lo he hecho. Probablemente no sea la mejor, ni las mas efectiva, pero es con la que yo me siento más comodo. En primer lugar divido todo el código del motor en módulos. Un módulo para matemáticas, otro de física, otro para crear el display, etc....

Para cada módulo tengo un directorio y en su interior tantas carpetas como plataformas quiero soportar. Un módulo tendría una estructura similar a esta:

Modulo de fisicas
|
__Linux
         |__Codigo especifico de linux
__Window
|          |__Codigo especifico de windows
|__Código multiplataforma
|__Interfaz comun para el codigo que depende del S.O.

Despues creo un proyecto para linux en el que añado el código especifico de linux, el codigo multiplataforma y el codigo de las interfaces. Este proyecto como es obvio solo compila para linux. De forma similar creo un proyecto especifico para windows.

Como ya te dije antes, esta es la forma en que yo lo hago. Hay bastantes maneras, incluso se puede crear un único proyecto, con archivos en los que "mezclas" el código nativo de linux y su equivalente en windows y mediante #ifdef se le dice al compilador que código debe compilar segun el sistema operativo.

[Prompt]

Mi aporte muy personal:
Si estas apuntando a juegos casuales, olvidate de linux (no vale la pena).
Para Windows VC9.
Para Mac XCode.
Hace una abstracción del sistema operativo y APIs (si es que no lo hace el motor)
Separa codigo del juego con codigo del motor o librerias, en el codigo del juego no debe haber nada dependiente de la plataforma o api.
Todo el juego hacelo en Windows, y luego solo portalo a la otra plataforma, entre el ida y vuelta del port vas a detectar bugs y corregirlos tambien.
Saludos y suerte

Estoy totalmente en desacuerdo, de hecho es muy pero que muy absurdo. Tribal Trouble es un ejemplo claro de como vende un juego indie en Linux. Es más utilizar IDEs que solo están disponibles en windows y mac es absurdo, cuando puedes tener 1 único IDE, eclipse y encima compilando con GCC, solo tienes que iniciar sesión en el SO y darle a compilar. Evidentemente el código debe estar preparado.

Pero vamos, es automático si compila con GCC va a compilar en todas partes. Eso que dices, es contra producente totalmente. Es más si le compila en GCC por qué no va a compilarlo en Linux y sacar tajada de ese mercado?

Como digo, el Tribal Trouble este, el número de ventas de Linux + Mac == Windows.  0:-)

[tewe76]

Si estas apuntando a juegos casuales, olvidate de linux (no vale la pena).

Estoy de acuerdo, mi orden de prioridades es Win - Mac - Linux. Es simplemente que no quiero descartar Linux desde un principio. Además, yo creo que Linux cada vez va a más.

Separa codigo del juego con codigo del motor o librerias, en el codigo del juego no debe haber nada dependiente de la plataforma o api.

Sí, lo tengo en cuenta.

Todo el juego hacelo en Windows, y luego solo portalo a la otra plataforma, entre el ida y vuelta del port vas a detectar bugs y corregirlos tambien.

Supongo que esa es tu experiencia con Dylo y Airport, así que funcionar funciona ;) ¿Podrías decir más o menos cuánto te llevó pasarlo a Mac? ¿Algún problema en concreto que te diese mucho trabajo?

A Marci:
Tu metodología me gusta, es bastante intuitiva. No obstante, creo que con ifdefs me podría apañar bastante bien, fundamentalmente porque creo que de casi todo lo multiplataforma se encarga el irrlicht. En el fondo, el 95% de lo que tengo que programar es la lógica del juego, que no debería tener problemas de incompatibilidades excepto en temas de variables, etc. Hablo desde el desconocimiento, éso sí :-[

A prompt:

utilizar IDEs que solo están disponibles en windows y mac es absurdo, cuando puedes tener 1 único IDE,

Suena totalmente razonable. El único motivo para no hacerlo así es que ese "único IDE" te resulte incómodo y te compense más trabajar en dos "cómodos". Así que al final es cuestión de gustos...

Pero vamos, es automático si compila con GCC va a compilar en todas partes.

Repito mi pregunta anterior: ¿MinGW o GCC? GCC, supongo... ¿O quizás es que no hay GCC para Win y por éso se usa MinGW? ??? No tengo ni idea del tema ::)

si le compila en GCC por qué no va a compilarlo en Linux y sacar tajada de ese mercado?

Bueno, no hay que olvidar que "soportar" Linux no es sólo "compilar para Linux". Pero sí, si tu juego funciona en Linux es claramente tentador intentar vender también esa versión.

PS: gracias por todas las respuestas, ¿eh? 8)

[Zaelsius]

Yo opino como Pogacha, lo mejor es usar las mejores herramientas disponibles en cada OS (Visual Studio y Xcode/GCC). No cuesta nada mantener dos proyectos separados, y tanto VC como Xcode te permiten ajustar fácilmente muchos parámetros específicos para cada plataforma. Además, el hecho de usar dos compiladores distintos siempre dará como resultado un código mucho más estándar y más limpio de errores. Trust me, I know.

Sobre el tema de Linux. Tribal Trouble es un caso concreto, no se puede generalizar a partir de un solo juego. Hoy por hoy, Linux sigue sin ser un mercado interesante *para la mayoría de juegos casuales descargables*. Sacar un juego para Linux no solo implica compilarlo y que funcione, también tienes que dar soporte a los clientes y si ya con Windows el ratio de support requests y devoluciones es sustancial, no quiero imaginarme en Linux (con cientos de miles de combinaciones de software y hardware posibles). Tribal Trouble está programado en Java, supongo que por ahí se ahorran ya bastantes problemas.

[Pogacha]

Si el juego es Casual, no va a vender fuera de los portales, podes buscar un portal que distribulla juegos para linux ...
Una cosa es las ganas y orgullo de los linuxeros de linux y otra cosa es lo comercialmente rentable.
Si el juego es mas indie que casual puede que sea diferente, pero aun asi por las estadisticas de la gente que vende juegos indie en linux es mas desmoralizante que otra cosa.

Igual es preferible centrar los esfuerzos en sacar un mejor juego que que ande en linux, el mercado de casuales descargables es un mercado hit-driven, o sea que mientras mas mejor. Si el juego es un exito total, despues pagale a un estudio que te haga el port a linux, sino no vale la pena.

La mejor plataforma de desarrollo te la da el VC, por lejos, no te conviene desarrollar en otra cosa, una vez que tengas el juego andando, utiliza otro compilador e IDE para el port (ya lo explico bien Julio). Tanto en Dylo's Adventure y Airport Mania, Julio hizo el port a Mac.

¿Podrías decir más o menos cuánto te llevó pasarlo a Mac?

Julio te podra decir mejor, pero fue un trabajo fragmentado ...

¿Algún problema en concreto que te diese mucho trabajo?

Basicamente la mejor metodologia seria arma la estructura para que sea multiplataforma y luego no vuelvas a tocar nada especifico de otra plataforma hasta que no termines con el juego, una vez terminado 100%, escribes el codigo correspondiente de cada plataforma diferente y buscas bugs y demas.
Algunos de los problemas fueron por no hacer esto al 100%, hacer modificaciones que llevaron a modificaciones del port y luego vuelta atraz.

Sobre problemas del port, que recuerde fueron wide strings (en mac tienen 4 bytes y no lo habia tenido en cuenta en un principio), NULL por NIL es engañoso tambien. Desde luego tenes que tener cuidado con el endianess, aun que los power pc parecen estar desapareciendo.
El resto de los problemas lamentablemente no me enteré gracias a Julio, supongo el podra darte mas detalles. Habia redactado el un documento con informacion util sobre port a mac pero no lo encuentro.

PS: Me olvidaba, el XCode tambien tiene buenas herramientas de desarrollo que te serviran para tunear el juego una vez terminado.

[tewe76]

No cuesta nada mantener dos proyectos separados

8o Me parece un poco exagerado. Si lo dejas en "No cuesta demasiado" entonces me convence más ;)

el hecho de usar dos compiladores distintos siempre dará como resultado un código mucho más estándar

Esto también me parece exagerado, por ilógico. Si usas un compilador único que compila bien en los tres OS, por narices te tiene que dar código estándar.

Sacar un juego para Linux no solo implica compilarlo y que funcione, también tienes que dar soporte a los clientes

Sí, ya se lo comenté a Prompt. Desde luego no es mi target principal.

Si el juego es un exito total, despues pagale a un estudio que te haga el port a linux, sino no vale la pena.

Es lógico. Aunque si lo haces desde un principio pensando en eso, más fácil lo tendrás.

Habia redactado el un documento con informacion util sobre port a mac pero no lo encuentro.

No entiendo bien la frase, supongo que te refieres a que "Julio había redactado". Estaría bien tenerlo...


Bueno, mi conclusión entonces sobre IDE es que fijo fijo que voy a empezar con VC++. Cuando lo tenga más adelantado, me volveré a plantear pasarlo a E+CDT, aunque visto lo visto es probable que continúe en VC++. Lo siento, prompt, pero es que Po y Zae tienen juegos comerciales a sus espaldas y tú, creo, todavía no ;) Además, su consejo me viene mejor que el tuyo, se acerca más a mi prejuicio original :P

De todas formas, me he quedado con la duda: ¿MinGW o GCC?

[Zaelsius]

No cuesta nada mantener dos proyectos separados

8o Me parece un poco exagerado. Si lo dejas en "No cuesta demasiado" entonces me convence más ;)

el hecho de usar dos compiladores distintos siempre dará como resultado un código mucho más estándar

Esto también me parece exagerado, por ilógico. Si usas un compilador único que compila bien en los tres OS, por narices te tiene que dar código estándar.

Los proyectos de Visual Studio y Xcode los creas solo una vez al principio, luego solo tienes que ir incorporando nuevos ficheros .cpp según avanzas en la implementación.

Lo del código más estándar con distintos compiladores, es por que que aunque no lo creas, hay bastante código que en Visual C++ compila y en GCC no, y viceversa (si bien las diferencias entre VC9 y GCC 4 son menores que las que había en su día entre GCC 3.X y VC6 por ejemplo).