Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Jun 2011
Offline Last Active Yesterday, 09:34 AM

#5114803 A newbie question

Posted by __SKYe on 06 December 2013 - 12:49 AM

I don't (and never did) work at a game company before, and i'm sure others who did can answer this much better than me, but the companies that you're talking about, that invest millions, they have, literally, hundreds of people working on a single game (you have programmers, artists, 3d modelers, animators, designers, script writers, audio editors, voice actors, game testers, marketing staff, business staff, etc), during the spawn of years, as some games take a year to be finished, others take as much as 10 years (games like Skyrim (even though it didn't take 10 years, it still took a long development time compared to annualy games), Starcraft 2, Diablo 3, etc).


Then, even though i'm not familiar with it, i'd assume that maintaining a studio of this magnitude (game company, or at least a branch) is costly, even without the game specific staff (things like office maintenance, R&D (i think of R&D here, as researching and developing the technology used for future games/engines, as oposed to direct development of a specific game, though if i'm wrong, please correct me).


Like i said i'm no expert in this but i think you can get an idea of how costly it is to run a business this big.


Hope it helps.

#5108578 writing 3D Model data to the game executable?

Posted by __SKYe on 11 November 2013 - 07:04 PM

One way to do it is to declare the 3D model data (vertices, normals, texture coordinates, etc) as variables inside the code.


Now, i don't know if you just want to know if it's possible, and if you even care about what i'll tell you, but you should never do something like that.

This may be okay for icons, but you should always separate your code (program) from your data (graphics, sounds, 3D models, etc).

#5090885 what textures to use filtering on?

Posted by __SKYe on 01 September 2013 - 04:11 PM

Assuming, I'm not misunderstanding your question and you want to use something like diffuse texture + normal map (and maybe a bump map), I'd say that a problem could arise if the normal map is much smaller than the diffuse texture, since if could convey incorrect vertex normals due to sampling.


In my opinion, if you don't see a difference, then use linear filtering, since it's the least expensive.


Hope it helps.

#5090880 Vsync with GLee

Posted by __SKYe on 01 September 2013 - 04:01 PM

Have you tried enabling VSync after creating the window (on GLUT i think it was called glutCreateWindow(), not sure though), if it was not created before?


I've never actually tried to having VSync enabled at startup, i only had it possible to enable it by pressing a key.

#5076280 How to tell if a context has been created?

Posted by __SKYe on 08 July 2013 - 10:16 PM

If you use GLEW, you can type:

//Initialize GLEW
if(glewInit() != GLEW_OK)
    //On failure

If this fails, then normally, the context has yet to be created.


Another way, is to call


If the context has yet to be created, then it will always return GL_INVALID_OPERATION (1282).

Note, however that multiple errors issued by OpenGL calls are saved by OpenGL, so the spec says that glGetError() should always be called in a loop, until it returns GL_NO_ERROR.

Since other OpenGL calls may have triggered an invalid operation, to be sure, you could call glGetError() a large number of times in a row (1000 maybe?), and if the last return value is still GL_INVALID_OPERATION, then you know the context is not created.


Hope it helps.

#5076278 Managing objects in different game states

Posted by __SKYe on 08 July 2013 - 09:58 PM

I think it is simpler to have a single ObjectManager class that manages all objects, and every state adds it's objects to that manager.

Each state should be, however, responsible for adding it's objects to the manager when it is created, and removing then when it is destroyed. In other words the global ObjectManager doesn't have to keep checking which objects are no longer needed.


L. Spiro has a very good article about managing game state (among other things), if you're interested: http://lspiroengine.com/?p=351


About your off-topic question:


If, when you say the entity is "dead", you're referring to something like, an enemy entity was just killed and has no purpose left in the game, then i'd say removing it from the ObjectManager is a good option, simply because it's one less update call the ObjectManager must make.

However, if the ObjectManager has to check for a variable to know if the object needs to be updated, then, on top of doing the same thing the above option does (issuing update calls), it will still have to execute a branching instruction for every entity (including the ones that are not updated), so it would be slower.


Note that this, however, probably won't even be noticed, with the speed of processors nowadays.


Hope it helps, and sorry if i misunderstood the question(s).

#5071548 Loading level information based on a parameter

Posted by __SKYe on 20 June 2013 - 01:10 PM

That's great you understood it.

Also if you need help with binary files, i can help too, they aren't that much harder than text files.


I have one final piece of advice, although it wasn't solicited.

Although binary files have the advantages of being more efficient in terms of speed and space, keep in mind that text files are much easier to edit by hand (which you'll probably do unless you make some level/map editor).

So perhaps during development, unless you build a custom level/map editor that creates the binary files automatically, you may want to use text file, for the easiness of use.


Good luck!

#5071457 Scale up an object on a plane

Posted by __SKYe on 20 June 2013 - 08:07 AM

You'll have to scale it and then translate (move) it in the direction of the plane's normal by some amount.

//You must know the distance (for each axis) from the center point of your object (it's origin) and the point that touches the plane
//I'll call this distance, and put some random value
vec3 distance = (0.0f, 3.0f, 0.0f);

//In this example the object is at the center of the world, but move up in the Y axis by 3.0.
//Now do the scaling (remember scaling by 1.0 means staying the same)
//We're just scaling in the Y axis
glScalef(1.0f, 2.0f, 1.0f);

//Calculate the amount to translate the object
vec3 move;

//The <scale.X>, etc are the values passed to glScalef()
//We subtract 1.0f from the scale value, again because 1.0f  is the starting value (identity).
move.x = distance.x * (<scale.x> - 1.0f);
move.y = distance.y * (<scale.y> - 1.0f);
move.z = distance.z * (<scale.z> - 1.0f);

//Translate the object
glTranslatef(move.x, move.y, move.z);

Hope you understand (and that it is correct... i think so),

#5071415 Trading Hits

Posted by __SKYe on 20 June 2013 - 05:51 AM

Well, i think a good option is the one you described, you could do all the collision tests between the players, and instead of executing the consequences of any collision immediately after any collision happens, just save the result of whether none, one or both players where hit, and execute whatever action at the end of all collision tests.




Player 1 punches player 2. When it's time to check for collisions you check player 1 first to check if he hit player 2, and it did. Now instead of immediately making player 2 hit (whatever you do, like changing to "hit" animation, decrease HP, etc), just have some boolean variable hold the result of the test.

Do the same for player 2 (check collision, etc).

At the end of the tests, check the boolean values and see if anyone was hit. If only one of the player was hit, then you do the normal thing when one takes damage, and if both have been hit, then it's the "trading hits" case.


This works equally for multiple hit-boxes, the only difference is that you check all hit-boxes for collisions and save all the results.


Basically delay the actions of collisions until all the tests are completed.

#5071411 Loading level information based on a parameter

Posted by __SKYe on 20 June 2013 - 05:34 AM

The best thing to do, in my opinion, is to separate the level data from the code (never hard-code things).


You should create a file for each level, that contains the data for that level.

If at level load you need to know what is the tileset for the background, then put it into the file, and when you load a level, open this file and read the appropriate data.

About the objects, it's also simple.


Imagine you can have multiple objects in your level that requires 2 things: a position and a sprite (this is just an example, you can have much more properties).

But you don't want to have a fixed number of objects for all levels (by doing this, you either waste space, if the level doesn't require all the objects, or you are limiting the number of objects you can have.

To solve this you could have this in your level file (again, just an example):


//Background stuff here

//As an example, using 2D position (x, y)
///he sprite here is the name of a texture/image, but you could put instead the coordinates for a specific tile from a tileset


OBJ_SPRITE = image

OBJ_SPRITE = image2

In your Level class, along with the background stuff, you would have a pointer to an array of objects (imagine your object struct/class is called object_s).

At the level load, you read the NUM_OBJECTS value from the level file, and allocate the required number of objects, and then loop through the number of objects to load their properties.

It could be something like this:

void LoadLevel(...)
    //Open file, read any other stuff you need first (could be level name, background tileset, etc...

    //Read the number of objects
    //This Read function doesn't exist, it's just an example
    int numObjects = Read("NUM_OBJECTS");
    //Allocate space for the objects
    //You should probably check if the number is valid (either 0, negative or just too large)
    object_s *objs = new object_s[numObjects];

      //Read each object's properties
      for(int A = 0; A < numObjects; A++)
      //Read position
      objs[A] = Read("OBJ_POSITION");

      //Read sprite
      objs[A] = Read("OBJ_SPRITE");

Note that this code is just an example, and obviously wouldn't work, but it demonstrates the process of reading an arbitrary number of objects from a file.

This way you don't have to limit the number of objects for all your levels.


The "read any other stuff you need first" part, just means that if your level file has other things that have to be read before the objects (it could be the level name, the background properties, what BGM should be played in that level, etc) you should read them first until you reach the objects part.


As an example, this is a possible level file:

File: Level.txt


BACKGROUND = BgTileset.png

BG_MUSIC = MyLevelMusic.wav


OBJ_SPRITE = image
OBJ_SPRITE = image2

Also, note that the level format is entirely up to you, as is the type of file (you could use a binary file instead of a text file).


I hope that this is understandable, if you don't understand something, i'll try to explain better.

#5071163 How on earth do I start a game?!

Posted by __SKYe on 19 June 2013 - 10:25 AM

And i really advise to spend a good amount of time on step 1, and getting a good grasp on the language (whichever you choose), before jumping to step 2.

#5058362 Scripting Language Choice

Posted by __SKYe on 01 May 2013 - 12:18 PM

There's also C#. I'm not sure, but i think C# is Windows only, so if cross-platform is an issue, you may want to use Python.


Edit: According to http://www.mono-project.com/Main_Page, it's also possible to use C# in Linux & Mac.

#5058344 Getting weird colors when using textures with OpenGL

Posted by __SKYe on 01 May 2013 - 11:34 AM

Do you set the color to white when you render the rest of the textures?

If you don't have a

glColor3f(1.0f 1.0f, 1.0f);


before you draw the textured quads, then any color you've used for something else will also affect the next draws.


Also, since in your example you use the same color for every vertex, you can do this:

//Render the window fill
        glColor3ub( 0, 17, 34 );
        glBegin( GL_QUADS );
            glVertex2f( 0.f,    0.f );
            glVertex2f( box.w - ( ThemeTemplate->quadWidth * 2 ), 0.f );
            glVertex2f( box.w - ( ThemeTemplate->quadWidth * 2 ), box.h - ( ThemeTemplate->quadHeight * 2 ) );
            glVertex2f( 0.f,   box.h - ( ThemeTemplate->quadHeight * 2 ) );


There's no need to repeat the glColor* every vertex.

#5055052 Including Header Files

Posted by __SKYe on 19 April 2013 - 04:39 PM

If you include Foo.h in another file, then that other file will also include any files included in Foo.h.


I don't know if there's a proper way or not, but the only thing i can tell you, is that you don't need to include them again. I think it goes a little into the field of coding style.

#5055042 What is an entity?

Posted by __SKYe on 19 April 2013 - 04:09 PM

Pretty much like FLeBlanc said, an entity is anything that may exist in a game world, be it the player character, a projectile, a trigger (as in event trigger, not a gun trigger), etc.


One thing to note is that normally when we hear game world one usually thinks about the visible things (geometry), but an entity isn't necessarily something that needs to be rendered (although there may be people who only call entities to the things that need to be rendered).