#750 sin ver el resto del código no puedo decirte mucho. Has probado a pasarlo por renderdoc?
#751 Pues no conocía esta herramienta. Tampoco parece algo inmediato aprender a usarla así que me la dejo en reserva por si me quedo sin otras opciones. Gracias!
#752 pásame una build de Windows y miro yo que pasa en renderdoc. Estos cambios los tienes en alguna rama de github?
#753 Gracias! Te acabo de crear la rama: https://github.com/vircon32/vircon32-libretro/tree/BufferBug
No está basada en master, pero el efecto es el mismo y el cambio (que es 1 solo commit con 2 líneas) lo vas a ver más fácil ahí.
Por si ayuda, tengo sospechas de que el problema está relacionado con glBufferSubData y glVertexAttribPointer. Pero no sé decirte más...
La build te la puedo pasar, pero no es un ejecutable sino un core de libretro. ¿La puedes probar dentro de retroarch? Aparte, no tengo claro si el problema solo pasa con OpenGL ES...
#754 asi a bote pronto estas llamando a
glBufferData
(
GL_ARRAY_BUFFER,
20 * 8 * sizeof( GLfloat ),
QuadPositionCoords,
GL_DYNAMIC_DRAW
);
y le dices que cree un buffer de 20 * 8 floats, pero QuadPositionCoords son 8 floats nada mas.
Hazte tambien una macro que llame a glGetError y la vas intercalando despues de cada llamada a OpenGL, para saber cuando esta haciendo alguna llamada incorrecta.
#755 Tienes razón en lo de QuadPositionCoords, pero ya lo cambié y no era el problema. Hice también lo de los glGetError, pero no he visto errores (de hecho funcionar sí funciona, solo es tema de rendimiento).
En realidad da igual el tamaño del buffer, el problema solo pasa cuando se hace una modificación parcial del buffer. Es decir, cuando en las llamadas a glBufferSubData no se usa el mismo tamaño que en el glBufferData. Sin embargo esa es la manera normal de hacerlo en OpenGL (no tienen por qué coincidir).
Investigando he visto un par de enlaces que sugieren puede ser un tema concreto de las GPU Mali (como la de la RG552 que tengo). La solución en este caso es simplemente hacer modificaciones completas del buffer. Es un poco más "feo", pero como tampoco voy a usar un buffer muy grande tampoco debería haber problema.
He estado en contacto con un desarrollador de AmberELEC. Es un sistema Linux para emuladores derivado de EmuELEC, específico para máquinas de Anbernic. En la RG552 el rendimiento con Linux es menor que con Android, así que he optimizado bastante la parte de OpenGL y ahora van los juegos mucho mejor en Linux. Hasta ahora estaba dibujando cada región como un quad separado, y ahora se agrupan cuando es posible.
Esto solo lo he hecho en el core de libretro. El emulador de escritorio no tiene problema de rendimiento, así que de momento sigue con el sistema antiguo para mantener el código más fácil de seguir. Lo que sí he hecho en ambos (emulador y núcleo) es cambiar un poco la manera en que se gestionan los errores de la CPU, que antes se comprobaba en cada paso y ahora se hace más automático con excepciones.
He visto que en los programas de test no tenía ninguno que comprobara estos errores así que he creado uno nuevo. Con este menú se puede producir cualquiera de los 11 tipos de errores hardware de la consola.
¡Al fin ocurrió! Vircon32 ha sido aceptada en RetroArch. Ahora ya os podréis descargar el core de Vircon32 directamente desde el propio RetroArch y lo instalará automáticamente. Eso sí: como en otras consolas, aún necesitaréis descargar la bios.
Además, por el camino, la gente de Libretro me ha ayudado a hacer que el core también se pueda usar en la Nintendo Switch.
Este va a ser un paso muy importante. A partir de ahora será más fácil probar la consola y tendrá más visibilidad. No me extrañaría que dentro de algún tiempo algunas consolas chinas empiecen ya a traer juegos de Vircon32 
RetroArch ha abierto una página de Steam para el core de Vircon32 
https://store.steampowered.com/app/2862100/RetroArch__Vircon32/
Así que ahora mi consola es DLC jajaja
#764 Jajajajajajaja. Eso sí que nos dejaría en shock por aquí. El único abandono sorprendente del subforo xD
He lanzado una nueva versión del núcleo RetroArch (v1.1). Ahora incluye la bios dentro del propio core, así que ya no hace falta dar el paso extra de descargarla y ponerla. Si alguien quiere usar otra bios también lo permite, poniéndola en el directorio de sistema con nombre Vircon32Bios.v32.
También incluye las optimizaciones que hice y además una nueva opción de para frame skip automático.
Activarla evita problemas de audio en sistemas donde Vircon32 no pueda alcanzar 60fps. Pero tened en cuenta que con esta opción pueden aparecer otros problemas, porque Vircon32 usa los frames para la sincronización. Si activamos esta opción puede haber otros problemas como tirones en la imagen o que se pierda algún input.
Con esto mi idea es dejar de trabajar en la propia consola durante un tiempo, para poder centrarme en los juegos.
7 días después
Estos días no he hecho demasiado de la consola, pero la gente de Libretro y RetroArch ha publicado un artículo que escribí para su blog. Si os interesa, lo tenéis aquí: Vircon32 joins RetroArch.
(está en inglés pero imagino que con un traductor web lo podréis leer también en español)
16 días después
Como dije me estoy centrando en hacer juegos de nuevo. Aquí podéis ver un video del que estoy empezando ahora: es un juego de carreras sencillo. Los gráficos no son los definitivos pero ya puedo crear circuitos y probar el manejo del coche.
En el video comento en inglés algunas cosas pero os lo pongo aquí. En la esquina de arriba véis lo que estoy pulsando. Cuando se pulsa una dirección, el coche intentará girar hasta esa dirección. Creo que después de probarlo un poco el sistema es más o menos intuitivo, y veréis que he sido capaz de hacer una vuelta completa decente, a buena velocidad. Podemos ir marcha atrás y el control es el mismo, aunque la dirección cambia 180º, para adaptarse a dónde se va a mover el coche.
El juego detecta cuándo estamos fuera de la carretera (veréis la animación de polvo en las ruedas) pero aún me falta cambiar la física cuando pase eso. También quiero meterle alguna mecánica de derrapes.
Para la segunda versión he cambiado los gráficos por una vista pseudo-3D estilo modo 7. Como véis en el video (ahí lo comento también, en inglés) en realidad el control y la física siguen siendo los mismos y puedo alternar esa vista modo 7 con la vista anterior 2D desde arriba.
El control en 3D ahora mismo no es muy preciso pero esto es por culpa del sprite del coche, que es provisional y sólo tiene 8 direcciones. Cuando ponga un sprite que gire con un ángulo más fino va a mejorar bastante.
El efecto modo 7 creo que ha quedado bastante bien y va suave. Por supuesto en esta consola no se puede hacer que en un modo 7 gire la cámara, porque todo se tiene que dibujar con líneas horizontales/verticales de las texturas del cartucho. Ahora mismo (primera versión del código) dibujar el circuito en modo 7 se está chupando un 90% de la CPU, pero creo que lo puedo ser capaz de optimizar bastante más. Veremos cuánto...
#770 Jaja en serio nunca has oído del modo 7 de la super nintendo?
Es lo que usaban juegos como mario kart o f-zero.
Pero también se ha seguido usando ese nombre desde entonces
#769 Eres un puto amo tio 
Estaría guapo meterle objetos a lo mario kart, aunque no sé si entra en tus planes.
#771 pues desconocia totalmente el termino 
Como va en cuanto a comunidad? ha ido aparecido mas gente que este desarollando cosas? Con el tema de las diferentes integraciones que estas haciendo alguno mas debe estar haciendo cositas no?
#772 Jeje no iba por ahí. La idea es hacer un juego más tipo arcade. Además no va a ser un circuito donde des vueltas sino que es estilo carrera por etapas.
#773 Pues hasta donde sé, no. Creo que sí hay más personas jugando a la consola, tras aparecer en RetroArch, Steam y demás. Pero desarrollando no, o por lo menos si hay alguien haciendo cosas no ha dicho ni enseñado nada. Por ahora cuento con que los juegos los seguiré haciendo básicamente yo.
Como visteis necesitaba un nuevo sprite de coche para mi juego, con más ángulos para poder girar más suave. Pensé en usar algún modelo de coche 3D gratuito, pero no soy artista 3D así que me iba a ser difícil hacerlo bien. También tenía la idea de pagar a alguien en Fiverr para que me lo hiciera pero puede salir caro y encima es complicado que me vayan a dejar bien del todo la perspectiva, los ángulos de giro y la iluminación.
Al final se me ocurrió otra idea: usar coches en miniatura (vamos, de los de juguete). Son baratos, fáciles de encontrar y tienen buena pinta, así que los busqué y me compré varios.
Me monté un entorno controlado con la posición y la iluminación que buscaba, y saqué fotos girando el coche 15 grados cada vez, para tener el sprite con 24 posiciones. También dibujé una cuadrícula para controlar que la perspectiva de las fotos fuera la misma que usa el juego. Y le pegué un pequeño punto de color en el techo para saber dónde queda el centro de giro y poder colocar bien todas las fotos.
Este es el resultado final. Tenéis un modelo más grande con todo el detalle, y también el modelo reducido que va a usar el juego, ya con estilo más "pixel art". Todo esto me ha llevado tiempo (y aún sólo he hecho este coche), pero queda muy bien. También se adapta bastante bien a la perspectiva del juego, así que estoy contento 
#777 Bueno de momento sólo he hecho ese primer coche (que su curro me ha llevado). Tampoco sé si llegaré a hacer los 4 o alguno de ellos no, pero sí me gustaría que no hubiera un solo tipo de coche.
Sí, os lo enseñaré en el juego pero antes voy a intentar hacer un poco más realista el circuito. Ahora el coche queda tan bien que hay mucho contraste con el resto jaja
#778 con algun shader puedes sacar varios colores del mismo modelo, y ahorrar algo de trabajo.
El metodo que has usado es parecido a la roboscopia usada en prince of persia!!
#775 No se ni que decir tio, es que eres un puto dios. Ojala fuera la mitad de resolutivo que eres tu para todo. Que envidia sana joder.
