opengl common-lisp portability

opengl - Ceceo común: portabilidad



common-lisp portability (4)

Portabilidad

Debe distinguir entre la portabilidad en todas las plataformas (por ejemplo, ¿se desarrollará su programa bajo Clozure en Windows ejecutado en Linux?) Y en todas las implementaciones (por ejemplo, ¿su programa Clozure se ejecutará bajo SBCL?)

Tendrá que examinar cuidadosamente los detalles en los manuales de implementación específicos, pero, en términos generales, si usa la funcionalidad CL estándar más CFFI, no debería tener problemas importantes en ninguno de los aspectos.

En términos prácticos, debe examinar qué tan bien se ejecuta Clozure en las plataformas que le interesan y si CFFI es compatible con Clozure en esas plataformas. Estas preguntas se hacen mejor a los desarrolladores, no aquí.

Instalabilidad

Todas las implementaciones de CL realizan la "entrega del producto" de alguna forma, por ejemplo, creando ejecutables independientes que luego puede empaquetar y distribuir.

pregunta

Si hago un juego 2d en lisp común (use: lispbuilder-sdl, quicklisp, cffi) usando clozure cl en windows, ¿podré fácilmente transferirlo a otras plataformas (linux / iPhone (tal vez) / android) más tarde? ¿El lisp es "adecuado" para programas instalados?

información

  1. El juego usará OpenGL para gráficos. Lo más probable es que use sdl para inicialización input / opengl, y sdl o openal para audio. Podría terminar usando mi propia biblioteca en lugar de sdl más tarde.
  2. Escribir pocas bibliotecas C ++ para cffi (para ajustar la funcionalidad de manera "portátil") no es un problema.

razonamiento

Estoy realmente cansado de C ++. Desea probar algo (que no es python) con sintaxis más simple + más potencia. Tenga en mente un proyecto de juego, quiero saber si elegir lisp para un juego significa serios problemas si de repente decido distribuir / portar el juego más tarde.

--editar--

información adicional

¿Qué quiere decir con "adecuado" y "programas instalables"?

No estoy seguro de qué tan bien jugará CFFI / quicklisp si trato de convertir el programa terminado que puede ejecutarse en mi máquina en un paquete instalable (Windows installer en Windows, por ejemplo). quicklisp, por ejemplo, configura rutas / repositorios dentro del directorio de inicio del usuario (que podría no ser un comportamiento aceptable) e intenta descargar paquetes automáticamente desde fuentes externas, lo cual no es bueno cuando intenta distribuir el programa y asegurarse de que funciona como destinado a. CFFI en algunos puntos "vincula" bibliotecas extranjeras a funciones de ceceo, y no está claro para mí qué tan bien funcionará, por ejemplo, si vuelco la imagen del programa, lo incrusto en exe y ejecuto dicho exe en otra máquina. De acuerdo con el sentido común, eso debería funcionar bien, pero en el peor de los casos, podría tener que escribir un instalador complicado para la distribución de lisp.


** NOTA: Disculpa si declaro lo obvio en esta publicación, no estoy seguro de tu familiaridad con Common Lisp **

Continuando desde sds:

Parece haber un poco de vida para que funcione Android en Android, pero el rendimiento disponible aún está por verse. Es muy poco probable que veamos juegos lisp en la tienda iphone a menos que compilen en otro idioma donde el compilador no esté disponible en tiempo de ejecución (vea Nu o para una opción propietaria vea mocl que ambos tienen formas de abordar este problema)

Portabilidad: en todas las implementaciones

En las bibliotecas, definitivamente vale la pena hacer que funcionen de manera portátil en tantas implementaciones como sea posible; sin embargo, para los juegos, realmente solo elegiría una implementación y perfeccionaría su código allí. Probablemente distribuirá su juego como un paquete para cada plataforma en lugar de hacerlo a través de Quicklisp, ¿verdad?

Portabilidad: a través de plataformas

Asegúrese de verificar el progreso de su implementación preferida en cada plataforma, puede haber sutiles inconvenientes. Para mí uso SBCL y en Windows solo 32 bits es totalmente compatible, mientras que 64 aún está en desarrollo.

embalaje

Esto tiene un buen momento para ti, ya que cierta información sobre el empaquetado de las aplicaciones Clozure para Apple Mac Store fue publicada hoy en openmcl-devel . Todavía no he leído bien, pero el hilo puede proporcionar más información.

Zach Beane también ha hecho buildapp para SBCL

La gente de lispbuilder también parece tener algo de información sobre cómo hacer ejecutables independientes .

Herramientas

