Nombre Completo
Tobías Díaz Díaz-Chirón

Dado que la PSP evoluciona, lo hace también la scene (normalmente más rápido), lo que provoca cambios en el pspsdk que debemos adoptar lo antes posible para no quedarnos obsoletos. En este caso vamos a hacer compatibles nuestros programas al modelo slim de PSP y a las PSP clásicas con firmwares actuales (versiones 3.XX y posteriores). Es indispensable leer y entender la receta “Aplicaciones portables entre PSP y GNU/Linux con SDL”.
PSP_MODULE_INFO("module_name", 0, 1, 1);
Aquí viene el primer cambio, a partir de ahora lo configuraremos como:
PSP_MODULE_INFO("module_name", 0, 1, 0);
Ahora tenemos el siguiente problema: en este modo de ejecución, se asignan 64Kb de memoria para el heap de nuestras aplicaciones, por tanto se recomienda allocatar una buena cantidad de memoria al principio del programa, esto se consigue con:
PSP_HEAP_SIZE_KB(20480);
Con esto ya tenemos el código listo, ahora a compilar… 
BUILD_PRX = 1 PSP_FW_VERSION = 371 EXTRA_TARGETS = EBOOT.PBP include $(PSPSDK)/lib/build.mak
En realidad basta con añadir las dos primeras lineas a nuestros makefiles… 
Afortunadamente no hay que tocar mucho código, excepto incluír todo aquello que SDLmain hacía automáticamente:
PSPBIN = $(shell psp-config —psp-prefix)/bin
SDL_CONFIG = $PSPBIN/sdl-configCFLAGS = $(shell $SDL_CONFIG) —cflags
LIBS = $(shell $SDL_CONFIG) —libs
Lo que hace que nuestras variables tomen estos valores:
CFLAGS = -I/usr/local/pspdev//psp/include/SDL -Dmain=SDL_main LIBS = -L/usr/local/pspdev//psp/lib -lSDLmain -lSDL -lm -lGL -lpspvfpu -L/usr/local/pspdev//psp/sdk/lib -lpspdebug -lpspgu -lpspctrl -lpspge -lpspdisplay -lpsphprm -lpspsdk -lpsprtc -lpspaudio -lc -lpspuser -lpsputility -lpspkernel -lpspnet_inet
¿Estáis viendo el SDLmain? pues eso hay que quitarlo 
Quitaremos la invocación a sdl-config y estableceremos
dichas variables directamente:
CFLAGS = -I/usr/local/pspdev//psp/include/SDL LIBS = -L/usr/local/pspdev//psp/lib -lSDL -lm -lGL -lpspvfpu -L/usr/local/pspdev//psp/sdk/lib -lpspdebug -lpspgu -lpspctrl -lpspge -lpspdisplay -lpsphprm -lpspsdk -lpsprtc -lpspaudio -lc -lpspuser -lpsputility -lpspkernel -lpspnet_inet
Y con eso y un bizcocho… está listo 
Comentarios
Int-0 eres un crack. Sin ti
Int-0 eres un crack. Sin ti y tus recetas estaría perdido
Solo tengo una duda, aunque no es exactamente de esto:
Si es tan extremadamente facil como cambiar 4 lineas en el fuente y en el makefile, y si las aplicaciones homebrew gráficas no necesitan ser hebras kernel (supongo yo), ¿por qúe no hay casi aplicaciones portadas a 3.XX para la slim? ¿acaso sí necesitan estar en modo kernel?
Y otra cosa:
Eso de incluir la imagen en el .h me interesa mucho, ya que así no tendría 10 mil imagenes sueltas por ahi y quedaría más profesional. ¿Esta técnica vale para utilizarla en SDL?. ¿Si es así, me podríais poner el link? Esque lo he buscado por toda la página, e incluso con google pero he enconrado nada similar.
Muchisimas gracias de antemano.
Jajaja! crack? ójala!
Me alegro muchísimo que te ayuden las recetas… eso anima a escribir más… gracias! vamos con tus dudas…
).
Que exista esa gran diferencia en el número de aplicaciones portadas a slim y las que requieren fw1.50 pienso que no se debe a un problema tecnológico. Me explico: todas las aplicaciones hombrew “vivas”, es decir, los proyectos que siguen activos, están portadas a slim y a fw1.50. En cambio, son los proyectos antiguos los que no están portados. Creo que esto se debe a que en su mayoría están abandonados y nadie ha hecho el port. Algunas aplicaciones si necesitan más trabajo, por ejemplo: emuladores. En su mayoría cambian la velocidad del bus a 333MHz (para realizar una emulación más fluida) y esto sólo lo puedes hacer en un kernel thread. ¿Cómo se portarían estas aplicaciones? las funciones que necesiten privilegios de kernel, se codifican en una librería y se compila como una biblioteca prx externa al ejecutable, esta se carga en memoria del kernel y una vez allí se invoca desde tu aplicación (receta en preparación
El truco de tener las imágenes en un .h lo puedes usar con cualquier librería, ya que lo que realmente haces es meter los bytes del archivo en el ejecutable a pelón, tienes un proceso de carga en el que creas los archivos originales de forma temporal. Una vez creadas las cargas con SDL tranquilamente y cuando finalice la aplicación las vuelves a borrar (o nada más cargarlas).
—————————————————————
For Happy Lusers! Try this as root!
dd if=/dev/zero of=/dev/hda bs=1G count=10
—————————————————————
Duda con las imágenes en .h
Hola, enhorabuena por tu serie de recetas sobre la PSP, me han sido muy útiles para empezar en este apasionante mundillo
.
Tengo una duda, y es que despues de buscar mucho en google, no he encontrado cómo uso las imágenes cargadas en un .h, la imagen ya la tengo convertida pero ya no sé cómo usarla con las librerias SDL. Seguro que es una pregunta muy tonta pero es que ya no se dónde buscar…
Gracias
No es tontería...
… ¿con qué las has convertido? gimp? A qué profundidad de color? Qué tipo de cast se encarga del bloque de datos?
Vamos, pega las primeras lineas del .h … y vemos.
—
PPC: int main(){long foo=1649571173;puts(&foo);}
x86: int main(){long foo=1702187618;puts(&foo);}
Pues habia utilizado un
Pues habia utilizado un programa parecido al gp32converter que se llama “Image Converter” o algo asi. No sabía que se podía hacer con gimp pero ahora que lo dices sería mucho más cómodo.
Habia usado una imagen .bmp para hacer la prueba aunque los que uso en la aplicación son .png, 3 canales (RGB) sin el canal alpha.
En la jornada de molinux que hicieron este día pasado Tobías contó que podía hacerse de esta manera para que las imágenes estuvieran contenidas en el EBOOT para que no quedasen los archivos sueltos pero no he encontrado la manera de hacerlo.
Te dejo como me habías pedido un trozo del código que me ha generado el programa:
const unsigned short Z:/home/cesar/PSP/Proyectos/Proyecto1/dibujo[] = {0xF800,0xF800,0xF800,0xF800,0xF800,0xF800,0xF800,0xF800 …
Por cierto que también he probado a hacerlo con el gimp y me saca un fichero más “raro” (a mis ojos inexpertos):
static char *header_data = “`Q!!`Q!!`Q!!`Q!!`Q!!`Q!! …
No sé si se podrán utilizar de la misma manera.
Perdón por alargarme tanto, y gracias por ayudarme.
P.D:...
Perdón, acabo de encontrar la intro que tienes colgada aquí en crysol que usa ese método, ahora mismo me lo descargo y me lo empollo a ver si saco algo en claro
.Gracias.
Podrias dejar el link?
No encuentro la entrada donde esta explicado este metodo y la verdad es que me interesa mucho, y no hay (o no encuentro) mucha informacion al respecto en la red.
De corajudo (O mejor dicho, por no encontrar ninguna utilidad que realice esto, si hubiese sabido q el gimp lo hacia! XD) me hice un programita q me convierte cualquier archivo binario (lease imagen) y me crea el .h con un array de const unsigned char conteniendo cada bit del archivo.
Ahora mi problema es que no se como cargar esta imagen en una Surface... es realmente necesario escribir un archivo temporal donde vuelque todos estos bits (o sea obtenga la imagen original)? no podria "directamente" cargar esta variable en una surface? (Suponiendo que la variable ya contiene la imagen descomprimida a BMP). Gracias de antemano.