Hola :)
Voy a empezar a hacer mi miniengine (TWIrr) sobre el engine IrrLicht (es decir, la estructura base sobre la que programar un futuro juego), usando como IDE el MS VC++ 2008 Express.
Soy novato en C++, soy novato en MS VC++ 2008 Express, soy novato en IrrLicht, he probado Linux un par de veces en mi vida, he usado un Mac creo que cinco minutos... pero quiero hacer un juego multiplataforma (Win-Mac-Linux) en C++ :o . Sí, bueno, suena a locura, pero no tengo dudas de que puedo conseguirlo, es cuestión de aprender lo necesario y delegar lo que no pueda aprender (sí, seguramente delegaré mucho, es un proyecto algo ambicioso y soy consciente de ello).
Bueno, teniendo en cuenta esta introducción, mi duda es: ¿qué cosas tengo que tener en cuenta a la hora de programar para que portarlo (en un futuro medio-lejano) de Win a Mac y Linux sea lo más simple posible?
IrrLicht es multiplataforma, así que el tema de inicialización de ventana, carga de modelos, render, etc, no debería ser problema.
Y el input tampoco, que también va en IrrLicht.
Para audio seguramente usaré IrrKlang, así que ídem.
Y para lectura y escritura de archivos voy a usar las funciones XML de IrrLicht también, que imagino que ya tendrá en cuenta temas de big endian y tal.
Donde tengo más dudas es en tema de variables (según tengo entendido los bits de cada tipo varían según IDE y/o SO), cosas de punteros que sean distintas según SO, o... no sé, ya digo que soy novato ::)
En definitiva, ¿consejos de los pro para un novato?
Gracias ;)
Buenas. Lo primero suerte con tu engine ;)
Bueno, no se si soy el mas indicado para decir esto, pero si lo quieres hacer multiplataforma te aconsejo usar un ide multiplataforma. De esta forma te aseguras de que el "proyecto" lo puedas compilar tal cual en todas las plataformas. A mi me encanta el visual studio, pero puede que a la hora de compilar en linux o en mac te vuelvas loco preparando el make de cero cuando tengas 1000 clases......sin embargo haciendolo con cada nueva clase se hace mas ligero.
SUERTE!!!
Pues... si estás usando un motor multiplataforma como base no creo que vayas a tener mucho problema. Mira a ver si el mismo motor te define los tipos de datos, que si es multiplataforma lo más normal es que te los defina él solito (Irrlicht te los define de hecho como un,sn,cn,fn según si son unsigned, signed, char o float de n bits) Por lo de punteros y demás, en teoría si te riges por el estándar no te vas a encontrar con nada raro, aunque eso es sólo en teoría :P. Aquí te dejo una guía de portabilidad de C++
https://developer.mozilla.org/En/C___Portability_Guide
Edito: A lo mejor esa guía es demasiado restrictiva para lo que tú quieres, así que tampoco te tomes al pie de la letra el 100% de lo que diga :)
CitarLo primero suerte con tu engine
Gracias :)
Citarsi lo quieres hacer multiplataforma te aconsejo usar un ide multiplataforma
Sí, ya me lo había planteado. Pero decidí usar el de MS porque tiene buena fama y, sobre todo, porque me dió la sensación de que era el "IDE oficial" para Windows en IrrLicht, aunque ya no estoy yo muy seguro...
¿Qué IDEs multiplataforma me recomendáis?CitarMira a ver si el mismo motor te define los tipos de datos, que si es multiplataforma lo más normal es que te los defina él solito (Irrlicht te los define de hecho como un,sn,cn,fn según si son unsigned, signed, char o float de n bits)
Sí, sí que tiene tipos definidos 8)
CitarAquí te dejo una guía de portabilidad de C++
Muy interesante, gracias. Aunque sí, hay muchas tiquismiqueces, me parece a mí ::)
¿Algún consejo más?
Ay mierda :P Suerte con el engine de mi parte también, que con la prisa de responder se me ha ido. Luego me extraña que me llamen descastao...
Cita de: tewe76 en 02 de Febrero de 2009, 11:27:50 AM
¿Qué IDEs multiplataforma me recomendáis?
Pues el Eclipse+CDT tira bastante bien. El port a Linux (y seguramente Mac, aunque tendría que preguntarlo) del Penumbra está hecho ahí. El IDE es una maravilla, muy completo, aunque he de reconocer que lo he usado más bien para Java y PHP, pero te aseguro que funciona :) También está Code::Blocks, bastante más ligero, y NetBeans (con el plugin para C/C++), aunque éste último no lo he probado.
Ahora mismo no se me ocurre nada más que decirte, supongo que si algo revienta vendrás a preguntar otra vez, ¿no? :P
Hola. Quizas este hilo pueda ayudarte algo: http://www.stratos-ad.com/forums/index.php?topic=10627.msg116377#msg116377 (http://www.stratos-ad.com/forums/index.php?topic=10627.msg116377#msg116377)
Y en cuanto a IDE, sin duda yo me quedo con code::blocks
Primero me autocito:
Citarme dió la sensación de que era el "IDE oficial" para Windows en IrrLicht
Sí, efectívamente los ejemplos vienen con MSVC++ en mente, así que creo que por ahora voy a seguir con él. No obstante, voy a echarle un vistazo a los que me recomendáis...
CitarQuizas este hilo pueda ayudarte algo
Me lo apunto también ;)
Yo no se que mas ides hay, en general vengo trabajando (bueno, en mi tiempo libre) con el vs2005 cuando codeo en c++ y el netbeans cuando lo hago en java, y la verdad es q estoy bastante contento con ambos. Lo unico que le echo en cara el vs (y principalmente por esto te lo digo) es que ultimamente en las compilaciones de consola que hago no puedo puedo decirle que vacie carpetas y recompile todo desde cero, sino empieza a dar problemas con el manifiest y tengo que guardando los archivos de codigo crear un proyecto nuevo y añadirlos. Una guarrada.
El netbeans no lo he utilizado para c, pero en java la verdad estoy muy contento. Tiene su ventanita para ver las variables internas de la clase que estas codeando, lo cual es muy comodo....y tamboen tiene el autocomplete cuando estas escribiendo (que aunque algunas veces molesta, al final acaba gustando xDD)
Bueno, suerte de todas maneras, ya nos contarás ^_^
Bueno, se agradece todo tipo de información, que no se me entienda mal, pero el tema del IDE lo considero secundario. Me interesa más el asunto de hacer código multiplataforma.
Por cierto:
- he probado en C::B y la primera impresión (5 minutos) no ha sido muy buena. ¿Qué fuente usa por defecto? 8o ¿F1 sobre una keyword no te abre la ayuda sobre esa palabra? Oo
- con el Eclipse+CDT no me aclaro bien: ¿tengo que descargar sólo ésto: http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/ganymedesr1 ? ¿O aparte tengo que descargar algo para el CDT? Lo he probado también un poco (la primera descarga) y, la misma duda, ¿F1 no da ayuda sobre el keyword? ???
Creo que me quedo con el MSVC++, me siento cómodo en él...
Yo hablo como poseedor de un motor multiplataforma y como programador desde hace siglos compilando para linux mis cosas.
Si es tu primer proyecto y tal... yo te recomendaría Eclipse + CDT. El plugin de C++ está muy avanzado y aunque eclipse utiliza Java y en Linux al menos en maquinas no potentes va fatal, siempre podrás llevarte el código con el IDE y compilarlo donde sea.
Lo único que tendrás que hacer será configurar los proyectos con Debug Win32 Release Win32, Debug Linux Release Linux.... etc
Ya que en las soluciones de Win32 hay que configurarlo para que use MinGW y ciertas cosas. Es más, compilando con GCC tu código siempre será standard y portable allá donde exista GCC.
Yo personalmente prefiero, de momento, utilizar VS 2008 + Vissual Assist porque se es mucho más productivo y el debugger, su interface visual del IDE es mucho mejor y se nota el €€€€ dinerito invertido. Luego ya tengo mis proyectos montados con eclipse y como con hacer "Refresh" coge todos los archivos... compilo y listos :)
Cita de: tewe76 en 03 de Febrero de 2009, 07:49:18 AM
Creo que me quedo con el MSVC++, me siento cómodo en él...
Pues si no tienes experiencia en C++ y programar multiplataforma, prepárate para morir... cuando quieras hacerlo.
Está aqui tio:
http://www.eclipse.org/downloads/
Eclipse IDE for C/C++ Developers (68 MB)
http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/ganymede/SR1/eclipse-cpp-ganymede-SR1-win32.zip
Te va a pegar un bocado! xD
A ver, que me estás liando ::)
CitarEclipse IDE for C/C++ Developers (68 MB)
http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/ganymede/SR1/eclipse-cpp-ganymede-SR1-win32.zip
Sí, ese es el que me he descargado. Tu link y el mío son distintos, pero llevan al mismo archivo.
Primero me dices:
CitarSi es tu primer proyecto y tal... yo te recomendaría Eclipse + CDT.
Citar"Creo que me quedo con el MSVC++, me siento cómodo en él..."
Pues si no tienes experiencia en C++ y programar multiplataforma, prepárate para morir... cuando quieras hacerlo.
Y luego me dices:
CitarYo personalmente prefiero, de momento, utilizar VS 2008 + Vissual Assist porque se es mucho más productivo y el debugger, su interface visual del IDE es mucho mejor y se nota el €€€€ dinerito invertido.
En qué quedamos ???
¿Por qué dices lo de "Pues si no tienes experiencia en C++ y programar multiplataforma, prepárate para morir... cuando quieras hacerlo."? ¿Qué problemas me puede dar?
Ah, y gracias :)
Y si usas el motor del Prompt? Asi podreis ayudaros mutuamente ;)
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.
Cita de: AK47 en 03 de Febrero de 2009, 01:35:32 PM
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.
CitarQuedamos 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.
Tanto Eclise como Code:Blocks tienen MUY buenas recomendaciones.
Cita de: tewe76 en 03 de Febrero de 2009, 03:24:39 PM
CitarQuedamos 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.
CitarTe 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.
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.
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?
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
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.
Cita de: Pogacha en 03 de Febrero de 2009, 08:47:52 PM
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:-)
CitarSi 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.
CitarSepara 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.
CitarTodo 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:
Citarutilizar 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...
CitarPero 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 ::)
Citarsi 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)
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.
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.
Citar¿Podrías decir más o menos cuánto te llevó pasarlo a Mac?
Julio te podra decir mejor, pero fue un trabajo fragmentado ...
Citar¿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.
CitarNo cuesta nada mantener dos proyectos separados
8o Me parece un poco exagerado. Si lo dejas en "No cuesta demasiado" entonces me convence más ;)
Citarel 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.
CitarSacar 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.
CitarSi 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.
CitarHabia 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?
Cita de: tewe76 en 04 de Febrero de 2009, 03:31:56 PM
CitarNo cuesta nada mantener dos proyectos separados
8o Me parece un poco exagerado. Si lo dejas en "No cuesta demasiado" entonces me convence más ;)
Citarel 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).
CitarLos 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.
Quizás no te estoy entendiendo bien, pero eso me suena a duplicar trabajo, peligro de que se te olvide modificar algo en los dos sitios, etc.
CitarLo 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
Ah, te refieres a estándar entre IDEs. Pensaba que te referías a entre SOs. A ver, la idea es que si haces algo en VC, para pasarlo a Mac tienes que adaptarlo tanto al nuevo SO como al nuevo IDE. En cambio, si lo haces en E+CDT, para pasarlo a Mac sólo tienes que adaptarlo al nuevo SO, por que el IDE es el mismo.
PS: ¿tú no tendrás ese "documento con informacion util sobre port a mac" que no encuentra Pogacha?
No me estás entendiendo... me refiero a que hay código C++ que Visual C++ acepta y compila perfectamente, y que GCC no aceptará y te soltará un error. Y viceversa. Y me refiero a C++ puro, sin entrar en APIs específicas de cada OS.
El documento al que hace referencia Pogacha lo teníamos antes en la web, pero lo quitamos. Aquí hay una versión antigua:
http://www.gamedev.net/reference/articles/article2281.asp
No es una guía de porting definitiva, tan solo una recopilación de pequeños fragmentos de código y consejos. En los comentarios del artículo hay más información útil:
http://www.gamedev.net/community/forums/topic.asp?key=featart&uid=2281&forum_id=35&Topic_Title=Handy+PC%2FMac+OS+X+Snippets+for+Indie+Development
Sí, sí te entiendo :) Usamos distintos significados de estándar, pero sé a lo que te refieres y estoy de acuerdo.
Gracias por los links.
Una preguntita: en alguno de los links que me habéis pasado, comentaban como un muy buen consejo para hacerlo multiplataforma, que los nombres de archivo de código (cpp, h, etc) sean sólo en minúsculas, porque hay IDEs (o compiladores, o SOs, no sé) que dan problemas si tienen mayúsculas.
¿Es así?
Y si lo es, ¿sería conveniente aplicar éso también a cualquiera de los nombres de archivo (o de carpeta) que use tu programa? Me refiero a los nombres de las imágenes, archivos 3D, oggs, etc.
Yo personalmente sigo la convención de escribir todos los nombres de directorios y ficheros en minúsculas, pero por comodidad y uniformidad más que nada.
¿Pero sólo los de código o también los de datos (imágenes, etc)?
Cita de: tewe76 en 06 de Febrero de 2009, 07:16:58 PM
Una preguntita: en alguno de los links que me habéis pasado, comentaban como un muy buen consejo para hacerlo multiplataforma, que los nombres de archivo de código (cpp, h, etc) sean sólo en minúsculas, porque hay IDEs (o compiladores, o SOs, no sé) que dan problemas si tienen mayúsculas.
¿Es así?
Y si lo es, ¿sería conveniente aplicar éso también a cualquiera de los nombres de archivo (o de carpeta) que use tu programa? Me refiero a los nombres de las imágenes, archivos 3D, oggs, etc.
Supongo que esto es para evitar problemas porque Windows no es sensible al caso con los ficheros pero Linux sip (así que si intentas compilar Hola.cpp y el fichero se llama hola.cpp en Windows compila y en Linux nop). Esto también lo tienes que recordar cuando desde tu código accedas a tus recursos (imágenes, música,...).
Un saludo!
Vicente
Sí, era por algo así.
Pero si intento compilar "Hola.cpp" y el fichero se llama efectívamente "Hola.cpp", ¿compilará bien en todos los casos?
Entiendo que lo importante entonces no es no usar mayúsculas, sino que si las uso lo tenga en cuenta al hacer las llamadas (cosa lógica :.. ) aunque en Windows no se queje. Es eso, ¿no? O sea, que no hay problema en sí, pero puede generar problemas por la "permisividad" de Windows que en Linux no vas a tener.
Cita de: tewe76 en 07 de Febrero de 2009, 07:14:07 AM
¿Pero sólo los de código o también los de datos (imágenes, etc)?
Todos. Eliminar las mayúsculas te evita pensar en cuándo tienes que utilizarlas y cuándo no, y en cuándo la distinción entre mayúsculas y minúsculas es importante.
Tener una convención para los nombres (tanto de recursos como de cualquier tipo de código) que incluya los casos de uso de mayúsculas y minúsculas es muy saludable en general.
Vale, pero la cuestión es que mientras escribas siempre bien los nombres, no importa si llevan o no mayúsculas, ¿no? El hecho de ponerlo en minúsculas sirve para eliminar posibilidades de error, pero todos los IDEs en todos los SOs van a admitir nombres con mayúsculas.
¿Lo he entendido bien?
Si
¡¡¡¡¡¡¡Bien!!!!!!! :o :o :o :o
:P
Solo decir que, no hay nada que compiles con GCC del lenguage C/C++ standard que no compile luego en Visual C. Porque GCC va de la mano del ANSI estrictamente.
Y lo bueno de Eclipse y Codeblocks, es que cogen el mismo arbol de directorios del HD para el proyecto, luego tambien puedes crear directorios virtuales pero me parece un error grave. Yo estoy hasta los mismos de eso en el VS. Y si, en XCode por lo tanto tienes que duplicar todo el trabajo, donde no, es usando eclipse o codeblocks ya que al hacer "refresh" carga la estructura del disco duro y solo le das al botoncito de compilar.
Para gustos los colores, yo comento lo que uso y algunos porqués. Como por ejemplo que habria que usar oooooooooooootro IDE si quiere portarlo a GNU/Linux. una barbaridad vamos...
Un saludo.
En realidad tu idea me parece lógica, Prompt. El motivo fundamental por el que he elegido la otra es porque, a corto plazo, me viene mucho mejor usar VC++, por las "ayudas" que da a los que no dominan aún el lenguaje. Si fuese un pro de C++ es bastante probable que usase Eclipse, por los motivos que das tú (a no ser que, justamente al ser un pro, me diese cuenta de limitaciones importantes que tuviese Eclipse, que es posible que las tenga).
En cualquier caso, muchas gracias por tu opinión 8). Como mínimo me ha servido para descargarme Eclipse y C::B y echarles un vistazo ;)
Cita de: Prompt en 09 de Febrero de 2009, 10:03:32 AM
Solo decir que, no hay nada que compiles con GCC del lenguage C/C++ standard que no compile luego en Visual C. Porque GCC va de la mano del ANSI estrictamente.
No es cierto. Si bien tanto g++ como MVC++ cumplen con casi la totalidad del estándar actual, este último reserva partes a la implementación de manera explícita.
En todo caso, habría que matizar el concepto de adecuación al estándar, que puede interpretarse de varias maneras.
Cita de: davur en 09 de Febrero de 2009, 08:09:12 PM
Cita de: Prompt en 09 de Febrero de 2009, 10:03:32 AM
Solo decir que, no hay nada que compiles con GCC del lenguage C/C++ standard que no compile luego en Visual C. Porque GCC va de la mano del ANSI estrictamente.
No es cierto. Si bien tanto g++ como MVC++ cumplen con casi la totalidad del estándar actual, este último reserva partes a la implementación de manera explícita.
En todo caso, habría que matizar el concepto de adecuación al estándar, que puede interpretarse de varias maneras.
Has tenido en cuenta, que la conio.h, threads o sockets no son ANSI?
Cita de: Prompt en 09 de Febrero de 2009, 08:24:14 PM
Cita de: davur en 09 de Febrero de 2009, 08:09:12 PM
Cita de: Prompt en 09 de Febrero de 2009, 10:03:32 AM
Solo decir que, no hay nada que compiles con GCC del lenguage C/C++ standard que no compile luego en Visual C. Porque GCC va de la mano del ANSI estrictamente.
No es cierto. Si bien tanto g++ como MVC++ cumplen con casi la totalidad del estándar actual, este último reserva partes a la implementación de manera explícita.
En todo caso, habría que matizar el concepto de adecuación al estándar, que puede interpretarse de varias maneras.
Has tenido en cuenta, que la conio.h, threads o sockets no son ANSI?
Te refieres a librerías que no forman parte del estándar. Yo me refiero a partes del estándar (http://www.google.es/url?sa=t&source=web&ct=res&cd=8&url=http%3A%2F%2Fopenassist.googlecode.com%2Ffiles%2FC%252B%252B%2520Standard%2520-%2520ANSI%2520ISO%2520IEC%252014882%25202003.pdf&ei=loKQSfX8KoS2jAem7f27Cg&usg=AFQjCNG4-cbawIu_O0_KwFqjXU6VG1cZDA&sig2=71L_wchYv0htx0nlPr220g) reservadas a la implementación como, por ejemplo, el tipo de std::set::iterator.
Hombre davur! hablamos de escribir std::iterator y que compile en ambas partes. El standard ANSI dice que debe existir eso porque es parte del lenguaje. Luego yá como se haga o no por dentro es cosa de cada S.O. existiendo una alternativa de código libre con GCC.
Pero es obvio que cada S.O. hace su propia implementación o usa una alternativa open source.
Yo creo que esto era obvio y no por ello deja algo de ser standard. 8)
Cita de: Prompt en 09 de Febrero de 2009, 08:47:36 PM
Hombre davur! hablamos de escribir std::iterator y que compile en ambas partes. El standard ANSI dice que debe existir eso porque es parte del lenguaje. Luego yá como se haga o no por dentro es cosa de cada S.O. existiendo una alternativa de código libre con GCC.
Pero es obvio que cada S.O. hace su propia implementación o usa una alternativa open source.
Yo creo que esto era obvio y no por ello deja algo de ser standard. 8)
¡Es que tampoco me refiero a eso!
Me refiero a que es posible escribir código que utilice std::set::iterator/std::set::const_iterator que compile en MVC++ y no compile en g++. El código es estándar, en el sentido de que se adecúa a la restricción de 'definido por la implementación' del estándar, pero no es portable entre compiladores.
Pues vas a tener que afinar más porque no me convence.
Por ejemplo en MSVC vector::erase devuelve el iterador al siguiente elemento. Cosa que aún parece ser que no es standard hasta la X0 (o como demonios se llame el nuevo standard), como GCC usa estrictamente el standard su implementación de vector::erase no devuelve el iterador al siguiente elemento. Cosa que jode, por cierto.
Pues MSVC vá y lo mete porque ve que es util, necesario y debe estar.
No se cual será el caso de ese set::iterator. Se me ocurren otros como de templates que el standard obliga a adjuntar typename en un determinado caso con ::iterator.
Todo esto se reduce a que si compila en GCC va a compilar en donde sea. Si nó, que me pongan un ejemplo!! ::)
Pero bueno, se por donde vas davur.
Un saludo.
Un ejemplo (que no es muestra de buen hacer, sino simplemente eso, un ejemplo algo artificial):
#include <iostream>
#include <iterator>
#include <set>
#include <string>
int main()
{
std::set<std::string> words;
std::string s;
while (std::cin >> s)
{
(*words.insert(s).first).append('#');
}
std::copy(words.begin(), words.end(), std::ostream_iterator<std::string>(std::cout, "\n"));
}
Este código compila en MVC++, pero no en g++. ¿Es estándar o no?
Será standard en el sentido que usa las palabras y estructuras standares pero evidentemente cada SO como he dicho implementará internamente eso de cierta manera. Yo me pre-supongo que hay una serie de restricciones a la hora de implementarlo para que siga siendo standard. Que creo que es a lo que te refieres, que ciertamente no lo es.
No obstante, mantengo aquello de "si compila en GCC va a compilar en MSVC", 99% :P no crees?
davur, fíjate que tú defiendes: "hay código estándar que no compila en GCC" y Prompt defiende: "el código que compila en GCC es estándar". No son cosas incompatibles, si lo miras bien, así que los dos tenéis razón ::).
Es que hay código estándar que no compila en g++, porque g++ no implementa todo el estándar. Y lo mismo se puede decir de todos los demás compiladores actuales de C++, excepto uno.
Y no todo el código que compila en g++ es estándar, porque éste también define sus extensiones particulares.
Pero por supuesto, en la mayoría de casos esto no tiene mayor importancia, porque en cuanto tu aplicación necesita acceso a la tarjeta gráfica (por ejemplo), ya te sales del ámbito del estándar.
Creo que sé la respuesta, pero a ver si me lo confirmáis: para hacerlo multiplataforma, lo mejor es que en las rutas se use siempre "/" en vez de "\", ¿no? ("Carpeta/Archivo" en vez de "Carpeta\\Archivo")
Cita de: tewe76 en 24 de Febrero de 2009, 06:42:57 PM
Creo que sé la respuesta, pero a ver si me lo confirmáis: para hacerlo multiplataforma, lo mejor es que en las rutas se use siempre "/" en vez de "\", ¿no? ("Carpeta/Archivo" en vez de "Carpeta\\Archivo")
En realidad, lo suyo sería que le preguntases al sistema operativo cual es su "separator char" y en las rutas usaras ese caracter. Pero vamos, creo que "/" te valdrá en todos los lados.
Un saludo,
Vicente
Gracias 8)
Cita de: tewe76 en 24 de Febrero de 2009, 06:42:57 PM
Creo que sé la respuesta, pero a ver si me lo confirmáis: para hacerlo multiplataforma, lo mejor es que en las rutas se use siempre "/" en vez de "\", ¿no? ("Carpeta/Archivo" en vez de "Carpeta\\Archivo")
Creo que es mejor que uses boost::filesystem. Mira aquí: http://www.boost.org/ Particularmente en http://www.boost.org/doc/libs/1_38_0/libs/filesystem/doc/index.htm
La idea es que usas un objeto "path" y él ya se encarga de convertir el formato del sistema operativo que sea.
Por ahora me quedo con la solución para vagos ::) . Pero tengo que echarle un vistazo a eso del boost, porque no paro de verlo por todos lados...
Gracias, de todas maneras :)
Hola.
Un ejemplo de cosa que compila en Visual y no en GCC:
typedef std::vector<Clase*, std::allocator<Clase*>> VECTOR; <-- SI EN VISUAL, NO EN GCC
typedef std::vector<Clase*, std::allocator<Clase*> > VECTOR; <-- SI EN VISUAL, SI EN GCC
Es sutil y una chorrada, un simple espacio entre >>... pero en visual me compilaba y NUNCA le dí más importancia hasta que ahora compilo con GCC y eso me da error... así que imaginate la de cositas que pueden salir...
Un saludo.
Hola.
Otra cosa buena de Codeblocks es que puedes compilar con el compilador de Visual ademas de con otros... ¿en Eclipse le puedo indicar que use el compilador de visual?.
Puede parecer una chorrada... pero en mi caso tengo que hacer una libreria que rule en windows/linux y ademas una DLL para que rule en .NET... asi que con Codeblocks podría tener el mismo IDE con diferentes configuraciones de compilación.
Un saludo.
[quote author=[Over] link=topic=11877.msg128927#msg128927 date=1236938161]
Hola.
Un ejemplo de cosa que compila en Visual y no en GCC:
typedef std::vector<Clase*, std::allocator<Clase*>> VECTOR; <-- SI EN VISUAL, NO EN GCC
typedef std::vector<Clase*, std::allocator<Clase*> > VECTOR; <-- SI EN VISUAL, SI EN GCC
Es sutil y una chorrada, un simple espacio entre >>... pero en visual me compilaba y NUNCA le dí más importancia hasta que ahora compilo con GCC y eso me da error... así que imaginate la de cositas que pueden salir...
Un saludo.
[/quote]
No es una chorrada. De hecho hay un punto dedicado a este tema en el futuro estándar del C++ (el C++0x).
http://en.wikipedia.org/wiki/C%2B%2B0x#Angle_bracket
Digamos que los del VisualC están ahora colaborando con la comisión de estandarización y hay muchas cosas del nuevo estándar que se han "colado" en el VisualC. Por ejemplo las enumeraciones fuertemente tipadas estaban ya en el VC2005. Prueba a poner esto:
enum MIENUM : unsigned char
{
uno, dos, tres
};
Y según leo en el blog de los del VisualC, para el VC10 ya van a poner las lambdas (¡por fin!), referencias de rvalues, etc.
Hola.
Ahora... el debugger de Visual está muy por encima del resto de debuggers... al menos yo en codeblocks el debugger que uso para GCC es una PUTA MIERDA. O yo no se usarlo... o es una castaña total :)
Un saludo.