Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mego]

I had a general question about C: How would one call functions from different source files? I've got a rough idea for a text-based dungeon crawler floating in my head, and it'd probably be much cleaner to keep things like monsters and loot in separate files.

There's multiple ways to do this. Like fergus said, you can toss all the function prototypes from a file into a header file and #include that, but there's a small gotcha involved. If that header file is included in multiple files in the project, when you go to compile, you'll get a lot of errors about multiple definitions of functions. The simplest workaround is this:

Code: (header.h) [Select]

#ifndef HEADER_H_INCLUDED // Guard word, typically made in the format of NAME_EXTENSION_INCLUDED
#define HEADER_H_INCLUDED

// function prototypes here

#endif

At your point in learning the language, you probably haven't learned much about preprocessor directives like #define and #ifndef, so I'll give you a quick explanation. When this file is included in one of the source files during compilation, it checks to see if the symbol HEADER_H_INCLUDED is defined. If it's not, it defines the symbol, and the rest of the code is included. The next time the compiler tries to include header.h, it sees that HEADER_H_INCLUDED is already defined, so it skips to the #endif at the end of the file. The function prototypes haven't been included in the compiled code again, so no errors.

[Gatleos]

If you could do a little tutorial, that'd be great.

Okay, how is the slope and box defined and how do you "move" an object?

It's all grid-based, with each node on the grid containing a shape. Each grid can contain a full square, a 1:1 slope (in all four directions), or either half of a 1:2 slope^[1] (in all four directions). The grid is used for a coarse collision check, looping through every node that an entity is touching and checking for a collision in that node. As a result, the engine already knows that the entity's AABB is intersecting the node's x and y axes by the time the fine collision detection function is used, so it only needs to check against the slope's axis after that. The objects on the map simply teleport to their new location based on speed every tick, then check for collision. I haven't gotten to the stage where I'm worrying about tunneling through small objects yet.

^[1] It could contain either of these (red is a collision):


Hope that was clear enough.

[malloc]

Oh, and to add a few extra notes to Mego's already good explanations.
First of all, you can call your guard words whatever you like. In the last project I worked in, we used this naming scheme:
__[First letter in Core Name][Module Name] so, for an example a header for mathematics could look like this __mQUATERNIONS. But yeah, it's just to illustrate that you can name them anything, as long as the naming is consistent. Also, adding underscores will generally keep them away from important code when using code suggestions. (Yes I am a big fan and user of intellisense)
Another thing you should remember when using headers is the guard word #pragma once.
Instead of writing:

Code: [Select]

#ifndef something
#define something
//Interface
#endif
You can write:

Code: [Select]

#pragma once
//Interface

The reason why it's smart to use this keyword is that major compiler actually are optimized to make use of the pragma once keyword. The #ifndef guard will make the compiler scan the file each time to find the #endif. Which, if the file is used in many other files, will slow down compilation.
#pragma once is however not a standard preprocessor directive, and some compilers will not support it. That is why you can, if you want, include both:

Code: [Select]

#pragma once
#ifndef something
#define something

//Here you put your interface.

#endif

This will keep the code portable, but still make use of the pragma keyword if the compiler supports it.


@Gatleos, I think simply adding the slopes max height to the object when it "stands" on a slope is probably the easiest solution with the setup you're using.
I don't really know what else to say, I just don't think I quite understand what you mean. Sorry!

[MorleyDev]

Galteos, how are you attempting the conflict resolution at the moment?

My first instinct would be to figure out the equation of the line between the centre of the object and the tile, figure out how much of that line falls within both the object and the 'red' part of the tile and then move the object along the line away from the tile by that much. Do this for either x iterations or until their is no overlap between that object and any red tiles.

[Gatleos]

@Gatleos, I think simply adding the slopes max height to the object when it "stands" on a slope is probably the easiest solution with the setup you're using.
I don't really know what else to say, I just don't think I quite understand what you mean. Sorry!

Really, all you need to know is that all moving objects are AABBs and I need them to detect collision with sloped surfaces properly. You didn't need that detailed explanation I gave.

Galteos, how are you attempting the conflict resolution at the moment?

My first instinct would be to figure out the overlap, figure out the equation of the line between the centre of the object and the tile, figure out how much of that line falls within the overlap and then move the object along the line away from the tile by that much. Do this for either x iterations or until their is no overlap between that object and any tiles.

The main problem is figuring out which axis to push the object out on. If it collides from the bottom, flat edge of the slope, I need it to push the object downward rather than teleporting it above onto the sloped part. I just can't find an efficient way to determine which side it collided from.

