The Big Programming Thread - Page 370

On October 09 2013 04:08 NB wrote:
Im trying to make a simple snake game. Do i really need to make 3 threads (mainDisplay, snakeRun, input) for it or there is a way that i could get away with 2?

On October 09 2013 04:42 NB wrote:
Because if i combine my input and display into 1 thread, which is what im doing right now, I cant get an input delay system running that prevent cases where User input is too fast.

For example: Here is my snake running to the right

--------------
-ooo>-----
--------------

what would happen is that if the user input UP->LEFT faster than my frame rate, the snake will run backward through itself -_-.

def game_loop():
    while True:
        process_input(...)
        update_world(...)
        render_world(...)

On October 09 2013 04:42 NB wrote:
Because if i combine my input and display into 1 thread, which is what im doing right now, I cant get an input delay system running that prevent cases where User input is too fast.

For example: Here is my snake running to the right

--------------
-ooo>-----
--------------

what would happen is that if the user input UP->LEFT faster than my frame rate, the snake will run backward through itself -_-.

On October 09 2013 05:14 Tobberoth wrote:

You have to protect yourself from that on your own part. You should probably set it up so that the snake can only update its position once per frame or is disallowed from moving back through itself, which would let a user change his mind midframe. This is easy enough to implement, one way would be to have the snake object keep track of the desired direction for the next update and simply disallow setting it pointing towards the tail.

Using threads will not only make your game slower (unless you have a good reason to use threads, the overhead is far worse than the gains) it will also make it far harder to work with since you will have to make sure it's synchronized.

thread(update_world(&x, ...));
thread.start;

def game_loop():
    while True:
        x=process_input(...)
        render_world(...)

On October 09 2013 05:24 NB wrote:

Im trying to avoid having the 1move-1frame solution though. I really want it to work in real time with an manual input lag. This is only a test game for me to make bigger applications and such implementation is needed.

yes i do use move_state. it looks something like this

thread(update_world(&x, ...));
thread.start;

def game_loop():
    while True:
        x=process_input(...)
        render_world(...)

x is my move state. This means that my snake will move completely independent compare to the display/input. Right now my input is set up like above because its how SFML handle it(as far as i know). I would like to set it up so that my input run in a separated thread so when i insert a delay, it does not interfere with my render.

On October 09 2013 05:59 NB wrote:
update_world.speed = 500ms/loops
game_loops.speed = 8ms/loops (input_check + rendering) (~roughly 120fps)

these are my numbers right now. Obviously if i raise the Update_world.speed into 200ms/loops it would be pretty hard for human input to 'break' the game but I also need my snake to run at small speed early on.

Correct me if im wrong but are you suggesting that I should manually decrease the render_world.speed to match my update_world.speed?

On October 05 2013 09:22 berated- wrote:


Can you please explain "expensive operations to translate between objects and database entries"? Are you speaking to trying to persist large object graphs in a normalized manner? Or?

Also, how is Map<Class<? extends Component>,Map<int, Component>> not object oriented?

If you need a fast key value store though, redis or memcached might prove helpful.

On October 09 2013 05:59 NB wrote:
update_world.speed = 500ms/loops
game_loops.speed = 8ms/loops (input_check + rendering) (~roughly 120fps)

these are my numbers right now. Obviously if i raise the Update_world.speed into 200ms/loops it would be pretty hard for human input to 'break' the game but I also need my snake to run at small speed early on.

Correct me if im wrong but are you suggesting that I should manually decrease the render_world.speed to match my update_world.speed?

char x;
int i=0;
while (gameRunning)
{
  if(keydown()){
    x=keypressed();
}
if (i==20) //20 ms between each frame
{
   changeWorld(x);
   render();
  x="";i=0;
}
 i++;
sleep(1);
}

On October 08 2013 18:32 goody153 wrote:


i am more knowledgeable in java than in JS .. one more thing i wanted to ask .. aside from OpenGL ES 2.0 or WebGL ..any other library that is easier to use and integrate unto the android program later ? since i am just making a Tower Defense game its really emphasized on the graphics much ..

