I don't see anything that would cause a crash, apart from what mowgli mentioned. There's some minor logical errors and a lot of things that can be simplified, but nothing fatal. In fact, it looks like your background image is 960 wide, just judging from your code, so that's probably the error.
Here's some advice.
Write a raise() function that prints an error message and sleeps the thread, then:
//-----------------------------error check
int i;
for(i = 0; i < 10; ++i) {
if(BlinkyImages == NULL) {raise("Failed to load Blinky image file.\n");}
}
if(Star == NULL) {raise("Failed to load Star image file.\n");}
if(Bullet == NULL) {raise("Failed to load Bullet image file.\n");}
if(Background == NULL) {raise("Failed to load Background image file.\n");}
Check this out:
GunPosY = BlinkyPosY; //~~~ these two variables are not necessary (see below)
GunPosX = BlinkyPosX+53;
...
if(pad.Buttons & PSP_CTRL_CROSS) { //fire
BulletShot = 1; //~~~ can fire bullets while one is already onscreen!
BulletPosY = BlinkyPosY;
BulletPosX = BlinkyPosX + 53;
}
This line comes too early. Blinky will never blink!:
if(BlinkTimer++ > 100) {FrameCounter++;} //~~~ think this should maybe come later
Just put it after your control logic.
In fact, it can go just before this:
if(BlinkTimer > 120) {BlinkTimer = 0;} //makes blinky stop blinking
However, that line can be replaced with:
BlinkTimer %= 121;
Which is faster and makes you look cool.
You have bounds checking for blinky:
//~~~ these checks should be done during input checking
if(BlinkyPosX < 0) {BlinkyPosX = 0;}
else if(BlinkyPosX > (480 - 106)) {BlinkyPosX = (480 - 106);}
if(BlinkyPosY < 0) {BlinkyPosY = 0;}
else if(BlinkyPosY > (272 - 72)) {BlinkyPosY = (272 - 72);}
But you can put that in the input check like this:
if(pad.Lx < 50) { //left
BlinkyPosX -= 4;
FrameCounter = 2;
if(BlinkyPosX < 0) {BlinkyPosX = 0;}
}
Which looks cleaner and will save you from making useless checks every frame. (faster)
Also:
if(DeadStars == 30) {Running = 0;} //~~~ put this inside the (StarPosY > 272)
For the same reason.
Next is this:
//~~~ this should be done mathematically, also _StarPosY_is_integral_
if(DifficultySetting == 1) {StarPosY += 1.5;}
if(DifficultySetting == 2) {StarPosY += 2;}
if(DifficultySetting == 3) {StarPosY += 2.5;}
StarPosY is an
integer. You can't use floating point values with it. For now I'd recommend just:
StarPosY += DifficultySetting;
But really I think you should have a motion counter, because even just +1 every frame is going to be very fast. (60 pixels per second!)
Add a new variable 'MotionTimer' and initialize it to zero. Increment it once every frame. Reverse your difficulty setting numbers, so that 3 is easy and 1 is hard. Then do this instead:
if(MotionTimer > (12 * DifficultySetting)) {
++StarPosY;
MotionTimer = 0;
}
Note:
//collision test
if((StarPosX < BulletPosX) && ((StarPosX + Star->imageWidth) > (BulletPosX + Bullet->imageWidth))) {
//~~~ this next line is incorrect. height should be checked but width is checked
if((StarPosY < BulletPosY) && ((StarPosY + Star->imageWidth) > (BulletPosY + Bullet->imageWidth))) {
//collision
BulletShot = 0; //makes bullet go away
Score++; //adds to score
DeadStars++; //adds to timer that eventualy ends the game
StarPosX = GetRandomNum(BackroundBegin, BackroundEnd); //puts the star at a random x position
StarPosY = 0; //puts star at top of screen
}
}
I just cleaned up the syntax a little, but there is an error in there. I'll leave it for you to fix.
You have variables 'BackroundBegin' and 'BackroundEnd', but you only really need 'BackroundScroll'.

Overall this is a good start now that it's cleaned up a bit. You can see I changed some of the formatting in terms of where the brackets are and stuff, but that's just my personal style.
Now I'd like to tell you about using a spritesheet. Get the program working before you try this, but this is a good thing to know.
Currently you have 10 different images for your blinky sprite. That's fine, but a spritesheet can make it easier to handle. What you do is put them all into one image file like this:
---------------------
|Idle |IdleBlink |
|Left |LeftBlink |
|Right |RightBlink|
|Up |UpBlink |
|Down |DownBlink |
---------------------
In other words, you divide the image into 'cells', each of the exact same width and height as the others. Then when you want to draw blinky in his left facing blink state, you can select the cell logically/mathematically like this:
tex_x = 0;
if(blinking_right_now) {tex_x = cell_width;}
//earlier you used 'FrameCounter' to specify a direction. I'll use that here:
tex_y = (FrameCounter / 2);
tex_y *= cell_height;
blitAlphaImageToScreen(tex_x, tex_y, 106, 72, BlinkyImage, BlinkyPosX, BlinkyPosY);
Make sense?

Also, I'd like to tell you about object-oriented-programming.
In the OOP model you make each object handle its own 'business'. For instance, in this case you have the objects: blinky, star, and bullet. Each one is handled by the procedural code.
What you could do is give each one a struct to hold its own properties:
typedef struct {
int x;
int y;
int facing;
int blink_counter;
Image* spritesheet;
} BlinkyObject;
Get the idea? All of the variables that deal directly with blinky himself are kept inside his struct. Then when you set up the scene you just:
BlinkyObject* blinky = (BlinkyObject*)malloc(sizeof(BlinkyObject));
if(blinky == NULL) {raise("Failed to allocate Blinky!");}
blinky->spritesheet = loadImage("./Images/Blinky.png");
if(blinky->spritesheet == NULL) {raise("Failed to load Blinky's image!");}
blinky->x = 170;
blinky->y = 170;
blinky->facing = 0;
Get the idea?
So why do this? Simple. Because then when you want to handle blinky's logic for the frame you can make a seperate function to handle it:
void updateBlinky(BlinkyObject* blinkyObj) {
if(pad.Lx < 50) { //'pad' should be global for this to work.
blinkyObj->x -= 4;
blinkyObj->facing = 2;
}
//etc...
}
If you write the code this way you can just have a few 'update' functions in your control loop that will handle all the logic. Also, say you wanted to modify the game so that there's more than one star on the screen at once. In the current code that would get messy, but if stars are just objects then all you have to do is make a new variable for a star object, set it up and call the update function on it once per frame. You can even have a different number of stars at once depending on difficulty and just use 'for' loops to set them all up and call their update functions, etc. It means the difference between spending two hours on the code and spending 10 minutes on the code.
Finally, getting used to OOP will prepare you to step into C++, which is basically C except with some upgrades and some neat goodies that make OOP much easier to do.
I'd recommend getting your game to work in its current incarnation, then trying out a spritesheet, and then rewriting it in an OOP flavor.
As always, any questions can be asked here.
You're doing well. I look forward to seeing your game.