[MorleyDev]

The main problem is figuring out which axis to push the object out on. If it collides from the bottom, flat edge of the slope, I need it to push the object downward rather than teleporting it above onto the sloped part. I just can't find an efficient way to determine which side it collided from.

That should only happen with a sufficiently large time-step or fast object where the centre of the object goes past the centre of the tile. If your tiles are 32px wide and you're time step is 1/60th of a second (I assume your timestep for physics is fixed), then this would admittedly be a problem if you had an object moving at 480 pixels or more a second on full tiles and 16px on half-tiles.

You could have some sort of check against the direction of velocity or original position of the object to make sure the object hasn't gone past the centre?

[Nadaka]

Yes, you can use the vector of motion of the object, and its fairly simple math the reflect a vector off a flat surface.

[Sirus]

-stuff-

-more stuff-

I think I understood maybe 1 in 5 words. Don't worry about it, I've still got a long ways to go.

[Levi]

Yeesh.  Its crazy how much code I got to write just for infrastructure for this game, and there is still no end in sight.  This certainly has been an educational experience.  If I ever manage to finish I'll feel a lot more confident about building something more complex.   

[Mego]

Oh, and to add a few extra notes to Mego's already good explanations.
First of all, you can call your guard words whatever you like. In the last project I worked in, we used this naming scheme:
__[First letter in Core Name][Module Name] so, for an example a header for mathematics could look like this __mQUATERNIONS. But yeah, it's just to illustrate that you can name them anything, as long as the naming is consistent. Also, adding underscores will generally keep them away from important code when using code suggestions. (Yes I am a big fan and user of intellisense)
Another thing you should remember when using headers is the guard word #pragma once.
Instead of writing:

Code: [Select]

#ifndef something
#define something
//Interface
#endif
You can write:

Code: [Select]

#pragma once
//Interface

The reason why it's smart to use this keyword is that major compiler actually are optimized to make use of the pragma once keyword. The #ifndef guard will make the compiler scan the file each time to find the #endif. Which, if the file is used in many other files, will slow down compilation.
#pragma once is however not a standard preprocessor directive, and some compilers will not support it. That is why you can, if you want, include both:

Code: [Select]

#pragma once
#ifndef something
#define something

//Here you put your interface.

#endif

This will keep the code portable, but still make use of the pragma keyword if the compiler supports it.


@Gatleos, I think simply adding the slopes max height to the object when it "stands" on a slope is probably the easiest solution with the setup you're using.
I don't really know what else to say, I just don't think I quite understand what you mean. Sorry!

I stayed away from #pragma because it's not in the standard, so not all compilers will support it. If yours does, that's great, take advantage of what it can do. However, as you said, not all compilers support it, so I prefer to stick with the #define method, as that directive is in the standard.

Another way to solve the function-is-defined-elsewhere problem is to still have the function declared as normal in the file you're using it in, but prepend the declaration with extern. That will indicate to the compiler that the definition is in another file.

Code: (a.c) [Select]

#include <stdio.h>

void print(char* msg) {
    printf("%s\n", msg);
}


Code: (main.c) [Select]

extern void print(char*);

int main() {
    print("Hello, world!");
    return 0;
}

EDIT: Forgot to put "void" in the declaration in main.c.

[malloc]

Interesting, I did actually not know you could do that, but I think it makes a lot of sense. I usually use the extern keyword to make global objects, it's much better than using singletons in my opinion.

[Mego]

For global objects, I typically define them as static in a header file that gets included in every source file. I usually have a file called includes.h that includes all the other headers I create for a project, as well as defines global objects, and include that in every source file.

[MorleyDev]

For global objects, I typically define them as static in a header file that gets included in every source file. I usually have a file called includes.h that includes all the other headers I create for a project, as well as defines global objects, and include that in every source file.

Aren't statics unique to a translation unit? I thought in C (like C++) you declared global variables you want to cross source files as extern...

[Mego]

Statics are unique to a program, not to a translation unit. That's another way to avoid using guard words in header files: declare everything static.

[malloc]

I thought so too Morley.


It's funny Mego, I usually never bundle headers and global together, other than for the most basic and needed stuff.
(STL, openGL loaders, etc etc.)

I always try to make interfaces as clean as possible. If I can avoid it, I never include anything in my headers, so if I want one component, I can just include that one component, and I don't get anything extra. It is the basic c++ mindset, you should only get what you actually need/use.