cl-opengl es una muy buena envoltura para opengl. Es compatible con los estilos opengl tanto antiguos como modernos, por lo que considero que las áreas que intentan proporcionar abstracciones de mayor nivel son un poco limitantes (me alejo personalmente de las plataformas GL de cl-opengl). Sin embargo, hay que leer la fuente, ya que hay algunas cosas geniales allí, especialmente cuando comienzas a escribir más código cffi. {cl-opengl aún se está desarrollando y disponible a través de quicklisp; lo he usado en Linux y tengo buenas ventanas}

lispbuilder-sdl es genial, pero de nuevo es posible que tengas ganas de tomar el control de algunas áreas. Por ejemplo, la macro sdl: with-events es genial, pero toma el control de su bucle principal y el manejo del paso de tiempo. Esto puede funcionar perfectamente para usted, pero si no, no tema buscar y escribir algo mejor para reemplazar esas partes.

También lispbuilder proporciona una variedad de bibliotecas, por lo que antes de usarlas compruebe si hay un equivalente más reciente en quicklisp. Por ejemplo, lispbuilder tiene lispbuilder-opengl. No use esto, quédese con cl-opengl. De nuevo lispbuilder tiene lispbuilder-regex mientras que probablemente sea mucho mejor usar CL-PPCRE .

Probablemente no recomendaría usarlo tal como está, pero pasé un tiempo un tiempo atrás sacando todo lispbuilder-sdl que no pertenecía a los juegos opengl modernos (así que no hay superficies de software sdl, etc.). ¡NO creo que la gente deba usar esto todavía, pero puede darte algunas ideas! {lispbuilder no está en desarrollo, pero está disponible a través de quicklisp; lo he usado en Linux y tengo buenas ventanas}

Además, mientras soy un código de proxenetismo escrito por gente excelente y luego destrozado por mí, mira este video sobre cómo recompilar partes de tu juego mientras se está ejecutando . No es mi técnica pero funciona muy bien.

Lo anterior requerirá que use SLIME o SLIMV, lo que significa que usa Vim o Emacs. ¡SLIME realmente vale la pena, así que échale un vistazo!

Con todo, buena suerte, el ceceo común es muy divertido de desarrollar y mientras que puede tardar un tiempo en obtener un flujo de trabajo abierto que disfrute, si tiene tiempo no tengo dudas de que se lo pasará en grande.

Esperamos ver el juego!


Para usar Common Lisp como tiempo de ejecución del juego, ya hay una respuesta excelente.

Solo quiero mencionar que los juegos de PlayStation 2 Jak y Daxter: The Precursor Legacy y Crash Bondicoot están desarrollados usando Common Lisp de una manera ligeramente diferente.

Tenían su entorno en desarrollo en Commmon Lisp e hicieron un lenguaje de juego, GOAL (más tarde GOOL) , que era un lenguaje de alto nivel con ensamblado en línea (Like C''s __asm__ ). Por lo tanto, el producto tiene poco que ver con su entorno de desarrollo cuando se compiló el producto final.

Solo se enfocaron en una plataforma (PS2), pero imagino que uno podría hacer construcciones de lenguaje para que pueda optimizar para varias plataformas usando casi el mismo método. Hacer lenguaje de juego podría abstraer las diferencias reales de hardware y biblioteca y mantener la complejidad de un compilador más baja que intentar compilar Common Lisp para, por ejemplo, Dalvik directamente. el compilador realmente no necesita terminar como código objeto tampoco. Podría compilarse con C / Java / Objective C.

El problema de la portabilidad se convierte entonces en algo que usted controla al mirar un objetivo preferido al diseñar su idioma y cómo hacer que el paquete / binario siga las formas del objetivo.


¿Seré capaz de portarlo fácilmente a otras plataformas (Linux / iPhone (tal vez) / Android) más tarde?

Bueno, depende en gran medida de las bibliotecas que elijas.

No tengo ninguna experiencia con el desarrollo de Android o iOS, pero actualmente estoy desarrollando un proyecto pequeño en Common Lisp, que usa lispbuilder-sdl, cl-opengl, quicklisp, etc., y no hubo problemas para transferirlo entre SBCL en Linux a Clozure-CL en Windows.

Además, existe al menos una implementación de Common Lisp móvil prometedora: https://wukix.com/mocl

Por lo tanto, creo que no tendrá problemas para transferir su código, solo asegúrese de que todas las bibliotecas utilizadas en su aplicación cuenten con el soporte adecuado en cada plataforma y la implementación de Lisp.

¿El lisp es "adecuado" para programas instalados?

La mayoría de Lisps tiene la capacidad de crear ejecutables independientes con bibliotecas integradas. Por otro lado, si su proyecto crece lo suficiente, tendrá que escribir instaladores específicos de plataforma sin importar los posibles problemas relacionados con Lisp. Y dudo que la parte relacionada con Lisp resulte ser la más compleja. También consulte esta publicación: Lisp Executable , y considere la idea de distribuir las imágenes de tiempo de ejecución de Lisp en lugar de ejecutables independientes.