mini juego Deadly Eye port in progress desde DIV1

[SplinterGU]

No comparo, he dicho que no he hecho pruebas, pero que parece lo más lógico, sobre todo teniendo en cuenta lo que cito sobre restas VS divisiones, que pese a la carga extra de la pseudointerpretación, un if+resta sigue siendo más rápido que un módulo.

Supuestamente hay circuitos integrados diseñados para realizar las divisiones en un ciclo, pero está visto que no se usan en las ALUs de las CPU. Tendría que analizar cuantos ciclos lleva realizar una raiz cuadrada, aunque sea por aproximación mediante series de fourier, y comparar:
-con una (resta+abs+comparación)*2+comparación en el peor de los casos.
-con una resta+abs+comparación en el mejor de los casos.

PD: esta forma de pensar ¿me convierte en analista programador junior? ;D

junior no, pero yo no afirmaria eso.

[Noivern]

Hacer un fget_distance debe ser menos costoso que un collision o collision_box en cada frame espero.
He probado en el laptop con el último dcb y noto que el proce va MUCHO más holgado a 800 mhz
Y sigan comentando todo lo técnico, esta buena la clase :D

Free me tiene en suspenso hasta que llegue a casa, que según su mp es dentro de 10 horas xD

[SplinterGU]

Hacer un fget_distance debe ser menos costoso que un collision o collision_box en cada frame espero.
He probado en el laptop con el último dcb y noto que el proce va MUCHO más holgado a 800 mhz
Y sigan comentando todo lo técnico, esta buena la clase :D

Free me tiene en suspenso hasta que llegue a casa, que según su mp es dentro de 10 horas xD

pues no deberia, porque no solo haces fget_dist, tambien necesitas hacer get_id, y ahi ya tenes 2 calls y el loop, accesos a pila y condiciones internas del motor, ademas, que con get_dist no estas teniendo en cuenta cosas como size, angle, tamaño del grafico (si este cambia, y si lo tenes en cuenta tenes que adicionar logica para eso) y otras tantas cosas.

[SplinterGU]

Hacer un fget_distance debe ser menos costoso que un collision o collision_box en cada frame espero.
He probado en el laptop con el último dcb y noto que el proce va MUCHO más holgado a 800 mhz
Y sigan comentando todo lo técnico, esta buena la clase :D

Free me tiene en suspenso hasta que llegue a casa, que según su mp es dentro de 10 horas xD

y en esta prueba sobre el 800mhz que estas usando?

[Noivern]

y en esta prueba sobre el 800mhz que estas usando?

Hice todos los cambios que me sugirieron:
dump_type, restore_type, verificar la distancia y al final el collision_box()
Lo noto bastante mejor que antes, cuando hacia un collision(type) en cada frame.
A veces hay un bajón de fps, pero sucede cuando pasa la nube grande (posee alpha y genera sombras con alpha) + MUCHOS disparos.
Antes, no habia bajón de fps, pero lo que sucedia era que tanta carga forzaba al proce a subir a 1.6 Ghz o 1.9 Ghz. Ahora ya no sucede este salto en la frecuencia =)

[SplinterGU]

si usas collision_box, proba quitar la verificacion de la distancia, porque eso ya lo hace el collision_box.

[Drumpi]

Las nubes, si usas un alpha de 128, te sale algo más rentable con flags=4 (o cualquier valor intermedio (144-112), teniendo en cuenta que por defecto existen sólo 16 ALPHA_STEPS).

Y si usas varios procesos nube, es probable (no lo sé con seguridad) que sea más rápido usando un scroll (claro que usarás mapas más grandes). La creación/destrucción de procesos hay que tenerlos en cuenta, aparte de su ejecución individual.

NOTA: estos son consejos de optimización específicos (porque sabemos que tenemos más RAM que CPU) y muy guarros. Sólo aplicables en caso de necesidad urgente de recursos. Por lo general conviene hacer las cosas de una forma elegante y optimizando recursos :D :D :D

[Noivern]

si usas collision_box, proba quitar la verificacion de la distancia, porque eso ya lo hace el collision_box.

