características al programar para wiz

Prg · December 29, 2009, 07:55:46 PM

bien, la idea es recopilar información sobre las características para los juegos que se programan en wiz (para aquellos que no tenemos una)

primero sobre la medida de scroll, eso ya se comentó, y aquí hay una liga:
http://forum.bennugd.org/index.php?topic=962.0

detectar teclas en la wiz:
http://forum.bennugd.org/index.php?topic=737.0

pantalla táctil:
mouse.left y coordenadas de mouse.

discusiones con respecto al wiz:
http://forum.bennugd.org/index.php?topic=772.0
ahora algunas dudas:

he escuchado rumores acerca de que no es bueno modificar el size del gráfico, es verdad?
cuánto es la recaida de fps ante los escalados de gráficos?

cómo está el tema de las transparencias?
están completamente prohibidas?

colisiones, cómo van?
consumen mucho en el wiz?

sugerencias, problemas, ventajas?

saludos

pd:
una duda que tengo desde hace tiempo que no tiene mucho que ver con la wiz, al hacer exit() libero recursos? o lo tengo que hacer antes?

SplinterGU · December 30, 2009, 12:34:10 AM

al morir un programa el sistema libera todo aquello que no se ha liberado...

SplinterGU · December 30, 2009, 12:35:53 AM

todas las demas preguntas, creo que mientras no abuses no hay problema...

Futu-block · December 30, 2009, 08:58:13 AM

transparencias?? que quieres decir con transparencias?? porque un esprite es transparente por algunas partes...

Hokutoy · December 30, 2009, 01:25:06 PM

Quote from: Futublog on December 30, 2009, 08:58:13 AM
transparencias?? que quieres decir con transparencias?? porque un esprite es transparente por algunas partes...

Se refiere, imagino, a si usas un efecto de transparencia como flags=4;

La verdad es que el tema de Flags y el tema de size(sobretodo size) si que afectan bastantante al rendimiento.
Si tienes solo 4 o 5 graficos "resizeados" no pasa nada pero si usas por ejemplo enemigos resizeados, aunque sea a poco tamaño y juntes 10 o 15 sí que notaras caidas importante de framerate.

Si no teneis wiz para probar el codigo intentar encontrar a alguien con una para que os haga de betatester frecuentemente... a veces añades codigo nuevo que en el PC va de muerte y que en la wiz, por el motivo que sea, ralentiza bastante.

Saludos!

Prg · December 31, 2009, 01:43:25 AM

Quote from: Hokutoy on December 30, 2009, 01:25:06 PM
Quote from: Futublog on December 30, 2009, 08:58:13 AM
transparencias?? que quieres decir con transparencias?? porque un esprite es transparente por algunas partes...
Se refiere, imagino, a si usas un efecto de transparencia como flags=4;

La verdad es que el tema de Flags y el tema de size(sobretodo size) si que afectan bastantante al rendimiento.
Si tienes solo 4 o 5 graficos "resizeados" no pasa nada pero si usas por ejemplo enemigos resizeados, aunque sea a poco tamaño y juntes 10 o 15 sí que notaras caidas importante de framerate.

Si no teneis wiz para probar el codigo intentar encontrar a alguien con una para que os haga de betatester frecuentemente... a veces añades codigo nuevo que en el PC va de muerte y que en la wiz, por el motivo que sea, ralentiza bastante.

Saludos!

a eso me refería, gracias por la información amigo :)

Drumpi · December 31, 2009, 02:30:55 AM

Flags=4 es mucho más efectivo en rendimiento que usar la local ALPHA.

En teoría, si, usar size y alpha consumen recursos... pero en GP2X. Con 4 o 5 procesos con un alpha distinta de 255 si que se nota la bajada de rendimiento: de 60 a 50fps. En WIZ no debería haber tanto problema, pues hablamos de una máquina por defecto 2.5 veces más potente (hasta 4 veces usando overclock).
Pero eso si, no es bueno abusar, seguimos hablando de recursos limitados.

De momento, yo estoy haciendo mis pruebas en mi gp2x, y creo que estoy haciendo BURRADAS, y apenas he perdido unos 4 o 5 fps: voy a 50 fps y he metido unos 100 procesos tile con siete procesos enemigo, con una detección de durezas de considerable tamaño, y detectando colisiones. Lo que he probado, a 240MHz y activando los RAM timings (cambio de los tiempos de reacción de la RAM a unos más rápidos) va suave suave, por lo que en wiz debe ir de fábula.

