Ver la versión completa : Dodgin' Diamond II para GP2X
Wild[Kyo]
19/03/2006, 02:30
Bueno, bueno... :D
El caso es que estaba jugando a este port que hizo A600 para GP32 y he decidido que ya era hora que aportara algo a la scene. Y como he visto que aún nadie lo había portado pues lo he intentado.
Tengo un resfriado bastante jodido y me duele bastante la cabeza por lo que no le he dado más vueltas pero el juego, creo, es jugable.
El juego, para quien no lo conozca, es un sencillo juego de naves en scroll vertical.
Controles:
Stick -> Moverse
B -> Disparar (en el menu para aceptar)
Start -> Pause
Select -> Volver al Menu.
R -> Hacer captura del juego
Y -> En el menu sirve para volver atras (se supone)
Si encontrais algun bug me hariais un favor que me lo comentaseis y si los gurus de Gp32Spain (miq01, Kaos, Uncanny, etc, etc... :D) me quieren echar una mano se lo agradecería mucho. :)
En el archivo comprimido viene el juego y el código fuente.
Foxandxss
19/03/2006, 03:07
Weee me encantan estos tipos de juego, en gp32 nunca lo jugué, asi que cuando el lunes me venga la consola lo pruebo sin falta :).
Si veo bugs te los iré diciendo, pena que aun me falte un poco de conocimiento para poder solucionar los bugs :).
Un saludo.
EDITO: Veo que viene el codigo fuente, voy a mirarlo, pero aun no voy a entender mucho.
Wild[Kyo]
19/03/2006, 05:02
He compilado el juego con las SDL aceleradas por Hardware y el juego va bastante mejor (el sonido sigue mal).
El problema es que la resolucion del juego es 320 x 200. Y al reescalarlo queda un marco rosa (algo muy raro) encima de una parte del juego...
¿Sabeis alguna forma de que no reescale la pantalla? Es que la mejora se nota pero no quiero que me lo reescale T_T
Yo os invoco programadores de Gp32 y Gp2X!!! ^^U
Si soy un "gurú" seguro que es en el arte del mínimo esfuerzo porque a vago y flojo pocos me ganan xDDD.
Ahora miro el código entre anuncio y anuncio de la peli que estoy viendo (para algo tenían que servir esos largos anuncios xD) a ver que se puede mejorar de primeras :)
Una pregunta antes de que me ponga a mirar detenidamente el código, dices lo del reescalado, pero es que se reescala solo o tu lo has forzado para que no se vea ese marco rosa, porque si has visto el marco y dices que en la GP2X se reescala supongo que es porque o lo has compilado en tu PC para Windows/Linux y has visto que pasa eso ¿no?
P.D: Un vistazo de a primera vista me dice que el código no está muy comentado, pero está realmente bien estructurado, así que será facil seguirlo.
jeje se le ve con buena pinta... aver si me la pido i lo pruebo... eske nu tengo muxa pasta pero me muero de ganas de comprarla
Wild[Kyo]
19/03/2006, 20:50
Si soy un "gurú" seguro que es arte del mínimo esfuerzo porque a vago y flojo pocos me ganan xDDD.
Ahora miro el código entre anuncio y anuncio de la peli que estoy viendo (para algo tenían que servir esos largos anuncios xD) a ver que se puede mejorar de primeras :)
Una pregunta antes de que me ponga a mirar detenidamente el código, dices lo del reescalado, pero es que se reescala solo o tu lo has forzado para que no se vea ese marco rosa, porque si has visto el marco y dices que en la GP2X se reescala supongo que es porque o lo has compilado en tu PC para Windows/Linux y has visto que pasa eso ¿no?
P.D: Un vistazo de a primera vista me dice que el código no está muy comentado, pero está realmente bien estructurado, así que será facil seguirlo.
Gracias, yo te gano en vago y flojo pero hoy el resfriado me ha retenido delante del monitor. :D
Seguro que se puede mejorar a primeras pero el dolor de tarro me tiene chungo. XD
Mmmmm, con las librerias aceleradas tengo entendido que pongas la resolución que le pongas (por ejemplo si se inicia con 640x480 pasa a 320x240, no?) las SDL te reescalan la imágen para que quepa en pantalla.
Entonces el problema viene que el juego se inicia a 320x200, las SDL aceleradas lo intentan poner a 320x240 (la version que hay colgada ahora mismo no tiene problemas porque esta compilada con las SDL sin acelerar o quizás con otra versión que no es la última). Entonces cuando lo ejecuto yo pensaba que lo reescalaria y no habría problemas pero no es asi.
Se nota la mejora y que lo reescala pero sale un feo marco abajo del todo de color rosa y con parte de la pantalla. Ahora lo colgaré para que lo veas...
Lo siento porque no este muy comentado, a ver si cuando lo arregla un poco le pongo unos comentarios mios ya que el autor dejo solo unos pocos por ahi (aunque como bien dices el código esta bastante bien estructurado).
Gracias de antemano!!
PD: Vaya parrafada he soltado!! [Ahhh]
< - >
Una cosa más, si le digo que se inicie a 320x240 directamente las paredes no se muestran bien... el juego se nota que esta pensado a ir si o si a 320x200.
< - >
He subido una nueva versión con las diagonales arregladas. El sonido sigue mal y como veis sale un marco rosa un poco feote que no sé como quitarlo con las SDL aceleradas. :(
A ver si algun programador me hecha una mano! :)
Hola.
Ni he mirado el código ni soy un gurú, y a lo mejor lo que digo es una parrafada, pero... ¿Has probado a hacer un FillRect a negro sobre la superficie principal antes de hacer el flip, o al backbuffer antes de pintar en el al comienzo (si es que lo usa)?
Saludos
Wild[Kyo] ¿puedes decirme que versión de las SDL usaste en la primera versión que has compilado que se ve a pantalla completa?
Es cierto que con las SDL aceleradas (al menos la ultima versión) la pantalla ni se redimensiona a toda la pantalla ni se centra ajustada al tamaño real que usa el juego (320x200), ese marco rosa como dices es la misma parte superior de la pantalla que se copia de vez en cuando la parte superior en la parte de abajo (¿a que me recuerda esto?). He comprobado que solo pasa con HWSURFACE pero no con SWSURFACE (y para usar SWSURFACE en SDL_SetVideoMode() he tenido que colocar algunas macros condicionales para usar SDL_UptateRect() en lugar de SDL_Flip()), aunque el hueco en la parte inferior se queda, solo que de color negro. Voy a seguir mirando a que se debe y como se puede solucionar esto con las SDL aceleradas (paeryn incluyó algunas funciones extras) pero cuando puedas dime que SDL usaste con los binarios que has adjuntado al principio.
Respecto al audio, prueba cambiando la función Mix_OpenAudio() en main.c y menu.c por:
Mix_OpenAudio(22050, AUDIO_S16LSB, 2, 512)
He forzado la frecuencia a 22050 Hz (la variable i tomaria este valor si pones en el menu Medium Quality para el sonido), cambiado el formato de salida del sample por AUDIO_S16LSB y el el buffer lo he puesto a 512 para evitar la desincronización del audio, aunque puedes ponerlo a 256 o 128 si quieres intentar sincronizarlo aun más (aunque puede que notes algún corte del sonido si lo reduces mucho).
@Arcnor: Si, si miras el código verás que en determinados momentos (cuando va a cambiar de pantalla, del menu al juego o del juego al menu por ejemplo) se dibuja en negro completamente con SDL_FillRect() como forma de borrar la pantalla y luego hace el obligado volcado de la superficie en pantalla, aunque lo que no se es si dices lo de usar SDL_FillRect() buscando otra utilidad.
']Una cosa más, si le digo que se inicie a 320x240 directamente las paredes no se muestran bien... el juego se nota que esta pensado a ir si o si a 320x200.
Para el port de la GP32, modifiqué el gráfico del fondo y el código para que tirara a 320x240. Échale un vistazo.
Para el port de la GP32, modifiqué el gráfico del fondo y el código para que tirara a 320x240. Échale un vistazo.A600 a la hora de visualizar el juego la pantalla de la GP32 ¿también te daba problemas con los gráficos originales a 320x200?
Wild[Kyo]
20/03/2006, 02:03
Gracias a todos ahora me pongo a leer vuestras sabias palabras. :D
Bueno Wild[Kyo] después de modificar solo unas pocas lineas del código fuente aquí te dejo un ZIP con dos dos versiones del ejecutable, dd2x_sw.gpe es usando SWSURFACE y dd2x_hw.gpe es usando HWSURFACE (como estaba originalmente) para que veas con cual te parece que va mejor, incluye el código fuente por supuesto, he cambiado el gfx.bmp del subdirectorio data por el del port de A600 para GP32 y cambiado el valor de la constante SCREENH por 240 en lugar de 200 y te incluyo un Makefile extra para compilar el juego desde Linux.
Seguro que con algunos cambios más que le hagas se puede optimizar el juego para que vaya aun más fluido, lo que si que habría que centrarse es en mejorar los controles para que responda lo antes posible y funcione con las diagonales (como el juego original).
Wild[Kyo]
20/03/2006, 02:34
Wild[Kyo] ¿puedes decirme que versión de las SDL usaste en la primera versión que has compilado que se ve a pantalla completa?
Es cierto que con las SDL aceleradas (al menos la ultima versión) la pantalla ni se redimensiona a toda la pantalla ni se centra ajustada al tamaño real que usa el juego (320x200), ese marco rosa como dices es la misma parte superior de la pantalla que se copia de vez en cuando la parte superior en la parte de abajo (¿a que me recuerda esto?). He comprobado que solo pasa con HWSURFACE pero no con SWSURFACE (y para usar SWSURFACE en SDL_SetVideoMode() he tenido que colocar algunas macros condicionales para usar SDL_UptateRect() en lugar de SDL_Flip()), aunque el hueco en la parte inferior se queda, solo que de color negro. Voy a seguir mirando a que se debe y como se puede solucionar esto con las SDL aceleradas (paeryn incluyó algunas funciones extras) pero cuando puedas dime que SDL usaste con los binarios que has adjuntado al principio.
En la primera versión use las de oddbot. Para la segunda versión, la que hay colgada ahora, las de oddbot + las SDL aceleradas (que solo se substituyen algunas librerias).
Respecto al audio, prueba cambiando la función Mix_OpenAudio() en main.c y menu.c por:
Mix_OpenAudio(22050, AUDIO_S16LSB, 2, 512)
He forzado la frecuencia a 22050 Hz (la variable i tomaria este valor si pones en el menu Medium Quality para el sonido), cambiado el formato de salida del sample por AUDIO_S16LSB y el el buffer lo he puesto a 512 para evitar la desincronización del audio, aunque puedes ponerlo a 256 o 128 si quieres intentar sincronizarlo aun más (aunque puede que notes algún corte del sonido si lo reduces mucho).
Ahora mismo le echo un vistazo a esto que cuentas...
@A600: Ahora mismo me miro el port de GP32, la verdad es que se me había pasado por completo que tenía el código fuente de tu port y lo porte directamente desde el original... Ya me vale!
< - >
Bueno Wild[Kyo] después de modificar solo unas pocas lineas del código fuente aquí te dejo un ZIP con dos dos versiones del ejecutable, dd2x_sw.gpe es usando SWSURFACE y dd2x_hw.gpe es usando HWSURFACE (como estaba originalmente) para que veas con cual te parece que va mejor, incluye el código fuente por supuesto, he cambiado el gfx.bmp del subdirectorio data por el del port de A600 para GP32 y cambiado el valor de la constante SCREENH por 240 en lugar de 200 y te incluyo un Makefile extra para compilar el juego desde Linux.
Seguro que con algunos cambios más que le hagas se puede optimizar el juego para que vaya aun más fluido, lo que si que habría que centrarse es en mejorar los controles para que responda lo antes posible y funcione con las diagonales (como el juego original).
[Ahhh]
Que rapidez!!!!
Los controles ya los tengo dominados, creo, por eso no hay problema. Le he echado un vistazo rápido a los dos ejecutables. Hay que decir que antes ni siquiera se me escuchaba la música!! Y ahora en tu versión si que se escucha!
Miro el código fuente a ver que más veo!
Muchiiiisimas gracias Uncanny, lo que yo digo, todo un guru! :D
Así que primero usaste las de theoddbot, que traian una versión de las librerías SDL originales (si caso de Open2x), espero que paeryn solucione problemillas como estos al usar resoluciones como esta (como que que se redimensione completamente o se centre en pantalla).
Lo de que la música no se te escuche, será cosa de MikMod (ya que usa modulos XM) y las SDL_Mixer que usas, Guyfawkes a colgado aquí (http://207.44.176.77/~admin28/sdl-libs-03032006.rar) las libs que ha compilado (incluida la de MikMod, con lo que el sonido se escucha a velocidad normal en firms 1.4.0 y anteriores).
Si tienes alguna duda o necesitas alguna cosa más solo tienes que decirla por aquí :)
EDITO:
Ten en cuenta que he usado las fuentes de ayer, no la beta 2 que pusiste esta tarde, que por cierto, ahora les hecho un vistazo porque dices que has mejorado los controles para las diagonales y supongo que lo de la mejora de velocidad es por las SDL de aceleradas no por cambios en el código.
Wild[Kyo]
20/03/2006, 06:09
Así que primero usaste las de theoddbot, que traian una versión de las librerías SDL originales (si caso de Open2x), espero que paeryn solucione problemillas como estos al usar resoluciones como esta (como que que se redimensione completamente o se centre en pantalla).
Lo de que la música no se te escuche, será cosa de MikMod (ya que usa modulos XM) y las SDL_Mixer que usas, Guyfawkes a colgado aquí (http://207.44.176.77/~admin28/sdl-libs-03032006.rar) las libs que ha compilado (incluida la de MikMod, con lo que el sonido se escucha a velocidad normal en firms 1.4.0 y anteriores).
Si tienes alguna duda o necesitas alguna cosa más solo tienes que decirla por aquí :)
EDITO:
Ten en cuenta que he usado las fuentes de ayer, no la beta 2 que pusiste esta tarde, que por cierto, ahora les hecho un vistazo porque dices que has mejorado los controles para las diagonales y supongo que lo de la mejora de velocidad es por las SDL de aceleradas no por cambios en el código.
Bueno ya me lo he estado mirando mejor.
Lo primero: Muchas gracias por tu ayuda. :D
Si, en el código poca cosa toque de más, solo que implemente las diagonales y algun detalle...
He visto un problemilla con el arreglo que has realizado con la resolución y es que el scroll a veces pega un tiron. Supongo que es por modificar la imágen... lo ideal seria que las SDL aceleradas no reescalaran la imagen o en su efecto que lo hiciera bien... Habrá que esperar alguna versión nueva de las SDL que lo arreglen.
Por cierto, una pregunta. Me he instalado las libs de Guyfawkes que has posteado. ¿Estas libs contienen ya las SDL aceleradas? Creo que la respuesta es si pero es para asegurarme.
Ahora en un rato cuando se carguen las pilas pruebo la versión que he hecho y la pongo por aqui.
Un saludo y gracias de nuevo! :brindis:
Sobre el edit:
Si, lo he tenido en cuenta, ya he hecho un Mix de tu versión y la mia... un poco popurri pero ya funciona...
Si, las libs de Guyfawkes traen las SDL aceleradas de paeyn, de hecho trae la última versión publicada, entre otras librerías.
Respecto al scroll, pues si, jugando un rato me he dado cuenta de que ocurre en ciertos momentos y que no siempre es cuando hay muchos enemigos en pantalla, aunque el apaño se basa (el que ya tienes en el que te he puesto para descargar) en usar el sprite que hace las veces de scroll espacial de fondo procedente de la versión de GP32 de A600 como el mismo sugería y cambiarle la resolución que usa el juego para que ya fuera a pantalla completa, así que teoricamente ya no hay reescalado alguno, al menos del scroll (de los sprites es otro tema, pero se puede solucionar en el propio código). Si se me ocurre algo para mejorar esto, así como para que el scroll vaya sin tirones y fluido, lo pongo en práctica y si funciona te lo digo :)
Wild[Kyo]
20/03/2006, 08:15
Si, las libs de Guyfawkes traen las SDL aceleradas de paeyn, de hecho trae la última versión publicada, entre otras librerías.
Respecto al scroll, pues si, jugando un rato me he dado cuenta de que ocurre en ciertos momentos y que no siempre es cuando hay muchos enemigos en pantalla, aunque el apaño se basa (el que ya tienes en el que te he puesto para descargar) en usar el sprite que hace las veces de scroll espacial de fondo procedente de la versión de GP32 de A600 como el mismo sugería y cambiarle la resolución que usa el juego para que ya fuera a pantalla completa, así que teoricamente ya no hay reescalado alguno, al menos del scroll (de los sprites es otro tema, pero se puede solucionar en el propio código). Si se me ocurre algo para mejorar esto, así como para que el scroll vaya sin tirones y fluido, lo pongo en práctica y si funciona te lo digo :)
Ostia Uncanny lo que acabo de descubrir!!! (xD igual todo el mundo lo sabía y yo aqui descubriendo mis Americas).
Me he bajado los sources de las SDL aceleradas por Hardware para compilarmelas y me ha dado por leerme el README.GP2X.
Parece ser que Paeryn es todo un genio y hay una función que redimensiona la pantalla dinámicamente. Algo asi como hacer un ZoomIn ZoomOut en el punto que tu quieras.
void SDL_GP2X_Display(SDL_Rect *area);
Sets the hardware scaler to show requested area of primary surface as
fullscreen. The scaler does not physically alter the surface, it just
affects how the surface will appear on-screen. This allows you to pan
around a surface larger than the screen, and/or zoom in/out.
You cannot zoom out further than having the full surface on-screen.
area->x and area->y set which pixel of the primary surface will appear at
the top-left corner of the display,
area->w and area->h set the width and height of the area to fill the display.
El caso es que lo he probado asi por encima y funciona!!! Osease que dejando las imágenes originales del juego y aunque reescala el juego a 320x240 después le dices que te lo reescale a 320x200 y te lo deja perfecto sin el marco rosa!!
Evidentemente no es la solución más eficiente ya que parece que no va el juego al 100% pero es una solución sencilla... :D
< - >
Lo que no entiendo es que al principio cuando juegas va mal de velocidad pero al cabo de unos 15 segundos va perfecto... :S
Si, conocía esa función de cuando publico paeryn su primera versión de las SDL con reescalado por hardware, pero ya ni me acordaba de ella :p, aunque no la he probado aun ¿donde la aplicas? ¿en las areas rectangulares a y b para el scroll parallax?
Wild[Kyo]
20/03/2006, 08:31
Si, conocía esa función de cuando publico paeryn su primera versión de las SDL con reescalado por hardware, pero ya ni me acordaba de ella :p, aunque no la he probado aun ¿donde la aplicas? ¿en las areas rectangulares a y b para el scroll parallax?
La aplico justo aqui:
screen=SDL_SetVideoMode(SCREENW, SCREENH, bpp, SDL_HWSURFACE|SDL_HWPALETTE|SDL_DOUBLEBUF);
if(!screen) {
fprintf(stderr, "Unable to set video mode: %s\n", SDL_GetError());
return 1;
}
SDL_Rect area;
area.x = 0;
area.y = 0;
area.w = 320;
area.h = 200;
SDL_GP2X_Display(&area);
Justo después de hacer el SetVideoMode. Nunca me acostaré sin una cosa nueva que aprender [wei6]. Yo creo que el port ya esta algo decente para sacarlo a la luz, no? :D Muchas gracias por todo Uncanny :)
Entiendo, creas una nueva area rectangular para esto, una cosa, ya no ves el marco rosa ese, pero a 320x200, ¿lo ves centrado con esos valores de la estructura area? con area.x = 0 y area.y = 0 a 320x200 la imagen debería salir en pantalla perfectamente pero con un hueco abajo ¿no? ¿has probado si se centra con area.y=20?
No tienes que agradecermelo, a mi me gusta la programación y aprender todo lo que pueda y se aprende mucho viendo el código de otros e intentando ayudar en lo que puedas a mejorarlo :) Si ves que la versión que tienes ya es jugable para ti pues ya sabes, hazla pública y ponla en las noticias :brindis:
P.D: Una cosa que le falta a paeryn es documentar con algún ejemplo sencillo cada función exclusiva de sus SDL aceleradas por hardware :D
Wild[Kyo]
20/03/2006, 09:08
Entiendo, creas una nueva area rectangular para esto, una cosa, ya no ves el marco rosa ese, pero a 320x200, ¿lo ves centrado con esos valores de la estructura area? con area.x = 0 y area.y = 0 a 320x200 la imagen debería salir en pantalla perfectamente pero con un hueco abajo ¿no? ¿has probado si se centra con area.y=20?
No tienes que agradecermelo, a mi me gusta la programación y aprender todo lo que pueda y se aprende mucho viendo el código de otros e intentando ayudar en lo que puedas a mejorarlo :) Si ves que la versión que tienes ya es jugable para ti pues ya sabes, hazla pública y ponla en las noticias :brindis:
P.D: Una cosa que le falta a paeryn es documentar con algún ejemplo sencillo cada función exclusiva de sus SDL aceleradas por hardware :D
Si, esta centrado. En realidad el marco rosa supongo que seguirá ahi pero ya no se ve porque en pantalla solo se muestra el rectángulo que ocupa 320x200 (vamos lo que ya se veia bien).
Lo que hace la función es que al pasarle tu un rectangulo la función le hace un zoom (en este caso in pero supongo que también se podría hacer un zoom out con esto) y lo acopla a la pantalla, digamos que es parecido al reescalado que hace automáticamente.
No sé si me explico... la verdad es que es una idea un poco liante [wei6]
PD: Yo no tenía ni idea que tenia funciones especiales pero por lo que he visto solo tiene tres y esta es la única que he entendido. :D
< - >
Que difícil es poner una auto-noticia. XDDDDDDDDD Me siento extraño y no sé que decir. :quepalmo::quepalmo::quepalmo:
Por cierto, con todo lo que sabes de programación... a ver cuando vemos alguna cosita tuya! :)
Ya es algo tarde, así que mañana probaré la beta 3, tengo que probar esa función que me ha picado la curiosidad cuando me has dicho que sale centrada teniendo las posiciones 0,0 de hecho lo suyo es preguntarle al propio paeryn por el uso de sus funciones :)
Lo bueno de escribir una autonoticia es que puedes decir lo que quieras que para eso es tuya xDDD
Respecto a un proyecto mio, el openMSX hace semanas que lo tengo algo abandonado, tendré que meterle caña de nuevo (porque será tan grande y porque estár completamente escrito en C++, con lo que "aprecio" a la POO :p), lo malo de los ports es que si son programas muy grandes da más trabajo a veces que ponerse a escribirlos de cero, porque tardas más en saber para que sirve cada cosa del código (y cuando se trata de POO en C++ con muchas clases mejor ni hablamos xD). Realmente me gustaría crear un juego de cero y directamente para GP2X, lo que pasa es lo de siempre, se juntan mi omnipresente flojera con la falta de ideas, y aunque alguna tengo de que tipo y temática de juego hacer luego estaría el tema de los gráficos que no es lo mio xDD
Buen port, sí señor. Muchas gracias a los dos.
Por cierto, por defecto está activada la opción de teclado y si arranco sin cambiar la configuración puedo ver la nave, pero no moverla. He de cambiar "keyboard" por "joystick 1". ¿Qué tal poner por defecto el stick?
Wild[Kyo]
20/03/2006, 19:19
Buen port, sí señor. Muchas gracias a los dos.
Por cierto, por defecto está activada la opción de teclado y si arranco sin cambiar la configuración puedo ver la nave, pero no moverla. He de cambiar "keyboard" por "joystick 1". ¿Qué tal poner por defecto el stick?
Tienes razón, me acabo de fijar que pasa eso pero yo creia que en el código lo había puesto bien... :confused:
Ahora le echo un vistazo a ver que encuentro...
Gracias por el aviso miq01! :)
< - >
Bueno, ya he subido una nueva versión en la que no debería pasar ese problema...
http://www.gp32spain.com/foros/downloads.php?do=file&id=537
Si te sigue pasando avisame porfavor :brindis:
Gracias! :)
Buenas Wild[Kyo] te adjunto una versión con unos pocos cambios, más que nada para el sonido y la resolución, para que pruebes si notas alguna mejoría respecto a la beta 4. Esta versión está a 320x240 pero va bien, digamos que con el reescalado a 320x200 veía la imagen estirada (se reescala pero para llenar toda la pantalla, no para ajustarse centrada), tanto el panel, el scroll e incluso las naves. Pruebalo en tu aparte, sin machacar tu versión, porque la carpeta data incluye el gfx.bmp con el fondo de scroll de 320x240 del port de A600 para GP32.
Creo que ya no petardea el sonido, más o menos se escucha sincronizado y no da tantos tirones, pero mejor pruebalo tu y me dices :)
Wild[Kyo]
21/03/2006, 09:25
Buenas Wild[Kyo] te adjunto una versión con unos pocos cambios, más que nada para el sonido y la resolución, para que pruebes si notas alguna mejoría respecto a la beta 4. Esta versión está a 320x240 pero va bien, digamos que con el reescalado a 320x200 veía la imagen estirada (se reescala pero para llenar toda la pantalla, no para ajustarse centrada), tanto el panel, el scroll e incluso las naves. Pruebalo en tu aparte, sin machacar tu versión, porque la carpeta data incluye el gfx.bmp con el fondo de scroll de 320x240 del port de A600 para GP32.
Creo que ya no petardea el sonido, más o menos se escucha sincronizado y no da tantos tirones, pero mejor pruebalo tu y me dices :)
Hola, muchas gracias de nuevo!
Le he echado un ojo al juego (no al código aún que a estas horas no sabria distinguir las lineas. XD).
Se ve mucho mejor que la beta 4 (maldito reescalado :D) y ya no hace aquel efecto que hacia antes del salto de sprites. El sonido se escucha genial sin petardeos.
Por contra, respecto a la beta 4, la velocidad es más baja y va más a tirones, y el sonido esta más desincronizado... o esa es mi impresion pasando de jugar del uno al otro...
Mañana le echo un vistazo al código con más detenimiento por ahora a simple vista he visto que usas esto en tu código:
SDL_Rect area;
area.x = 0;
area.y = 0;
area.w = 320;
area.h = 240;
SDL_GP2X_Display(&area);
Esto es lo que usaba yo para el truco de pasar del marco rosa.
Creo que se podría eliminar sin problemas y seguramente esto pueda estar causando que la velocidad baje ya que esta reescalando algo que ya esta reescalado (valga la redundancia XD).
Al Mix_OpenAudio le pasas 15435, es por algo en especial? Me ha llamado mucho la atención... Yo llamo a la función con estos parámetros, que son los que más sincronización me dan: Mix_OpenAudio(16000, AUDIO_S16LSB, 2, 256)
No entiendo muy bien porque pones SDL_Delay(10); despues de un SDL_Flip(screen), esto no perjudicaria a la velocidad del juego?
Y finalmente veo que has cambiado los FPS a 50, esto si que deberia mejorar la velocidad...
Un saludo y gracias! Mañana le echare mejor el ojo! :D
PD: Veo tambien que has usado el truco de Franxis para ganar más memoria a la hora de compilarlo...[wei6]
En realidad es que tengo bastantes funciones en ensamblador para ARM bajadas del CVS de NetBSD (no son exactamente las mismas que las de MAME) y viendo que Franxis obtiene un resultado espectacular en el MAME 1.9 probé a ver (ya se obtuvo en su dia con algunas aplicaciones de la GP32 con la función memcpy() en ASM para ARM) aunque no se si en este caso ha mejorado algo.
El SDL_Delay con 10 milisegundos se usa a veces como otra forma de controlar la tasa de frames por segundo (como bien dices, incorrectamente usado o con valores muy altos puede bajar el rendimiento pues detiene el juego) para buscar velocidad pero jugable, vamos, ha sido otra de las cosas de mis pruebas (cosas que debería haber borrado) por eso has visto también lo de FPS a 50 :p
Lo de SDL_GP2X_Display no lo he borrado para no trastocar mucho más el código, pero como dices quizás ya no sea necesario e incluso pueda ir mejor, todo es cuestión de probar, pero si he vuelto a cambiar la constante SCREENH a 240 y sustituir algún valor en main.c que pusiste directamente a 200 por esta constante.
Lo del Mix_OpenAudio(15435, AUDIO_S16LSB, 2, 256) con el 15435 para la frecuencia ha sido porque me puse a probar con multiplos de 5 para intentar conseguir que sonara con buena calidad y a su vez no se entrecortara con un buffer bajo. Si deshabilitas el sonido verás que el juego vuela, si lo pones a 11025 también va bastante bien, pero la calidad sonora deja que desear, y si aumentas el buffer puede que no se entrecorte el sonido, pero si que se desincroniza.
P.D: Se me ocurre que conviertiendo los XM a OGG de bajo bitrate incluso se podría obtener mejores resultados (para eso SDL_Mixer usa la lib Tremor), pero esto ya mejor lo pruebo mañana.
']No entiendo muy bien porque pones SDL_Delay(10); despues de un SDL_Flip(screen), esto no perjudicaria a la velocidad del juego?
Al contrario de lo que pueda parecer, no SIEMPRE ralentiza el delay del SDL. Prueba un programa sencillo en SDL, sólo con un bucle que llame al método que controla los eventos, que contenga solo el PollEvents y verás lo que digo. Si no pones un SDL_Delay en el bucle del PollEvents, notarás ralentización (en mi caso, por un consumo del 100% de la CPU), al contrario de lo que podría parecer lógico :P.
SilentSei
21/03/2006, 17:53
Este post es interesantisimo. Da gusto ver como gente que sabe de programación discurre sobre su trabajo. Además de que se puede aprender un montón (si entiendes de lo que habláis) y ver la evolución del programa es también muy interesante.
Gran trabajo, seguir así!!! :brindis:
Wild[Kyo]
21/03/2006, 18:47
En realidad es que tengo bastantes funciones en ensamblador para ARM bajadas del CVS de NetBSD (no son exactamente las mismas que las de MAME) y viendo que Franxis obtiene un resultado espectacular en el MAME 1.9 probé a ver (ya se obtuvo en su dia con algunas aplicaciones de la GP32 con la función memcpy() en ASM para ARM) aunque no se si en este caso ha mejorado algo.
El SDL_Delay con 10 milisegundos se usa a veces como otra forma de controlar la tasa de frames por segundo (como bien dices, incorrectamente usado o con valores muy altos puede bajar el rendimiento pues detiene el juego) para buscar velocidad pero jugable, vamos, ha sido otra de las cosas de mis pruebas (cosas que debería haber borrado) por eso has visto también lo de FPS a 50 :p
Lo de SDL_GP2X_Display no lo he borrado para no trastocar mucho más el código, pero como dices quizás ya no sea necesario e incluso pueda ir mejor, todo es cuestión de probar, pero si he vuelto a cambiar la constante SCREENH a 240 y sustituir algún valor en main.c que pusiste directamente a 200 por esta constante.
Lo del Mix_OpenAudio(15435, AUDIO_S16LSB, 2, 256) con el 15435 para la frecuencia ha sido porque me puse a probar con multiplos de 5 para intentar conseguir que sonara con buena calidad y a su vez no se entrecortara con un buffer bajo. Si deshabilitas el sonido verás que el juego vuela, si lo pones a 11025 también va bastante bien, pero la calidad sonora deja que desear, y si aumentas el buffer puede que no se entrecorte el sonido, pero si que se desincroniza.
P.D: Se me ocurre que conviertiendo los XM a OGG de bajo bitrate incluso se podría obtener mejores resultados (para eso SDL_Mixer usa la lib Tremor), pero esto ya mejor lo pruebo mañana.
Gracias, como siempre por tu respuesta. :D Voy a aprender más de programación en este foro que en la uni.:rolleyes:
Me tengo que ir a la uni he tocado poco el código pero te comento.
Quitando el SDL_GP2X_Display y el SDL_Delay (he puesto tambien los FPS a 60) la velocidad mejora bastante, ya no va a tirones pero el sonido (que se escucha muy bien) sigue desincronizado.
La verdad es que ahora parece que de velocidad va bien pero la beta 4 o va perfecta o va pasada de vueltas porque me parece que va muy rápida (supongo que es en parte por la calidad del sonido, no se entrecorta pero petardea un poco).
No he tocado lo del audio porque es lo que más miedo me da de todo y para ir haciendo pruebas con eso necesito más tiempo. Luego probaré a ponerle a tu mod la calidad del sonido que tengo en mi beta 4 para ver si es solo esa la causa de la diferencia de velocidad.
Gracias de nuevo por todo Uncanny! :D
< - >
Al contrario de lo que pueda parecer, no SIEMPRE ralentiza el delay del SDL. Prueba un programa sencillo en SDL, sólo con un bucle que llame al método que controla los eventos, que contenga solo el PollEvents y verás lo que digo. Si no pones un SDL_Delay en el bucle del PollEvents, notarás ralentización (en mi caso, por un consumo del 100% de la CPU), al contrario de lo que podría parecer lógico :P.
Ya, ya :D. No digo que siempre lo ralentice pero podría ser que lo hiciera ya que lo hace justo después de volcar el contenido del buffer secundario al principal...
Por lo que he visto antes al quitarlo la velocidad a mejorado un poco y los tirones casi habían desaparecido.
Como te dije probé con OGG y va mucho mejor, te adjunto los dos OGG para que los guardes en el subdirectorio data junto con el resto de archivos y te digo lo único que debes cambiar en las fuentes de tu beta 4 para probarlo:
main.c:
- La constante FPS a 60 o 70
- Cambia los XM por por los OGG: sprintf(buffer,"%s/bgm1.xm",DD2_DATA); // por bgm1.ogg e idem con la misma función sprintf posterior sustituyendo bgm2.xm por bgm2.ogg
- La apertura del mixer: Mix_OpenAudio(22050, AUDIO_S16LSB, 2, 256)
Recuerda que yo he probado con la constante SCREENH a 240 en engine.h y que uso el gfx.bmp de la versión de A600 para GP32 para usar el sprite correspondiente al scroll que está adaptado a 320x240, la función SDL_GP2X_Display para reescalar que pusiste, no parece afectar al rendimiento (yo al menos no lo he notado) pero si usas el valor 240 para SCREENH y el gfx.bmp carece de utilidad porque no hace falta reescalar.
Wild[Kyo]
23/03/2006, 07:15
Como te dije probé con OGG y va mucho mejor, te adjunto los dos OGG para que los guardes en el subdirectorio data junto con el resto de archivos y te digo lo único que debes cambiar en las fuentes de tu beta 4 para probarlo:
main.c:
- La constante FPS a 60 o 70
- Cambia los XM por por los OGG: sprintf(buffer,"%s/bgm1.xm",DD2_DATA); // por bgm1.ogg e idem con la misma función sprintf posterior sustituyendo bgm2.xm por bgm2.ogg
- La apertura del mixer: Mix_OpenAudio(22050, AUDIO_S16LSB, 2, 256)
Recuerda que yo he probado con la constante SCREENH a 240 en engine.h y que uso el gfx.bmp de la versión de A600 para GP32 para usar el sprite correspondiente al scroll que está adaptado a 320x240, la función SDL_GP2X_Display para reescalar que pusiste, no parece afectar al rendimiento (yo al menos no lo he notado) pero si usas el valor 240 para SCREENH y el gfx.bmp carece de utilidad porque no hace falta reescalar.
Ahora si que si. Va perfecto. En mi versión la mejora no se aprecia, va exactamente igual. Pero tu versión va perfecta con los ogg y los sonidos se escuchan perfectamente.
Chapó Uncanny. No sé como agradecerte toda la ayuda que me has ofrecido compañero...
Después colgaré la nueva versión y si no te importa colgaré la tuya ya que esta bastante mejor por lo que he probado en la gp2x.
Miles de gracias!!!
El merito es tuyo, yo simplemente te he echado una mano, además me gusta este juego (simple pero adictivo xD), así que si quieres colocar las dos versiones por mi estupendo :D
P.D: Te iba a decir que le dieras un toque al autor original de Dodgin' Diamond II porque le gusta saber y nombrar a quien hace un port de su juego, pero ya veo que ya apareces en su web (http://www.usebox.net/jjm/dd2/) :brindis:
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions Inc. All rights reserved.