Valid C

[Sauer2]

Since I'm a beginner with C, is this a valid header?

[alapshin]

Yes, I think it is ok.. Only coding style comments, if you want..

[Sauer2]

Thank you, why not?

[alapshin]

Changes I may advise (it is just a coding style, so no errors from your side):
1. #ifndef Miscellaneous_H -> #ifndef MISCELLANEOUS_H (Usually all defines are written in capital letters)
2. All #define directives at the top if these are constants
3. const modifier is preferrable than #define for constants since it defines type directly, no chances to cheat for compiler.
4. Use enums for constants. For example:

enum CloudType
{
SMALL = 0,
MEDIUM,
BIG
}

struct Cloud{
CloudType Type;
int XPosition;
int YPosition;
}

I think this way increases readability of the code. "Magic" consts is not a good practice.
5. After #endif usually there is something like "//MISCELLANEOUS_H" (this helps when there are nested ifdefs)

[Sauer2]

Cool, thanks. Only one problem left: In Case I don't put a ';' behind the structures, the compiler gives me an error.

{l Code}: {l Select All Code}

two or more data types in declaration specifiers


EDIT: I also get

{l Code}: {l Select All Code}

expected specifier-qualifier-list before ‘CloudType’

from the enumerations.

[alapshin]

Sorry, I forgot ";" after enum.. I did not try to compile this..

[Sauer2]

Something's still fishy...I get the last one even if I have ";" set.

[alapshin]

";" after structs are also needed.
The following code was compiled well with gcc:

enum CloudType
{
S = 0,
M,
B
};

struct Cloud{
CloudType Type; /*0 is small, 1 is medium, 2 is big*/
int XPosition;
int YPosition;
};

int main()
{
return 0;
}

[Sauer2]

Hmm, still doesn't work, strange... Also I tried adding 'typedef' in front of struct. I always get the second message.

Anyway, thank you for the tipps. I'm gonna try this further tomorrow.

EDIT: I got it working, surprisingly. there was enum in front of CloudType Cloud missing.

[Sauer2]

Another Problem: I have a function loadImage that looks like this:

{l Code}: {l Select All Code}

SDL_Surface* LoadImage(char *file) {
  SDL_Surface *tmp;
  tmp = IMG_Load(file);
 
  if (!tmp) {
    fprintf(stderr, "Error: '%s' could not be opened: %s\n", file, IMG_GetError());
    exit(1);
    return NULL;
  }   
  return tmp;
}

In case I try to load an Image like this:

SDL_Surface playerImage = loadImage("player.png");

i get:

error: invalid initializer

[Sauer2]

Sorry, that was just some pointer stuff i forgot. (the function gives back a pointer)

Slowly, I realize why THEY hate C...

[Sauer2]

Does someone know a simple game written in C using SDL? There are some things I'd like to study from another game...
BTW: Why ain't there a question icon similar to this...

icon_question.png (657 Bytes) Viewed 24176 times

?

[Sauer2]

Ok, I have another question for someone familar with C. For the "Falling" game, i want to make own c files and header files for clouds and birds. But what about the variables like the lists and the surfaces I want to put there? Do they need to be global variables or is there a special C trick? If they need to be globals, can I make them read- and write-only from the file they are from?
I'd like to make some kind of Getter/Setter system.


Also: Is it enough to include SDL, etc. in the main file?

Thanks and best regards

Sauer2

[qubodup]

It might be simpler, if you had the code on-line in a repository so that people can take a look at how you structure your code currently. I would recommend it over tarballs.

I can only recommend http://github.com . If you can figure out how to install git on your system, it will be easy to use, as the basic 2-3 commands are shown so that you can start a repository there.

[Sauer2]

Done, the repository's name is 'falling'.

[qubodup]

Done, the repository's name is 'falling'.

................. link?

[Sauer2]

Sorry, heh.

http://github.com/Sauer2/falling

[qubodup]

http://github.com/Sauer2/falling

Well, this compiles for me on arch linux 64bit without problems.

[Sauer2]

...because I didn't change many things yet (loading images was optimized by converting them to display format).

[Sauer2]

Hm, I have a problem here. I restructured the code and put the cloud blitting procedure into 'clouds.c', also I did this with the global pointer to the cloud images.

Now the clouds are not blitted anymore. Someone knows why?

[dusted]

I'm using this method instead of global variables, it works well across multiple files, and I'm fairly sure the function call is optimized out, basically, I have a struct of stuff that I find convinient to have available globally.
I've not checked the assembly output from using this method, but I suspect that there are very few cycles eaten by the pointer dereferencing.

Here's an example:

globalstuff.h:

{l Code}: {l Select All Code}

struct global_s
{
  //global things..
  int somethingGlobal; //A global int
};
typedef struct global_s global_t;

//Function returns pointer to the global struct.
inline global_t getGlobal();

globalstuff.c:

{l Code}: {l Select All Code}

#include "globalstuff.h"

//declare the struct
global_t theActualStruct;

inline global_t getGlobal()
{
  //Return the pointer to the struct (notice the & )
  return( &theActualStruct );
}

Really simple, now for usage, in ANY file that I need to access the global variables:

whateverfile.c

{l Code}: {l Select All Code}

#include "global.h" //Include the header

void whatEverFunctionNeedsAccessToGlobal()
{
  getGlobal()->somethingGlobal=10; //access the struct member
  printf("The value of the int somethingGlobal is %i\n", getGlobal()->somethingGlobal);
}

[Sauer2]

No offense, but isn't that just global variables/structures (still without any function structure around) in their own file with some kind of getter/setter giving their pointer?

Edit: BTW, I know, I'm tired and stuff, but the = instead of == wasn't the source of the problem.

[Sauer2]

Yay, 'merging clouds' is working. But I think, there better not be 3 Layers of it, performance and stuff..

[dusted]

Yes, that is exactly what it is But with the ability to have the same "instance" of the data shared between multiple files, without the oddities that comes with using the extern keyword.

[Sauer2]

That was what i planned in case b. Thank you, though.