interfaz graficos graficar grafica dev como c++ graphics 3d real-time

graficos - ¿Cuál es la mejor alternativa a C++ para la programación de gráficos en tiempo real?



graficos en codeblocks (30)

Si su objetivo es una PC, creo que puede probar C #, o incrustar Lua en su aplicación C ++ y ejecutar scripts para cosas de "alto nivel". Sin embargo, si su objetivo es una consola, ¡ debe gestionar su propia memoria!

C ++ simplemente apesta demasiado de mi tiempo al hacerme microgestionar mi propia memoria, haciendo que escriba demasiado (hello std::vector<Thingy>::const_iterator it = lotsOfThingys.begin() ), y std::vector<Thingy>::const_iterator it = lotsOfThingys.begin() con long tiempos de compilación. ¿Cuál es la mejor alternativa para la programación gráfica seria en tiempo real? La recolección de basura es imprescindible (como lo es la capacidad de evitar su uso cuando sea necesario), y la velocidad debe ser competitiva con C ++. Una historia razonable para acceder a las bibliotecas de C también es imprescindible.

(Divulgación completa: tengo mi propia respuesta a esto, pero estoy interesado en ver lo que otros han encontrado como buenas alternativas a C ++ para el trabajo de gráficos en tiempo real).

Editar: Gracias a todos por las respuestas reflexivas. Dado que realmente no hay una respuesta "correcta" a esta pregunta, no seleccionaré ninguna respuesta en particular. Además elegiría el idioma que me gusta como alternativa de C ++, lo cual no sería realmente justo.


La recolección de basura es imprescindible (como lo es la capacidad de evitar su uso cuando sea necesario)

No puede desactivar un recolector de basura temporalmente. Necesitarías un recolector de basura determinista entonces. Pero tal bestia viene con un golpe de rendimiento también. Creo que BEA JRockit es una bestia y entonces debes apegarte a Java.

Solo para comentar tu ejemplo; typedef es tu amigo ...

typedef std::vector<Thingy> Thingys; Thingys::const_iterator it = lotsOfThingys.begin()


A veces, mirando fuera del camino trillado puede encontrar una verdadera joya. Es posible que desee considerar PureBasic (no permita que el nombre lo engañe). Aquí hay algunos detalles:

Funciones de PureBasic

  • Ejecutables de Código de Máquina (Ensamblaje) (FASM)
    • Soporte de montaje en línea
    • No se necesitan tiempos de ejecución (no se necesitan archivos DLL, etc.) 1 archivo ejecutable
    • Pequeños ejecutables (tan pequeños o más pequeños / tan rápidos o más rápidos que C ++ sin el tiempo de ejecución)
    • Puedes escribir archivos DLL
    • Soporte multi-thread
    • Soporte completo de API de SO
  • Soporte multiplataforma
    • Windows 95-2003
    • Linux
    • Mac OS X
    • Amiga
  • Desarrollo de juegos 2D y 3D
    • DirectX
    • OGRO
  • Generoso Licenciamiento
    • Económico (79 euros o alrededor de $ 112)
    • Licencia de por vida (todas las actualizaciones y versiones futuras incluidas)
    • Un precio para todas las plataformas
  • Soporte de biblioteca externa
    • DLL de terceros
    • Bibliotecas de usuario
  • Soporte en línea
    • Equipo de desarrollo receptivo liderado por su creador
    • Foro en línea
      • Un lugar para respuestas (no tiene que ir por toda la red)
      • Gran cantidad de código de muestra (intente con el código mientras está en IE con IEtool)
      • Respuestas rápidas a preguntas
  • Aprendizaje adicional (alternativa al aprendizaje C ++)
    • API
    • Estructuras
    • Interfaces
    • Punteros

