Test de mi gameEngine en C++

Todo aquello que no está relacionado con Gemix Studio ni con la programación DIV en general.

Re: Test de mi gameEngine en C++

Postby CicTec » Wed Dec 12, 2018 12:19 am

erkosone wrote:Es curioso que a las horas de hablar con cictec sobre este tema el autor de raylib ha actualizado la libreria para unificar todos los buffers de pintado de lineas, triangulos y quads todos a uno quedando todo mas optimo y rapido.

This commit implements a big update of rlgl module, intended to optimize some parts. This change could break some code bases... hopefully not, but it could.
The BIG changes to the module are:
- Replaced LINES-TRIANGLES-QUADS buffers by a single one, now all vertex data is accumulated on a single buffer and managed with registered draw calls. LINES-TRIANGLES-QUADS could be used the same way as before, rlgl will manage them carefully. That's a big improvement of the system.
- Support multi-buffering if required. Just define MAX_BATCH_BUFFERING desired size (currently set to 1 batch). Should be enough for most of the situations.
- Removed temporal accumulative buffers for matrix transformations, now transformations are directly applied to vertex when on rlVertex3f()
- Reviewed rlPushMatrix()/rlPopMatrix() to be consistent with OpenGL 1.1, probably I should remove that ancient behaviour but... well, it was not consistent and now it is.
- Minor tweaks: LoadText(), I broke it in last update... also multiple comments reviewed.
- TODO: MAX_BATCH_ELEMENTS checking should probably be reviewed... done some tests and it works but...

Igual esta mirando el hilo de aqui, o alguien lo esta informando sobre algunas sugerencias y cosas de aqui.

Estaria interesante comparar el nuevo rendimiento, porque tal como esta escrito ahora el codigo, soluciona el problema de la Z con todos los objetos, pero el rendering deberia ser mas lento que ante.
Aun asi esta lib sigue tenendo varias limitaciones en comparacion al engine OpenGL que implemente en Gemix.
User avatar
CicTec
 
Posts: 16554
Joined: Thu Jul 31, 2008 10:18 pm

Re: Test de mi gameEngine en C++

Postby erkosone » Wed Dec 12, 2018 9:35 am

por ahora no la cambiare, haber si avanzo un poco mas en engine.
Ya tengo el fading de pantalla listo y el objeto mouse igualito que en gemix/div!

ADD:
- fadeOn( time );
- fadeOff( time );

Ahora a por los signal()!
User avatar
erkosone
 
Posts: 10654
Joined: Tue Feb 24, 2009 2:13 pm
Location: Barcelona.

Re: Test de mi gameEngine en C++

Postby Hokuto7 » Wed Dec 12, 2018 4:44 pm

Seguramente este mirando este hilo el mismo,porque cuando estuve hablando con el hace unos meses le dije que probara gemix y gamelibzero para coger ideas pero no me hizo mucho caso.

Pero si lo esta mirando le hago dos sugerencias al creador de raylib,introduce un sistema de procesos o objetos para dividr el codigo en objetos del juego,porque como esta diseñado actualmente no lo veo muy claro para el diseño de juegos.

Tambien estaria muy bien que introdujera un modo para trabajar por software o por direct3d9 porque opengl no le funciona bien a todo el mundo.
User avatar
Hokuto7
 
Posts: 1397
Joined: Mon Aug 28, 2017 10:14 am

Re: Test de mi gameEngine en C++

Postby erkosone » Wed Dec 12, 2018 6:42 pm

Hacer procesos o algo parecido en C99 es muy dificil y engorroso hokuto, y sobre hacer esta biblioteca compatible con modo software no tiene mucho sentido.. ahora mismo por que estas usando hardware completamente desfasado y un sistema operativo que lleva sin actualizarse de manera standar desde hace ya 4 años o mas..

Tu caso no es lo normal, mas bien por suerte es una excepción muy rara, por que usar windows7 no tiene ningun sentido, ya que es un sistema operativo "a nivel de usuario" abandonado por microsoft de manera oficial desde hace años ya, por ende los drivers funcionan por suerte, pero es como si te pones a hacer juegos desde ms_dos, no tiene mucha lógica. "te lo digo con todo el cariño tio.. no es una critica en plan oye mira que mierda tienes.." cada cual programa desde donde puede..

Y como te digo, el caso de la raylib, hacer un juego en C a pelo es mas dificil, no es por la complejidad en si misma, si no por que no hay abstraccion de objetos, y por ende tienes que trabajar con toneladas de codigo mezclado y a mi eso me da asco como ya a la gran mayoria del mundo, C++ apareció para erradicar eso mismo..

