Nonsense. http://java.sun.com/docs/books/tutorial/java/nutsandbolts/branch.html

Ashley iS H4X:

But using a pure rectangle1.intersects(rectangle2) is really inaccurate and sometimes the two sprites can be a few pixels apart and still register as a hit and it just looks really poorly programmed.  I'm thinking of entering the imagine cup, and they would expect far more than a simple intersects method and they would expect it to look professional etc.

Ashley

Of course it will look poorly programmed if no additional effort is involved in tidying it up.  If there's a space between the two objects, it could simply be that your rectangle is too big; e.g. if you create the rectangle based on texture width and height but the texture has some alpha around the edges, this alpha will give the appearance of space.  If this is the case, you could either just chop the alpha sections from the image, or create a slightly smaller rectangle. You can also create a projected rectangle and then test collisions with this and lastly find the difference between the objects to prevent any overlap.

As for the Imagine Cup, they don't care how you implement your collisions.  I used various different collision detection methods for my IC game (per pixel, rectangle, circular) when the situation required them.  There's no reason for rectangular collisions to look unprofessional at all with a little bit of work (mine didn't).  Also as mentioned in previous posts, rectangles are much more efficient than per pixel; they are quicker to calculate and there's no need to hold loads of colour data so in my opinion if there's a scenario in which the collision is actually rectangular (e.g. running into a wall, standing on a block) then it's probably the most ideal solution.  However, if the player was to run into an odd shaped item (like an enemy) then it would be better to use per pixel so the player loses a life (or whatever) when they are actually touching rather than just an intersection of rectangles.

There's no reason you couldn't use a combination of the two for your platforms.  Say for example the platforms had rounded ends, you wouldn't want your player looking like they are standing seemingly in mid air!  You could use rectangular collisions for the mid sections and per pixel collisions for the rounded ends for example.

Ashley iS H4X:

Craig Martin:

break

Thanks, i thought that was only for use in switch statements - I was told it was bad programming to use a break statement within a loop but guess that's fine in C# and obv. not fine in Java haha

Erglegrue:

Ashley iS H4X:

Craig Martin:

break

Thanks, i thought that was only for use in switch statements - I was told it was bad programming to use a break statement within a loop but guess that's fine in C# and obv. not fine in Java haha

It's fine in Java, too. Where did you get the idea that it wasn't?

Some programming classes seem to teach that it is bad programming practice to use break for anything other than switch statements.  Don't really know why it's taught as a bad practice; I rarely find myself needing to use it anyway.

jmitch18:

Some programming classes seem to teach that it is bad programming practice to use break for anything other than switch statements.  Don't really know why it's taught as a bad practice; I rarely find myself needing to use it anyway.

I remember I used break and continue in a project for one of my CS classes, and the grader deducted points for "spaghetti programming", just due to the presence of break/continue within a loop.

Then again, this was a class with a professor who tried to make us create functional Java programs and object-oriented Scheme programs... And then a later project in the course had a provided framework which included something along the lines of "while(true) { ... if(...) break; ... }"

Break and continue both have their uses. While I wouldn't recommend using break in every loop you ever write, I also think calling break inside a loop "bad practice" is moronic.

Yeah I had marks deducted from me before in a Java class and I agree that labeling it as "bad practice" is moronic.  We were pointed at a Java book that described it as bad practice, I can't remember the name of it now though.

But in my opinion:


is more clear about what is actually happening than: