Test de mi gameEngine en C++

[OskarG]

Bueno, entonces espero que lo solvente...si te gusta java como es en mi caso echa un vistazo a la libreria de almasb ...flipo lo rápido que me va y estoy hablando de java .tiene buenos ejemplos.. también se puede utilizar kotlin ...java tiene una filosofía mucho más entendible que c++ ... aunque lo ideal es programar como hace div...ya que es muy asequible de entender......

[OskarG]

Ahh se me olvidaba sobre pixie ya amaka hizo un ejemplo y la verdad que el rendimiento era realmente bueno, lastima que no tenga tiempo en reescribír divgo con esta librería ,pues el cambio en velocidad sería notable.

[Hokuto7]

Entonces esta claro que es el nuevo modulo de sonido el que da problemas y ademas de que esta nueva version de raylib es mas lenta que la version 2.0,pero no me sorprende el rendimiento de esta libreria porque esta hecha para enseñar a programar,no para hacer juegos optimizados.

Olvidate de que cambie los nombres,si algo he aprendido en estos dos años en distintos foros de distintas herramientas es que sus creadores no van a realizar ningun cambio que tu le sugieras,las unicas personas que han aceptado introducir o cambiar algo ,sois tu y el creador de pilasengine.

Es una putada que tuvieras que empezar de nuevo despues de todo el trabajo,pero si no te queda mas remedio esta vez hay que hacer bien las cosas desde el principio para no volver a tener este tipo de problemas.

Por eso antes de hacer nada habria que ir probando los ejemplos de las distintas librerias o framework,probar tanto el sonido como los graficos y su rendimiento y cuando se encuentre algo que te convenza entonces se puede empezar con ello.

Tambien se puede probar juegos completos hechos con estas herramientas,es la mejor manera para saber como rinde el engine y que tan bueno sea.Pero bueno,esperemos que no tengas que empezar de nuevo,aunque la cosa no pinta nada bien.

Por cierto OscarG,por el estilo div no te preocupes,todas las librerias hechas por erkosone tienen el estilo div pero mas moderno.

[erkosone]

Teneis razon.. espero que este hombre sea razonable y adapte la raylib para hacerla compatible y no romper los standar en windows..
Bueno.. también he de decir que me parece que está obligado a adaptarla.. ya que es terrible el no poder incluir practicamente raylib en ningun proyecto que use otras librerias standar para windows..

Sobre el sonido.. pues si que parece que el nuevo modulo de sonido esta podrido.. ya me costó compilarlo con la libreria.. ya que a ray se le olvidó incluir unos archivos .c en las fuente y no compilaba de inicio.. pero sacando las fuente de la verisón anterior de desarrollo conseguí compilar la libreria..

@OscarG pues a mi también me encanta java.. y te digo una cosa.. es igual de rapido que C++ hoy en dia.. los nuevos compiladores no tienen diferencia.. te lo digo por que desde processing mismo puedes abrir varios test de emisores de particulas que te dejan con la boca abierta.. y van igual de rapido que en C++

La libreria esta que me dices la voy a mirar.. haber que tal funciona, y si yo también pienso que C++ es retorcido como el solo, es complejo en nomenclatura por que en concepto es practicamente lo mismo que java.
Voy a hecharle un vistazo a esta libreria que me dices haber que tal esta..

[Hokuto7]

He probado esta libreria que comenta oscarg que se llama fxgl,en la pagina hay algunas demos y aunque la mayoria me funcionan bien hay tres que me van bastante lentas,desde mi punto de vista no merece la pena perder el tiempo con esta libreria.

Ayer estuve jugando al juego Slipstream,este es un juego que salio el año pasado y es de velocidad,muy parecido a outrun clasico,descubri que esta hecho con libgdx y me funciona bastante bien.

Tambien tengo otro juego que se llama master spy,he buscado con que libreria esta hecho y la libreria se llama melonJs ,el juego me funciona muy bien ademas he probado otros juegos que estan en la pagina de melonjs y funcionan bien.

[Hokuto7]

Hecho con libGDX.

[Hokuto7]

Hecho con melonJS.

[CicTec]

@OscarG pues a mi también me encanta java.. y te digo una cosa.. es igual de rapido que C++ hoy en dia.. los nuevos compiladores no tienen diferencia.. te lo digo por que desde processing mismo puedes abrir varios test de emisores de particulas que te dejan con la boca abierta.. y van igual de rapido que en C++