Lo que si está prohibido es usar resoluciones más altas a la nativa, porque ahi si que cae el rendimiento a lo bestia (a poco que le metas alguna transparencia, adiós). En mi negrita, 800x600 va por debajo de 25fps.
Y no lo he probado en Bennu, pero los comandos PUT a toda la pantalla tampoco es muy buena idea. Si Splinter ha hecho MUY bien sus deberes, ya no debería ser tanto problema, pero en Fenix sí que lo era.

Recomendación: la misma que todos, haz pruebas, usa una WIZ, una GP2X o un PC a 500-800MHz.

Hokutoy · December 31, 2009, 06:02:11 AM

Algo que si es importante... si pensais utilizar overclock en la wiz (con el polluxset) pensar que la tactil se descalibra una barbaridad... hablo de 2 a 3 cms de fallo que en la pantallita de la wiz es brutal.
Resumen... overclock en la wiz con un juego no tactil, genial, mas fluidez. Overclock en un juego que usa tactil con frecuencia, inviable.

Aunque sin overclockear la wiz, se tendría que poder hacer cualquier cosa de sobras.

Saludos!

Futu-block · December 31, 2009, 11:35:59 AM

Quote from: Hokutoy on December 30, 2009, 01:25:06 PM
Quote from: Futublog on December 30, 2009, 08:58:13 AM
transparencias?? que quieres decir con transparencias?? porque un esprite es transparente por algunas partes...
Se refiere, imagino, a si usas un efecto de transparencia como flags=4;

La verdad es que el tema de Flags y el tema de size(sobretodo size) si que afectan bastantante al rendimiento.
Si tienes solo 4 o 5 graficos "resizeados" no pasa nada pero si usas por ejemplo enemigos resizeados, aunque sea a poco tamaño y juntes 10 o 15 sí que notaras caidas importante de framerate.

Si no teneis wiz para probar el codigo intentar encontrar a alguien con una para que os haga de betatester frecuentemente... a veces añades codigo nuevo que en el PC va de muerte y que en la wiz, por el motivo que sea, ralentiza bastante.

Saludos!

A lo que comento: ¿para que usar un size de un personaje, enemigo o lo que sea si es una pantalla de 320 x 240?? prefiero reducirlo con el paint ^^U pixelará de todas formas...

un par de cuestions mor: -Un .fpg con imagenes tan pequeñas (esprites 32 x 32 por ejemplo) no relentizará el rendimiento aunque tenga muchiiiiiiisimas ¿no? lo digo para no usar flag para invertir la imagen...

-¿como va el tema del puntero? cambiando de tema...

a lo mejor es

Quotepantalla táctil:
mouse.left y coordenadas de mouse.

pero estoy muy pez en eso...

BoMbErLiNk · December 31, 2009, 02:00:37 PM

Quote from: Hokutoy on December 31, 2009, 06:02:11 AM
Algo que si es importante... si pensais utilizar overclock en la wiz (con el polluxset) pensar que la tactil se descalibra una barbaridad... hablo de 2 a 3 cms de fallo que en la pantallita de la wiz es brutal.
Resumen... overclock en la wiz con un juego no tactil, genial, mas fluidez. Overclock en un juego que usa tactil con frecuencia, inviable.

Aunque sin overclockear la wiz, se tendría que poder hacer cualquier cosa de sobras.

Saludos!

Yo no he tenido ese problema y overclockeo a 800 mhz con polluxset..

--

Respecto al alpha, si es 1 proceso pero ocupa toda la pantalla va a ser siempre lento, es decir el tamaño del gráfico con transparencia es tan importante como el número de ellos.

Futulog puedes usar flags invertido sin ningún tipo de problema.

Prg · December 31, 2009, 02:53:39 PM

Quotelos comandos PUT a toda la pantalla tampoco es muy buena idea. Si Splinter ha hecho MUY bien sus deberes, ya no debería ser tanto problema, pero en Fenix sí que lo era.

mi juego se basa en dibujado con draw, habrá problemas?

