HomeForumsWhat's newResources 
 
 
Why doesn't this code work...
slinga - Jan 25, 2003
  slinga Jan 25, 2003
Why doesn't this code work...


  
	
	

		
		

			void makeGrid()



{



	char grid[15];



	Uint32 temp = 0;



	do{ 



 grid[temp] = "X";



 slPrint(grid[temp],slLocate(temp+1, 2));



 temp++;



	}while(temp<15);



}


I wanna display characters from the array. It doesn't work.

If I replace grid[temp] in slPrint with "AB" or something like that, it works....What happens now is that it displays blanks characters.

 antime Jan 26, 2003
Why doesn't this code work...

Well, there is at least one problem with your code: slPrint takes a pointer to a string as its second argument. However, you give it an element of a char array. Remember that in C, strings are null-terminated and that local variables are uninitialized so there's no telling what is in the array when you start. Also, in the assignment

Code: 
  
grid[temp] = "X";
you assign the address of a string constant to a char which gets truncated to 8 bits. Doesn't the compiler warn you about this? Try this:

Code: 
  
void makeGrid()

{

 char grid[16]; /* make room for the extra null char */

 Uint32 temp = 0;

 do{ 

  grid[temp] = 'X';

  grid[temp+1] = '\0'; /* make it a valid string */

  slPrint(&grid[temp],slLocate(temp+1, 2)); /* address of to make a pointer */

  temp++;

 } while(temp<15);

}
However, if all you're trying to do is print fifteen copies of the letter X in a row, why not do

Code: 
  
slPrint("XXXXXXXXXXXXXXX", slLocate(1, 2));
instead?

 slinga Jan 26, 2003
Why doesn't this code work...

Hmm yeah that codes works, but its going to give me problems later on. Is there anyway to display just a single character?

What I was trying to do was try and code a game similiar to snake. I've never done any game coding before so I was going to try and put everything in a double array of char. Start with the actual game grid, and go from there.

 antime Jan 26, 2003
Why doesn't this code work...

I don't really know SGL, but slPrint("X", slLocate(x, y)) should print a single X at the position (x,y). For a snake-type game you can store the positions currently occupied by the snake body in a 2D array, but unless you're doing a "Tron"-style game where the tail never moves you must also store the positions of the turns and their directions.

Also note that you only need to draw one character per update (two, if the tail moves), so a loop is unnecessary. Read the direction of the pad, check if that position is aldready occupied or outside the grid, if so -> game over. Else draw an "X" in that position and update the gamegrid. Repeat.

 vreuzon Jan 27, 2003
Why doesn't this code work...


  
	
	

		
		

			What I was trying to do was try and code a game similiar to snake


Great !

A text mode game is a good idea. How many players ?

Just one technical thing you have to know : the screen is NOT blanked between two slSynch(), so you have to erase it yourself.

You can find many snake sources everywhere. For instance

ftp://x2ftp.oulu.fi/pub/msdos/programming...src/ws...

 slinga Jan 27, 2003
Why doesn't this code work...

For now only one player, eventually though of course I'll make it multiplayer

I'm only doing it with characters because that's the only programming I know. I have no idea how to use graphics on the saturn (or on any system for that matter). I looked through your source code for Le Pin and it scares the crap out of me.

Another dumb question: How do you create your own classes in C? Or can you only create structs?

 antime Jan 27, 2003
Why doesn't this code work...

C doesn't feature classes. You can fake them by including function pointers in your structs, but you'll have to explicitly pass the "this" pointer.

I recommend getting a good book on C, Kernighan and Ritchie's book is still among the best.

(GCC also supports C++, but it isn't always trivial to get it working, and if you intend on using SGL/SBL and the Sega-supplied ancient compiler it can get rather.. interesting.)

 vreuzon Jan 28, 2003
Why doesn't this code work...

You do not need classes anyway.

In short (and according to me and my limited knowledge) you cannot program a console like you'ld program a computer.

Basically,

- you know the total amount of memory you can use, because all consoles of a same type are (about) the same and because there is no operating system, thus no memory sharing between apps.

- you know the velocity of the hardware, ie you cannot hope it'll be faster on newer machines (and malloc is slow).

As a result, you don't use malloc for console programming, but only fixed-size arrays. Classes in C++ heavily rely on the use of dynamical memory allocation; you may not find it beneficial to use it.

It is possible to use a class logic through. To illustrate antime's previous post, let's say we want a "Door" that you can paint. you could do like this :

Code: 
  
----------------- door.h

typedef struct _DOOR {

   ...       // some other attributes

   int color;

   ...

} DOOR

...  // some other methods

void door_setColor(DOOR* pDoor, int color);

----------------- door.c

#include "door.h"

...

void door_setColor(DOOR* pDoor, int color){

  pDoor->color = color;

}

...

----------------- main.c

#include "door.h"

#define MAX_DOOR 10

...

DOOR mydoor[MAX_DOOR];

void paintItBlack(){

  int i;

  for (i=0;i

Then what about inheritance, and such things ? I finally agree with antime: you can read a C book (or a good online tutorial).

 antime Jan 28, 2003
Why doesn't this code work...

There's nothing wrong with using C++, as long as you use it wisely and know which parts to avoid. Many of the features offered by C++ are compile-time features that incur no additional runtime cost. There are plenty of resources available on embedded C++ programming, they all apply for the Saturn as well.


  
	
	

		
		

			Originally posted by vreuzon@Jan. 28 2003, 5:55 pm



- you know the velocity of the hardware, ie you cannot hope it'll be faster on newer machines (and malloc is slow).



As a result, you don't use malloc for console programming, but only fixed-size arrays. Classes in C++ heavily rely on the use of dynamical memory allocation; you may not find it beneficial to use it.


If the malloc implementation you're using is slow, make your own. There are plenty of implementations available, suitable for different uses. Temporary objects in C++ are created on the stack, so allocating/deallocating memory for them only involves moving the stack pointer. There are also various methods to minimize the amount of temporaries created. Granted, many of these tricks and techniques require a level of knowledge of the language and compiler that most users don't possess, but there's a lot of info available on the net and in books.


  
	
	

		
		

			Then what about inheritance, and such things ?


You can manually create additional types, or use nested structures or something. Remember that Stroustrup's original C++ compiler in reality was a C++-to-C translator. Granted, the language was much simpler then but surprisingly much of C++ is still "syntactic sugar" that can be done manually (resulting in ugly, unmaintainable code). Here's... a quick example I found which illustrates the process.

 TakaIsSilly Jan 28, 2003
Why doesn't this code work...

Huh, speaking of Saturn-specific information, the malloc (altough more workable than I originally belived) is very limited. You can work only with around 256Kb of data of H-WORKRAM. Altough it's harder to maintain, a good programming rule is to have a document or (in my case) a piece of paper with "areas" you hardcode into the program... for example, if I wanted to keep a map of a snake game, I'd #define SNAKETABLE1 at the start of L-WORKRAM and gray out the needed space for a 20x20 table of char(800 bytes). Then you can:

Code: 
  
char *game_table;

game_table = (char*) SNAKETABLE1;

game_table[posx+20*posy]='X'; // An example of the table usage

(I don't code in C for 3 months, so pardon is there's any error)

Linked lists (for example, the worm/nibble is normally created as a linked list) is more dificult, but feasible, but i just wanted to make the note about usage of non-malloc memory reserving techniques...