Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Jun 2012
Offline Last Active May 11 2014 01:36 PM

Posts I've Made

In Topic: How to 'ship' your game assets

12 May 2013 - 07:37 PM

Perhaps something like BoxedApp is what you're looking after? It packs files into the executable and unpacks them in a virtualized environment for your game.exe to use. I'm not security expert at all (really, I haven't got the slightest idea what I am talking about!), but as far as I am concerned it gives you basic protection against DLL-injections and hides your resources from public view. Also you get a single binary for shipping. No installation required, just click the exe and run the game. Registry-values is saved in a virtual registry.

In Topic: SDL Regulating frame rate

10 May 2013 - 10:00 AM

What others have mentioned, you usually don't use SDL_Delay() too regulate framerate. While this is a quick and easy approach to fix a game running to fast, the results will vary on slower and faster computers than your own.
Usually velocity is measured in pps, pixels per second. You want something to move 10 pixels per second, you set velocity = 10. deltaTime how long time it took to run a frame. If your game takes 1 second too run 1 frame, you get:
velocity * deltaTime = 10pps * 1000ms = 10ppf (10 pixels per frame)
0.5s to run 1frame would be:
velocity * deltaTime = 10pps * 500ms = 5ppf
So if your game runs faster, your character moves shorter per frame. If your game runs slower, your character moves faster. If the game run double the speed, the character only moves 5ppf. If the game runs 1s/frame he moves 10ppf. This should make sence. This makes gameplay run equally fast on different computers, but with altering framerates. This is what many others said before, but no one mentioned pixels per second or frames per second which, IMHO, makes this subject more easy to think about.


Tip: When using SDL everything is measured in ms, NOT seconds, hence why I used ms in my explanation. When calculating deltaTime you would do something like:


Uint32 getDeltaTime()
   Uint32 deltaTime = SDL_GetTicks() - previousFrameTime;
   previousFrameTime = SDL_GetTicks();
   return deltaTime;


This would return 1000 if the time between each frame is 1sec. Doing position += velocity * getDeltaTime() will scale your velocity by 1000 if you defined your velocity as pps. You must either define your velocity as ppms (pixels per milliseconds) or divide deltaTime by 1000:


Uint32 getDeltaTime()
   Uint32 deltaTime = SDL_GetTicks() - previousFrameTime;
   previousFrameTime = SDL_GetTicks();
   return deltaTime / 1000;              //Seconds instead of milliseconds


Division is an expensive operation you might say, but considering the circumstances its a piss in the ocean (as we say in sweden, instead of "it doesn't matter"). Dividing by 1000 once every frame isn't gonna cause your game to meltdown. New game programmers tend to prematurely optimize everything, including myself, and it's easy to think dividing by 1000 every single frame is bad code. It isn't.

In Topic: Problem with understanding data access and responding to events in component...

06 May 2013 - 02:54 PM

Components are objects stored within a class as members, components are not inherited and thus it's not a component based system.


Assuming Foo is inheriting SolidObject and GameplayObject you could do something like:


vector<Foo> solidsAndGameplayObjects; //A container of the class inheriting from SolidObject and GameplayObject


for(auto foos1 = solidsAndGameplayObjects.begin(); foos1 != solidsAndGameplayObjects.end(); ++foos1)  //Iterate through all foos
    for(auto foos2 = foos1+1; foos2 != solidsAndGameplayObjects.end(); ++foos2)   //Nestled for-loop to compare all Foo's with eachother exactly one time
        if( collision( foos1, foos2) == true) //Check for collision
            foos1.hitpoint -= foos2.collisionDamage;  //collisionDamage lives in Foo
            foos2.hitpoint -= foos1.collisionDamage;


While I wouldn't recommend this approach since you will find yourself programming HORRIBLY TERRIFYING CODE which is not maintainable whence you create more classes inheriting from SolidObject, as you would need another vector for each subclass of SolidComponent...


This is a simple and direct approach to solve your issue though, but I wouldn't recommend it as it will be difficult to maintain.

In Topic: Having a brain-fart about 2-D arrays

28 April 2013 - 07:04 PM

Well... that's pretty much how it usually works in the memory of a computer . The multiple dimensions just make it easier for you. I realize you can do that, but it's just easier for me to do foo[20,20,20,40], as opposed to foo[320000] .

How about foo[20*20*20*40] ;)?


Also, easy to understand picture:



In Topic: What is an entity?

19 April 2013 - 07:17 PM

As previous posts suggested an entity is pretty much everything. It's for sure to complicated to explain in one post, articles are more suited for the job. I'm not gonna try explain to you what an entity is, but I want to give you an advice - everyone has different opinions about what an entity is, why you need one, how it is implemented etc etc. Everything you read about the matter should be read with a pinch of salt (and in some cases a handful of salt!). You can't read an article and assume what that article explained to you is true in another article, that I learned the hard way.


The most common approaches of Entity Systems have unofficial labels that you will come across whence you lurk more... People talking about, for example, T-Machine ES (Entity System) are generally talking about the same approach of entity system. You might want to memorize the unofficial labels names each type of ES has been given and what's special about that entity system, it will help you from mixing up the different concepts of different entity systems.


Here's some helpful articles that helped me understand ES:


http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ (T-machine entity system)

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ (Objects (entities) as pure aggregation)


While it might be mind-boggling to read get into ES-concept, it is well worth it. I personally feel Entity Systems give the programmer much more freedom and it becomes easier to structure your game. Decoupling is very easy to manage.


I can answer your questions very briefly how I did it:


1. An entitiy is an integer, GUID (Globally Unique IDentifier), that is used to index arrays for it's components (data-collections). In my implementation it is NOT a class.

2. The entity GUID index arrays to access it's components.

3. Systems has access to relevant components. My moveSystem have an update function which can iterate through all positionComponents and velocityComponents and do the logic upon these, altering the component values.