Sign in to follow this  
YellowMaple

SHMUP coding/design question

Recommended Posts

Hi, I'm working on a top down shooter (e.g. ikaruga, 1942, etc) in C++ using OpenGL for windows. I have an Actor class, and two classes bullet and player which inherit the actor class. The main loop passes the keyboard/controller status to the player object. The player object processes this input in a function called processInput(...) (e.g. move player left, or right). If the fire/shoot button is held down, the processInput function returns a bullet object. The problem I'm having is that while the fire button is held down, there is a lot of slowdown. If it's release, bullets fly and the player moves at a normal rate. I was wondering if anyone could spot some potential design problems that may cause this slowdown. I was also wondering if when a function returns an object (say in this case bullet), will it ALWAYS run through that objects constructor method, even if it returns NULL? if so, then i was thinking this might cause some of the slowdown. anyways, any help is greatly appreciated, thanks guys!

Share this post


Link to post
Share on other sites
Quote:
Original post by YellowMaple
I'm working on a top down shooter (e.g. ikaruga, 1942, etc) in C++ using OpenGL for windows. I have an Actor class, and two classes bullet and player which inherit the actor class.

The main loop passes the keyboard/controller status to the player object. The player object processes this input in a function called processInput(...) (e.g. move player left, or right). If the fire/shoot button is held down, the processInput function returns a bullet object.

The problem I'm having is that while the fire button is held down, there is a lot of slowdown. If it's release, bullets fly and the player moves at a normal rate. I was wondering if anyone could spot some potential design problems that may cause this slowdown.
You haven't really given us enough information so I can only assue that the amount of bullets spawned when holding down the fire button is slowing down the game.
My suggestion is that you add a reload counter which you reset to some value whenever a bullet has been fired, and count down each frame until it reaches zero and you're allowed to fire again.
Or perhaps you're looping the update function while it's returning new bullets? In that case just call it once per frame.

Quote:
Original post by YellowMaple
I was also wondering if when a function returns an object (say in this case bullet), will it ALWAYS run through that objects constructor method, even if it returns NULL? if so, then i was thinking this might cause some of the slowdown. anyways, any help is greatly appreciated, thanks guys!
I'm not quite sure what you're asking. An object returned by value must be created but a pointer (as would generally be required when returning NULL) does not.

Share this post


Link to post
Share on other sites
What type of input are you using? Buffered or non-buffered?

If it's non-buffered then you are creating a bullet every frame that the fire button is held down. You could be creating hundreds of bullets a seconds if not more. If you want to be able to hold the button down and shoot continually, then you'll have to work out a timing system that allows you to shoot only X number of bullets a second.

As for your constructor question, if you create a class object then it's constructor is called. That's only when you create a new class object though, not if you are just passing it around as an argument/return value.

Share this post


Link to post
Share on other sites
Quote:
The problem I'm having is that while the fire button is held down, there is a lot of slowdown. If it's release, bullets fly and the player moves at a normal rate. I was wondering if anyone could spot some potential design problems that may cause this slowdown.


FPS slowdown or movement slowdown?

Assuming we're talking about FPS slowdown: It sounds like said slowdown is caused either:

1) The input mechanism - not enough information on how your project handles this to know if this is a problem/is the slowdown. I'd doubt that it's this, however, so I'll ignore this for now.

2) The allocation of memory for the bullet(s). Are you allocating each bullet with new/delete (or *shudder* malloc/free)? This could be your problem, these can be somewhat expensive operations. An alternative would be to use some sort of pool such as the Boost Pool Library, which can optimize your (de)allocation and help reuse memory better.

3) The constructor(s) of the bullet class. Again, I'd doubt this, but I might as well throw it in for completeness. If you're loading the mesh, texture, etc. from file each time you create a new bullet, this would be a problem. Your actual bullet "instance" should be fairly lightweight, with the model/texture loaded once for the collection of bullets, and that data shared.

Assuming a movement slowdown (which would be associated with a "virtual" FPS slowdown, although this may not affect the actual displayed FPS if the original FPS was/is higher than the monitor's refresh rate), this would be due to using frame-based movement instead of time-based movement.

This one's pretty simple. Assume for a moment you advance something 1 meter/frame. If you're running at 120FPS, that object will move at 120 meters/second. If you're running at 1FPS, that object will move at 1 meter/second.

The idea here is to somehow factor time into the equasion. This is usually done using a time delta.

Delta refers to change. The time delta I'm refering to is "how much time has changed since the last frame" - i.e. at 120FPS, on average, this time delta will be 1/120th of a second. You then multiply all movement amounts by this delta.

Basically, your loop turns from this:
while( true ) {
render();
position += 1;
}

Into:
//Some variables and initial values:
double time = now();
double previous_frame_time = time;
double time_delta = 0.0;
while( true ) {
previous_frame_time = time;
time = now();
time_delta = time - previous_frame_time;
position += (1 * time_delta);
}

Now, when running at 120FPS, each frame the object will move forward 1/120th of a meter (for a total of 1 meter/second), and when running at 1FPS, each frame the object will move forward 1 meter, for a total of 1 meter/second again.

Quote:
I was also wondering if when a function returns an object (say in this case bullet), will it ALWAYS run through that objects constructor method, even if it returns NULL? if so, then i was thinking this might cause some of the slowdown. anyways, any help is greatly appreciated, thanks guys!


If you're returning a pointer, no constructor is ever involved with that operation. A pointer references an object, it dosn't create a new one. Could you prehaps show some source code to explain what you're talking about?

Share this post


Link to post
Share on other sites
thanks for the reply guys. I'll try out the counter idea. Currently, the processInput() function in the player class always creates a bullet object and returns a pointer to that object as long as the fire button is pressed. My main loop then receives a pointer to this bullet object and adds it to a linked list of bullets in the scene. The way I currently moderate the amount of bullets is before adding a new bullet to the list, in the main loop I check to make sure that the difference in the position of the last bullet that was added to the linked list and the new bullet is greater than some threshold.

In other words, the processInput function always returns a bullet, however the main loop only adds it to the scene if the previously fired bullet is far away enough from the new bullet.

However, I see many problems with this :p and the counter idea sounds much better, thanks guys!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this