Problem porting a game from PC to PSP

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
memon
Posts: 63
Joined: Mon Oct 03, 2005 10:51 pm

Problem porting a game from PC to PSP

Post by memon »

Hi,

I've been trying to port one of my games to PSP lately, but I ran into a weird crash which does not really make any sense at all.

Code: Select all

int FindClosestEdge(const Vec3& pos, float maxDist, Vec3& outPos)
{
	int		bestIdx = UNDEF_IDX;
	float	bestDistSqr = FLT_MAX;
	float	maxDistSqr = sqr(maxDist);
	Vec3	bestPos;
	Vec3	out;

	for&#40;size_t i = 0; i < m_edges.size&#40;&#41;; i++&#41;
	&#123;
		if&#40;m_edges&#91;i&#93;.type == 0&#41;
			continue;
		float	distSqr = DistanceSqrToLine&#40;pos, m_verts&#91;m_edges&#91;i&#93;.va&#93;, m_verts&#91;m_edges&#91;i&#93;.vb&#93;, out&#41;;
		if&#40;distSqr < maxDistSqr && distSqr < bestDistSqr&#41;
		&#123;
			// IT CRASHES HERE...
			bestDistSqr = distSqr;
			bestIdx = &#40;int&#41;i;
			bestPos = out;
		&#125;
	&#125;
	outPos = bestPos;
	return bestIdx;
&#125;
Basically the code crashes when it tries to store some data to a varialbe which is in stack. At least that is my hypothesis. All the data is fine, if I just loop through the list and print the numbers on screen everything is just fine. The call stack is no more than 4-5 functions deep.

My question is... how should I start debugging this thing? Is there some stuff which I can use to keep track of my stack & heap usage? Or any other educated guesses what might cause that even if the amount of information is very limited here?

And the crash... it just hangs and eventually psp shutsdown itself.


--mikko
ooPo
Site Admin
Posts: 2023
Joined: Sat Jan 17, 2004 9:56 am
Location: Canada
Contact:

Post by ooPo »

Code: Select all

if&#40;distSqr < maxDistSqr && distSqr < bestDistSqr&#41;
That looks very odd. Are you sure it ever worked? Try this:

Code: Select all

if&#40;&#40;distSqr < maxDistSqr&#41; && &#40;distSqr < bestDistSqr&#41;&#41;
memon
Posts: 63
Joined: Mon Oct 03, 2005 10:51 pm

Post by memon »

Yep, it returns correct results on my pc version and comparison operators have higher precedense (executed first) than logic ops.
http://www.cppreference.com/operator_precedence.html
The place where the C operator precedense usually gets hairy when you need to mask and shift, since shift has higher precedence than bitwise and and or. Example:

Code: Select all

int a = b & 0xff << 8;
vs.
int a = &#40;b & 0xff&#41; << 8;
Anyway... that should not cause the crash, though. Actually if I just comment out the contents of the if block it does not crash.

And any further use of the result from that function is not used at the moment. That is, the program returns back to main menu. And that works if I comment out the block of code that stores the result.
User avatar
dot_blank
Posts: 498
Joined: Wed Sep 28, 2005 8:47 am
Location: Brasil

Post by dot_blank »

why use this

Code: Select all

for&#40;size_t i = 0; i < m_edges.size&#40;&#41;; i++&#41; 
when you should use this

Code: Select all

size_t i;
for&#40;i = 0; i < m_edges.size&#40;&#41;; i++&#41;
10011011 00101010 11010111 10001001 10111010
ufoz
Posts: 86
Joined: Thu Nov 10, 2005 2:36 am
Location: Tokyo
Contact:

Post by ufoz »

dot_blank wrote:why use this

Code: Select all

for&#40;size_t i = 0; i < m_edges.size&#40;&#41;; i++&#41; 
when you should use this

Code: Select all

size_t i;
for&#40;i = 0; i < m_edges.size&#40;&#41;; i++&#41;
um, because the first is the cleaner and accepted way to do loops in c++ when you don't need the loop variable later on? that part is perfectly fine.

with weird crash bugs like these, for me, it's usually some other part of the code with messy pointer handling or a buffer overrun or somesuch, screwing up the memory enough to have it crash in unexpected locations, your code looks fine.
User avatar
dot_blank
Posts: 498
Joined: Wed Sep 28, 2005 8:47 am
Location: Brasil

Post by dot_blank »

yes i understand its standard in C++ but code looked
like standard C ....my bad if that wasnt clear
10011011 00101010 11010111 10001001 10111010
ooPo
Site Admin
Posts: 2023
Joined: Sat Jan 17, 2004 9:56 am
Location: Canada
Contact:

Re: Problem porting a game from PC to PSP

Post by ooPo »

memon wrote: Vec3 bestPos;

(and later on...)

bestPos = out;
How is Vec3 defined? And under what compiler/os does this code work?
memon
Posts: 63
Joined: Mon Oct 03, 2005 10:51 pm

Post by memon »

The code is indeed C++ (I think that const reference would have been a good clue ;)). The Vec3 is a class and that code works well under VC7 and GCC. The same vector class is used in code which I can verify working.

I suspected bad pointers at first too. I have douple checked a lot of code to make sure that does not happen (cannot be 100% sure of course). I use STL containers alot so there should not be that much the normal pointer mishaps. Bad pointers usually make the stuff to crash when trying to read or write beyond valid range, but this thing just hangs which makes me think that it might be something else.

