He revisado tutoriales en la red y todos ellos terminan explicando el método de animación con las clases CSprite y CFrame. Esto, me parece muy bien como "metodo final" pero necesito saber los pasos básicos.
Yo me he creado 3 funciones (carga, borra y dibuja) que luego llamo en un bucle para mover un grafico:
Citar
MAIN
int x = player.setX(0);
grafico = player.cargaGrafico("player.bmp");
while(salir == 0){
ResetTimeBase();
x += 5;
player.borrarGrafico(pantalla, negro); //Borro TODA la pantalla.
player.dibujaGrafico(pantalla, grafico, x, 0);// Dibujo sprite en la nueva posición.
SDL_Flip(pantalla);//Muestro lo que hay en el buffer (Si, puse DOBLE_BUFFER)
En la animación se produce un casi imperceptible parpadeo ya que borro la pantalla.
Imagino que todo lo que tengo que hacer es borrar el sprite que está en la posición anterior, pero antes de ello mostrar el sprite en la nueva posición (cosa que todavia no he logrado).
Tampoco entiendo por qué al sustituir:
player.borrarGrafico(pantalla, negro); //Borro TODA la pantalla.
Por:
player.borrarGrafico(
grafico, negro); //Borro SOLO el gráfico.
No me imprime (o no veo) absolutamente nada. Debería obtener el mismo resultado ¿no?
En fin, ¿sabeis de algún tutorial que explique un movimiento básico con código básico?.
S2.
para evitar el parpadeo debes de dibujar en otro sitio que no sea directo sobre la memoria de video, no se si al final estas con gdi+ pues por eso te lo digo tan generico, no obstante en todos los sistemas al sistema de evitar el parpadeo se le llama doble buffer (double buffer o double buffering) que consiste en renderizar la escena en una imagen (backbuffer llamado normalmente) y luego pasarlo a la memoria de video (frontbuffer)
sobre la duda que tienes pintar sobre la pantalla y el grafico son cosas diferentes, la pantalla en esta caso creo que es la memoria de video y el grafico es un dibujo que te gustaria pintar en pantalla, si pintas sobre grafico estas borrando en grafico y no en pantalla
si estas co gdi+ te dire que te resultara mas dificil de aprender que opengl o sdl, en principio te recomiendo sdl que es un api que te permitira dibujar sin preocuparte de ciertas cosas que en principio te pueden liar
saludos
Dos curiosidades, tienes un TFT? comprueba primero que el haz que dices que deja no sea de tu monitor
y.. grafico supongo que es una superficie SDL que contiene el bitmap del sprite no? si la pintas toda de negro, luego estaras pintando negros sobre la pantalla, y si la pantalla es negra, se vera todo negro :P
CitarImagino que todo lo que tengo que hacer es borrar el sprite que está en la posición anterior, pero antes de ello mostrar el sprite en la nueva posición (cosa que todavia no he logrado).
Eso esta mal pensado. PRIMERO se borra siempre el sprite, si no habra un momento en el que se vean dos sprites.
Pero como dice zupervaca, se trabaja con un buffer que no es la pantalla directamente, para asi a la pantalla hacerla un volcado directo, envez de ir añadiendo cosas que van a producir efectos graficos indeseados. Lo que pasa es que zupervaca no debe conocer o recordar que esto ya no es msdos y como funciona SDL. No pintas en la pantalla, lo que tienes es una superficie con las caracteristicas de la pantalla, y cuando utilizas el SDL_Flip es cuando se procede a volcar el contenido de esa superficie en la vga. Por lo que en SDL es posible tener un doble buffer y lo que decia zupervaca seria ya un triple buffer, que por otro lado es aun mejor.
Buscate un tutorial de SDL mas decente.
Cita de: "seryu"Buscate un tutorial de SDL mas decente.
Buscar, busco pero parece que es lo que hay.
Si, estoy con SDL, he dejado aparcado GDI+,... al menos de momento (no me parecía tan chungo como comentas).
Lo del TFT:
Si, en la pantalla del portatil el paradeo es mas evidente que en el monitor (apenas perceptible).
Si explicais un poco mas detalladamente eso de NO dibujar directamente en el buffer de pantalla mejor.
en realidad solo tengo 2 superficies:
1- pantalla (donde le indico la resolucion, buffer,...)
2- grafico
S2.
efectivamente SDL no lo conozco con lo que no puedo ayudarte
Lo de guardar solo la zona donde se dibujaba un sprite para luego recuperarla y volver a dibujar en la nueva posicion se hacia antiguamente porque el borrar todo el fondo costaba un tiempo valiosisimo con las vga antiguas, ahora ya no es necesario meterse en ese embolao. Es mejor borrar toda la pantalla de un color o con otra imagen y dibujar los sprites en sus nuevas posiciones.
Si el proceso de borrado y los dibujos se hicieran directamente sobre el buffer que vemos, se notarian los parpadeos y otros efectos odiosos, para evitar esto lo que se hace es que se crean dos buffers identicos paralelos, mientras uno de ellos es mostrado, en el otro se dibuja. Cuando se llama a SDL_fllip lo que se hace es intercambiar los buffers tan rapido que el ojo ni lo ve, de modo que lo que se habia dibujado en el buffer que permacia oculto ahora es mostrado, y el buffer que veiamos ahora queda oculto y listo para ser borrado y dibujado de nuevo.
Todo esto es trasparente para el programador, porque todas las operaciones de dibujo se efectuan sobre el buffer oculto, que viene determinado por la llamada a SDL_flip.
Lo q te dije en otro post... si tienes muchos sprites en pantalla, lo mejor es borrar todo el fondo(o volcar todo el fondo entero que tengas) y luego volver a pintar sprites.
El efecto de parpadeo es normal si no utilizas el doublebuffer... para activarlo en SDL tienes que hacer la llamada a SDL_VideoInit() con SDL_HWSURFACE, SDL_FULLSCREEN y SDL_DOUBLEBUF. Es decir, solo tendras el double buffer en modo pantalla completa y cuando utilices superficies hardware :).
Mas adelante, cuando pilotes mas...decirte que si utilizas glSDL podras tener double buffer tambien en modo ventana :).
Y de todos modos, creo q mi lib te podria ser util, quizas no para programar con ella puesto que quieres aprender pero si para aclarar ideas :)
si tienes cualquier otra cosa, tiralo por aqui... que de SDL y demas...estoy muy puesto jejeje
ah y luego para volcar a screen...debes usar el SDL_Flip!!! (en modo doublebuf)
Cita de: "Mandelbrot"si tienes cualquier otra cosa, tiralo por aqui... que de SDL y demas...estoy muy puesto jejeje
Una simple animación que carga el fichero "player.bmp" que se mueve de izquierda a derecha.
Es como la tenía originalmente. ¿Es correcta la forma en que animo el sprite?. Es que ya no se si son mis ojos o que. Porque yo diría que hay un parpadeo aunque muy leve.
No se, gracias en cualquier caso.
Aquí el código (ya se que no es el metodo correcto a seguir, esto simplemente son pruebas):
#ifndef TIEMPO_H_
#define TIEMPO_H_
Uint32 ini_miliSeg, fin_miliSeg, frameTime;
void ResetTimeBase(){
ini_miliSeg = SDL_GetTicks();
}
int CurrentTime(){
fin_miliSeg = SDL_GetTicks();
return fin_miliSeg - ini_miliSeg;
}
#endif
#ifndef INICIASDL_H_
#define INICIASDL_H_
SDL_Surface *pantalla;
int IniciaSDL(int ancho, int alto){
if(SDL_Init(SDL_INIT_VIDEO) < 0){
printf("No puedo inicializar las SDL: %s\n", SDL_GetError());
return 1;
}
pantalla = SDL_SetVideoMode(ancho, alto, 24, SDL_HWSURFACE | SDL_DOUBLEBUF | SDL_FULLSCREEN);
if(pantalla == NULL){
printf("El modo video no lo puedo inicializar, Miguel: %s\n", SDL_GetError());
return 1;
}
if(TTF_Init() < 0){
printf("Tio, no se ha podido inicializar las TTF: %s\n", SDL_GetError());
return 1;
}
atexit(SDL_Quit);
atexit(TTF_Quit);
return 0;
}
#endif
#ifndef SPRITE_H_
#define SPRITE_H_
class SPRITE{
private:
int posX, posY, veloc;
public:
int setVeloc(int v){veloc = v;return veloc;};
int setX(int x){posX = x;return posX;};
int setY(int y){posY = y;return posY;};
int teclado(SDL_Event _evento);
SDL_Surface* cargaGrafico(const char *fichero);
void borrarGrafico(SDL_Surface *screen, SDL_Color color);
void dibujaGrafico(SDL_Surface *screen, SDL_Surface *sprite, int x, int y);
};
SDL_Surface* SPRITE::cargaGrafico(const char *fichero){
SDL_Surface *tmp, *bmp;
Uint32 colorKey;
tmp = SDL_LoadBMP(fichero);
colorKey = SDL_MapRGB(tmp->format, 255, 255, 255);
SDL_SetColorKey(tmp, SDL_SRCCOLORKEY|SDL_RLEACCEL, colorKey);
bmp = SDL_DisplayFormat(tmp);//Transforma la superficie bmp en el formato de pantalla tmp.
SDL_FreeSurface(tmp);
return bmp;
}
void SPRITE::borrarGrafico(SDL_Surface *screen, SDL_Color color){
Uint32 col = SDL_MapRGB(screen->format, color.r, color.g, color.b);
SDL_FillRect(screen, 0, col);
}
void SPRITE::dibujaGrafico(SDL_Surface *screen, SDL_Surface *sprite, int x, int y){
SDL_Rect rect;
rect.x = x;
rect.y = y;
SDL_BlitSurface(sprite, 0, screen, &rect);
}
int SPRITE::teclado(SDL_Event _evento){
if(_evento.type == SDL_KEYDOWN){
switch(_evento.key.keysym.sym){
case SDLK_ESCAPE:
return 1;
break;
case SDLK_RIGHT:
//mover(-1);
break;
}
}
return 0;
}
#endif
//MAIN.cpp
//C++ estándar
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
//SDL
#include <SDL.h>
#include <SDL_ttf.h>
//Propias
#include "cabeceras\IniciaSDL.h"
#include "cabeceras\tiempo.h"
#include "cabeceras\sprite.h"
#include "cabeceras\tipografia.h"
#include "setup.txt"
//Objetos
SPRITE player;
SDL_Event evento;
SDL_Surface *grafico;
SDL_Color negro;
int velocPlayer = 5;
int main(int argc, char *argv[]){
IniciaSDL(RESOLUCION_X, RESOLUCION_Y);
int x = player.setX(0);
grafico = player.cargaGrafico("player.bmp");
while(player.teclado(evento) == 0){
ResetTimeBase();
x += player.setVeloc(velocPlayer);
player.borrarGrafico(pantalla, negro);
player.dibujaGrafico(pantalla, grafico, x, 0);
SDL_Flip(pantalla);
while(SDL_PollEvent(&evento)){
player.teclado(evento);
}
do{
frameTime = CurrentTime();
}while(frameTime < 30);
}
return 0;
}
S2.
Se me olvidaba. otra cosa que noto son "titoncillos" en la velocidad. Como si leyese del HDD o algo asi.
S2.
"titon..." :D tironcillos, parones queria decir.
S2.
Uhmm....estoy vago :), zipeame todo el codigo y mandamelo a mi email(esta aki abajo indicado) y te lo pruebo a ver q pasa....
he visto una cosa que no debes hacer je, no utilices el modo 24bits en cualquier resolucion...es LENTISIMO!!! o te pones con 16bit(en makinas antiguas) o a 32bits que es mas rapido q 24bits.
y los tironcillos puede ser pq tu mismo has puesto un limitador de velocidad....
do{
frameTime = CurrentTime();
}while(frameTime < 30);
espero tu code..... si es q con estas dos cosillas no se te soluciona el problemilla...
Efectivamente.
Cambiando de 24 a 16, incluso a 32 bits. La animación ya no pega "tironcillos", tambien va mas rápida.
El limitador de velocidad lo he cambiado a 10 en lugar de a 30. Ya no hay parpadeo alguno.
Buf! que alivio.
Bueno, ya postearé mas problemas.
S2.
De todos modos...ese limitador de tiempo no me gusta mucho... buscate por ahi alguno otro o "fabrica" tu uno mejor y de paso q te de medidas de fps, q puedes limitar por fps o por tiempo y demas cosillas....
pos na, q siga la cosa bien :P
Bueno..., realmente el SDL es bastante lento, se pasa de un movimiento suave al dibujar solo un sprite a uno a saltos al hacer el blit de toda la pantalla, no quiero ni pensar como ira de lento cuando empiecen a rular mogollon de bichos por ahi.
pues nada, mi consejo para todo el mundo es pasar definitivamente ya de GDIs, SDLs, SVGAs y otros apaños que aunque para empezar a probar o como ayuda puntual de alguna funcion en un momento dado estan bien, pero que casi siempre conducen a callejones sin salida si se usa como contexto principal.
Lo mejor es empezar ya a usar OpenGL o DirectX aunque no se tenga mucha idea, eso si... apoyado en librerias y utilidades preparadas para facilitar el uso de estas APIS, solo asi (que yo sepa) se puede aprovechar toda la potencia grafica de los ordenadores actuales.
Podemos usarlo solo para 2D (si queremos evitar el tema del algebra, matrices y demas) y nos beneficiaremos de filtros para difuminar los pixels, mezclas de color para todo tipo de efectos, sombras, rotaciones de sprites, crear zonas donde se permita dibujar o no, z buffer para que queden ocultos los dibujos a partir de su distancia sin tener que dibujar primero los mas alejados, y un monton de cosas mas que nos permitira hacer practicamente todo lo que se nos ocurra sin limite alguno, mas facilmente de lo que parece y todo ello sin preocuparse de perder velocidad, y con la ventaja de poder añadir objetos 3D facilmente en un futuro.
Asi se hizo commandos, es un juego en 2D usando la tecnologia 3D de las tarjetas, por eso tiene esos graficos tan buenos (aparte de los grafistas claro esta).
Yo personalmente recomiendo para empezar, por su facilidad, OpenGL con la libreria GLUT que trae funciones para simplificar la iniciacion y gestion de la ventana, teclado, timer, etc.. y crear unas sencillas clases de sprites y a partir de ahi ya se puede empezar a hacer muchas cosas al tiempo que se aprenden otras nuevas.
Tambien se puede usar SDL+OpenGL aunque no se como va ni que resultados tiene puesto que no lo he probado. Otra opcion es usar DirectX 9 y las librerias de apoyo D3DX que incluye, da lo mismo, de lo que se trata es de programar la tarjeta grafica como dios manda y todo ello pasa por DirectX o OpenGL.
un saludo a todos y espero haber animado a alguien.
CitarBueno..., realmente el SDL es bastante lento, se pasa de un movimiento suave al dibujar solo un sprite a uno a saltos al hacer el blit de toda la pantalla, no quiero ni pensar como ira de lento cuando empiecen a rular mogollon de bichos por ahi.
Seguimos con los mismos mitos de siempre :P. Te recomiendo que busques un thread en este mismo foro llamado glSDL Benchmark... y veas los resultados y veas lo que puede hacer SDL en comparacion con otras APIs y la utilizacion del glSDL.... vamos, creo que te aclarara un poco la mente.
No es mala idea lo de empezar con opengl+glut pero es mucho mas pesado y sin embargo, SDL tiene mil librerias para hacer todo, multiplataforma y mas que probado... y eso de q es lento... sigue siendo un mito, lo siento.
Los blitters de SDL si es cierto que si lo compilas con Visual C no utiliza muchas mejoras MMX y aun compilandolo con mingw32 por ejemplo, algunas cosillas son mejorables. En mi libreria que es una capa por encima de SDL he retocado todo esto y el volcado via software he conseguido optimizarlo muy mucho dependiendo de la plataforma que utilices(pentium3,pentiumM,pentium4,pentiummmx,k6,k7 y k8) Pero vamos....glSDL rulez!
Quizas no me explique bien, pero al final una de mis recomendaciones era usar OpenGL+SDL aunque aclaraba que desconocia los resultados, y una de mis intenciones es estudiar la posibilidad de usarlo, y puede que sea una buena opcion para mi y para mucha gente.
Pero es que me sorprendi bastante al ver como se enlentecia enormemente un sprite que puse en movimiento al limpiar toda la ventana con SDL_BlitSurface cuando pensaba que al menos seria igual de rapido que el Blt de DirectDraw (¿que menos no?),. y la verdad..., empezar ya con limitaciones como esa, la del modo de color, no poder usar doble buffer en una ventana, y alguna que otra mas pues hace pensar mal de ello en un principio y "desconfiar" no?.
Creo recordar que probe ese benchmark (no estoy seguro pero creo que fue ese) y me daba error, imagino que me haria falta un dll o algo que no hacia bien, (se me quitaron las ganas de ponerme a "arreglarlo")
Digo yo que de lo que se trata es de que funcione por igual en cualquier modo de pantalla en cualquier pc actual sin tener que volverse demasiado loco y volver locos a los demas, y sin tener que hacer montones de pruebas en cada uno para conseguirlo, tambien lo ideal es tener el mayor control posible sobre el ordenador, no que el te controle a ti, te ponga trabas, y te obligue a hacer cosas que no quieres hacer. Una vez que se consigue esto pues ya que cada cual se apoye en las herramientas, utilidades, capas, librerias etc.. que mejor le convengan.
Yo si quiero hacer algo "pequeño" uso OpenGL 1.1, y me funciona en cualquier tarjeta incluso en una Riva TNT2, sin necesidad de dlls ni que el usuario tenga que instalar nada, ni configurar nada, ni volverse loco, por mi como si lo quiere usar en modo de 8 bits, sencillamente un pequeño exe de 100k que sabes que funcionara al ejecutarlo y que lo habre compilado como sea y con lo que sea, cosa que por otro lado no puedo decir de DirectX con sus cambios de versiones y su politica habitual.
De todos modos si me dices que con SDL puedes hacer lo mismo que con DirectX o OpenGL te creo, hay que acabar con los mitos. Y ademas quizas para alguien que empieza sea lo mejor, pero a mi personalmente no me gusta que me pongan limitaciones o me marquen las pautas de lo que debo hacer o lo que no y la verdad el SDL no me dio una buena primera impresion.
Esas limitaciones que comentas (no doublebuffer en ventana, del color, etc...) son las impuestas por DirectDraw. SDL tiene alguna restriccion por ahi pero vamos... no es esa :).
Sobre el soporte software ya te digo que esta bastante optimizado, yo he conseguido mejorarlo un poco mas (de un 10% a un 30% mas o menos) pero es por software.....
DirectDraw tiene un monton de limitaciones pero bueno....tiene ya mucho tiempo.
Por eso aquel test(el glSDL benchmark), para comprobar la mejora de utilizar glSDL: aceleracion hardware via opengl, soporte alpha por hardware, double buffer en ventana o pantalla completa, rotacion, escalado, etc... for free :)
Por si queda alguna duda por ahi, SDL no es un engine grafico en si, por debajo de el, se realizan plugin de graficos, para windows actualmente existen windib(lentooo), directdraw(depende para que...puede ir bien o no tan bien) y glSDL(el mas mejor de todos :P). En linux hay otros tantos(x11,directfb,etc.) y asi, en cada sistema utiliza sus "renderers". Por lo que, se puede escribir tu aplicacion y con cambiar una cosilla(una variable de entorno) utilizaras un sistema u otro. Y se trata de no volver loco al usuario final... por eso las pruebas y demas jeje
Vamos, que todo lo que haga DDraw...lo hace SDL.
mandelbrot: Uhm...y que error te daba el benchmark??
si algo no queda claro... decirlo, no calleis ;)
perdon, me lie con otra cosa, el benchmark si funciono al principio, pero tras un rato se bloqueo o aparecio un error (la verdad no lo recuerdo), bueno, es lo mismo, yo solo daba mi consejo, imagino que cada cual usara lo que mas le guste.
Ya te digo que me gusta la idea de poder usar SDL+OpenGL como entorno general de trabajo para pasar ya definitivamente de DirectInput y DirectSound. pero no se como estara de maduro el tema ese. Mas que nada por que bastante mareado anda ya uno con siglas, apis, versiones, y demas locuras. no quiero ni imaginar para el que empieza de 0
PD: Juraria que el BltFast de directdraw 6.0 era muchisimo mas rapido (mil millones de veces) que el SDL_BlitSurface, quizas hice mal las pruebas.
Uhmm...del benchmark te pudieron fallar las dos ultimas pruebas ya que requerian el .Net 2.0 y el DirectX Managed.. pero vamos, si no corrian esas dos pruebas, aun te generaba un report con muchas mas pruebas... y seria suficiente, si lo conservas por ahi miralo pq lo mismo tiene el htm generado y no lo viste :D
CitarPD: Juraria que el BltFast de directdraw 6.0 era muchisimo mas rapido (mil millones de veces) que el SDL_BlitSurface, quizas hice mal las pruebas.
Para que te vaya igual de rapido tienes q asegurarte varias cosas.... en SDL_VideoInit() tienes que pasarle un SDL_HWSURFACE y SDL_FULLSCREEN, asi utilizaras DirectDraw con aceleracion hardware y alli, aun con parpadeo(tendrias que indicar tambien SDL_DOUBLEBUF) te tendria que ir igual de rapido que el BltFast...
Si algun dia te aburres...y te pica la curiosidad...y lo pruebas... no te olvides de postear tus resultados :)
y bueno, actualmente si hay muchas siglas pero el que quiera hacer un juego... tendra q aprender tantas cosas... jejeje, eso es lo q mola, q nunca llegaras a saberlo todo
Test de rendimiento de video sobre SDLDibuja 100 y 1000 sprites de 64x64 con colorkey. Realiza las pruebas en modo fullscreen con y sin doublebuffer.
¿Que es glSDL?
Trabajar con openGL en sdl ¿o al revés?
S2.
Si, ya hice las pruebas, las he repetido para asegurarme, cargo un bmp de 640x480 en una superficie para luego copiarla en pantalla como fondo.
fondo = SDL_LoadBMP("fondo.bmp"))
y luego creo el modo de video del mismo tamaño.
SDL_SetVideoMode(640, 480, 32, SDL_HWSURFACE | SDL_DOUBLEBUF | SDL_FULLSCREEN );
primero desplazo un sprite de lado a lado de la pantalla y tarda 2 segundos
despues al añadir esto como fondo y borrado:
SDL_BlitSurface(fondo, NULL, screen, NULL);
el sprite tarda 4 segundos!!!! cuando deberia ser imperceptible la diferencia.
bien, es posible que haya que crear una superfice en la memoria de video y luego copiar a ella el bmp cargado en la memoria de sistema, pero... joer, vaya forma de facilitar las cosas, yo eso lo puedo deducir porque ya conozco DirectDraw, pero para alguien que empieza.....
no se que opinas tu si puede ser de eso.
Citar
y bueno, actualmente si hay muchas siglas pero el que quiera hacer un juego... tendra q aprender tantas cosas... jejeje, eso es lo q mola, q nunca llegaras a saberlo todo
yo todavia estoy buscando un sendero en este laberinto
Cita de: "J_F_NASH"¿Que es glSDL?
Trabajar con openGL en sdl ¿o al revés?
La verdad, no se todavia lo que es. Yo supongo que sera OpenGL en SDL, y desconozco si se puede usar 3D.
Yo sigo opinando que sera buena idea usarlo conjuntamente siempre que no afecte mucho al rendimiento de OpenGL y que no moleste.
Cita de: "J_F_NASH"Test de rendimiento de video sobre SDL
Dibuja 100 y 1000 sprites de 64x64 con colorkey. Realiza las pruebas en modo fullscreen con y sin doublebuffer.
¿Que es glSDL?
Trabajar con openGL en sdl ¿o al revés?
S2.
glSDL es un backend para SDL al igual que DirectDraw es otro backend para SDL.
En cristiano: tu programas en SDL, eliges el backend glSDL y utilizaras sin darte casi cuenta a OpenGL como aceleracion hardware pero en modo 2D. Beneficios? pues va todo como un tiro(tarjetas y equipos medianamente no muy antiguos), alpha por hardware, rotacion,escalado, modo ventana con doublebuffer....
De momento, te aconsejo que te olvides de esas cosas...tu centrate en seguir aprendiendo y tal.... porque luego implementar glSDL se hace en un pispas, yo tengo la lib SDL compilada para utilizar glSDL... si quieres, te la envio, no problem at all :)
por cierto, si has corrido el benchmark...puedes postear aki los resultados??? thx
Cita de: "Mandelbrot"Si, ya hice las pruebas, las he repetido para asegurarme, cargo un bmp de 640x480 en una superficie para luego copiarla en pantalla como fondo.
fondo = SDL_LoadBMP("fondo.bmp"))
y luego creo el modo de video del mismo tamaño.
SDL_SetVideoMode(640, 480, 32, SDL_HWSURFACE | SDL_DOUBLEBUF | SDL_FULLSCREEN );
primero desplazo un sprite de lado a lado de la pantalla y tarda 2 segundos
despues al añadir esto como fondo y borrado:
SDL_BlitSurface(fondo, NULL, screen, NULL);
el sprite tarda 4 segundos!!!! cuando deberia ser imperceptible la diferencia.
bien, es posible que haya que crear una superfice en la memoria de video y luego copiar a ella el bmp cargado en la memoria de sistema, pero... joer, vaya forma de facilitar las cosas, yo eso lo puedo deducir porque ya conozco DirectDraw, pero para alguien que empieza.....
no se que opinas tu si puede ser de eso.
Citar
y bueno, actualmente si hay muchas siglas pero el que quiera hacer un juego... tendra q aprender tantas cosas... jejeje, eso es lo q mola, q nunca llegaras a saberlo todo
yo todavia estoy buscando un sendero en este laberinto
Uhmm... cuando me aburra un rato hare ese test..lo malo, no dispongo de su homonimo en DirectDraw jeje
No se como limpiarias la pantalla... si es de un color puedes usar SDL_FillRect() que es mas rapido que blitear una superficie entera via software.... en modo hardware, el fillrect deberia ir como un tiro(ya lo probare) y el bliteo, siempre y cuando tu superficie a blitear este tambien en memoria de video, tambien ira como un tiro.
Lo de las siglas... pues se utiliza el google o este foro jejeje, no creo q haya nadie que se sepa todas :P pero animo y sigue con ello que yo en todo lo q pueda suelo ayudar, aunq no soy ningun maestro...digamos q sigo apalancado con las 2D...las 3D no me terminan de llamar para los generos q me interesan.....
el parpadeo normalmente sucede cuando uno blitea algo en la screen y luego hace un flip o un updaterect. no se debe hacer lo siguiente
SDL_BlitSurface()
SDL_Flip();
SDL_BlitSurface()
SDL_Flip();
eso produce un parpadeo, en cambio se debe hacer
SDL_BlitSurface()
SDL_BlitSurface()
SDL_Flip();
eso elimina el parpadeo, y lo de renderizar en otro sitio SDL ya lo tiene.
Pues aqui dejo el codigo que he usado para mis pruebas por si alguien lo quiere mirar o le interesa probarlo
He usado
DevC++ para compilarlo y las librerias
mingw32 (hace falta winrar o otro parecido para descomprimirlo)
Hay que copiar la carpeta include\SDL a la carpeta include del DevC++ y copiar los archivos de lib junto con las demas librerias.
crear un proyecto vacio, pegar el codigo y enlazar las librerias
copiar un par de archivos bmp a la carpeta de proyecto, uno de 640x480 y otro pequeño que hara de sprite
y compilar y ejecutar (F9)
// enlazar las librerias -lmingw32 -mwindows -lSDLmain -lSDL
// en proyecto/opciones de proyecto/Parametros/Linker
#include <windows.h>
#include <SDL\sdl.h>
int STDCALL
WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow)
{
// Iniciar SDL
if ( SDL_Init(SDL_INIT_VIDEO) < 0 ) {
MessageBox(0,"lo siento, no se pudo iniciar el SDL",0,0);
exit(0);
}
atexit(SDL_Quit);
// Cargar el archivo de fondo
SDL_Surface *fondo;
if ((fondo = SDL_LoadBMP("fondo.bmp"))==NULL) {
MessageBox(0,"no se pudo abrir el archivo fondo.bmp",0,0);
return 0;
}
// Cargar el archivo de sprite
SDL_Surface *sprite;
if ((sprite = SDL_LoadBMP("sprite.bmp"))==NULL) {
MessageBox(0,"no se pudo abrir el archivo sprite.bmp",0,0);
return 0;
}
// Iniciar la pantalla
SDL_Surface *screen;
screen = SDL_SetVideoMode(fondo->w, fondo->h, 32, SDL_HWSURFACE | SDL_DOUBLEBUF | SDL_FULLSCREEN );
// variables del sprite
int px=0, py=0;
int left=0, right=0, up=0, down=0;
// bucle principal
bool jugar=true;
SDL_Event event;
while (jugar) {
if (SDL_PollEvent(&event)>=0) {
switch (event.type) {
case SDL_KEYDOWN:
switch( event.key.keysym.sym ){
case SDLK_LEFT: left = -4; break;
case SDLK_RIGHT: right = 4; break;
case SDLK_UP: up = -4; break;
case SDLK_DOWN: down = 4; break;
case SDLK_ESCAPE: jugar=false; break;
default: break;
}
break;
case SDL_KEYUP:
switch( event.key.keysym.sym ){
case SDLK_LEFT: left = 0; break;
case SDLK_RIGHT: right = 0; break;
case SDLK_UP: up = 0; break;
case SDLK_DOWN: down = 0; break;
default: break;
}
break;
case SDL_QUIT:
jugar=false;
break;
}
}
// comprobar limites del sprite
if (px+left < 0) left=0;
if (px+right+sprite->w >= fondo->w) right=0;
if (py+up < 0) up=0;
if (py+down+sprite->h >= fondo->h) down=0;
// desplazar sprite
px+= left+right; py+= up+down;
// borrar con el fondo
SDL_BlitSurface(fondo, NULL, screen, NULL);
// dibujar el sprite
SDL_Rect rect={px,py,px+sprite->w,py+sprite->h};
SDL_BlitSurface(sprite, NULL, screen, &rect);
//mostrar el resultado en la pantalla
SDL_Flip(screen);
//Sleep(10);
}
SDL_FreeSurface(sprite);
SDL_FreeSurface(fondo);
return 0;
}
no se si me dejo algun paso o algo
Te pego aqui unos resultados (puedes ver mas en este otro hilo
glSDLBenchmarko en esta pagina
glSDL ).
Athlon XP 3000+ con Radeon 9700. Prueba con 1000 sprites de 64x64 en pantalla con limpiado de fondo en cada frame:
SDL usando DDraw: 110.99fps
SDL usando glSDL: 272.53fps
DDraw: 113fps
D3D en modo 2d: 312fps
Ahi ves que DDraw puro y DDraw utilizado desde SDL van casi igual. Que usando glSDL mejora muchisimo el tema y que se acerca un poco al D3D en modo 2D....
so..the way to go is SDL+glSDL :P
Hola TheAzazel.
Interesante eso del glSDL.
Una duda, para que SDL use glSDL es necesario compilarla o hacerle algo especial? o es suficiente con los libs/dll que trae ya compilados en la web?
Quizas no he hecho bien la prueba, porque el SDL a secas me va lentoooo lentoooo, efectivamente el uso de glSDL es muy efectivo al comprobar el Benchmark. aunque en mi opinion todavia limitado si no se puede usar el depth y stencil buffer, rotacion en cualquier grado, mezclas, filtros, luces, niebla, etc. por no hablar de la 3ª dimension, pero todo se andara.
De todos modos a mi personalmente ya no me preocupa demasiado porque he descubierto y probado que añadiendo el flag SDL_OPENGL en la funcion SDL_SetVideoMode se crea un contexto de ventana para OpenGL en el cual se pueden lanzar comandos sin haber apreciado en un principio perdida de calidad o velocidad, de modo que me metere en ello, me parece muyyyyyyy interesante el poder combinar la versatilidad de SDL (timer, audio, input, etc.) con la potencia grafica de OpenGL.
Ahora con mas razon recomiendo SDL+OpenGL (autentico) para los que ya controlen en 2D o DirectX, aunque para los iniciados seguramente sea lo mejor empezar con SDL a secas o mejor aun glSDL.
Un saludo a todos.
Cita de: "[Over"] Hola TheAzazel.
Interesante eso del glSDL.
Una duda, para que SDL use glSDL es necesario compilarla o hacerle algo especial? o es suficiente con los libs/dll que trae ya compilados en la web?
Tienes que bajarte una version (se anuncio por la lista de distribuccion) de SDL que incluye glSDL, la compilas y listo.
Ahora mismo no tengo la direccion pero yo tengo la lib compilada que lo incluye (para VisualC), si quereis, darme un email y os la envio, no es problema. Dicha version esta mas actualizada que la que te puedes descargar en la web (en el cvs esta la 1.2.8), se trata de la 1.2.9 no oficial pero todo va bien y encima con alguna mejora.
La historia es que en un futuro CERCANO, se incluya glSDL en la propia SDL y sea descargable desde su web directamente... pero por ahora estaba en fase de pruebas. Cuando hice el benchmark, un parte era para ver la velocidad y otra, para ver la compatibilidad y nadie me ha reportado ningun problema asi que... es rapida y estable :)
Cita de: "Mandelbrot"Quizas no he hecho bien la prueba, porque el SDL a secas me va lentoooo lentoooo, efectivamente el uso de glSDL es muy efectivo al comprobar el Benchmark. aunque en mi opinion todavia limitado si no se puede usar el depth y stencil buffer, rotacion en cualquier grado, mezclas, filtros, luces, niebla, etc. por no hablar de la 3ª dimension, pero todo se andara.
De todos modos a mi personalmente ya no me preocupa demasiado porque he descubierto y probado que añadiendo el flag SDL_OPENGL en la funcion SDL_SetVideoMode se crea un contexto de ventana para OpenGL en el cual se pueden lanzar comandos sin haber apreciado en un principio perdida de calidad o velocidad, de modo que me metere en ello, me parece muyyyyyyy interesante el poder combinar la versatilidad de SDL (timer, audio, input, etc.) con la potencia grafica de OpenGL.
Ahora con mas razon recomiendo SDL+OpenGL (autentico) para los que ya controlen en 2D o DirectX, aunque para los iniciados seguramente sea lo mejor empezar con SDL a secas o mejor aun glSDL.
Un saludo a todos.
si te iba lento, el error mas comun es blitear entre superficies de distinto formato al de screen, entonces cada blit, se esta realizando tambien una conversion al vuelo, y es mucho mas lento claro... por eso, cada vez que hagas un load de cualquier superficie...rapidamente le pasas por la funcion SDL_DisplayFormat() y te quedas con la que te devuelve...
Obviamente, llama a esta funcion despues de activar el modo de video deseado jeje y si este esta en hardware... te tiene que ir igual de rapido que ddraw a secas.
SDL y Opengl se han podido utilizar desde hace mucho tiempo...lo que se suele hacer es, utilizar todos los modulos que tu has dicho y luego renderizar con opengl, incluso puedes utilizar el apartado grafico de SDL y pegar a texturas de opengl jeje. Lo que pasa es que esto es mas por si quieres hacer una aplicacion 3D.
Para juegos 2D...la cosa es supersencilla...glSDL rulez! para que utilizar OpenGl a secas y programar todos los metodos que ya te ofrece SDL? y encima, utilizaras opengl sin darte casi ni cuenta!.
Actualmente con glSDL si se pueden hacer rotados y escalados por hardware solo que yo aun no me he puesto con ello e implementar las cosillas que tu dices podrias hacerlo facilmente...es todo codigo abierto!!!
jejeje, por cierto, no tengo ninguna comision de SDL ni de glSDL jejeje, solo que me gustan bastante y ademas, mi lib, CRM32Pro, esta basada por completo en SDL y tengo una version de pruebas que tambien incluye glSDL pero aun falta....jijijij
saludos a todos y siento si soy un poco repetitivo!!
Al principio pense que glSDL usaria otras librerias o dll mejoradas, pero por lo que veo se trata tan solo de una ampliacion del propio SDL. Decirte que aunque no he hice todas las pruebas, lo he encontre muy estable y rapido. (efectivamente el error que me daba al final era por no tener .Net 2.0 y el DirectX Managed)
Citar
La historia es que en un futuro CERCANO, se incluya glSDL en la propia SDL
Me parece una buena idea el incluir glSDL en el propio SDL, he echado un vistazo al codigo al codigo fuente del Benchmark y efectivamente el modo de video se crea con SDL_OPENGL. Entonces ¿sabes si de momento glSDL solo usa 2D porque esta en fase de pruebas?, ¿se ha previsto una ampliacion a 3D y al aprovechamiento maximo de las tarjetas de video cuando se incorpore definitivamente a SDL?.
seria interesante que fuera asi, y como ya te dije anteriormente las tarjetas graficas no solo son para calculos 3D, los efectos a nivel de pixel, las mejoras y facilidades en cuanto al tratamiento de la imagen 2D que se pueden aplicar por hardware sin apenas usar el procesador son lo suficientemente importantes como para tenerlas en cuenta en un futuro. sobre todo en lo que se refiere a efectos. Y a la larga facilita mucho el poder hacer algo facil y directamente por hardware mediante una simple llamada que tener que crearlo uno mismo consumiendo procesador o metiendose en mas lios.
He quedado gratamente sorprendido al comprobar como una pequeña demo OpenGL en 3D, incorporada a una ventana creada con SDL no ha sufrido ninguna diferencia de velocidad ni calidad, aunque lo tengo que mirar mejor en principio me parece genial SDL. esperemos que llegue a buen puerto la incorporacion de glSDL.
Saludos.