¿Como se almacenan las imagenes SDL en la psp?

me puedes decir si las 2.9 imagenes que cargas son de PNG o BMP o otro formato?

"Creo" que las imagenes se guardaban en la memoria principal y al blitear se copiaban a la vram pero no me agas mucho caso.

Recuerda que has de liberar todo lo que no gastes me parece raro que hayas llegado tan pronto al limite de la PSP... si estubieses con una ds...

por último recuerda que puedes adaptar las superficies que cargues al número de colores de la superficie de la pantalla ganando velocidad y espacio si las dejas a menos te recomiendo hacer esto y minimizar la profundidad de color ganarás memoria.

Son todas formato png, y por supuesto libero surfaces q no uso y bla bla bla. El modo de video es 16bits, pq 8 con paleta da mucho asco.
Vamos q me extraña q con apenas 3mg de imagenes en formato .h (las convierto a .h para integrarlas en el ejecutable) la cosa empieze a petarse por falta de memoria, pues nunca antes me habia pasado y empiezo a pensar q las surfaces se cargan en la vram, y como solo hay 4 mg si mal no recuerdo por eso se peta tan pronto. Jodios misterios.....

si las imagenes las tienes en png podria ser que se descomprimiesen en la memoria ocupando mucho más tamaño así que deberías pensarlo. recuerda lo que te he dicho de reconvertir las surfaces a tu sistema de color... y no se... podrías probar a hacer unos cuantos new de vectores grandes y así sabrias si te queda de verdad memoria.

sino ale a crear un sistema de cache o algo...

Ten en cuenta que el ejecutable se carga entero en memoria. Si las tienes integradas en el ejecutable supongo que éste te pesará bastante, a eso le sumamos que luego carga las imagenes en formato SDL_surface, es decir sin comprimir*, pues se te va la memoria en nada.

Yo cuando estaba haciendo el Kurayagi (un castlevania) me deboraba la memoria de la GP2X en un periquete, y eso que tiene alrededor de 20 megas libres si no recuerdo mal (32MB en total, le quitas lo que ocupe el sistema operativo, las librerias y el ejecutable y te quedan unos 20 o 24)


* Aunque tenga las imágenes en formato PNG y ocupen muy poco, al cargarlas en formato SDL_Surface se descomprimen y se quedan en memoria en formato crudo. Esto es algo que yo no tuve en cuenta en su día y me costó un buen disgusto. Me tocó reescribir bastante código.

como solucionaste en tu caso el exceso de memoria? hiciste una cache? o cargaste archivos de otra manera efegea?

Dejé de programarlo

No, en realidad dejé de programar el juego por dos motivos: porque el código era una basura y se acabó autodestruyendo (era mi primer juego) y porque decidí posponerlo hasta que tuviera listo mi engine 3D y hacer el juego en 2.5D como el remake del rondo of blood para psp (y el motivo para hacerlo en 2.5D es porque me resultaba infinitamente más facil modelar en 3D que hacer sprites y fondos en pixel art)

Pero bueno eso no es lo que tenía que explicar. El problema que tenía con la memoria era debido a la profundidad de color que usaba, 32bits (incluyendo el canal alpha) y a que para los fondos de los niveles usaba una imagen enorme. Entonces claro, la memoria se iba enseguida.

La solución era: usar imágenes de 8 bits y un sistema de tiles. Bastante evidente lo de los tiles, es lo que se ha usado toda la vida en todos los juegos, usar una imagen enorme fue una bestialdad por mi parte

pues por lo que veo el tema en cuestiones de memoria es siempre el mismo o reduces la profundidad de colores o algo... yo de momento no tengo problemas de memoria pero no cargo aún todas las animaciones igual mi solución es recortar animaciones y tal ...

Hace un par de post un xaval decía que no era fácil llegar al límite de memoria de psp... seguro que era ingeniero informático como poco...

Por cierto he estado leyendo algo de ti... como es eso de que querias vender el juego? eso se puede hacer? a quien selo querías vender? sabes que un juego ha de tener mucha calidad para poder venderlo?

Eso fue hace mucho tiempo, cuando el juego aún prometía y la gente estaba encantada con él...Me lo propusieron y hablé con el distribuidor de la GP2X en España y me propuso que le enseñaramos una demo a Gamepark Holdings a ver si estaban interesados.

Pero la cosa fue muy mal...no tenía grafista y había que rehacer todos los gráficos, pues estaba usando gráficos prestados del castlevania. Y luego lo que he comentado antes de que acabé cargándome el código.

Me hize ilusiones y ya ves como acabó todo. Ahora me avergüenzo de todo aquello :_(

hombre eso de comercializar el juego en realidad estaría bien si lo haces como trabajo ... yo si me pusiera a trabajar 8 horas al día en el juego en un mes seguramente te sacase algún juego de calidad comercial tambien ( ya que la gente flipa a la velocidad que trabajo normalmente hasta en el curro ).

Pero pienso que de momento la afición por un lado y el placer por otro además la cosa está muy jodida vender un juego así... en fin jejeje

Bien, veamos, el ejecutable ocupa 2mg, estoy usando el modo 16bits con la GU vamos la aceleracion por hard y sistema de tiles para los mapas, asi ocupan 2ks cada mapa.
Si las imagenes en png se descomprimen en memoria, ¿cual es su tamaño o como puedo saber lo q ocupan? ¿si las grabo por ejemplo en bmp sin comprimir seria el tamaño equivalente?

Por ejemplo ahora las imagenes son todas de 8bits con paleta, asi ocupan lo minimo, pero uso el modo 16bits para mejorar los colores con lo cual se convierten a 16bits y ocupan mas

el método para saber el tamaño de una imagen en memoria es el siguiente:

tamaño_horizontal_*tamaño_vertical*profundidaddecolorenbits*numerodecomponentesdecolor/8/1024/1024

eso te dará los Mbytes de una imagen.

PD: prueba a inicializar la SDL por soft a ver si te sigue pasando lo mismo... es una curiosidad que tengo

Si saulot usando soft el problema es el mismo, me quedo sin memoria, a pesar de q las imagenes q uso son de 256 colores, siguen pesando demasiado, ya me gustaria a mi usar un sprite con 3 frames

Me habian comentado por unos foros que podría ser que cuando usas SOFT la memoria era de video y cuando usas HARD la otra aunque yo creo que siempre es la misma la única diferencia es que por soft se usa el GU

¿Porque usas SDL cuando una librería multiplataforma, siempre va a ir peor y encima no sabes como funciona a nivel interno, ni que recursos utiliza de la consola?

Mejor sería que crearas tus propias rutinas para trabajar la pantalla, pero weno, cada uno es cada uno

Pues pq algunos somos muy vagos tito hermes y es mejor ir probando lo q haces en pc, y cuando terminas lo recompilas en psp y arreando

Eskematico escribió:Pues pq algunos somos muy vagos tito hermes y es mejor ir probando lo q haces en pc, y cuando terminas lo recompilas en psp y arreando

Pues a mi me parece que mas que arreando, sales arreado

Con lo que mola lanzar aplicacion, salir, volver a montar usb, compilar, copiar, expulsar unidad en windows, desmontar unidad, localizar y volver a lanzar aplicacion....

Hermes escribió:
Pues a mi me parece que mas que arreando, sales arreado

Con lo que mola lanzar aplicacion, salir, volver a montar usb, compilar, copiar, expulsar unidad en windows, desmontar unidad, localizar y volver a lanzar aplicacion....

emmm lo dices como si no gastases el link que hizo tyranid ( por muy gili... majo que sea el tio el programa está muy bien).

saulotmalo escribió:

emmm lo dices como si no gastases el link que hizo tyranid ( por muy gili... majo que sea el tio el programa está muy bien).

Pues no, no lo he "gastado" (tampoco es que haya hecho mucho en la PSP como para tener que probar 500 veces las cosas)

Para eso uno, tiene que saber que su rutina compilada sin errores, funcionara tal y como uno la ha proyectado (es la ventaja de acostumbrarse a diseñar uno sus propios metodos )

Pero vamos, si me pasas un enlace le echare un ojo.

Por cierto, si alguien tiene algo de documentacion sobre como utilizar las funciones graficas 3D de la PSP o ejemplos simples, tambien me interesa (y no, no quiero ports de Open GL, ni niño muerto: prefiero info sobre la libreria nativa, aunque tenga cierto parecido con Open GL segun creo)

Hermes escribió:¿Porque usas SDL cuando una librería multiplataforma, siempre va a ir peor y encima no sabes como funciona a nivel interno, ni que recursos utiliza de la consola?

Al ser un port de SDL debería tener el código fuente disponible ¿no?

Pregunto, que conste

aquí tienes un tutorial para configurarlo:

http://www.elotrolado.net/showthread.php?s=&postid=1705482679

luego para ejecutar un programa simplemente con el pcterm lo ejecutas como si estubieses en linux

./nombreejecutable

yo suelo ejecutar el eboot kxploiteado por costumbre más que nada otros lo hacen con el elf directamente creo que tambien se puede.

por otro lado es lo que comentan aqui la sdl puedes saber como se implementa porque está en código libre

por último la librería para gráficos que se usa en psp es la gu ( graphics unit) en el propio SDK hay bastantes ejemplos que te pueden ayudar a empezar y algo de documentación.

Cierto hermes, el precio a pagar por el multiplataforma es salir arreado o mas bien escaldado, pero yo por ejemplo considero una perdida de tiempo hacerme funciones y aprender el pspsdk, pq si mañana sale otra consola q me interese pasare de la psp y lo aprendido no servira de nada, pq otro consola funcionara de forma diferente.
Vamos q tengo 1 mes para hacer un juego y quiero codear el juego no perder ese tiempo aprendiendo a manejar el sdk correspondiente

Eskematico escribió:Cierto hermes, el precio a pagar por el multiplataforma es salir arreado o mas bien escaldado, pero yo por ejemplo considero una perdida de tiempo hacerme funciones y aprender el pspsdk, pq si mañana sale otra consola q me interese pasare de la psp y lo aprendido no servira de nada, pq otro consola funcionara de forma diferente.
Vamos q tengo 1 mes para hacer un juego y quiero codear el juego no perder ese tiempo aprendiendo a manejar el sdk correspondiente

Precisamente por eso,porque mañana puede salir otra consola, es por lo que interesa acostumbrarse a absorver informacion exclusiva de la maquina y a trabajar algunas cosas a bajo nivel.

Por ejemplo, SDL dispone de codigo fuente, pero ¿Sabrias tu como reparar el problema y adaptar la libreria para que trabaje de forma optimizada con tu consola?

Cuando te acostumbras a trabajar así, lo que ganas es un mayor conocimiento de la maquina, pero tambien ganas un mejor dominio de la siguiente maquina, pues con saber tres cosas, puedes trabajar con ella.

En mi caso, tengo documentacion 0 de PSP, nada de SDK ni leches, y echando un vistazo rapido a los fuentes de un emulador, aprendí en seguida a configurar la pantalla para dibujar a pelo, no me costó casi nada hacer una funcion que dibujara sprites en pantalla (incluso le inclui la posibilidad de dibujar graficos translucidos), poco me costó aprender como podia utilizar varios canales de audio y añadir una rutina de mi cosecha para generar efectos de sonido y otra para convertir PCM a diferentes frecuencias, etc.

Vamos, que no solo ganas una adaptacion mas rapida al pasar de una maquina a otra, si no que te da mejor base para poder reforzar tus programas y un mejor control sobre los recursos de la consola. y sus limites.

Es verdad que requiere quiza mas trabajo al principio, pero es que luego todo ese trabajo se traduce en codigo que conoces a la perfeccion y que te será muy facil exportar o adaptar a otros usos, pues es creacion tuya.

Ahora mismo, con aprender como configurar la pantalla para manejar graficos 3D, subir una textura a la VRAM y dibujar un par de triangulos, ya tienes un sprite acelerado con posibilidad de rotarlo, escalarlo y aplicarle otra serie de efectos, de forma sencilla e incluso, lo puedes encapsular con codigo propio para que si lo portas a otra consola, solo sea cuestion de adaptar esas funciones
a la nueva maquina.

Yo al menos, prefiero esa filosofia a dedicar tiempo a aprender como se usa una libreria que no conozco que recursos consume, ni su funcionamiento interno y cuando me dé algun problema, no tener la capacidad de poder arreglarlo (porque no estoy acostumbrado a tocar un nivel mas bajo) y a lo mejor, tener que desistir de crear un programa por ello.

En PC, es otra filosofia distinta y lo entiendo, pero en consola...

Cierto hermes, pero en mi caso no lo tengo tan facil para aprender, no todos tenemos esa capacidad de absorcion q teneis algunos(cacho marikita ). Y no tenemos mas remedio q tirar de librerias tipo SDL, LUA o cosas asi. Como dices no tengo ni pajolera de como modificar el source para adaptarlo a lo q necesito, por ejemplo ahora estoy liado con las paletas y tal vez la psp ni tan siquiera acepta paletas y solo esta pensada para currar a 16 o 32bits

Eskematico escribió:Cierto hermes, pero en mi caso no lo tengo tan facil para aprender, no todos tenemos esa capacidad de absorcion q teneis algunos(cacho marikita ). Y no tenemos mas remedio q tirar de librerias tipo SDL, LUA o cosas asi. Como dices no tengo ni pajolera de como modificar el source para adaptarlo a lo q necesito, por ejemplo ahora estoy liado con las paletas y tal vez la psp ni tan siquiera acepta paletas y solo esta pensada para currar a 16 o 32bits

Si estas liado con paletas, lo mejor que puedes hacer es traducir la paleta de color a 16 bits en una tabla y utilizar el color como indice a esa tabla para asi generar/dibujar un sprite a 16 bits.

Por cierto, la capacidad de absorcion que me atribuyes, es porque siempre trabajo asi (no es que yo tenga una capacidad que me permita trabajar de esa manera, es que si no trabajas asi, nunca tendrás esa capacidad).

Me interesa usar 8bits con 256 colores por el tema de tamaño de imagenes y reducir el consumo de ram, de ahi q quiera cargar paletas para obtener los colores correctos.
Pero si traduzco la paleta a 16 bits, ¿q diferencia hay con usar 16bits directamente?

Eskematico escribió:Me interesa usar 8bits con 256 colores por el tema de tamaño de imagenes y reducir el consumo de ram, de ahi q quiera cargar paletas para obtener los colores correctos.
Pero si traduzco la paleta a 16 bits, ¿q diferencia hay con usar 16bits directamente?

La diferencia es que no tienes porque estar ocupando un tamaño doble o cuadruple todo el tiempo y la conversion se realiza en un tris.

Si utilizas una rutina que dibuje un sprite de 16 bits haciendo la traduccion directamente, utilizando el color como indice de la paleta de 16 bits para obtener el color, ni siquiera tienes porque gastar memoria extra (como mucho la que utilice la paleta, si la quieres tener por separado, pero tambien podrias utiliza la misma memoria que ocupa la paleta de color original, solo que el dato en vez de ocupar 32 bits ocuparia 16 bits)