Parpadeo En Movimiento

[Mandelbrot]

 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.

[TheAzazel]

 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  ;)  

[Mandelbrot]

 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.

[TheAzazel]

 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

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.

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

[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.

[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.

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

[Mandelbrot]

¿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.

[TheAzazel]

 

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

[TheAzazel]

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.

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.....

[vicho]

 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.

[Mandelbrot]

 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)

Código [Seleccionar] Expand


// 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

[TheAzazel]

 Te pego aqui unos resultados (puedes ver mas en este otro hilo glSDLBenchmark
o 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

[[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?

[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.

[TheAzazel]

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 :)