02-11-2019, 04:18 AM (This post was last modified: 02-11-2019, 04:20 AM by Hokuto40.)
Hola megamarc,aqui estoy para darte un poco la lata
Lo primero decirte que estaria bien que crearas un nuevo hilo para hablar de lo nuevo que vas introduciendo y de las ideas que tienes para el futuro.
He estado intentando otra vez compilar los ejemplos de c y este es ya el ultimo intento,porque si no consigo nada me pasare definitivamente a la version de basic o python.
He probado el compilador tdm gcc,este trae un instalador y simplemente hay que ir a la carpeta de los ejemplos y poner "mingw32-make" en la consola,este comando te lo compila todo de golpe pero al parecer hay algunos ejemplos que no compilan y no se porque.He probado los ejemplos compilados y solo funcionan la mitad,tal vez el compilador sea antiguo o no se que es exactamente lo que pasa.
He probado tambien el compilador tcc,lo he introducido en la carpeta samples y he intendo utilizar todo tipo de comandos pero nada,te pongo una imagen de un error que ocurre en la supuesta compilacion.
Un compilador de C no se utiliza así como en la captura que adjuntas. A no ser que estés compilando un programa muy sencillo que sólo contenga un módulo y no utilice bibliotecas externas, que no es el caso. Para construir un ejecutable hay que indicarle la lista de fuentes, las rutas de inclusión de cabeceras, las de las biliotecas y los nombres de las propias bibliotecas. Como puede resultar complejo, existe el archivo Makefile, que consiste en una serie de reglas y pasos necesarios para costruir todos los componentes. Este archivo lo procesa la utilidad GNU mingw32-make. Por defecto utiliza el compilador gcc, y aunque el tcc se parece, no es totalmente compatible.
Para compilar con tcc por ejemplo el ejemplo Barrel que adjuntas en la captura:
Manejar un compildor de C desde línea de comandos no es trivial, te recomiendo un buen tutorial al respecto, si no entones es mejor que utilices Visual Studio, que te provee de un entorno amigable que oculta muchas de estas complejidades, o te quedes con gcc.
Bueno bueno,al fin he conseguido compilar algunos juegos,lo que me faltaba era poner tilengine.dll en la consola de comandos y ya.
Pero si que algunos ejemplos no he podido compilarlos porque se ve que son mas archivos y como estan todos mezclados no se cual es cual,creo que lo mejor es que para la proxima actualizacion incluyas cada ejemplo en carpetas independientes y de esa forma se puede compilar mas comodamente.
El ejemplo road se ve la pantalla azul y no sale nada mas,pero con el compilador tdm gcc se ve perfectamente el ejemplo y el ejemplo Barrel del señorito simon belmor tiene bug en la colision con el suelo.
Si te digo la verdad no merece la pena tanto esfuerzo para usar la version de c cuando tengo la de freebasic y python que no me dan problemas,lo que no me gusta de la version de python es que colocas el nombre de una variable o funcion y luego tienes que poner un punto para acceder a sus propiedas y luego otro punto,me gustaba mas antes cuando se parecia a la version de c que pones el nombre de una funcion y ya esta.
Y bueno.cuentame que tienes pensado para el corto y el largo plazo para tilengine(si es que tienes pensado algo),otra cosa,probastes la libreria gamelibzero del foro de gemix que te comente.
Cierto que los ejemplos están mezclados en la misma carpeta y puede ser complicado saber cual es cual. El motivo es que hay varios archivos que son comunes a varios (o todos) los ejemplos: actor.c/.h, Sin.c/.h, Tilengine.dll... si estuviesen repartidos en varias carpetas, habría que tener copias de todos ellos en cada carpeta, siendo en realidad el mismo archivo. En los archivos de proyecto de los ejemplos (Makefile y Samples.vcxproj) están las relaciones de dependencias de cada ejemplo.
Cierto es que el ejemplo de Barrel tiene las colisiones pobremente implementadas. Es uno de los primeros ejemplos que hice, y es demasiado complejo para usarse como ilustración de tilengine, los siguientes que he ido haciendo son más sencillos. Los otros ejemplos complicados que he hecho han ido a sus propios proyectos (SuperMarioClone, PythonPlatformer).
Libre eres de usar el lenguaje que más te guste de los disponibles. Los bindings de C# y Python utilizan las características propias de estos lenguajes (clases y objetos) en vez de ser un port directo de la API original, orientada a funciones.
No tengo un roadmap previsto de próximas características, últimamente voy implementando pequeñas mejoras y arreglos de bugs sugeridos por usuarios que se van encontrando con diferentes necesidades. Hay cosas que me gustaría ir haciendo, pero no tengo plan o fecha prevista:
Acabar documentación
Rotación de sprites
Portar a Javascript para poder ejecutarse dentro del navegador
Jope!! ,otra version mas y encima para javascripts,no es ya mucho trabajo para ti el mantener las versiones de c,c#,python y ahora te metes en javascripts.
Si despues de mas de 3 años no tienes todavia terminada la documentacion de c,ahora tambien tendras que meterte en la documentacion de c# y javascrits,ademas de terminar la de python.
Creo que no vas a terminar nunca con la documentacion,pero bueno... esta claro que la gente no se puede quejar de tu libreria en lo que se refiere en variedad de versiones.
Yo personalmente lo que hubiera hecho desde el principio,es hacer solo la version de c a bajo nivel para uso del programador de la libreria y para el uso de los usuarios crearia un lenguaje de scripts sencillo de usar para que todo el mundo pudiera usar esta libreria de una forma sencilla.
Y a partir de hay solo tendria que crear una documentacion y ejemplos para un solo lenguaje.Creo que el lenguaje no le interesa a nadie,lo que le importa a la gente es poder hacer cosas interesantes con la libreria.
Siento haber dado otra sugerencia,creo que he cogido una mania muy fea,foro al que entro sugerencia que doy...en fin,hasta otro dia.
El tema de javascript, en realidad es una plataforma nueva (navegador web), no otro binding. Hay un compilador llamado emscripten que coge código fuente de C y lo convierte en javascript/WebAssembly para poder ejecutarlo directamente en un navegador. Habrás visto versiones de emuladores y aplicaciones de escritorio funcionando en navegador, es así como lo hacen. Es muy interesante: https://emscripten.org/docs/introducing_...ipten.html
En realidad la documentación de referencia de C y Python está terminada hace tiempo, lo que está a medias es la versión paso a paso, en plan libro. Pero la referencia, con todas las funciones, su uso y parámetros, están completas y en línea.
La biblioteca está en C, pero normalmente quien hace juegos hoy en día no utiliza C/C++ directamente (es bastante engorroso) sino que se usan lenguajes de script intepretados (Lua, Javascript en GameMaker, Python...), o lenguajes de aplicación (C# en Unity). Por eso hice los bindings, para permitir utilizarse desde estos entornos familiares para los que hacen juegos. Desarrollar un lenguaje de guiones específico para Tilengine no tendría sentido, ya que es mucho más complejo que implementar un binding, y sería algo desconocido para los posibles usuarios que dificultaría la adopción. Es mejor ceñirse a los estándares que ya están en uso.
Jejejeje,se nota que no has utilizado nada gamemaker porque gamemaker no utiliza javascripts,este engine tiene su propio lenguaje de scripts llamado "GML" y tambien tiene un lenguaje visual.
Unity te permite utilizar c# pero no es su lenguaje estandar,el lenguaje de unity es el lenguaje unity scripts que se a creado exclusivamente para este engine ademas tambien se pueden usar lenguajes visuales.
Tambien tenemos a godot que tiene su propio lenguaje creado exclusivamente para este engine que se llama GD Scripts y en la nueva version que han sacado ahora,que es la version 3, se le ha añadido el lenguaje c# y un lenguaje visual de nodos.
Hay muchos mas pero era solo para que veas que la mayoria de engines tienen su propio lenguaje de scripts creado exclusivamente para ese engine y para facilitar el desarrollo del juego.
Pero entiendo perfectamente que tu libreria utilice los lenguajes estandar,me costo trabajo entenderlo ,porque como la vendieron en retromaniac como engine para hacer juegos retro, me pense lo que no era,pero despues de un tiempo supe que simplemente era una libreria grafica y no un engine para hacer juegos.
Entonces no hay nada que sugerirte ni nada que mejorar en tu libreria,tal y como esta diseñada esta perfecta,pero entenderas que nadie la va a utilizar para realizar juegos retro,solamente haran pequeñas cositas graficas por diversion.
GML es una versión de JavaScript adaptada a GameMaker, su sintaxis es muy parecida, aunque integra funciones específicas para el manejo de los juegos. En cuanto a Unity, tradicionalmente usaba UnityScript, que también es una versión de JavaScript, pero progresivamente han ido estableciendo C# como lenguaje oficial, y de hecho ya anunciaron hace un par de años que eliminaban el soporte para el antiguo UnityScript, siendo C# el lenguaje a usar: https://blogs.unity3d.com/2017/08/11/uni...he-sunset/
Por supuesto, cada uno es libre de usar la herramienta con la que se sienta más cómodo :-)
Queria comunicarte que ya he compilado todos los ejemplos de c con el compilador tcc y funciona todo perfecto,pero he encontrado un fallo en el ejemplo de naves.
Cuando los disparo colisionan en los enemigos,aparece la explosion,pero esta no desaparece y se queda flotando y parada.