Visite el foro en línea para obtener una mejor idea de PureBasic ( http://www.purebasic.fr/english/index.php ) o del sitio principal: www.purebasic.com


Al igual que James (hopkin), para mí, el enfoque híbrido es la mejor solución. Python y C ++ son una buena opción, pero funciona otro estilo como C # / C ++. Todo depende de tu contexto gráfico. Para juegos, XNA es una buena plataforma (limitada a win32), en este caso C # / C ++ es la mejor solución. Para la visualización científica, se acepta Python / C ++ (como las vinculaciones de vtk en python). Para el juego para dispositivos móviles JAVA / C ++ puede funcionar ...


Algunas variaciones de Lisp que se compilan en código máquina podrían ser casi tan rápidas como C ++ para este tipo de programación. El equipo Naughty Dog creó una versión de Lisp llamada Game Oriented Assembly Lisp , que usaron para crear varios títulos AAA, incluidas las series Jak y Daxter. Los dos principales impedimentos para un enfoque Lisp en la industria del juego serían la naturaleza arraigada del desarrollo C / C ++ (tanto las herramientas como los recursos humanos están fuertemente invertidos en C / C ++), así como la dificultad de encontrar ingenieros con talento que sean estrellas en tanto el dominio de programación del juego como el lenguaje Lisp.

Muchos equipos de programación en la industria están cambiando a un enfoque híbrido en el que el código en tiempo real, especialmente los gráficos y el código físico, está escrito en C o C ++, pero la lógica del juego se hace en un lenguaje de scripting de nivel superior. editable por programadores y no programadores por igual. Lua y Python son ambos populares para el scripting de alto nivel.


C # es un lenguaje agradable que se ajusta a sus requisitos, y es definitivamente adecuado para gráficos, gracias a los esfuerzos de Microsoft por proporcionarle excelentes herramientas y bibliotecas como Visual Studio y XNA.


C # es una buena respuesta aquí. Tiene una colección de basura justa (aunque tendrías que darle un perfil un poco - para cambiar la forma en que manejas las cosas ahora que todo el manejo de la memoria está fuera de tus manos), es simple usar, tener muchos ejemplos y está bien documentado. En el departamento de 3D da soporte completo para sombreadores y efectos, y así, esa sería mi elección.

Aún así, C # no es tan eficiente como C ++ y es más lento debido a la sobrecarga, así que si es la velocidad y la flexibilidad para usar cualquier truco en el libro que te gusta (con punteros y ensamblaje si te gusta ensuciarte las manos): C ++ y el precio estarían escribiendo mucho más código como lo mencionaste, pero teniendo control total sobre todo, incluida la gestión de la memoria.


Estoy totalmente de acuerdo con la mención de C # para la programación de gráficos. Tiene la ligera desventaja de ser un lenguaje administrado y permitir que el recolector de basura libre sobre su aplicación es un suicidio de framerate después de un tiempo, pero con algunas asignaciones de pools relativamente inteligentes realizadas al principio de la vida del programa, se pueden evitar problemas reales.

Varias personas ya han mencionado a XNA, que es increíblemente amigable y está bien documentado, y me gustaría hacerme eco de esa recomendación también. Personalmente lo estoy usando para mis proyectos de juegos de hobby y me ha tratado muy bien.

XNA no es la única alternativa, sin embargo. También está SlimDX, que se encuentra en constante desarrollo como un medio para proporcionar una capa delgada de DirectX de forma similar a Managed DirectX (que, en mi opinión, fue suspendida por Microsoft a favor de XNA). Ambos son dignos de investigación: http://code.google.com/p/slimdx/


La recolección de basura en tiempo real no coincide muy bien, me temo.

Es un poco difícil ofrecer garantías de respuesta en tiempo real si un recolector de basura puede ingresar en cualquier momento y gastar una cantidad indefinida de procesamiento ...


No descartaría C ++. De hecho, consideraría agregar Boost a su biblioteca C ++, lo que hace que el lenguaje sea mucho más útil. Tu ejemplo sería:

BOOST_FOREACH( Thingy& t, lostOfThingys ) { // do something with ''t'' }

Boost tiene toneladas de herramientas que ayudan a que C ++ tenga un mejor lenguaje.


No hay verdaderas alternativas para grandes títulos AAA, especialmente en las consolas. Para títulos más pequeños, C # debería funcionar.


Objective-C parece una buena combinación para sus requisitos (la última versión con GC opcional), aunque es muy dinámica y parecida a Smalltalk para mi gusto.


Quizás un enfoque híbrido. Python y C ++ hacen una buena combinación (ver, por ejemplo, PyGame).


Si se dirige a Windows, C ++ / CLI (el dialecto "administrado" .NET de Microsoft de C ++) es una posibilidad interesante, particularmente si desea aprovechar su experiencia en C ++. Puede mezclar código nativo (por ejemplo, llamadas a bibliotecas de estilo C) con el código administrado .NET sin interrupciones, y aprovechar .NET GC y las bibliotecas.

En cuanto a las preocupaciones sobre el impacto de GC en el rendimiento en "tiempo real", creo que tienden a ser exageradas. El GC multigeneracional .NET es muy bueno para nunca tomarse demasiado tiempo para hacer una recopilación, a menos que se encuentre en algún tipo de situación crítica de poca memoria. Escribo un código .NET que interactúa con los intercambios de derivados electrónicos, donde el tiempo demora == un montón de $$$, y nunca hemos tenido un problema relacionado con el GC. Unos pocos milisegundos es un tiempo largo, largo para el GC, pero no para un ser humano que interactúa con un software, incluso un juego en "tiempo real". Si realmente necesita un verdadero rendimiento "en tiempo real" (para dispositivos médicos, control de procesos, etc.), entonces no puede usar Windows de todos modos, simplemente no es un sistema operativo en tiempo real.


XNA es tu mejor apuesta, creo. Siendo compatible con .NET framework, puedes construir para una plataforma Windows o Xbox 360 simplemente cambiando una configuración en Game Studio. ¡Mejor aún, todas las herramientas son gratis!

Si decide ir con XNA, puede comenzar fácilmente a utilizar su guía de inicio rápido XNA Guía de inicio rápido

Ha sido una experiencia gratificante y divertida para mí hasta ahora, y un agradable descanso de la gestión de memoria de C ++.


Yo diría que el lenguaje de programación D es una buena opción. Puede vincular archivos de objeto C e interfaz con código C ++ a través de bibliotecas C. D tiene recolección de basura, ensamblado en línea y los desarrolladores de juegos han creado enlaces a las bibliotecas SDL y OpenGL, y también están trabajando activamente en nuevas aplicaciones de desarrollo de juegos. Me encanta D. Lástima que mi trabajo no exija su uso. :(


Muchos motores de juegos pueden adaptarse a tus necesidades, supongo. Por ejemplo, usando SDL o Cairo, si se necesita portabilidad. Muchos lenguajes de scripting (que vienen en general con sintaxis fácil y recolección de basura) tienen un enlace a este lienzo.
Flash podría ser otra alternativa.

Simplemente señalaré Processing , que es un lenguaje y entorno de programación de código abierto para las personas que desean programar imágenes, animaciones e interacciones.

En realidad, es una envoltura delgada alrededor de Java, lo que lo hace parecer un lenguaje de scripting: tiene un IDE (primitivo) cuando puede escribir unas pocas líneas de código y presionar Ejecutar sin siquiera tener que guardar el archivo. En realidad, envuelve el código alrededor de una clase y agrega una llamada main (), la compila y la ejecuta en una ventana.

Mucha gente lo usa para exhibiciones en tiempo real (VJ y similares). Tiene el poder y las limitaciones de Java, pero agrega una variedad de agradables envoltorios (bibliotecas) para simplificar el acceso a Java2D, OpenGL, SVG, etc.

De alguna manera, se ha convertido en un modelo de lenguaje de gráficos simple: hay varias aplicaciones que intentan imitar el procesamiento en otros idiomas, como Ruby, Scala o Python. Una de las más impresionantes es la implementación de JavaScript, que utiliza el componente canvas implementado en Firefox, Safari, Opera, etc.


No olvidemos mencionar el nuevo uso ''automático'':

auto it = lotsOfThingys.begin(); // Let the compiler figure it out. auto it2 = lotsOfFoos.begin(); if (it==it2) // It''s still strongly typed; a Thingy iter is not a Foo iter.


No pases por alto idiomas independientes en tu búsqueda. Emergence BASIC de Ionic Wind Software tiene un motor DirectX 9 incorporado, admite OOP y puede interactuar fácilmente con las bibliotecas de C.

http://www.ionicwind.com

James.


Como desarrollador / investigador / profesor de aplicaciones 3D VR durante unos 20 años, sugeriría que no hay alternativa (excepto posiblemente C). La única forma de reducir la latencia y habilitar la interacción en tiempo real es un lenguaje compilado optimizado (por ejemplo, C o C ++) con acceso a una biblioteca de gráficos 3D rápida y relatable, como OpenGL. Aunque estoy de acuerdo en que es necesario tener que codificar todo, esto también es esencial para el rendimiento y la optimización.


El mejor entorno para su proyecto es el que realiza su tarea de la manera más rápida posible. Esto, especialmente para gráficos 3D, incluye bibliotecas.

Dependiendo de la tarea, puede salirse con la suya con algunos pequeños hackeos de directx. Entonces podrías usar .NET y slimdx . Los lenguajes administrados tienden a ser más rápidos de programar y más fáciles de depurar.

¿Quizás necesites un motor 3D realmente bueno? Pruebe Ogre3D o Irrlicht . Necesitas calidad comercial (se podría argumentar que Ogre3D ofrece eso): ve a Cryengine o Unreal. Con Ogre3D e Irrlicht es posible que utilice .NET también, aunque los puertos no siempre están actualizados y los complementos no se incluyen tan fácilmente como en las versiones de C ++. Para Cryengine / Unrealengine no tendrás una elección real, supongo.

¿Lo necesitas más portátil? OpenGL para el rescate, aunque es posible que necesite un contenedor (por ejemplo, SDL ).

¿Necesitas una GUI también? wxWidgets , QT podría ser una posibilidad.

¿Ya tienes una cadena de herramientas? Sus bibliotecas deben ser capaces de manejar los formatos de archivo.

¿Quieres escribir una biblioteca? C / C ++ podría ser una solución, ya que la mayor parte del mundo puede usar librerías C / C ++. Tal vez con el uso de COM?

Todavía hay muchos proyectos / bibliotecas que no mencioné (XNA, Boost, ...) y si desea crear algún programa que no solo muestre gráficos en 3D, también podría tener otras necesidades (Entrada, Sonido) , Red, AI, Base de datos, GUI, ...)

Para resumir: un lenguaje de programación es una herramienta para alcanzar un objetivo. Tiene que ser visto en el contexto de la tarea en cuestión. La tarea tiene sus propias necesidades y estas necesidades pueden elegir el idioma por usted (por ejemplo, necesita una determinada biblioteca para obtener una característica que le lleva mucho tiempo programar y solo puede acceder a la biblioteca con el lenguaje X).

Si necesita el one-does-almost-all: pruebe C ++ / CLI (quizás en combinación con C # para una sintaxis más fácil).


He utilizado con mucho éxito C ++ para el motor, con la aplicación escrita en Lua en la parte superior. JavaScript también es muy práctico, ahora la última generación de motores JS basados ​​en JIT se encuentran alrededor (tracemonkey, V8, etc.).

Creo que C ++ estará con nosotros por un tiempo todavía; incluso Tim Sweeney aún no ha cambiado a Haskell (pdf), AFAIK :-)



Buena pregunta. En cuanto a "hacerme escribir demasiado", C ++ 0x parece abordar la mayor parte de lo mencionado:

auto it = lotsOfThingys.begin ()) // ... deduce el tipo, al igual que en * ML VS2010beta ya lo implementa.

En cuanto a la administración de memoria, para eficiencia, deberá mantener un buen seguimiento de las asignaciones de memoria, con o sin recolección de elementos no utilizados (es decir, crear agrupaciones de memoria, reutilizar objetos asignados a veces) de modo que eventualmente su entorno sea basura coleccionado o no, importa menos. También deberá llamar explícitamente a gc () para evitar que la memoria se fragmente. Tener formas consistentes de administrar la memoria es importante en cualquier lugar. RAII - es una característica clave de C ++ Otra cosa - es que la memoria es solo un recurso, usted todavía tiene que hacer un seguimiento de otros recursos con un GC, por lo que RIAA.

De todos modos, C # - es una buena alternativa en muchos aspectos, me parece un lenguaje muy agradable, especialmente la capacidad de escribir código de estilo funcional en él (la linda sintaxis lambda ->, mapa / seleccionar ''LINQ'' sintaxis, etc.), por lo tanto la posibilidad de escribir código paralelo; si bien sigue siendo un ''paréntesis estándar'', cuando usted (o sus colegas) lo necesitan.


Yo voto c ++ 0x. El soporte parcial ya está disponible en gcc-4.3 + usando el indicador -std = c ++ 0x.


No estoy de acuerdo con tu premisa. Cuando se usa cuidadosa y correctamente, C ++ es un excelente lenguaje, especialmente para un dominio como los gráficos en tiempo real, donde la velocidad es esencial.

La administración de la memoria se vuelve fácil si usted diseña bien su sistema y utiliza contenedores STL y punteros inteligentes.

std::vector::const_iterator it = lotsOfThingys.begin()) será mucho más corto si usa

using namespace std;
typedef vector::const_iterator ThingyConstIter;

Y puede acortar los tiempos de compilación de forma significativa al dividir sus sistemas en módulos razonablemente autónomos, mediante el uso de encabezados precompilados, o mediante el uso de la expresión idiomática PIMPL.



Java y LWJGL (OpenGL wrapper) me han funcionado bien. Si está buscando más de una biblioteca de tipo gráfico de escena como Orge, eche un vistazo a jMonkeyEngine que usamos para crear una aplicación tipo google earth (vea www.skapeworld.com). Si es sensato con la creación de objetos, la recolección de basura no es un problema.


¿Sería ''C'' una respuesta demasiado obvia?


Puedes mirar a Ada . No hay un recolector de basura, pero este lenguaje se usa a menudo para sistemas en tiempo real que requieren alta confiabilidad. Eso significa menos tiempos de depuración para sus aplicaciones 3D.

Y, también puedes mirar a Haskell , si no conoces el paradigma funcional, este lenguaje te parecerá extraño, pero vale la pena un poco de tu tiempo. Tim Sweeney (EPIC Inc) está considerando este lenguaje como una alternativa de C ++.