Not that I'm any C/C++ dev, but aren't you not supposed to have an infinite loop?
Or use a while loop instead of a for loop for the infinite one like:
Code:while(1)
Printable View
Not that I'm any C/C++ dev, but aren't you not supposed to have an infinite loop?
Or use a while loop instead of a for loop for the infinite one like:
Code:while(1)
for(;;) is pratically the same as while(1) (although its unnoticablly faster apparently).Zitat:
Zitat von michaelp
-Aura
I'm thinking it could be this part of the code:Zitat:
Zitat von Auraomega
All it does is change the text color, try taking it out. Also, I find it useful to make a log of what the program is doing. Something like this:Code:colournum++;
if(colournum==50)
{
colour = rand()%0xFFFFFFFF+1;
pspDebugScreenSetTextColor(colour);
colournum=0;
}
for(;;) {
function
sprintf record of function
printf("blah");
sprintf record of printf
something else
make record
write records to file
}
This will tell you exactly when the program stopped working, and what functions it was able to complete before it stopped.
sprintf record of
The idea is for the colour to keep changing randomly, but I was having this error before I added that peice of code anyway :p
I had tried using PSPLink, but for some odd reason I didn't get any output what so ever, even though it must be passing the printf function a few hundred times. I'll probably get back to working on it, seeing if I can find the cause, whatever it may be...
-Aura
Edit:
Is there any way I can force someone to run my app in the 3.XX kernel, instead of in the 1.50 kernel? I know how to force the 1.50 kernel but there doesn't appear to be an option to force the other way.
How do you pause the XMB ? ( you will not be able to move in it , it stops playing the currunt music/video , screen stay paused)
Take a look at the SCEP plugin source, it should be there somewhere, seeing as it stops the entire XMB when you load up the menu.Zitat:
Zitat von hallo007
-Aura
Can't you just pause the current thread (the XMB) and start a new thread?Zitat:
Zitat von hallo007
Unfortunatly no, pausing the threads causes problems (or at least did for me), and theres more than just one thread that needs to be paused, theres some for the waves, others for the controls, etc... all makes it really unstable to do so that way.Zitat:
Zitat von Judas
-Aura
Edit:
Is it possible to load a file from the flash in game mode, loading my app appears to work fine if its loaded as a game, but when its loaded as vsh, it throws errors left right and centre, I only know of a few functions to load an app from flash, and none of them allow you to load them as a game...
Crap srry... Fixed lloll
I doubt that it would make it unstable. If you pause all of the ones related to the XMB (and probably more) then I think it would be fine.Zitat:
Zitat von Auraomega
I've tried it in the past, it led to constant crashes when trying to resume... but thats just for me, I may have done something wrong, its just my personal experiances in the past.Zitat:
Zitat von _dysfunctional
-Aura
Oh really? How so. Explain please :) .Zitat:
Zitat von Auraomega
The instruction in assembly is the same for the two. j, which jumps to an offset. Since there is no condition to check in either of the two I don't see how it is faster.
Either way, a for(; ;) loop should end up the same as while(1), which ends up similar to
Code:_00000000:
...
j _00000000
branch delay slot.
It depends on if the compiler is smart enough to realize that while(1) has no conditions to check for. If it is, then it will be the same speed as for(;;). However, if not, it will be checking to make sure that 1 is non-zero once a loop, which will add a one or two instruction slowdown. Actually, I guess in MIPS it won't make a difference because of the beqz command.
hot very go go !! good ??
for(;;) doesn't seem to work for me in some specific cases. Any comparison about the two of them to see if the differences are really apparent?Zitat:
Zitat von Archaemic
Hi, the program stops here because it cant copy config 1 to 2? Its running under 1.50 kernel and im on 3.71 M33. Im guessing this may be why but i dont know how to make it for 3.71. It can read config 1 jus fine and display the info.
I also set some parameters using sceUtilitySetNetParam() and created a new configuration using sceUtilityCreateNetParam( ). It comes out that that worked correctly yet there isnt a new connection on the list? Have made the application Kernel but putting 0x1000 in the PSP_MODULE_INFO. Is there anything i need to load before accessing the network configurations? My aim is to be able to produce a new connection on the list.Code:printf("\n\nCopying Configuration 1 to 2...");
if(sceUtilityCopyNetParam(1, 2) != 0)
{
printf("\nFailed To Copy Network Config 1 to 2");
return 1;
}
Using pspdisplay.h and graphics.h, can I load something that is bigger then the PSP screen itself (like 1000x272) that I can use as a scrolling background?
I tried, and the homebrew just froze.
You can load any size image, but you can only blit an image up to 512 x 512. So load your 100x272 image, but just blit a 512x272 section at a time.Zitat:
Zitat von MrChaos
Ah, I see. Thanks.Zitat:
Zitat von Judas
-= Double Post =-
Well, I'm confused again :P.Zitat:
Zitat von MrChaos
Heres my code:
blitAlphaImageToScreen(0, 0, 1000, 272, tutorial, 0, 0);
What argument do I use to blit it as a scrolling backgrond?
Note: I looked at the discription for the arguments, but I still don't understand.
You can only load an image of 512x512, anything more than this is destroyed at the loading stage... of course, its not hard to change this limit to something sensible, look for this peice of code around line 100 (103 for me, but I'm not sure of what changes I've made currently)...Zitat:
Zitat von MrChaos
Simply change the 512 limits to whatever you need (within reason).Code:if (width > 512 || height > 512) {
free(image);
fclose(fp);
png_destroy_read_struct(&png_ptr, png_infopp_NULL, png_infopp_NULL);
return NULL;
}
This allows a larger image to be loaded, but you will still need to adjust the blitting of that image to 480x272 chunks.
The crashing was due to the image not being loaded, not because it can't be blitted.
You would simply need to do...Zitat:
Zitat von MrChaos
blitAlphaImageToScreen(X, Y, 480, 272, tutorial, 0, 0);
where X and Y are the variables you change to move...
-Aura
Alright, I'm starting to get it now.Zitat:
Zitat von Auraomega
Last thing, anything I need to define to get your code to work, it's coming up with undeclared for: png_destroy_read_struct(& png_ptr, png_infopp_NULL, png_infopp_NULL);
and implicit declaration for free, fclose, and png_destroy_read_struct.
That code is specifically in the graphics.c file... you'll need to open graphics.c and edit it in that... if you can't find it in the one you are using I'll send you my copy (with pre-edited limits).Zitat:
Zitat von MrChaos
-Aura
Ah. Now I get it. I didn't understand what you ment by chaging 512 to what I needed, but now I do. I found it in graphics.c, and changed it to what I need.Zitat:
Zitat von Auraomega
You've been a great help, thanks.
wouldn't the X, and Y go on the other side? like this,
blitAlphaImageToScreen(0, 0, 480, 272, tutorial, X, Y);
I believe the other 0's are the offset of the image.
Exactly, you need to change the offset position you read from otherwise the image will move onscreen... its hard to understand but what you've done will move its position on screen, the original way moved its position before it was read, and blitted it to screen...Zitat:
Zitat von BlackShark
*Sigh* I really explained that well didn't I :humped:
Just trust me I guess for this one :p
-Aura
O, i thought moving its positions on screen was what he wanted, and you did explain pretty well :P
I changed it:Zitat:
Zitat von Auraomega
blitAlphaImageToScreen(BG PosX, 0, 1000, 272, tutorial, 0, 0);
(And when you move:
if (pad.Buttons & PSP_CTRL_LEFT)
{
StanPosX -= 2;
BGPosX += 2;
}
if (pad.Buttons & PSP_CTRL_RIGHT)
{
StanPosX += 2;
BGPosX -= 2;
}
)
But, it still doesn't scroll the screen. However, it does show up now.
alright, well try what i did, and put BGPosX at the end like
blitAlphaImageToScreen(0, 0, 1000, 272, tutorial, BGPosX, 0);
also get rid of StanPosX, you shouldn't need it when moving the background.
I think StanPosX is the position of the character or something.
I tried it the way you told me to, and it worked.Zitat:
Zitat von BlackShark
Thanks.
kewl
Glad it all worked out well :)
I'm having a major problem with my app, its supposed to be flashed, but whenever I flash it I get errors galore. I've found that the probable cause is the use of PSP_HEAP_SIZE_KB, as this seems to impede the loading of some files from the memstick, but equally, I NEED that macro to load images, otherwise there isn't enough memory to load the amount I require.
I have originally been using PSPLink, and reset vsh, followed by the .prx, this is going nicely, but when I actually flash it I get these errors, I've also noticed that I don't get these errors when loading it from the XMB, so, my idea is either to change the heap size once the config file has been read, which I doubt is actually possible, or, to make a loader, so it loads my app the same way the XMB would.
The loading seems more fesible, but I've failed in actually getting it to load correctly, so does anyone know a way it can be done?
-Aura
Wtf? I just tried my app again, and the background scrolling image is sopposed to be a black line, with black grass on it, like somebody drew it. Only the line appears on the screen. I even went in paint and scribblied all over the screen, and it STILL does'nt display.
Know what's wrong?
(Sorry to intrupt you, Auromega.)
No problem (but the names Auraomega :p)Zitat:
Zitat von MrChaos
Sounds an odd bug, can you blit images like normal, or are all images going odd? Also, did you make sure that the image wasn't interlaced, even though I don't think its possible with paint, worth a check. Finally, make sure you didn't blit it in the wrong place, or blit anything over the top of it. Maybe you could upload the image?
-Aura
Oh, sorry. :pZitat:
Zitat von Auraomega
I double checked the image, it's blitted fine and everything.
Here, i hosted it on imageshack:
http://img441.imageshack.us/my.php?i...ialcopyxk8.png
Heres the order I'm blitting it in (the image is tutorial):
blitAlphaImageToScreen(BG PosX, 0, 1000, 272, tutorial, 0, 0);
blitAlphaImageToScreen(0, 0, 100, 100, sun, 0, 0);
blitAlphaImageToScreen(0, 0, 100, 100, Stan[0], StanPosX, StanPosY);
Sorted, the image is dodgy, but instead of trying to fix it, simply change your blit function to...Zitat:
Zitat von MrChaos
blitImageToScreen
Worked fine for me :tup:
-Aura
Yep, that did it.Zitat:
Zitat von Auraomega
Thanks.
i've got a little problem;
my top 10 pixels of the screen keep flikkering when i print text on it.
for example:
the only Hello World flikkers, not "menu option 1/2/3"Code://first initializing of the graphics, controls, callbacks etc.
for(;;)
{
initGraphics();
clearScreen(RGB(0,0,0));
printTextScreen(0,0,"Hello World", Red);
printTextScreen(150, arrowYaxis, "=>",Red);
printTextScreen(170, 140, "MenuOption1",White);
printTextScreen(170, 150, "MenuOption2",White);
printTextScreen(170, 160, "MenuOption3",White);
sceCtrlReadBufferPositive(&pad, 1);
sceDisplayWaitVblankStart();
flipScreen();
//Controls!! etc.
what the hell did I do wrong? (maby my psp a bit f*cked up) or is there a way to fix this.
EDIT: Bad Example, new one posted
EDIT 2:
is there any way of printing variabels and strings using the "printToScreen"-command?
Not actually looked at it, but I'm assuming the fact you are going through that loop so many times is causing that, you don't need the loop, remove it and you will see the same as normal (minus the flickering), if thats not the cause, then it may be because you keep initiating the graphics...
should work much better.Code://first initializing of the graphics, controls, callbacks etc.
initGraphics();
clearScreen(RGB(0,0,0));
printTextScreen(0,0,"Hello World", Red);
printTextScreen(150, arrowYaxis, "=>",Red);
printTextScreen(170, 140, "MenuOption1",White);
printTextScreen(170, 150, "MenuOption2",White);
printTextScreen(170, 160, "MenuOption3",White);
sceCtrlReadBufferPositive(&pad, 1);
//sceDisplayWaitVblankStart();
flipScreen();
for(;;)
{
//Controls!! etc.
}
2nd, you need to use sprintf or something along those lines... such as
Hope thats of some help.Code:char str[256];
sprintf(str, "%d out of %d", score, total);
printToScreen(150, 150, str, 0xFFFFFFFF);
flipScreen();
-Aura
Thanks you very much Auraomega :Jump: :Jump:
you fixed both of my problems ;)
the "flikkering" problem was caused by the initializing of the Graphics :)
But thiscouldn't work.. because this a menu, and when you 'press' up or down the arrow wil move up or down.. and if you remove the loop it doesn't update the arrow anymore. but thanks anyway :)Code://first initializing of the graphics, controls, callbacks etc.
initGraphics();
clearScreen(RGB(0,0,0));
printTextScreen(0,0,"Hello World", Red);
printTextScreen(150, arrowYaxis, "=>",Red);
printTextScreen(170, 140, "MenuOption1",White);
printTextScreen(170, 150, "MenuOption2",White);
printTextScreen(170, 160, "MenuOption3",White);
sceCtrlReadBufferPositive(&pad, 1);
//sceDisplayWaitVblankStart();
flipScreen();
for(;;)
{
//Controls!! etc.
}