Yo creo que si ray ya anuncia su raylib como una libreria para "C/C++" es por que el mismo ya sabe que la compatibilidad con el standar "C99" le otorga la portabilidad que merece la libreria, pero C++ le da la funcionalidad que necesita.
User avatar
erkosone
 
Posts: 10654
Joined: Tue Feb 24, 2009 2:13 pm
Location: Barcelona.

Re: Test de mi gameEngine en C++

Postby CicTec » Wed Dec 12, 2018 8:30 pm

Hokuto7 wrote:Seguramente este mirando este hilo el mismo,porque cuando estuve hablando con el hace unos meses le dije que probara gemix y gamelibzero para coger ideas pero no me hizo mucho caso.

Pero si lo esta mirando le hago dos sugerencias al creador de raylib,introduce un sistema de procesos o objetos para dividr el codigo en objetos del juego,porque como esta diseñado actualmente no lo veo muy claro para el diseño de juegos.

Tambien estaria muy bien que introdujera un modo para trabajar por software o por direct3d9 porque opengl no le funciona bien a todo el mundo.

Pues si lo avisaste de mirar aqui entonces posiblemente esta explicado del cambio justo despues de haberle indicado yo a erkosone el problema, pero sinceramente no se como no se dijeron cuenta durante todo este tiempo de este problema.

La implementacion Direct3D requiere una reescritura casi completa porque la API cambia totalmente, ademas del tipo de logica en si de Direct3D, deberian modificar todo para introducirlo, y es solo para productos microsoft, mientra OpenGL es uno standard para mas plataformas.

La implementacion software no tiene mucho sentido hoy en dia, aparte que seria un monton de trabajo y no daria los mismos resultados de eficiencia, etc..., como dicho Gemix se empezo en el 2005 y por eso tiene aun hoy este soporte.

erkosone wrote:Hacer procesos o algo parecido en C99 es muy dificil y engorroso hokuto, y sobre hacer esta biblioteca compatible con modo software no tiene mucho sentido.. ahora mismo por que estas usando hardware completamente desfasado y un sistema operativo que lleva sin actualizarse de manera standar desde hace ya 4 años o mas..

No es tan dificil, lo dificil es implementar un sistema bien eficiente y en particular pensado para un interprete.

erkosone wrote:Tu caso no es lo normal, mas bien por suerte es una excepción muy rara, por que usar windows7 no tiene ningun sentido, ya que es un sistema operativo "a nivel de usuario" abandonado por microsoft de manera oficial desde hace años ya, por ende los drivers funcionan por suerte, pero es como si te pones a hacer juegos desde ms_dos, no tiene mucha lógica. "te lo digo con todo el cariño tio.. no es una critica en plan oye mira que mierda tienes.." cada cual programa desde donde puede..

Si no me equivoco su SO es windows7, que hoy en dia tiene aun soporte de microsoft, aunque en 2-3 meses terminara este soporte, pero esto no significa que lo drivers videos no sean actualizados, esto depende del productor de la tarjeta.
Aun asi mucha gente seguira usando windows7 hasta que no pueda actualizar el PC, porque windows 10 tiene un horrible soporte para los viejos hardware (por no decir niguno, vease mi caso), lo cual porta a problemas de funcionamento video, etc...

erkosone wrote:Yo creo que si ray ya anuncia su raylib como una libreria para "C/C++" es por que el mismo ya sabe que la compatibilidad con el standar "C99" le otorga la portabilidad que merece la libreria, pero C++ le da la funcionalidad que necesita.

Es porque OpenGL es una API pensada para el C, hacer una libreria C++ en OpenGL significa hacer un wrapper sobre ella y eso crea overhead, caso inverso a las Direct3D cuya API es C++ nativa (serie de clases, etc...)
User avatar
CicTec
 
Posts: 16554
Joined: Thu Jul 31, 2008 10:18 pm

Re: Test de mi gameEngine en C++

Postby Hokuto7 » Wed Dec 12, 2018 9:16 pm

Erkozone!,eso de que window 7 no tiene sentido hoy en dia es demasiado exagerado porque actualmente es el sistema operativo que mas se usa ,y yo usaria widow xp pero como ya no tiene soporte pues me pase el 7,pero creo que la gente usa hoy en dia window 10 porque tiene ordenadores nuevos o les gusta lo mas nuevo o por necesidad, pero yo no toco ese sistema hasta que no me quede mas remedio porque me parece una autentica basura.

Lo de opengl pues me parece que crear herramientas o programas que solo usen opengl te estas limitando a un grupo de usuarios porque te digo que hay mucha gente que tiene problemas con opengl.Yo suelo utilizar muchos programas con soporte para opengl,software y direct3d y actualmente tambien les estan metiendo soporte para vulkan por eso si que no veo sentido el hacer algo para opengl solamente,pero bueno,alla el que lo hace porque hay mucha gente que no le va bien opengl y no usara esos programas.