Probaré cuando me desenferme, hoy ha sido un mal día u.u

Las nubes, si usas un alpha de 128, te sale algo más rentable con flags=4 (o cualquier valor intermedio (144-112), teniendo en cuenta que por defecto existen sólo 16 ALPHA_STEPS).

Y si usas varios procesos nube, es probable (no lo sé con seguridad) que sea más rápido usando un scroll (claro que usarás mapas más grandes). La creación/destrucción de procesos hay que tenerlos en cuenta, aparte de su ejecución individual.

NOTA: estos son consejos de optimización específicos (porque sabemos que tenemos más RAM que CPU) y muy guarros. Sólo aplicables en caso de necesidad urgente de recursos. Por lo general conviene hacer las cosas de una forma elegante y optimizando recursos :D :D :D

En la nube gigante uso alpha... mmm... 255 - 2*(255/alpha_steps). Igual creo que lo mejor es quitarle el alpha en la wiz/caanoo, ni siquiera flags 4, que se ve fea esa nube con 50% de transpariencia. Y si, tengo cuidado de eliminar todo lo que no se usa, de hecho, es mi pequeño orgullo que este shmup ande muy suave incluso a 800 Mhz con muchos procesos en pantalla, a diferencia de varios proyectos que he probado que tarde o temprano hacen saltar la frecuencia a 1.6Ghz o más, en linux al menos. La media de cpu usado es de 35% con peaks de 65% ~ 70% con el laser y la fukin nube gigante.
Tengo que revisar redundancias a ver si lo puedo mejorar más aún, si se fijan en el video que grabó Free anda muy lento, eso si hay que tener en cuenta que se esta usando rescale_resolution.
¿Ayudará en algo añadir modo hardware al set_mode() en wiz/caanoo?

[SplinterGU]

si usas collision_box, proba quitar la verificacion de la distancia, porque eso ya lo hace el collision_box.

Probaré cuando me desenferme, hoy ha sido un mal día u.u

Las nubes, si usas un alpha de 128, te sale algo más rentable con flags=4 (o cualquier valor intermedio (144-112), teniendo en cuenta que por defecto existen sólo 16 ALPHA_STEPS).

Y si usas varios procesos nube, es probable (no lo sé con seguridad) que sea más rápido usando un scroll (claro que usarás mapas más grandes). La creación/destrucción de procesos hay que tenerlos en cuenta, aparte de su ejecución individual.

NOTA: estos son consejos de optimización específicos (porque sabemos que tenemos más RAM que CPU) y muy guarros. Sólo aplicables en caso de necesidad urgente de recursos. Por lo general conviene hacer las cosas de una forma elegante y optimizando recursos :D :D :D

En la nube gigante uso alpha... mmm... 255 - 2*(255/alpha_steps). Igual creo que lo mejor es quitarle el alpha en la wiz/caanoo, ni siquiera flags 4, que se ve fea esa nube con 50% de transpariencia. Y si, tengo cuidado de eliminar todo lo que no se usa, de hecho, es mi pequeño orgullo que este shmup ande muy suave incluso a 800 Mhz con muchos procesos en pantalla, a diferencia de varios proyectos que he probado que tarde o temprano hacen saltar la frecuencia a 1.6Ghz o más, en linux al menos. La media de cpu usado es de 35% con peaks de 65% ~ 70% con el laser y la fukin nube gigante.
Tengo que revisar redundancias a ver si lo puedo mejorar más aún, si se fijan en el video que grabó Free anda muy lento, eso si hay que tener en cuenta que se esta usando rescale_resolution.
¿Ayudará en algo añadir modo hardware al set_mode() en wiz/caanoo?

si estas en plan de optimizar, lo ideal seria quitar el scale_resolution y currarse una version para wiz/caanoo a 320x240.

scale_resolution funciona, pero a pesar de utilizar tablas de optimizacion es lento, pensa que primero dibuja la pantalla normal y luego la reescala, usando tablas para no calcular el reescalado, pero va copiando pixel a pixel.

[Noivern]

Lo sé, pero quiero que sea el último recurso, que trabajar con los gráficos y reacomodar las cosas me da pereza xD
Y mientras tanto Free anda de viaje (o preparandose para ello), asi que hasta la próxima semana no tendré feedback :(

[Drumpi]

Creo que WIZ/CAANOO hacían reescalado por HW si usas resoluciones mayores que la pantalla. Haz la prueba de todas formas, comenta la linea de escale_resolution, sólo pueden pasar dos cosas:
-Que no se reescale y sólo se vea parte de la pantalla.
-Que se reescale automaticamente, usando el HW de reescalado en lugar de hacerlo por soft (vamos, creo que las SDL de WIZ/CAANOO hacen uso de dicho hardware).

Pero siempre es mejor lo que dice Splinter: hacer el juego directamente a 320x240.
No recuerdo si dejé por ahí un programa que reescalaba gráficos de FPGs de forma automática...

[Noivern]

si usas collision_box, proba quitar la verificacion de la distancia, porque eso ya lo hace el collision_box.

He probado y.... no noto diferencia. A ver si Free y su caanoo me ayudan aquí xD. Lo he dejado con un simple collision_box(tipo proceso). Según lo que comentaste, se debería notar en la caanoo (para bien o para mal), puesto que ya no estoy obteniendo las id 1 a 1 ni midiendo distancia. Se supone que la distancia el mismo collision_box() la mide.

Creo que WIZ/CAANOO hacían reescalado por HW si usas resoluciones mayores que la pantalla. Haz la prueba de todas formas, comenta la linea de escale_resolution, sólo pueden pasar dos cosas:
-Que no se reescale y sólo se vea parte de la pantalla.
-Que se reescale automaticamente, usando el HW de reescalado en lugar de hacerlo por soft (vamos, creo que las SDL de WIZ/CAANOO hacen uso de dicho hardware).

Pero siempre es mejor lo que dice Splinter: hacer el juego directamente a 320x240.
No recuerdo si dejé por ahí un programa que reescalaba gráficos de FPGs de forma automática...

¿Recuerdas el nombre del programa para buscarlo?
¿has probado lo que dices acerca del reescalado automático por hw? Yo no puedo, no tengo ni wiz ni caanoo ni siquiera dingoo... pero estoy esperando la llegada de la caanoo :)


Acerca del desarrollo: con las fiestas casi nada xD solo pruebas, le cambié el color 0,0,0 que habia en el mapa de tierra y que hacía que quedaran residuos de gráficos en algunas zonas, agregué sonidos al tomar el item de armas. No pude dejarlos iguales al del powerup, nunca anoté los valores para los efectos en el audacity ni el orden, esto de ser tan desordenado... xD. Sin embargo el resultado es aceptable.
Las descargas las actualizaré cuando tenga señales del parrandero (fiestero) de Free XD

[Drumpi]

El programa lo llamé "Venturer Resize", ya que lo diseñé para reescalar gráficos de juegos para Venturer de PC (800x600) a la resolución de GP2X (320x240). Se usa mediante línea de comandos, busca un fichero de texto llamado "library.ini", y busca las secciones [IMAGENES] y [ANIMACIONES], y reescala todos los fpg listados a continuación.
Sin embargo, vienen funciones de reescalado por soft en el propio código, por lo que se puede modificar para que busque los FPGs de un directorio y ejecute dicha función de forma automática con ellos.

La peor pega es que está escrito en código Fenix ;D

http://drumpi.se32.com/venturer/utils/ventresize.zip

EDIT: no dejeis de visitar la web de Venturer (venturer.esp.st) y la de "los V Days" (http://drumpi.se32.com/venturer/) ;D ;D ;D

[laghengar]

Ostias nene, que locura, XD a ver si venzo pronto al jefe, que me ha tenío loco un buen rato. Un saludo, gran juego.

[Noivern]

¡¡Actualizada la version para Windows!! Mejoras en rendimiento, ver más en el primer post!
Aprovecho de dar las gracias a Drumpi, Splinter y laghengar por sus comentarios ;D

@laghengar: Fijate en el puntaje que te da cada enemigo y con cada arma, asi lograrás sacar más créditos =)


EDIT:

Futu, revisa tus MPs  :P