Still, I would like to first verify the heap and stack usage. Any pointers to that stuff?
ector
Posts: 195
Joined: Thu May 12, 2005 10:22 pm

Post by ector »

Maybe you're accidentally declaring some brutally huge variables on the stack in the function tree that is calling this function? Maybe you passed in a too small value for stack size when you created the thread that's running this?
http://www.dtek.chalmers.se/~tronic/PSPTexTool.zip Free texture converter for PSP with source. More to come.
memon
Posts: 63
Joined: Mon Oct 03, 2005 10:51 pm

Post by memon »

ector, Where do I define the stack size? I tried to look around but could not really found anything. My entrypoint of the code is pretty much based on the cube sample. I dont create any extra threads in my program.

The another thing is how do I keep track of my stack? Is there some variable or function I can use to get the current stack size?
User avatar
dot_blank
Posts: 498
Joined: Wed Sep 28, 2005 8:47 am
Location: Brasil

Post by dot_blank »

Code: Select all

int sceKernelGetThreadStackFreeSize &#40; SceUID thid &#41;;
//Get the free stack size for a thread.

/* Define the main thread's stack size &#40;optional&#41; */
/** 
 * ELF&#58;
 * Elf default stack size is &#40;256K&#41;
 *
 * PRX&#58;
 * PRX default stack size is &#40;256K&#41;
 *	
 * Example Below&#58; smaller stack for kernel 
 *                thread for 1.0 psp &#40;32K&#41;
 */
PSP_MAIN_THREAD_STACK_SIZE_KB&#40;32&#41;;
const does not tell me much as that can be used in C
hope maybe the above helps you a bit :P
10011011 00101010 11010111 10001001 10111010
PlayfulPuppy
Posts: 22
Joined: Fri May 05, 2006 12:04 am

Post by PlayfulPuppy »

Is the crash precisely where that comment is (Either during or just after the square root test block) or is it somewhere within that block? I'm assuming the latter at the moment.

Although I'm fairly sure I'm wrong about this, I have my eye on the int cast you're doing there. I've had troubles before when casting between types of different sizes (I'm not too sure how big a size_t is on the PSP, it may be 8 bytes or it might be 4), but in my experience that's only ever been when trying to cast pointers that aren't aligned properly, so it's a long shot at best.

Still, humor both me and you and try commenting out that line (And, one by one, the ones surrounding it) to see if you can get it to pass that section.

Finally, do you have any copy consructors or overloaded assignment operators for Vec3? If so, the problem might be occuring in there.
memon
Posts: 63
Joined: Mon Oct 03, 2005 10:51 pm

Post by memon »

Thanks for the replies. After a bit a twiddling yesterday I got another crash. This time it was floating point exception. I think it is time to install that psplink :)

I think I will still try to check that stack usage too. The code crashed if I had any assignment inside the if.
CyberBill
Posts: 86
Joined: Tue Jul 26, 2005 3:53 pm
Location: Redmond, WA

Post by CyberBill »

Ahh yes, the PSP will hang when it hits floating point exceptions, where as PC will just continue on and put a value like #INF or 0 in its place.

Ensure that you arnt doing any divide by 0s, or any overflows or underflows. To really stress your code, use something like this:

Code: Select all

float intToFloat&#40;unsigned i&#41;
&#123;
   return *&#40;float*&#41;&i;
&#125;

for&#40;int i=0; i<=0xFFFFFFFF; i++&#41;
  for&#40;int j=0; j<=0xFFFFFFFF; j++&#41;
    for&#40;int k=0; k<=0xFFFFFFFF; k++&#41;
    &#123;
       Vec3f bruteVector&#40; intToFloat&#40;i&#41;, intToFloat&#40;j&#41;, intToFloat&#40;k&#41; &#41;;
       DistanceSqrToLine&#40; bruteVector, m_verts... blah blah blah &#41;;
    &#125;
Anyways, you get the idea. ;) On the PSP that'll pretty much always crash... you might want to put checks for NAN in intToFloat() to instead return 0 in those cases.... just a thought! :)

-Bill
User avatar
groepaz
Posts: 305
Joined: Thu Sep 01, 2005 7:44 am
Contact:

Post by groepaz »

you can disable the floatingpoint exceptions. (i dont recall how though, but it was answered in the forum at some point, searching should help :))
CyberBill
Posts: 86
Joined: Tue Jul 26, 2005 3:53 pm
Location: Redmond, WA

Post by CyberBill »

Dont disable exceptions....

Its more complicated and a bigger pain in the ass to worry about your game objects having #INF or #NAN values than it is to just fix the algorithms that make them creep in in the first place.
memon
Posts: 63
Joined: Mon Oct 03, 2005 10:51 pm

Post by memon »

I think I'll try to keep them enabled then. Any pointers to articles of good floating point practices? The new features in psplink sound promising too regarding my debugging needs... I think it's going to be interesting weekend then :)
ector
Posts: 195
Joined: Thu May 12, 2005 10:22 pm

Post by ector »

If you prefer to do your debugging on PC, you can just enable floating point exceptions on the PC instead (they're disabled by default) and do your debugging there...
http://www.dtek.chalmers.se/~tronic/PSPTexTool.zip Free texture converter for PSP with source. More to come.
Post Reply