Como velocidad de ejecucion de codigo mas o menos si, pero en cuanto a cosas graficas etc no hay color, C++ sigue mucho mejor, todavia volviendo a Java es como si vuelve atras, esto es un lenguaje muerto en cuanto a utilizo para creacion de game engines, bastante mejor JS en este aspecto, aunque pese mucho la diferencia de rendimiento y la potencia del lenguaje mismo.

[erkosone]

Tampoco puedes hacer mucho caso a como te funcione el juego jokuto, como bien decia CicTec.. un engine tipo div consume recursos por la forma en que esta hecho en si mismo, te da prefabricados un monton de buenos gestores.. de memoria.. de objetos.. de renderizado.. y a cambio se come parte del rendimiento por tener el sistema funcionando siempre completo..

Un gestor de procesos es costoso a nivel de computo, puede pareceros que no pero solo el hacer que el lenguaje sea estilo div se puede llegar a consumir el 60% del rendimiento en bruto.. osea.. me explico..

Tu normalmente en un juego hecho en C o C++ o java.. todo lo haces a mano.. y pierdes muchisimo tiempo.. pero esta claro que cuando no quieres que algo sea transparente no ejecutas funciones de transparencia por ejemplo.. entonces es ahí donde un engine tipo div tiene su punto flaco.. aplica casi todos los FX a todos los procesos en ejecución simplemente por que es la manera mas sencilla de hacer un process batch..

Aunque eje juego te funcione bien.. no significa que en un engine Divero vaya a funcionarte igual de bien.
Esta apunto de publicarse la 2.5 raylib oficial! haber si realmente el sonido llega arreglado.. hay mas gente con este problema por lo visto.. es algo introducido recientemente en el engine..

Yo por mi parte ando con un proyecto realmente innovador jeje.. creo que os voy a dejar con la baba colgando cuando lo publique! los que me conocen saben que el que avisa no es traidor jeje.. creo que nadie habrá visto algo así o por lo menos nadie de una comunidad indie ha osado a montar algo como esto que ando haciendo jeje... no voy a desvelar ningun detalle, haber is os gusta cuando lo publique!

[CicTec]

Tampoco puedes hacer mucho caso a como te funcione el juego jokuto, como bien decia CicTec.. un engine tipo div consume recursos por la forma en que esta hecho en si mismo, te da prefabricados un monton de buenos gestores.. de memoria.. de objetos.. de renderizado.. y a cambio se come parte del rendimiento por tener el sistema funcionando siempre completo..

Si, hay siempre que comparar con que framework, libreria, game engine esta hecho el juego, con uno podria ir mejor que con otro, depende de como internamente estan implementadas las cosas y sobre todo en que lenguaje.

Un gestor de procesos es costoso a nivel de computo, puede pareceros que no pero solo el hacer que el lenguaje sea estilo div se puede llegar a consumir el 60% del rendimiento en bruto.. osea.. me explico..

La relentizacion a nivel de computo es debita a la VM del gestor de procesos y codigo, esto porque siendo DIV un lenguaje de programacion script es basicamente traducido en un bytecode y interpretado, esto permite una portabilidad mayor a cambio del coste de computo, aun asi es principalmente debito a la implementacion de la VM, Java y C# funcionan con el mismo principio, todavia los creadores en el curso del tiempo han optimizado la VM con tecnicas mas eficientes y encima con compilador JIT para traducir a istrucciones maquinas reales, eliminando casi totalmente el problema del computo y manteniendo la ventaja de la portabilidad.

Todo esto en una VM de un DIV engine es perfectamente aplicable, el problema, especialmente en el caso de un JIT es que es un monton de trabajo para implementarlo.

Tu normalmente en un juego hecho en C o C++ o java.. todo lo haces a mano.. y pierdes muchisimo tiempo.. pero esta claro que cuando no quieres que algo sea transparente no ejecutas funciones de transparencia por ejemplo.. entonces es ahí donde un engine tipo div tiene su punto flaco.. aplica casi todos los FX a todos los procesos en ejecución simplemente por que es la manera mas sencilla de hacer un process batch..

Bueno, no es que aplica todo los FX, etc... esto es como es implementado, digamos que lo que seguramente ocupa mas es memoria porque si hay 30 variables locales built-in, cada instancia tendra una copia de esas 30 variables, aunque realmente el proceso no necesite mas de 4-5, eso todavia pasa tambien con los engine modernos que estan todos en OOP, cada instancia es una clase y esa tiene muchas variables proprias y heredadas de otras clases, y casi siempre muchas ni se utilizan para aquella instancia de objeto.

Aunque eje juego te funcione bien.. no significa que en un engine Divero vaya a funcionarte igual de bien.

Si, en eso estoy de acuerdo.