and also i have been doing sort of research .. what version of android should i work on ? some told me to work on lower versions like 2.0 to 2.5 ... somewhere around that

and in the database part of the development .. would my knowledge on php help on that matter ? or its a separate thing

anyways thanks for the great advice tec27

On October 09 2013 06:09 Tobberoth wrote:

No, there is no reason to do that. What you would normally do, in a game, is cap the input and update to 25-30 frames per second, while not capping the drawing at all. That's what lets games run really fast and smooth on fast computers without messing up the gameplay, physics etc.

It's important to note though, that human input shouldn't ever be problematic. You check to see what the human is pressing, then you tell the model (the actual gameplay world) what the human wants you do to. Then you let the world update itself accordingly. Let's say the human spams keys, up->left->up->left over and over. That shouldn't matter to the world because it only updates at set intervals, it doesn't let the human input a bunch of stuff which happens at once (because that would break most games, think of a 2D RPG like Dragons Quest... if you press left 10 times in one frame when you're next to a wall, you shouldn't be allowed to walk through the wall).

Think of it like components. Your handleInput method is like a controller, the update_world is like a separate world which only reacts, and the drawing is just a representation of that world at a point in time. If you want to simulate input lag, that code should probably be in the controller, but this shouldn't affect the world. You don't need threads to simulate this.

Keep in mind, 60 frames per second is less than 17 milliseconds per frame. A human won't notice if it's 1 thread or 10 (though 10 will probably slow things down). Threads don't actually run things in parallel (unless it's long computations optimized for running on another core), but they actually takes turns. So you're just giving control of what happens when to the computer, when you can keep all that control to yourself.

The main point here is that you shouldn't let your world (IE your snakes speed) be dependent on user input, it should be dependent on world rules. If the world states that the snake can only move 100px per second, or change its direction once per frame, the amount of user input should not be allowed to break this, and this is solved quite easily by simply supplying delta time on each update. So lets say you set your snake speed to 100. In snakeUpdate(clock.elapsedMilliseconds) you would simply do something like snake.Position += speed * elapsedMilliseconds.AsSeconds. This would mean that no matter how slow or fast the game is going, the snake will still only move 100px per second, the frame rate will just decide how choppy it looks.

Threads don't actually run things in parallel (unless it's long computations optimized for running on another core), but they actually takes turns. So you're just giving control of what happens when to the computer, when you can keep all that control to yourself.

On October 09 2013 06:26 Frigo wrote:


Object-relational mapping. Look it up.

That specific Java based component storage is a matter of convenience, I'm using the .class of the various components, for example Position.class, as keys rather than strings, for example "Position". I could have written Object instead of Component, it would still be the same. And it's far fetched to call that OOP, just because components derive directly from Object. But all of this is beside the point: as long as the entities (the "int" part of that line) do not form form a class hierarchy, implement custom logic, or hardwire together, it is fine.

An SQL or key-value storage would do as well for storing components. As I said, one MMORPG implemented entities and components in a relational database with transactions as the update logic. There is a .ppt or .pdf somewhere on the net detailing their way, but I can not find it.

On October 09 2013 07:53 CecilSunkure wrote:
There exists something coined the "slot map" around my school which is best for looking up game objects. The only thing on the internet similar (that I know of) is Noel Llopis's HandleManager. Since we're on the topic of kv lookups for game objects specifically (yes, even in a ECS) this simple data structure is ideal. I suggest checking it out.

Edit: And no it isn't slow, nor a bottleneck. The lookup cost is one if branch and an array index operation. I recently did a lecture on this sort of thing: slides here.

On October 09 2013 06:09 Tobberoth wrote:

No, there is no reason to do that. What you would normally do, in a game, is cap the input and update to 25-30 frames per second, while not capping the drawing at all. That's what lets games run really fast and smooth on fast computers without messing up the gameplay, physics etc.

It's important to note though, that human input shouldn't ever be problematic. You check to see what the human is pressing, then you tell the model (the actual gameplay world) what the human wants you do to. Then you let the world update itself accordingly. Let's say the human spams keys, up->left->up->left over and over. That shouldn't matter to the world because it only updates at set intervals, it doesn't let the human input a bunch of stuff which happens at once (because that would break most games, think of a 2D RPG like Dragons Quest... if you press left 10 times in one frame when you're next to a wall, you shouldn't be allowed to walk through the wall).