Y bueno,se que el ordenador que tengo esta desfasado pero no me gusta malgastar el dinero y mientras me siga funcionando seguire dandole caña, pero cuando dices que algo no tiene sentido creo que tendrias que pensartelo mejor porque lo que no tiene sentido es que estemos haciendo juegos en librerias o engines que todo es con codigo y con el notepad++,lo mas normal y logico es que estemos usando herramientas modernas como unity o unreal 4 no te parece,de hecho cualquiera que quiera crear un juego para ganar algo de dinero lo logico es utilizar unity si no es mejor no perder el tiempo.

Lo de hacer procesos en raylib solo lo he dicho porque esa libreria es complicada para hacer juegos como esta actualmente y nadie con sentido comun la usaria como esta actualmente pero es solo una sugerencia para el creador.

Lo que has comentado del msdos me ha hecho gracia porque hoy en dia con las herramientas que hay tenemos comunidades gigantescas creando juegos para amstrad,spectrum,nes,megadrive,neogeo etc..Creo que cualquier cosa tiene sentido si disfrutas con ella.Y como te conozco un poco y antes de que lo digas no estoy molesto solo queria expresarme ;)

Por cierto cictec,yo no he avisado ha nadie,seguramente se habra pasado por aqui y habra visto esto y poco mas .
User avatar
Hokuto7
 
Posts: 1397
Joined: Mon Aug 28, 2017 10:14 am

Re: Test de mi gameEngine en C++

Postby erkosone » Wed Dec 12, 2018 9:38 pm

Windows 10 hace tiempo que esta por delante de windows 7 hokuto.

Windows 7 fue un gran sistema operativo, pero si lo sigues usando no puedes acceder a servicios actuales que te piden minimo el 8.1.. quizá para ti te funciona muy bien, o para la contabilidad de una panaderia, pero para trabajar todo son problemas.
También es verdad que muchas veces nos empeñamos en querer trabajar con hardware muy obsoleto y queremos creer que una vieja versión de windows sigue siendo funcional, pero la realidad es que no es asi por muchos motivos.

A nivel de tu casa seguro que w7 te sirve, nadie lo duda.. pero mira los problemas que tienes con algo tan basico como la targeta grafica.
Yo tengo un intel core i5 2º gen. y hace ya mas de 6 años que lo tengo.. y mira.. es viejo de cojones.. esta obsoleto.. imagina algo peor que esto..
You do not have the required permissions to view the files attached to this post.
User avatar
erkosone
 
Posts: 10654
Joined: Tue Feb 24, 2009 2:13 pm
Location: Barcelona.

Re: Test de mi gameEngine en C++

Postby erkosone » Wed Dec 12, 2018 10:51 pm

Bueno.. ya tengo el metodo collisionMouse() y collisionMouse(id)..
En breve el sistema de colisiones entre id´s y collisionType() y listos.. ya estara un paso mas adelante para poder hacer un juego sencillo ya.
User avatar
erkosone
 
Posts: 10654
Joined: Tue Feb 24, 2009 2:13 pm
Location: Barcelona.

Re: Test de mi gameEngine en C++

Postby erkosone » Thu Dec 13, 2018 9:06 am

Conseguido!

Ya dispongo de identificador unico como en gemix/div para cada proceso, y de type para el tipo de proceso como en gemix/div :D :D

El codigo para sacar el type es un poco asqueroso la verdad... pero ha merecido la pena.. ahora puedo comprobar colision con un tipo de objeto.. esto es estupendo por que la libreria Chipmunk2D necesita que tu le indiques el filtro type manualmente.. y que el engine lo genere automaticamente desde el nombre de la clase derivada que instancia a una clase base "sprite" es fabuloso para la simplicidad del codigo :)

Bueno ya queda menos, solo viendo lo rapido y bien que esta saliendo todo me dan ganas ya de ponerme a hacer un juego jeje..
Aquí se ven los objetos del juego con su ID, collisionMouse() y type..
You do not have the required permissions to view the files attached to this post.
User avatar
erkosone
 
Posts: 10654
Joined: Tue Feb 24, 2009 2:13 pm
Location: Barcelona.

Re: Test de mi gameEngine en C++

Postby CicTec » Thu Dec 13, 2018 9:43 am

Hokuto7 wrote:Lo de hacer procesos en raylib solo lo he dicho porque esa libreria es complicada para hacer juegos como esta actualmente y nadie con sentido comun la usaria como esta actualmente pero es solo una sugerencia para el creador.

