Suelto la pregunta a bocajarro:
¿Qué os parece que el juego en momentos determinados (mostrar 1 mapa fijo) baje a 18 FPS?
Creo que son pocos, el resto funciona correctamente a sus 60 FPS. Y lamentablemente no puedo "recortar" más la rutina de dibujado de mapa.
La máquina es un iPad 1.
Alguna opinión? O_O
Hark0 eso es con la Beta o con la version Stable?¿..
Te lo digo porque mi juego funciona a 45 FPS (constantes, a veces baja a 43 o 44 pero ni un seg), y tiene todo lo que le puedas añadir a GLBasic , físicas 2D, texturas iluminacion en tiempo real...
Ojo que yo estoy trabajando en el ipad a 480x320, pero aún asi deberia de no dar ningun problema...
Mi iPad también es el 1...
hmmmm
Es con la última beta.... tendré que repasar mi fuente a ver si consigo acelerar el tema.
Reboto esto al foro EN:
http://www.glbasic.com/forum/index.php?topic=8581.0
Pues yo creo que tienes que tener un pintado muy complicado, o estás haciendo muchos bucles y cálculos, o estás reescalando sprites, que es muy costoso en tiempo. Intenta optimizar el pintado. Mira también que no estés copiando TYPES en algún bucle, porque eso también ralentizaría. Por ejemplo, es mejor usar índices a datos en cada celda del mapa que usar los propios datos.
Quote from: hardyx on 2012-Sep-20
Pues yo creo que tienes que tener un pintado muy complicado, o estás haciendo muchos bucles y cálculos, o estás reescalando sprites, que es muy costoso en tiempo. Intenta optimizar el pintado. Mira también que no estés copiando TYPES en algún bucle, porque eso también ralentizaría. Por ejemplo, es mejor usar índices a datos en cada celda del mapa que usar los propios datos.
He hecho una prueba "simple"...
Tengo un bucle que pinta así:
FOR y=0 TO 126
FOR x=0 TO 133
aqui ANTES tenia esto: drawrect x,y,5,5,rgb // PINTANDO UN CUADRADO DE 5x5px
ahora he probado con drawsprite grfx,x,y //PINTANDO UNA IMAGEN
Bien, probando a pintar con DRAWRECT tarda 11 ms
pintando con DRAWSPRITE consigo 6.2 ms
Ahora estoy examinando el tema ALPHAMODE, que lo gasto nada menos que 72 veces (NO SIEMPRE EN EL MAIN LOOP), sinó en total en el proyecto....
hmmm ¿alguna alternativa a esta funcion?
Lo del Alphamode, no es demasiado problemático lo pregunté en el foro Inglés, y me comentarón que aunque parece a mi me lo parecia que es una cosa que consume , parece ser que no consume demasiado....
Te expongo una cosilla que vi con el Arduino, por si no consigues subir los FPS... porque no tratas de intercalar lo que tienes que dibujar en 2 partes. o sea dibujas la mitad de arriba y la de abajo, alternando muy rápidamente...
Estó aunque es un apaño chapuzdero, es lo que hace mi pantalla LCD de 128x64 en el Arduino, y no se nota nada... aquí no sé si se puede hacer igual....
A ver...
PS: Yo optaria por no usar aún la Beta, como te digo, yo tengo muchísimos más calculos que tú estoy seguro, y ya no te hablo del iPad, si no en el Palm Pre sigue funcionando a 45 FPS... algo hay...
Ojo no hayas anindados 3 bucles, que eso es la maquina de comerse frames, con for que lleguen solo a 30 o asi, en el mismo PC, se ralentiza pero una barbaridad....
El Alphamode lo mismo depende de la máquina, habrá máquinas que lo hacen por software mezclando colores como la Wiz, y otras que lo hacen por OpenGL muy rápido como el iPhone. Pero puedes probar a pintar por capas, te creas una pantalla virtual CREATESCREEN y pintas todo lo que tenga el mismo alphamode (por ejemplo, para sombras o textos) y luego lo vuelcas en la pantalla principal de golpe, que será más rápido.
Yo estoy ahora con el mismo problema con un juego que quería sacar ¡por fin! este fin de semana. Es el típico shooter de marcianitos que comencé para aprender GLBasic y que aunque no quería publicar me han convencido para que lo haga. Todos los niveles van bien salvo uno que tiene nubes. Ahí los fps bajan drásticamente a 16. Es por el alphamode que se lo voy a tener que quitar y aún así reducir el número de nubes de 30 a 10 en pantalla. Está claro que las transparencias sí que consumen procesador.
@mentalthink: efectivamente parece que ALPHAMODE no afecta en mi loop. He eliminado TODOS los ALPHAMODE (se ve fatal claro, pero es un test) y NO GANO NADA EN VELOCIDAD... sobre lo de partir la pantalla... casi me decanto por la "opción Hardyx".
@hardyx: es lo que estoy pensando, crear un buffer, volcarlo por capas a medida que necesite X o Y gráfico...
@Alex_R: hmmmm ahora si que me dejas con el mosqueo... ¿en ordenador que FPS tienes? en iOS estás en FPS 16-18 verdad? raro raro raro
Estoy "arañando" Frames por todas partes :D
Me sigue sorprendiendo que el programa corra CUATRO veces más rápido sobre vmware en macos (ósea, está emulando un pc, pero como si nada), contra el ipad1 que cae en picado...
Ya tengo 40 FPS en pantallas "normales" (menús, opciones, etc) y 20 FPS en la pantalla del mapa.
(Utilizando CREATESCREEN para el mapa pasa a 40 FPS).
"Cosas" que han ralentizado mi loop, según veo: PINTAR líneas con DRAWLINE... O_O
Sigo actualizando según observo:
Definitivamente las rutinas gráficas DRAWRECT también ralentizan el loop.
Basta comentar que he eliminado TODAS las llamadas a dicha función... he pasado de un tiempo de render por pantalla de 8ms a 2ms.
::)
Antes de marearte tanto, ¿has comprobado en otro iPad?, ¿mira que si tienes "algo" instalado que estás creando conflicto?.
Por probar...
Quote from: msx on 2012-Sep-20
Antes de marearte tanto, ¿has comprobado en otro iPad?, ¿mira que si tienes "algo" instalado que estás creando conflicto?.
Por probar...
hmmmm no había caido XDDDDDDDDDDDD
Habrá que probarlo... sigo tocando mi src.... :/
Bien, parece que lo he logrado!
Aunque creo que todavía puedo sacarle más FPS, actualmente tengo 45-60 FPS en casi la totalidad de la aplicación, salvo en la pantalla de juego, que depente de la cantidad de gráficos que contenga el mapa en cuestión... se queda en 30 FPS.
El tiempo de pintado de pantalla está actualmente en 0.5-1 ms para el juego normal y cae a 3,5 ms para las pantallas con más carga gráfica...
¿Dónde estaba el problema?
- Parece que al iPad1, le cuesta ejecutar con la misma velocidad que en ordenador, las rutinas gráficas de GLB tipo DRAWLINE, DRAWRECT, etc. He sustituído estas funciones por DRAWSPRITE / DRAWANIM que sí funcionan a velocidad aceptable.
- He PREcalculado las posiciones de los gráficos antes de pintar la matriz de mapas. Anteriormente realizaba los cálculos en el bucle de pintado de mapas, frenando así la velocidad del juego. La diferencia puede ser muy notable, os recomiendo hacer pruebas en vuestros loops si tenéis que calcular en tiempo real la posición de tiles, etc... Un cambio tan sencillo como añadir una suma en un loop puede hacer que el tiempo de render de una pantalla pase de 0,5 a 10 ms rapidamente.
- Para la rutina de dibujado de mapa, que es un bucle bastante largo debido a las dimensiones de mi mapa, he seguido el consejo de @Hardyx... con CREATESCREEN hago un solo cálculo y luego sólo tengo que pintar el sprite correspondiente al mapa... he pasado en esta pantalla de 50 ms a 0,5 ms...
...
¿Os quedaríais con los 30 FPS en las pantallas "complicadas" o intentaríais ganar algo más?
Para aclarar MÁS las cosas:
No es lo mismo esto:
posx=0
posy=0
FOR y=0 TO BING_ALTO-1
FOR x=0 TO BING_ANCHO-1
[color=red]renderx=posicion_scrollx+posx
rendery=posicion_scrolly+posy[/color]
//recorte mapa
IF renderx>limitex_max AND renderx<limitex_min AND rendery>limitey_max AND rendery<limitey_min
IF BING_GRFX[x][y]>0 THEN DRAWANIM GRAFICOS_Bloque_Codigo,BING_GRFX[x][y],[color=red]renderx,rendery[/color]
IF BING_OBJETOS[x][y]>0 THEN DRAWANIM GRAFICOS_Objeto_Codigo,BING_OBJETOS[x][y],[color=red]renderx,rendery[/color]
IF BING_ENEMIGOS[x][y]>0 THEN DRAWANIM GRAFICOS_ENEMIGO_Codigo,BING_ENEMIGOS[x][y],[color=red]renderx,rendery[/color]
ENDIF
posx=posx+50
NEXT
posx=0
posy=posy+50
NEXT
Que ésto otro:
posx=0
posy=0
FOR y=0 TO BING_ALTO-1
FOR x=0 TO BING_ANCHO-1
//recorte mapa
IF renderx>limitex_max AND renderx<limitex_min AND rendery>limitey_max AND rendery<limitey_min
IF BING_GRFX[x][y]>0 THEN DRAWANIM GRAFICOS_Bloque_Codigo,BING_GRFX[x][y],[color=red]posicion_scrollx+posx,posicion_scrolly+posy[/color]
IF BING_OBJETOS[x][y]>0 THEN DRAWANIM GRAFICOS_Objeto_Codigo,BING_OBJETOS[x][y],[color=red]posicion_scrollx+posx,posicion_scrolly+posy[/color]
IF BING_ENEMIGOS[x][y]>0 THEN DRAWANIM GRAFICOS_ENEMIGO_Codigo,BING_ENEMIGOS[x][y],[color=red]posicion_scrollx+posx,posicion_scrolly+posy[/color]
ENDIF
posx=posx+50
NEXT
posx=0
posy=posy+50
NEXT
El primero ES el loop rápido.... =D
Repasa tus loops @Alex_R ;)
Menuda optimización que has hecho!!! Las ordenes de dibujo de geometrías linea, rectángulo, van más lentas que dibujar un sprite o imagen preparada, ya que la mayoría de librerías gráficas están optimizadas para eso. Además, cuando dibujas una línea o un círculo se hace un cálculo por debajo, que se llama algoritmo de Bressenham (no me llaméis friki :D) para pintar los pixels de la línea.
Aqui puedes ver el algoritmo de Bressenham
http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm
http://en.wikipedia.org/wiki/Bresenham%27s_circle_algorithm
Enhorabuena hark0, seguro que todos saldremos beneficiados de tus investigaciones.
Mi problema de bajada de fps estaba en un iPod Touch que es el que uso para hacer pruebas. Tengo limitado el juego a 30 fps y siempre está en todos los niveles ahí salvo el de las nubes que bajaba drásticamente. Le he bajado el número de nubes de 30 a 10 y ahora va bien en el iPod Touch. Además, le he puesto alphamode 1 y se nota más rápido que con -1.
Por cierto que he hecho una prueba con un iPhone 4s con 50 nubes (con el iPod le tengo puesto 10 a la vez) y no hay reducción de fps. En cualquier caso esto es para deciros que las transparencias sí influyen en la velocidad y más con alphamode interpolado y con blending (claro, según mi experiencia)
Quote from: Alex_R on 2012-Sep-21
Mi problema de bajada de fps estaba en un iPod Touch que es el que uso para hacer pruebas. Tengo limitado el juego a 30 fps y siempre está en todos los niveles ahí salvo el de las nubes que bajaba drásticamente. Le he bajado el número de nubes de 30 a 10 y ahora va bien en el iPod Touch. Además, le he puesto alphamode 1 y se nota más rápido que con -1.
Por cierto que he hecho una prueba con un iPhone 4s con 50 nubes (con el iPod le tengo puesto 10 a la vez) y no hay reducción de fps. En cualquier caso esto es para deciros que las transparencias sí influyen en la velocidad y más con alphamode interpolado y con blending (claro, según mi experiencia)
Hmmm quizás el tema de ALPHAMODE está en donde y cómo se use... en mi caso particular NO afecta ni un misero 0,1 ms. :P
Personalmente el tema de los Alphamode como dice Alex si te pasas en el array puede dar quebraderos de cabeza, una cosa
es meter el Alphamode dentro del for para recorrer las cosas, pero si todos tienen la misma transparecias pues supongo que es mejor dejarlo antes del For:
Me alegro Hark0 que lo hayas arreglado, interesante lo que comentas que los drawline bajan los FPS, cosa que desconocia...
Quote from: mentalthink on 2012-Sep-21
Personalmente el tema de los Alphamode como dice Alex si te pasas en el array puede dar quebraderos de cabeza, una cosa
es meter el Alphamode dentro del for para recorrer las cosas, pero si todos tienen la misma transparecias pues supongo que es mejor dejarlo antes del For:
Me alegro Hark0 que lo hayas arreglado, interesante lo que comentas que los drawline bajan los FPS, cosa que desconocia...
Como ya se ha comentado (
frikimente :D =D ;)) en el hilo, las rutinas gráficas suelen ser más lentas que volcar una
surface imagen...
También, supongo yo, que se deberá a la tarjeta gráfica de la máquina en cuestión.... anteriormente programaba en un portátil HP DV4000 (tarjeta GM915, creo que este era el modelo). Pues bien, con esta tarjeta de vídeo
NO podía usar funciones MEM2SPRITE ni silimares, ya que no soportaba estas
historias (sorprendentemente corría todo tipo de apps/juegos sin problemas, léase el WOW).
En el equipo del despacho, con una tarjeta de vídeo Raedon HD6450, todo funciona de narices...
Pero lo bueno del asunto, es que el juego lo programo por las noches en casa, con un MacBook Pro, emulando con VMware... y
NI UN PROBLEMA...
Lo recomendable sería, y como se ha comentado aquí, probarlo en diferentes máquinas y/o configuraciones.
Pego aquí el código que utilizo para cálcular el tiempo de render por pantalla:
...
... inicio de loop con for o lo que sea
...
Tiempo_Render=GETTIMERALL()
Tiempo_Render_FIN=0
....
.... loop render / cálculos de lo que sea
....
Tiempo_Render_FIN=GETTIMERALL()-Tiempo_Render
PRINT Tiempo_Render_FIN,0,0
SHOWSCREEN
....
.... fin del loop
....
No es nada complicado como se puede ver, pero si nos da información sobre el timming de nuestras rutinas. Además se puede meter de forma muy sencilla en cualquier LOOP para ver su tiempo de cálculo.
Espero que os sirva. ;)