la variable exit_status funciona en la wiz, sirve para algo?

Quote
-¿como va el tema del puntero? cambiando de tema...

a lo mejor es

Quotepantalla táctil:
mouse.left y coordenadas de mouse.
pero estoy muy pez en eso...

pues tengo entendido que pulsar sobre la pantalla es igual a mouse.left, y por ende las coordenadas de la pulsación deben ser las del mouse :)

muchas gracias por sus comentarios, me están sirviendo muchísimo, ya que en México la wiz es algo del otro mundo (no la he visto en ningún lugar ??? ).

Quote
Algo que si es importante... si pensais utilizar overclock en la wiz (con el polluxset) pensar que la tactil se descalibra una barbaridad... hablo de 2 a 3 cms de fallo que en la pantallita de la wiz es brutal.

eso se activa con código o de alguna otra forma, es que mi juego es completamente táctil, y si necesita presición (de cm a mm)

Hokutoy · December 31, 2009, 04:49:53 PM

Quote from: BoMbErLiNk on December 31, 2009, 02:00:37 PM
Quote from: Hokutoy on December 31, 2009, 06:02:11 AM
Algo que si es importante... si pensais utilizar overclock en la wiz (con el polluxset) pensar que la tactil se descalibra una barbaridad... hablo de 2 a 3 cms de fallo que en la pantallita de la wiz es brutal.
Resumen... overclock en la wiz con un juego no tactil, genial, mas fluidez. Overclock en un juego que usa tactil con frecuencia, inviable.

Aunque sin overclockear la wiz, se tendría que poder hacer cualquier cosa de sobras.

Saludos!

Yo no he tenido ese problema y overclockeo a 800 mhz con polluxset..

--

Respecto al alpha, si es 1 proceso pero ocupa toda la pantalla va a ser siempre lento, es decir el tamaño del gráfico con transparencia es tan importante como el número de ellos.

Futulog puedes usar flags invertido sin ningún tipo de problema.

Buenas Bomber!
Eso que comentas me interesa bastante la verdad... te importa pasarme el .gpe que usas para cargar el pollusex sin que se descalibre la pantalla? Lo he probado bastntes veces con varios juegos mios que usan la tactil y el resultado siempre es el mismo cuando usas Bennu y overclock... pulsas en mitad de la pantalla y el "cursor" aparece en la derecha del todo... con un fallo de sensibilidad de 2 a 3 cms.
Si no es molestia pasame el .gpe (o escribe en el foro las lineas) o un ejemplo si tienes algo de tiempo.

Gracias!

BoMbErLiNk · December 31, 2009, 06:05:26 PM

Pues uso el siguiente código, espero que te sirva :)

Quote
#!/bin/sh
./pollux_set 'lcd_timings=397,1,37,277,341,0,17,337;dpc_clkdiv0 =9;cpuclk=800;ram_timings=2,9,4,1,1,1,1'
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:../ruta_mi_juego/bgd-runtime
PATH=$PATH:../ruta_mi_juego/bgd-runtime

echo 2 > /proc/cpu/alignment

bgdi mi_juego

sync
cd /usr/gp2x
exec /usr/gp2x/gp2xmenu

Si te sigue fallando intenta recalibrar la pantalla, quizas el problema este por ahí ;)

--
Por cierto he visto que andabas haciendo un Streets of rage de cartas o algo así, tienes alguna captura o más info ? ;D

Drumpi · December 31, 2009, 06:32:04 PM

La lógica es la siguiente: a procesos con imágeens más grandes, más pixels que procesar. Así que un size con imágenes pequeñas no pasa nada, pero a medida que aumenta, el rendimiento baja, pero desconozco el tope.
Se pueden tener muchos procesos simultáneos (ya lo he dicho, más de 150 procesos tile de 16x16 sin problemas de rendimiento), pero ojo, la creación y la destrucción de procesos consume tiempo.
Y tambien se puede usar draw_xxx sin miedo, pero no se hasta que punto: en Fenix+GP2X el límite estaba en 320x120 pixels por frame. Bennu es más rápido, y la wiz unas 3 veces más potente.

Prg · December 31, 2009, 07:28:46 PM

entiendo, creo que voy entonces bien. gracias drumpi, karma++