HomeForumsWhat's newResources 
 
 
More Weird Stuff From the Saturn
slinga - Apr 1, 2003
  slinga Apr 1, 2003

  
	
	

		
		

			 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));



   }



  }


Gives me SH2 errors and crashes.


  
	
	

		
		

			 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+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....

 slinga Apr 1, 2003
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

 TakaIsSilly Apr 2, 2003
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.

 antime Apr 2, 2003
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
and

Code: 
  
else

{

  int temp;

  // Displays all the saves on the screen

  for(temp = 0; temp

  vreuzon Apr 2, 2003
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.

 slinga Apr 3, 2003
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.

 antime Apr 3, 2003
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);

}

  TakaIsSilly Apr 3, 2003
Actually, you shouldn't use malloc() on the Saturn, but I suppose that for simple stuff like that it's all right.

 antime Apr 3, 2003
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.).

 TakaIsSilly Apr 3, 2003
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

 antime Apr 3, 2003
You'll still have to dynamically manage things within the separate memories, eg. the textures and display lists in VDP1 RAM.