Ver la versión completa : Lentitud de ejecucion con SDL
Buenas tardes, estoy liado con las SDL intentado tirar adelante ese proyecto metal slug y bueno me surge un problema, a la hora de ejecutarlo va lentisimo y no a que puede deberse.
He visto en post anteriores que era por tener las imagenes a 16bits, pero segun el photoshop me las marca como de 8bits, con lo cual voy a suponer que no es ese el problema. ¿Alguna sugerencia?
¿Tienes la pantalla a 8bit o a 16bit?
¿Conviertes al formato de pantalla tras cargar una imagen usando RLE?
Prueba a usar el SDL stand-alone que viene en el último Fenix Runtime (0.84b).
Has configurado en el gpstart.c la velocidad de la cpu de la gp32, lo mismo la tienes a 40Mhz :D
Aparte de eso, solo se me ocurre lo de los 16bits.
Yo estoy usando pantalla16bits+imagenes8bits y va bastante bien a 60Mhz (tampoco seas burro y pongas mas jeje, bueno si te hace falta si ;))
Aiken
Pues la pantalla la tengo a 8 bits, 320,240,8 supongo q asi se pone en 8 ¿no? y la forma de cargar los graficos pues aqui os paso el codigo,
SDL_Surface *tmp2;
tmp2=IMG_Load_RW(SDL_RWFromMem(&personaje,21136),0);
personaje1=SDL_DisplayFormat(tmp2);
SDL_SetColorKey(personaje1,SDL_SRCCOLORKEY | SDL_RLEACCEL, SDL_MapRGB(personaje1->format,192,192,192));
SDL_FreeSurface(tmp2);
Y como digo segun el photoshop los graficos son de 8 bits, de hecho la web de donde los pille, eran todos de 8 bits, asi q no se :(
P.D edito para comentar la funcion q uso para setear la velocidad GpClockSpeedChange(132000000, 0x3c011, 3);
Y como digo segun el photoshop los graficos son de 8 bits, de hecho la web de donde los pille, eran todos de 8 bits, asi q no se :(
Has configurado en el gpstart.c la velocidad de la cpu de la gp32, lo mismo la tienes a 40Mhz :musico:
Aiken
¿Que funcion usas tu para setear la velocidad Aiken?
Da igual los bits de las imagenes segun las cargas... solo que te pueden ocupar mas.
Es muy probable que este a 40Mhz.
¿Has abierto el modo grafico con HW_SURFACE y DOUBLE_BUF?
Esto es lo q tengo
pantalla = SDL_SetVideoMode(320,240,8, SDL_HWSURFACE | SDL_DOUBLEBUF);
y para la velocidad
GpClockSpeedChange(132000000, 0x3c011, 3);
¿Que funcion usas tu para setear la velocidad Aiken?
Si estas usando la version de toda la vida de SDL (GPSDK wrapper):
GpClockSpeedChange (59250000, 0x47022, 1);
GpClockSpeedChange(132000000, 0x3a011, 3);
GpClockSpeedChange(67500000, 0x25002, 1);
GpClockSpeedChange (80000000, 0x48012, 2);
GpClockSpeedChange (99000000, 0x3a002, 2);
GpClockSpeedChange(132000000, 0x24001, 2);
¡ Pilla la velocidad que mas te guste !
Estupendo chui :) aunque sigue sin funcionar XDD aun se nota mucho como redibuja el fondo, seguire trasteando con el codigo a ver, saludos,
Por cierto aqui os dejo todo el codigo (no es secreto de estado XDD)
#include <gpstdio.h>
#include <gpstdlib.h>
#include <gpgraphic.h>
#include <gpfont.h>
#include "data.h" //los graficos
#include <sdl/SDL.h>
//una estructura para el personaje
struct miprota{
int x,
y,
activo,
nframe,
izquierda,
derecha,
arriba,
abajo,
direccion;
}jugador;
void GpMain(void *argv){
SDL_Surface *pantalla; //buffer de SDL para la pantalla
SDL_Surface *personaje1, *fondo; /* Las 2 imágenes, usea el fondo y el personaje */
GpClockSpeedChange(132000000, 0x24001, 2); //velocidad de la gp
SDL_Rect rect_fondo,otrorect,rect_personaje;
//DECLARO UNOS RECT PARA EL PERSONAJE Y LAS ANIMACIONES, APARTE DEL FONDO CLARO :)
int terminar = 0;
int graficox=50;
int graficoy=175;
int x2=0;
int y2=0;
Uint8 *teclas;
jugador.abajo=0;
jugador.arriba=0;
jugador.derecha=0;
jugador.izquierda=0;
jugador.nframe=0;
jugador.x=graficox;
jugador.y=graficoy;
///////////////////////////////
//////////////////////////////
// EL SCROLL DEL NIVEL
/////////////////////////////
////////////////////////////
void scroll(){
x2=x2-(2); //si a llegado movemos el fondo 2 pixels
}
/////////////////7
/////////////////
// MOVIMIENTOS DEL PERSONAJE
////////////////
///////////////
void MovimientoDerecha(){
rect_personaje.y=jugador.derecha;
rect_personaje.w=31;
rect_personaje.h=31;
rect_personaje.x=jugador.nframe*31;
//
// SCROLL DEL NIVEL
// Como veis no es nada del otro jueves y tampoco se si os mola la idea
// pienso que asi tienes toda la pantalla para moverte y si salen muchos enemigos
//puedes retroceder para cubrirte o para esquivar mejor los disparos
//
if(graficox>=100){ //comprobamos que el personaje llega a x=100
scroll();
graficox=graficox+(0); // y avanzamos el personaje 1 pixel
jugador.nframe++;
if(jugador.nframe>2){
jugador.nframe=0;
}
}else // si no pues movemos al personaje 2 pixels
{
graficox=graficox+(2);
jugador.nframe++;
if(jugador.nframe>2){
jugador.nframe=0;
}
}
}
void MovimientoIzquierda(){
rect_personaje.y=jugador.izquierda;
rect_personaje.w=31;
rect_personaje.h=31;
rect_personaje.x=jugador.nframe*31;
graficox=graficox-(2);
jugador.nframe++;
if(jugador.nframe>2){
jugador.nframe=0;
}
}
void MovimientoArriba(){
rect_personaje.y=jugador.arriba;
rect_personaje.w=31;
rect_personaje.h=31;
rect_personaje.x=jugador.nframe*31;
graficoy=graficoy-(2);
jugador.nframe++;
if(jugador.nframe>2){
jugador.nframe=0;
}
}
void MovimientoAbajo(){
rect_personaje.y=jugador.abajo;
rect_personaje.w=31;
rect_personaje.h=31;
rect_personaje.x=jugador.nframe*31;
graficoy=graficoy+(2);
jugador.nframe++;
if(jugador.nframe>2){
jugador.nframe=0;
}
}
///////////////////////////////
//////////////////////////////
// EL SCROLL DEL NIVEL
/////////////////////////////
////////////////////////////
// No se pq sera pero aun veo esta parte vacia XDDDD
// toi currando en ello o intentandolo :)
//////////////////
///////////////
// INICIAMOS EL VIDEO Y TAL
//////////////
/////////////
if(SDL_Init(SDL_INIT_VIDEO) == -1){
// printf("No se pudo iniciar el video: %s\n", SDL_GetError());
exit(-1);
}
pantalla = SDL_SetVideoMode(320,240,8, SDL_HWSURFACE | SDL_DOUBLEBUF);
if(!pantalla){
// printf("No se pudo iniciar el modo de pantalla: %s\n", SDL_GetError());
SDL_Quit();
exit(-1);
}
//////////
//////////
// CARGA DE LAS IMAGENES A SU SURFACE
////////////
///////////
// Cargamos gráfico
SDL_Surface *tmp;
tmp=IMG_Load_RW(SDL_RWFromMem(&fondo_juego,124969),0);
fondo=SDL_DisplayFormat(tmp);
SDL_SetColorKey(fondo, SDL_SRCCOLORKEY | SDL_RLEACCEL, SDL_MapRGB(fondo->format,1,1,1));
SDL_FreeSurface(tmp);
SDL_Surface *tmp2;
tmp2=IMG_Load_RW(SDL_RWFromMem(&personaje,21136),0);
personaje1=SDL_DisplayFormat(tmp2);
SDL_SetColorKey(personaje1,SDL_SRCCOLORKEY | SDL_RLEACCEL, SDL_MapRGB(personaje1->format,192,192,192));
SDL_FreeSurface(tmp2);
// Cargamos gráfico
// CON EL SETCOLORKEY LE ASIGNAMOS SU COLOR TRANSPARENTE
/* BUCLE PRINCIPAL DEL PROGRAMA*/
while( ! terminar ){
SDL_PollEvent(NULL);
teclas = SDL_GetKeyState(NULL);
if( teclas[SDLK_ESCAPE] ) terminar = 1;
if(teclas[SDLK_LEFT]) MovimientoIzquierda();
if(teclas[SDLK_RIGHT]) MovimientoDerecha();
if(teclas[SDLK_UP] && (graficoy>170)) MovimientoArriba();
if(teclas[SDLK_DOWN] && (graficoy<210)) MovimientoAbajo();
/*Dibujamos el fondo*/
rect_fondo=(SDL_Rect){x2,y2,0,0};
SDL_BlitSurface(fondo,NULL,pantalla, &rect_fondo);
/* Dibujamos el muñeco */
otrorect.w=rect_personaje.w;
otrorect.h=rect_personaje.h;
otrorect.x=graficox;
otrorect.y=graficoy;
SDL_BlitSurface(personaje1, &rect_personaje, pantalla, &otrorect);
//poner el rect de origen y luego el rect destino donde lo pones en pantalla
//en el rect de origen esta el clip que hagas de la imagen
SDL_Flip(pantalla);
// Volcamos el contenido de los buffers a la pantalla y ale solucionado, ya se ve nuestro juego :)
// espero que todos entendais bien el codigo, por supuesto todo esto es muy mejorable
// yo como no tengo ni zorra de programar juegos pos asi va...... XDD
}
SDL_Quit();
}
Saludos
Quita el SDL_SetColorKey del fondo. No hay transparencia sobre fondo, tienes un sprite enorme.
Ademas, si vas a hacer mucho recorte, SDL_RLEACCEL puede ser antiproducente ... todo eso se ve probandolo.
Ademas, suele ser mas util y optimo pintar un fondo a base de tiles... puedes repetirlos cuanto quiras haciendo mapas enormes y no tienes pq hacer recortes. Es algo mas complicado pero mucho mas eficiente en CPU y memoria.
cierto chui el rleaccel del fondo se me ha escapado :) y lo q dices de los tiles lo tenia en mente pero como el grafista del juego no da señales de vida y solo tengo ese fondo pues..... ya te imaginas el resto.
Esto es lo malo de los voluntarios que todo el mundo se apunta, luego nadie da señales de vida XD, saludos y gracias chui
Si es lo de siempre, la gente al principio se flipa pero luego hay que dedicarle horas y no mola .... es normal.
El SDL_RLEACCEL te decelera pero el SDL_SetColorKey en el fondo ... pera limonera, si estas usando un fondo de digamos 640x240, estas pintando un sprite de 640x240 ... casi ná.
El fondo es nada menos q de 4600x240 XD como veras tela, de todas maneras por si la lentitud fuera por el fondo lo he sustituido por uno mas pequeño 640x240 pero la velocidad sigue siendo lenta. En cuanto consiga algun tile para diseñar algo chulo lo sustituire por tiles a ver que tal la mejora.
Saludos,
¿Pero le has quitado el SDL_SetColorKey al fondo?
Por supuesto chui, el colorkey en el fondo no sirve para nada, simplemente se me colo la funcion en el codigo (eso pasa por cortar y pegar de otros proyectos). Mañana con mas calma repasare todo el codigo y probare a ver un mapa con tiles a ver que sale
anibarro
10/09/2005, 16:30
¿Eskema solucionaste los problemas esos de velocidad con SDL? A mi me pasa justo lo mismo :(
Es un fondo y un sprite, el fondo lo cargo con un SDL_LoadBMP(FICHERO_FONDO) y un SDL_DisplayFormat para usar la imagen optimizada y el sprite lo cargo con la función que esta en el ejemplo "blanquita", que hace un SDL_LoadBMP, luego el SDL_SetColorKey con verde fosforito y al final SDL_DisplayFormat para usar la imagen convertida.
Y luego lo pinto con SDL_BlitSurface para el fondo y el Sprite.
El fondo he probado a cargarlo entero, como una imagen de 320x240 y a anidar 2 for, recortando cada iteracion un cuadrado de 32x16 de la imagen y pegandolo, como si fuese por tiles, y va igual de lento :(
La pantalla al principio la tenia a 16bits, pero al ir tan lento probé a 8 bits, y va mejor, pero no creo pintando un fondo y un sprite tenga q ir lento a 16bits...¿se me olvida algo?
Edit: y la GP a 133 mhz q se me olvidaba ;)
Veras, lo de las tiles no es eso que dices. tiles, es un motor, por ejemplo el del celda, en que que te puedes encontrar algo así:
http://www.armchairempire.com/images/Reviews/gameboy-advance-gba/legend-zelda-link-past/legend-zelda-link-past-3.jpg
Si te fijas verás que muchas partes del entorno están repetidas, por ejemplo el suelo esta hecho con varios cuadraditos de baldosa juntos, lo mismo que los setos y las vallas.
El caso es que como eso se repite tanto, no es necesario cargar una image de eso en pantalla, basta con cargar esos recuadros que se repiten tanto y reutilizarlos. Luego el mapa del juego se hace asignando esos tiles a la posición que corresponda
Ejemplo, supongamos que queremos hacer una habitacion con un cofre, supongamos que tenemos tiles de pared (índice 0), suelo (índice 1) y cofre (índice 0), y por ese orden. El mapa de la habitación sería:
00000000
01111110
01112111
01111110
00000000
Si sabes cómo funcionan los colores indexados, la idea es la misma.
Por otro lado veo en el código que simplemente redibujas el fondo y encima el sprite. No es lo más recomendable. Para mover un sprite, lo que hay que hacer es redibujar la parte de fondo que ocupa (así lo borras) y luego volver a dibujarlo, porque redibujar una imagen muy grande en cada frame es muy costoso
¿Y como se hace eso de redibujar solo la parte del sprite o los sprites en caso de tener varios? desde luego la mejora de velocidad ha de ser muy buena, pero no tengo ni zorra de como hacer eso. ¿Podrias poner algo de codigo para ver como se hace eso? pq todos los juegos q he visto por ahi redibujan la pantalla completa...
Saludos,
Tal vez de aquí puedas sacar alguna ideilla:
http://www.vjuegos.org/modules.php?name=Content&pa=showpage&pid=33
MAs o menos tenia una idea de lo que era hacer un nivel a base de tiles, ahora me lo habeis aclarado mucho mas, seguro que me es de utilidad en el futuro.
Lo mejor si se trabaja con tiles es crearte un editor de niveles,no?
Hay algun estandar en la creacion de niveles, o te creas tu el formato que quieras para guardar elementos y posicones de los mismos?
Saludos
PD.Para hace scroles hay que usar tiles en distintas profuncidades, no?
Como "editor de niveles" a falta de uno creado por uno mismo, puedes usar Mappy
http://www.tilemap.co.uk/mappy.php
Gracias!!Es muy flexible?Jejeje.
Saludos
anibarro
10/09/2005, 22:44
Veras, lo de las tiles no es eso que dices. tiles, es un motor, por ejemplo el del celda, en que que te puedes encontrar algo así:
Zheo lo se, lo se, si tengo unas pruebas con el SDK oficial usando un motor de tiles q venia en un tutorial, solo lo hice asi para ver si era por eso lo de la lentitud, ya que tarda o mismo en coger partes de una imagen entera y colocarlos como si fuesen tiles, que se fuesen tiles reales (imaginate que haces un mapa que coloca los tiles tal y como estan en la imagen donde los guardas).
Lo de ir lento puede que sea por eso que dices, de repintar todo el fondo en vez de la zona que cambia solo, probare eso gracias ;)
PD.Para hace scroles hay que usar tiles en distintas profuncidades, no?
Si te refieres a scroll tipo Parallax puedes usar varios arrays con ciertos tiles transparentes, movidos a varias velocidades cada uno. (no se si me explicado mu bien, sorry)
Sipo, pero la verdad, no veo la necesidad de usar transparencias, no se si jugastes al valkirie profile, pero como unos plano del scroll esta mas alto que el otro, simplemente no se ve.
Vamos, para que hagas una idea, como el paralax de cualquier juego de gameboy :P
Saludos
Zheo lo se, lo se, si tengo unas pruebas con el SDK oficial usando un motor de tiles q venia en un tutorial, solo lo hice asi para ver si era por eso lo de la lentitud, ya que tarda o mismo en coger partes de una imagen entera y colocarlos como si fuesen tiles, que se fuesen tiles reales (imaginate que haces un mapa que coloca los tiles tal y como estan en la imagen donde los guardas).
Lo de ir lento puede que sea por eso que dices, de repintar todo el fondo en vez de la zona que cambia solo, probare eso gracias ;)
Ok ok, de todas maneras Otto se ha leído la explicación y le ha sido útil así que de pm :teacher: <-- que caña de emoti**** xD
Y por otro lado, si, al hacer Blits importa muchísimo más la cantidad total de imágnes que haces que la sobrecarga por la llamada de función (proporcionalmente hablando digo)
Creo recordar que en la mail list habían probado bliteando una imagen entera y luego dividida en 50 o 100 (no recuerdo) y la diferencia en tiempo era despreciable.
Tiles en profundidades: o bien el parallax para simular profundidad, o bien que puede haber varios niveles de tiles (es decir unas se dibujan antes o después y las que se dibujan después sobreescriben a las primeras) que es algo necesario en un motor de tiles. Otra cosa es que tenga soporte hardware para ello (como la GBA)
Yo tb estoy repintando todo el fondo y si q se nota perdida de velocidad, pero vamos tampoco es para tirarse de los pelos. Tu ejemplo anibarro me funciona muy rapido a 133, ¿tal vez no estas contento con la velocidad XD?
Es casi imprescindible usar los 8 bits de color pq a 16 si que se nota mucha mas perdida.
Yo tb estoy repintando todo el fondo y si q se nota perdida de velocidad, pero vamos tampoco es para tirarse de los pelos. Tu ejemplo anibarro me funciona muy rapido a 133, ¿tal vez no estas contento con la velocidad XD?
Es casi imprescindible usar los 8 bits de color pq a 16 si que se nota mucha mas perdida.
Con 16 bits estás moviendo casi un mega de información por frame: 320x200x16=0,97 megas aprox no recuerdo exactamente la res de la GP.
Si tu sprite fuera, por ejemplo, de 60x40 estarías moviendo 60x40x16 x 2 redibujados = 0,07 megas.
Un ahorro del 92% más o menos, ¿estas seguro que no es para tirarse de los pelos? ;)
Tienes toda la razon, si ya digo yo q esto de programar juegos no es nada sencillo y cada dia aprendes algo nuevo, atendiendo a esos datos, calculo q mi juego podria funcionar a 66mhz de forma fluida y no a 100 como va ahora.
Ale ahora a calentarse la cabeza pa ver como se hace todo eso ;)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.