sdl usa la memoria ram para leer imagenes?

[zupervaca]

Buenas, pues estoy desde el curro teniendo un problema y es que el motor que se usa por aqui tiene como base sdl, el problema es que parece ser que lee las imagenes en memoria ram ya que si lees varias imagenes tochas la memoria ram se dispara, ¿hay forma de obligarle a leer las imagenes en la memoria de video? el motor usa surfaces y estube revilando por los parametros de lectura y creacion para indicarle el flag de que la textura se lea en memoria de video o se use el hard para ello, pero ni asi.

Editado: El titulo esta mal sorry, me acabo de dar cuenta

[Sante]

Para indicar a SDL que cree una superficie en memoria de video le tienes que pasar el flag SDL_HWSURFACE. Si no me equivoco, es la única manera.

Aun asi, no es seguro que te haga caso. El flag simplemente hace que intente crearla ahí, pero si no puede por la razon que fuera la creará en la memoria RAM de toda la vida.

Prueba a llamar a SDL_GetVideoInfo( ), y a mirar el flag que te devuelve en hw_available, que indica si es posible la creación de superficies hardware en ese dispositivo. Si te dice que no, ya tienes la razón de porque te falla.

[TheAzazel]

Veras, eso depende de cuando creas la surface el flag que pases, por defecto las creara en RAM (SDL_SWSURFACE) y aunque le pases un SDL_HWSURFACE si esa surface tiene alpha y tu backend no lo soporta (en ninguno lo soporta..salgo si usas glSDL) pasara de tu flag y lo creara en RAM ya que los alpha no estan acelerados por hardware.

Con mas info...mas ayuda..en que plataformas? porque si estas en alguna pequeña lo mismo no hay soporte hardware y por eso solo tira de la RAM...

PD: por Dios!! estuVe!! que casi me quedo ciego :P

PD2: se me adelantaron... jejeje

[Pogacha]

En realidad tendras que tener cuidado. Rasterizar de ram a video es lentisimo.  Rasterizar de video a ram peor aun. Rasterizar de video a video (usando hardware) es rapidisimo, usando software todo lo contrario. . Por eso suele ser conveniente (si no vas a usar aceleración por hardware) tener todo en ram y solo la suferficie primaria en video (que no puedes evitar).

[zupervaca]

gracias a todos.

ya que los alpha no estan acelerados por hardware

oki aqui esta el problema entonces, las imagenes que menciono tiene canal alfa.

¿Cambian muchas cosas de usar SDL a glSDL? La pregunta creo que es un pelin estupida, pero es que con sdl nunca me he metido hasta ahora.

[TheAzazel]

No, no cambia nada.

glSDL es un backend, al igual que windib o ddraw. SDL esconde todo eso y puedes cambiar de backend facilmente y utilizar el que mas te guste.

En windows ultimamente viene siendo:

- windib: va como un tiro y es el mas compatible. Funciona sin problemas en Win64 y Vista(ademas aqui, ira aun mas rapido y hay rumores que ira acelerado por hard...). Hoy por hoy, solo software.

- ddraw: en desuso... ahora da algun problema, sobre todo en win64 y vista y parece que poco a poco lo van a ir dando boleto... . Soporta software y hardware, pero este ultimo un poco limitado(por ejemplo, no soporta alpha)

- glSDL: el mas mejor! pero necesitas una tarjeta que soporte OpenGL. Acelera todo por hardware. No esta incluido en SDL 1.2.11 y hay que agregarlo a pelo. Yo lo tengo asi, si alguien quiere probarlo... la v4.95 de mi lib lo incluye aunque esta en pruebas...

Para cambiar de un backend a otro, lo puedes hacer con una variable de entorno:

SDL_VIDEODRIVER=windib o directx o glSDL o lo que sea...

Las buenas noticias es que en el desarrollo actual de SDL1.3/2.0, los backend seran en windows:

- OpenGL
- Direct3D
- Windib

asi que muchos de los problemas actuales debido a su edad van a desaparecer y sera supersencillo programar cosas en 2D siendo totalmente aceleradas. Esto lo quiero conseguir yo un poco antes con la v5.0 de mi lib :), pero tengo que pulir un poco el glSDL con respecto a mis interfaces y clases.

Y bueno, hay un par de normas para utilizar glSDL que son de cajon:
http://icps.u-strasbg.fr/~marchesin/sdl/glsdl.html

Alguna otra cosa mas... pregunta pregunta

saludos