Pues eso es precisamente el motivo por el cual no hago una libreria/framework como me preguntaste una vez, el utilizo requiere un nivel bastante mas avanzado por parte del usuario y seria uno de los muchos frameworks en la calle, en el caso de erkos que se monta algo principalmente para uso personal puede estar bien, pero si principalmente esta pensado para el utilizo al publico, ya hay mucho hecho para eso, asi que mejor me siga encentrando en el proyecto Gemix intentando mejorarlo mas que pueda en lugar que reempezar todo nuevamente o hacer algo extra de 0.

Hokuto7 wrote:Lo de opengl pues me parece que crear herramientas o programas que solo usen opengl te estas limitando a un grupo de usuarios porque te digo que hay mucha gente que tiene problemas con opengl.Yo suelo utilizar muchos programas con soporte para opengl,software y direct3d y actualmente tambien les estan metiendo soporte para vulkan por eso si que no veo sentido el hacer algo para opengl solamente,pero bueno,alla el que lo hace porque hay mucha gente que no le va bien opengl y no usara esos programas.

El sentido lo tiene, porque es la API grafica que mas soporta plataformas, tienes en cuenta que actualmente hay:
OpenGL: Version desktop para PC (Windows, Linux), Mac (versiones hasta la 10.10), raspberry PI, etc...
OpenGL ES: Version embedded para Android, iOS (hasta la version 7), y otros devices mobile.
WebGL: Version para WEB browsers
Vulkan: Version para Desktop (Windows, Linux) y embedded (Android) y WEB browser, es la nueva generacion de API grafica del standard Khronos, en principio pensada como sucesor de las OpenGL/OpenGL ES/WebGL (OpenGL 5.0) pero luego renombrada a Vulkan y pensada como alternativa para unificar las 3 API anteriores en una y eliminar las problematicas de las mismas, solo funciona con hardwares de ultima generacion.
Metal: Version para Mac y iOS, nueva generacion de API que substituye el OpenGL/ES, apple hubiera tenido que participar al nuevo standard Vulkan pero luego decidio crear su API propria para sus SO y hardware
Direct2D/3D: Version para Desktop (Windows) y embedded (Windows RT, Windows Phone), actualmente la ultima version funciona para todos los hardware que montan productos Microsoft.

Como ves te encuentras con 4 API, cada API a su vez soporta mas especificas, por ejemplo OpenGL 2.1, OpenGL 3.3, OpenGL 4.0, OpenGL ES 2.0, OpenGL ES 3.0, Direct3D 9/10/11/12 y cada especifica cambia bastante o totalmente como API respecto a las anteriores, esto conlleva que hacer un motor grafico que soporte todas las API y todos los hardware va a ser un trabajo infernal, por eso se opta principalmente para OpenGL porque siendo uno standard abierto es el que mas plataformas soporta, aunque lamentablemente muchos productores hardware le dan un soporte pesimo (vease el caso de las tarjetas Intel antiguas).

Hokuto7 wrote:Por cierto cictec,yo no he avisado ha nadie,seguramente se habra pasado por aqui y habra visto esto y poco mas .

Si no te preocupes, me referia a que alguien que usa esta libreria lo hubiera avisado mirando aqui y no solo el mismo autor.

erkosone wrote:Windows 10 hace tiempo que esta por delante de windows 7 hokuto.

Windows 7 fue un gran sistema operativo, pero si lo sigues usando no puedes acceder a servicios actuales que te piden minimo el 8.1.. quizá para ti te funciona muy bien, o para la contabilidad de una panaderia, pero para trabajar todo son problemas.
También es verdad que muchas veces nos empeñamos en querer trabajar con hardware muy obsoleto y queremos creer que una vieja versión de windows sigue siendo funcional, pero la realidad es que no es asi por muchos motivos.

A nivel de tu casa seguro que w7 te sirve, nadie lo duda.. pero mira los problemas que tienes con algo tan basico como la targeta grafica.
Yo tengo un intel core i5 2º gen. y hace ya mas de 6 años que lo tengo.. y mira.. es viejo de cojones.. esta obsoleto.. imagina algo peor que esto..

Si esta claro que hoy para acceder a una store te pidan minimo windows 8.1 el problema es que el 8 y el 10 especialmente tienen un soporte de hardware antiguo practicamente nulo, lo que lleva el sistema operativo a ser inestable en funcionamento en esas maquinas, conbasta que te vayas por google a mirar problemas como "windows 10 black screen issue" etc.. y ya veras cuanta gente con cuantos tipos de hardware tienen este problema, no todos necesitan servicios de store, con lo cual el windows 7 para muchos seguira siendo el SO da usar hasta que no puedan cambiar totalmente el PC, porque la otra alternativa es pasarse a Linux.
User avatar
CicTec
 
Posts: 16554
Joined: Thu Jul 31, 2008 10:18 pm

PreviousNext

Return to Offtopic

Who is online

Users browsing this forum: No registered users and 30 guests