Space Invaders. Both shoot and move at once?

Hi,

I am making a game of Space Invaders.

The ship moves left and right at the bottom of the screen, and shoots upwards, towards the targets.

I have managed to have my ship moving left and right and when the mouse button is pressed, shoot.

But I have a problem.

Currently I'm using an infinite loop to test for moveLeft, moveRight and Fire function calls, but I want to have the code "split" into two separate procedures once the user presses fire, so that the bullet will move at a different rate to the ship etc.

Like I mention, right now all of this is controlled with a single infinite loop, which isn't giving the effect I am seeking.

Many thanks for any advice, much appreciated.

:)

Im not quite sure what you mean with "move at a different rate to the ship"
You should be able to do something along like this

Code:

---

if(Move_left_key is pressed)
    MoveShipLeft()

if(Move_right_key is pressed)
    MoveShipRight()

if(Fire_bullet_key is pressed)
    FireWeapon()

---

Use a thread.

No need for a thread and you are just risking making things harder for yourself. a simple loop that looks something like this should do:

Code:

---

while(not_done)
{
    HandleKeys();    // Handle key-presses, like move left, move right, shoot etc etc
    UpdateWorld();    // Update all positions, headings, collision etc etc
    RenderScene()  // Based on the new values render the scene
}

---

Of course this is a very simplified example but that is the basic idea.

No, if you read what he said. A thread is necessary. He needs a function to control the speed of the projectile and another to simultaneously move the monsters, ship, or whatever.

Quote:

---

Originally Posted by MeTh0Dz

No, if you read what he said. A thread is necessary. He needs a function to control the speed of the projectile and another to simultaneously move the monsters, ship, or whatever.

---

But that's what UpdateWorld() would do, is it not? Move alien by 5, player by 10, bullet by 4 (or whatever the appropriate relative values are).

That's not how he wants to do it. Read what he said.

He explicitly said that he wanted this all to happen 'simultaneously', and the best way to emulate that is using threads.

However your method is applicable, threading just seems to be what he was talking about.

Although in the end he will probably end up with the same effect, and the UpdateWorld() technique may actually be less prone to bugs than threading.

If you are updating, and rendering 60+ times a second then do you really think that threads are necessary?

I didn't say they were necessary, I just provided that answer based on what he said he wanted to do. Like I said, the other solution will work just fine.

Quote:

---

No, if you read what he said. A thread is necessary. He needs a function to control the speed of the projectile and another to simultaneously move the monsters, ship, or whatever.

---

I do not recommend a thread for this. It introduces a plethora of problems and caveats that are not needed.

A simple update function will suffice. And while the various update functions are not called at exactly the same time if your frame rate is fast enough it will look like they are simultaneously executing. And even with a thread execution is not happening simultaneously on single core CPUs.

Using a thread for this is asking for trouble.

I'm tired of reiterating that I only suggested a thread because of the way he worded his question.

Quote:

---

I'm tired of reiterating that I only suggested a thread because of the way he worded his question.

---

With beginning programmers you shouldn't always interpret their question exactly as they word it.

threading is much better , i use it alot to lock index and vertex buffers and get smooth processing

Quote:

---

threading is much better , i use it alot to lock index and vertex buffers and get smooth processing

---

Which is not what is being suggested here. If you are locking your vertex buffer to move objects then you are most likely doing it the wrong way.

Code:

---

void GameApp::Update(float timeDelta)
{
    //Get any new input
    getKeyboardInput();
    getMouseInput();
 
 
    //Update physics
    m_Physics->Update(timeDelta);  //Delta clamped to 60 FPS inside physics

    //Update objects
    m_ObjectMgr->Update(timeDelta);
}

---

Now items that would be good for a thread:

• Keyboard/mouse input
• Sounds/Music
• AI

You could put updating objects and physics into a thread but synchronization would hurt and after the sync was done you would realize it was a linear process that didn't need threads. You must update physics before you update objects. You must get keyboard input and mouse input prior to updating anything. So you would end up waiting on events to fire off the update which means you are not gaining anything because you are not trying to do two things at once per se.

Code:

---

void ObjectMgr::Update(float timeDelta)
{
    WaitForSingleObject(m_doUpdate,INFINITE);
   
    std::list<IGameObject *>::iterator iter(m_Objects.begin());
    std::list<IGameObject *>::iterator end(m_Objects.end());
   
    while (iter != end)
    {
        (*iter)->Update(timeDelta);
        ++iter;
    }

    ResetEvent(m_doUpdate);
}

---

See a problem here? I do. Anytime the thread wakes up it will iterate through all objects. But if it doesn't get through all of the objects then some portion of them will still reflect the last frame's data and some will reflect the new frame's data. I don't think this is what you want to do. If you somehow force the thread to finish the loop (which you can't) then you are still doing everything linearily.

There would be a huge host of problems and sync issues to work out if you do it this way. I do know some games like Falcon 4: Allied Force makes use of threads for the AI but I think update is done in the main process. If not they figured out how to solve the above issues which is something I really wouldn't waste my time on unless your current FPS state dictates that you need it.

So if you have to do it this way be fully aware of the pitfalls you may encounter. Remember that using threads does not guarantee your application will perform any better.