New to PSP programming, loading sections of image crash it?

[Elspin]

So I've been trying to write a few basic programs to test out the development tools but I'm running into a major problem: every time I try to paste a section of an image to the screen, it just crashes the PSP. I've confirmed that if I don't try and paste anything but text to the screen or if I paste the whole image of a smaller image to the screen it works fine, but cutting out sections doesn't work.

I stripped the sourcode down to just this to try and isolate the problem, and it's still happening:

Code:

#include <stdio.h>
#include <pspkernel.h>
#include <pspdisplay.h>
#include <pspctrl.h>
#include <psppower.h>
#include <png.h>

#ifdef __cplusplus
extern "C" {
#endif
#include "graphics.h"
#include "framebuffer.h"
#ifdef __cplusplus
}
#endif

PSP_MODULE_INFO("Test Game", 0, 1, 1);

#define RGB(r, g, b) ((r)|((g)<<8)|((b)<<16))

/* Exit callback */
int exit_callback(int arg1, int arg2, void *common) {
          sceKernelExitGame();
          return 0;
}

/* Callback thread */
int CallbackThread(SceSize args, void *argp) {
          int cbid;

          cbid = sceKernelCreateCallback("Exit Callback", exit_callback, NULL);
          sceKernelRegisterExitCallback(cbid);

          sceKernelSleepThreadCB();

          return 0;
}

/* Sets up the callback thread and returns its thread id */
int SetupCallbacks(void) {
          int thid = 0;

          thid = sceKernelCreateThread("update_thread", CallbackThread, 0x11, 0xFA0, 0, 0);
          if(thid >= 0) {
                    sceKernelStartThread(thid, 0, 0);
          }

          return thid;
}

int main() {

scePowerSetClockFrequency(333, 333, 166);

SetupCallbacks();
initGraphics();


Image *map = loadImage("pnglol.png");
int i = 0;
SceCtrlData pad;
char filler[10];
Color highlightColor = RGB(255, 255, 255);
Color shadowColor = RGB(55, 55, 55 );

while(1)
{
fillScreenRect( RGB(255,255,255), 0, 0, SCREEN_WIDTH, SCREEN_HEIGHT );

sceCtrlReadBufferPositive(&pad, 1);

                //actual image size is 1000x1000
blitAlphaImageToScreen( 0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, map, 0, 0); //this will always crash the program

sprintf(filler, "Picture On");
printTextScreen(11, 10, filler, shadowColor);
printTextScreen(10, 10, filler, highlightColor);

flipScreen();

for( i=0; i<3; i++ ) {
sceDisplayWaitVblankStart();
}
}


return 0;
}

I'm using visual studios with the minPSPdevkit and the headers are the same ones provided in these tutorials: http://www.psp-programming.com/tutorials/c/lesson04.htm

Would really appreciate some help on this, don't really know what I can do

[mowglisanu]

loadImage cannot load files greater than 512*512

also you have a buffer overflow @sprintf(filler, "Picture On");
the null terminating character must be counted as well

[Elspin]

loadImage cannot load files greater than 512*512

also you have a buffer overflow @sprintf(filler, "Picture On");
the null terminating character must be counted as well

Oh, thanks for the info, would have been nice if that had been written somewhere. 

also thanks for pointing out the sprintf thing, but oddly enough that's been working fine

[AlphaDingDong]

Sometimes overflows won't trigger any unexpected behavior until many other changes have been made to the program.  Once it reaches that point it can be a real pain in the ass to hunt down the problem.  Because of this it's a good habit to double check your buffer lengths after you complete a section of code.

Just as general advice, I'd recommend not using the fillScreenRect function to clear the screen.  As I recall it uses software drawing (draws each pixel one-by-one using the main CPU) which is very slow.  I remember that the graphics.c screen clearing function is broken.  Let me look it up real quick...

Code:

void clearScreen(Color color) {
if(!initialized) {return;}
guStart();
sceGuClearDepth(0);
sceGuClearColor(color); //this is what was missing.
sceGuClear(GU_COLOR_BUFFER_BIT|GU_DEPTH_BUFFER_BIT);
sceGuFinish();
sceGuSync(0, 0);
}

Replace it with that minor modification and it should work.  That method uses hardware drawing but it's still pretty slow because graphics.c always syncs up after every hardware drawing call.  Either way this method will be more effective until you move past graphics.c and start writing your own GU code.