More Weird Stuff From the Saturn

slinga

Established Member
else

{

int temp;

// Displays all the saves on the screen

for(temp = 0; temp<numSaves; temp++)

{

slPrint(saves[temp].filename, slLocate(5, temp+12));

slPrintHex(saves[temp].blocksize, slLocate(20, temp+12));

}

}


Gives me SH2 errors and crashes.

else

{

int temp;

// Displays all the saves on the screen

for(temp = 0; temp<numSaves; temp++)

{

slPrint(saves[temp].filename, slLocate(5, temp+12));

slPrintHex(saves[temp].blocksize, slLocate(20, temp+13));

}

}


Displays on the screen without crashing, except I want the information on one line. I'm guessing the problem is with saves[temp].filename, which is a 11 character array. I think the saturn isn't terminating it properly. Any suggestions?

It seems to be causing other problems as well. After I display the save, I prompt the user to hit start. That doesn't work, yet it's the same exact function I've called before and it works, so I know the press start function works. Hmmm....
 
Oh yeah I forgot to mention, I'm trying to print out the saves from memory in the following format:

Save_Game_01 Game_Size
 
Code:
else

  {

   int temp;

   // Displays all the saves on the screen

   for(temp = 0; temp   {

    slPrint(saves[temp].filename, slLocate(5, temp+12)); 

    slPrintHex(saves[temp].blocksize, slLocate(20, temp+12));

   }

  }

I'm impressed the code actually compiles. The for tag doesn't close, it should be in the format :

Code:
for (temp = 0; temp < ???; temp++){

(...)

}

where ??? is the number of interactions (er, memory saves) you want to display.

SGL terminates all arrays with null characters, so that's not the problem as well.
 
Slinga's post is messed up because he used "QUOTE" instead of "CODE" and that apparently triggers a bug in the message board software. The actual code is

Code:
else

{

  int temp;

  // Displays all the saves on the screen

  for(temp = 0; temp<numSaves; temp++)

  {

    slPrint(saves[temp].filename, slLocate(5, temp+12)); 

    slPrintHex(saves[temp].blocksize, slLocate(20, temp+12));

  }

}
and

Code:
else

{

  int temp;

  // Displays all the saves on the screen

  for(temp = 0; temp<numSaves; temp++)

  {

    slPrint(saves[temp].filename, slLocate(5, temp+12)); 

    slPrintHex(saves[temp].blocksize, slLocate(20, temp+13));

  }

}
 
I don't think the slLocate is the problem. If I were you, i'd take a closer look at the size of your "saves" array. The compiler won't detect an out of range indix, wich is known to cause random crashes (depending on what is stored in memory next to the array).

Note that the random crash will sometime seem to be reproductible, but will probably change if you add some code, even with no visible connexion.

If you fail in finding the error, you can send the array definition and accesses here.
 
You guys were right.

I changed my array declaration from:

Code:
BupDir* saves;

to

Code:
BupDir saves[8];

and it appears to work now. I can print out everything I want on one line, I can return to the main menu, and no crashes. I still don't understand why it was crashing in the first place. Perhaps I was overwriting memory I needed? I would of perferred to allocate memory dynamically, who knows how many saves a person can have on their backup memory cart, but I guess I can leave this for now. I'll probably increase the array size when the program is complete.
 
The first form is a pointer declaration, not an array declaration. There is no space reserved for the data. If you want to use dynamic allocation you must use something like
Code:
BupDir *saves;

saves = malloc(numSaves*sizeof(BupDir));

if (saves == NULL)

{

  /* allocation failed */

}

else

{

  /* whatever */

  free(saves);

}
 
We've been through this before, and blanket statements like that are still silly. If dynamic allocation is the appropriate tool, use it. If the malloc implementation is too slow or otherwise unsuitable for you, change it. There are plenty fast algorithms to use. Also, sooner or later you'll have to use dynamic allocation no matter what (texture allocation, display list management, sound memory allocation etc.).
 
You're right. Altough I disagree on the need to dynamically allocate (that's why separate work/video/sound memory is there for), the argument about this is getting old and I'll avoid mentioning it again. I do tend to sound like a smartass, so be free to warn me of that :)
 
You'll still have to dynamically manage things within the separate memories, eg. the textures and display lists in VDP1 RAM.
 
Back
Top