Think of it like components. Your handleInput method is like a controller, the update_world is like a separate world which only reacts, and the drawing is just a representation of that world at a point in time. If you want to simulate input lag, that code should probably be in the controller, but this shouldn't affect the world. You don't need threads to simulate this.

Keep in mind, 60 frames per second is less than 17 milliseconds per frame. A human won't notice if it's 1 thread or 10 (though 10 will probably slow things down). Threads don't actually run things in parallel (unless it's long computations optimized for running on another core), but they actually takes turns. So you're just giving control of what happens when to the computer, when you can keep all that control to yourself.

The main point here is that you shouldn't let your world (IE your snakes speed) be dependent on user input, it should be dependent on world rules. If the world states that the snake can only move 100px per second, or change its direction once per frame, the amount of user input should not be allowed to break this, and this is solved quite easily by simply supplying delta time on each update. So lets say you set your snake speed to 100. In snakeUpdate(clock.elapsedMilliseconds) you would simply do something like snake.Position += speed * elapsedMilliseconds.AsSeconds. This would mean that no matter how slow or fast the game is going, the snake will still only move 100px per second, the frame rate will just decide how choppy it looks.

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
    sf::CircleShape shape(100.f);
    shape.setFillColor(sf::Color::Green);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();
        window.draw(shape);
        window.display();
    }

    return 0;
}

On October 09 2013 17:39 NB wrote:

small problems though:

first of all let me show you how SFML draw a circle(code copied from there tutorial at http://www.sfml-dev.org/tutorials/2.1/start-vc.php)

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
    sf::CircleShape shape(100.f);
    shape.setFillColor(sf::Color::Green);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();
        window.draw(shape);
        window.display();
    }

    return 0;
}

As you can see, the event handling and the rendering process is both under the same root "window" and I just found out that each thread could only have 1 window activated and that goes both way. This means that if i somehow put a delay on my event handling, it will delay my render too.

2. I totally understand your point on how world_update should be a reactive process which response to the input function. But there is a reason why I am making Snake: the world_update process is automated. The snake is basicly a bot and you only gives it directions, not driving it. This means that my Updater will be automated. The speed of which it will be updating is also dynamic which depends on the level of the game. This means that at the very first level where the Updater is slow, there will be holes between which could create opening for human input. As this is the case, I want a dynamic lag variable that adjust according to the Updater.Speed variable.

3. The main reason why im trying this practice out is because I read one of the articles about super meat boy devs. Apparently one of them was really upset with how modern platformers handling the inputs so they built their own event handler WITH an artificial lag into some certain action. I am really interested in such design concept and the idea of having the flexibility to customize my own input system, catering it to my own games. So yes I really want input lag to work.

On October 09 2013 06:55 tec27 wrote:

2.3.x is the last version of Android with major version 2, so I'm not quite sure where you're getting your information from You should avoid Gingerbread (2.3.x/API 10) imo, as its crufty and old. The APIs and OS have improved substantially since then. Personally I would just pick whatever version you development device is running, ideally some version of JellyBean (4.1.x, 4.2.x, 4.3.x, API 16+). You should accept that whatever you're working on now will never be a major hit in the app store and therefore trying to "maximize your market" is a useless endeavor. Just focus on learning Android and seeing if you like it.

Knowledge of PHP will likely not be very helpful, unless you're talking about actually interfacing with databases. Android apps that use databases typically use SQLite, but I would think that for a simple game, you won't be touching databases at all.

On October 09 2013 16:18 Frigo wrote:


I know this under the name of entity id pooling. I have it implemented as a component storage strategy. Two main issues with it in this context is that it takes up at least (component types * entities) references which is a lot of memory, and it does not play nice with serialization and networking. I prefer non-changing int or long entity ids and fast primitive map implementations like Trove or Colt. They are more memory efficient and the performance difference is negligible.