Jump to content

  • Log In with Google      Sign In   
  • Create Account

BeerNutts

Member Since 27 Jun 2001
Offline Last Active Yesterday, 06:40 PM

Posts I've Made

In Topic: Python/pygame Code Review - Where To Next ?

19 July 2016 - 12:55 PM

I'm sure you have the indices memorized right now, but, if you stop working on this for a bit, then come back later, will you remember what 6 and 7 and 10 are?  Probably not, so, you still need to replace these magic numbers with constants.  Something as simple as this:

def turn(item):
    v=[]                    # empty list ( temp / local )
    v.append([item[VY],-item[VX]])      # add alternate vectors. use y,-x and -y,x
    v.append([-item[VY],item[VX]])
    u=random.randint(0,len(v)-1)        # pick one at random
    item[VX]=v[u][1]                    # update the x and y vector
    item[VY]=v[u][2]
    item[X]=item[SAFE_X]                # rewind item's x and y position to last know good value (pre collision)
    item[Y]=item[SAFE_Y]

Also, you don't need to comment every line.  Only comment where it makes sense.

For example, it's obvious, if you rewind x, you're doing the same thing for y.  So you could say rewind item's x and y position to last know good value (pre collision)


In Topic: Sharing object between 2 threads

29 June 2016 - 12:21 PM

Thanks for all the good answers. I realize that the better approach would be to use the same data structure in both threads, while having different classes.

What I am actually trying to do is:

 

The main thread handles the game logic and works on the resources (reading/writing them). The auxiliary thread handles the display only, reading only from the resources.

 

I want at a later point to be able to either have the render thread:

 

1. either read from the original data while the game logic thread waits (thus avoiding copying the resources at all).

2. either read from a copy of the original data, while the game logic continues its work.

 

In case 2 above, copying the resources will be done as a light copy first (i.e. actually sharing the resource until the point where the main thread modifies it: in that case, the main thread will first deep-copy the resource before modifying it, while the render thread will still read from the old, unmodified resource, thus avoiding a crash).

Why do you have a separate thread for Rendering? Is the Rendering phase a bottleneck in your program?  What happens if you simply render all your object within the main game loop?

 

Basically, are you sure what you're doing is worth the trouble?  Multithreaded programming can be difficult to do correctly, and if you miss 1 thing, you'll start having odd bugs that are very hard to debug.  Be sure you really need to do it before trying to do it.

 

If it's as an exercise, then disregard, but if it's a solution to a bigger problem (like making a game), then I'd re-evaluate and ensure it's really needed.

 

FWIW, in my hobby games I've written, I've never seen the need for more than 1 thread.  Some big games will need more, but they have to have good reasons for them.


In Topic: PowerUp stuck

29 June 2016 - 10:16 AM

Maybe, instead of having an index stored in the power up, you have the actual type stored and duration, and there's no need for an if in your loop.  You can also update before checking collision to also condense it.  Something  Like this:

 

            for(int i = 0; i < PowerUpses.Count; i++)
            {
                PowerUpses[i].update(time);
                if (PowerUpses[i].PowerUpPaddleCollision(paddle))
                {
                    paddle.pickPowerUp(PowerUpses[i].Type, PowerUpses[i].Duration);
                    PowerUpses.RemoveAt(i);
                }
            }

In Topic: PowerUp stuck

28 June 2016 - 01:27 PM

 

Edit: I Got it working.

                    if (paddle.powers.Count > 0)
                    {
                        foreach (var paddlePower in paddle.powers)
                        {
                            if (paddlePower.power == PowerUpses[i].power)
                            {
                               // paddlePower.reset();
                               Debug.WriteLine("paddle power is " + paddlePower.power);
                                paddlePower.OnRemove();
                                paddlePower.OnApplied();
                            }
                            else
                            {
                               
                                paddle.powers.Add(PowerUpses[i]);
                                paddlePower.OnApplied();
                            }
                        }
                    }
                    else
                    {
                        PowerUpses[i].OnApplied();
                        paddle.powers.Add(PowerUpses[i]);
                        
                    }
                  

Basically I used 2 list one for the paddle and other for the power up. I havent tested another type of power up yet

 

This looks wrong if you have multiple power ups.  While looping through the paddle's current power ups, you should not have an else if the power up doesn't match inside the loop, otherwise, for every power up that doesn't match, you'll re-add it and call OnApply().

 

Rather, you should do something like this:

bool isPowerFound = false;
foreach (var paddlePower in paddle.powers) {
  if (paddlePower.power == PowerUpses[i].power) {
    paddlePower.OnRemove();
    paddlePower.OnApplied();
    isPowerFound = true;
    break;
  }
}
// if we didn't find the power up on the paddle, add it now
if (!isPowerFound) {
  PowerUpses[i].OnApplied();
  paddle.powers.Add(PowerUpses[i]);
 }
...

In Topic: What About your compressed Audio Format?

24 June 2016 - 07:28 AM

if i'm correct UDP is when you use peer to peer architecture...in my case i'll use a client/server architecture so i think TCP is great in this case no?

 

No, that's not the case.  UDP is just a connectionless, unreliable protocol, so you can send a single packet to a destination IP address/port and you don't need to be connected to it, and you won't know if it gets there using UDP by itself.  TCP is a connection oriented streaming protocol, so it requires 2 IP addresses to connect, and the data sent is streamed and guaranteed to get there in the order sent.

 

Both TCP and UDP can be used with peer-to-peer, and both can be used for client/server.  Typically a game will include both TCP (for sending those must have data pieces ), and UDP (for sending the often updated states of players).

 

In your case, since you're doing interactive audio, you might want to use UDP since it will decrease communication time to/from others.  If you happen to drop a packet myou'll get a blip in the audio, but the other guy can just say, "What was that?"


PARTNERS