I get the same sort of results as 20thCB, I’m on:
WinXP, MSVM, Radeon 9000 Mobility.
Kev
I get the same sort of results as 20thCB, I’m on:
WinXP, MSVM, Radeon 9000 Mobility.
Kev
I’d move the “click on the applet to gain focus” text as it is not very readable at its current position.
Did it save my score of around 1300?
It would also be nice to distinguish the ship bullets from that of your own.
Well before you had to start a new game to save your old score. Sorry I didnt mean leave that in. Also I fixed the text and removed some small bottlenecks. But I don’t think that this is going to help plp using the old Microsoft Java Virtual Machine with slower cpu’s.
Any pointers to some tutorials related to speed optimizing java would help (I’ll look around).
No autofire, and no sign of the other changes you mentioned ?!?
Why don’t you submit it to http://grexengine.com/sections/externalgames/ ? Although it would be much much much better if you make a webstart version first (takes just a few minutes - there’s an article in the articles section on that site with full step-by-step instructions)
With autofire and the ability to turn the turret much further down I think it’s to easy now, got to 2000 points and stopped playing because I got bored. Maybe you could accelerate the rate of emergance of droids as the play time increases?
Well I’ve been twicking the game and I’ve been profiling it. At this point the most used method is collision() This is in a Sprite Class and something like a Bomber extends this class. Anyways here’s what I use for collision detection
public boolean collision(Sprite sprite){
if((int)(y)+(height>>>1)+(collisionHeight>>>1)<(int)(sprite.y)+(sprite.height>>>1)-(sprite.collisionHeight>>>1)) return false;
if((int)(y)+(height>>>1)-(collisionHeight>>>1)>(int)(sprite.y)+(sprite.height>>>1)+(sprite.collisionHeight>>>1)) return false;
if((int)(x)+(width>>>1)+(collisionWidth>>>1)<(int)(sprite.x)+(sprite.width>>>1)-(sprite.collisionWidth>>>1)) return false;
if((int)(x)+(width>>>1)-(collisionWidth>>>1)>(int)(sprite.x)+(sprite.width>>>1)+(sprite.collisionWidth>>>1)) return false;
return true;
}
Also drawing anything big with the MS JVM seems to eat up LOTS of time. Any suggestions on anything…
Sorry to double post but I totally revamped some stuff and I was wondering if the people who had “jerky” problems under the MS JVM, could run it one more time to see if its been fixed (at least a little I hope).
I like your IO infection game - runs flawlessly on my macosx machine.
FYI - my collision detection looks like this:
public boolean collidesWith(SJGSprite s) {
return ((getLeft() < (s.getLeft() + s.getWidth())) && ((getLeft() + getWidth()) > s.getLeft()) &&
(getTop() < (s.getTop() + s.getHeight())) && ((getTop() + getHeight()) > s.getTop()));
}
I don’t know if your optimisations with multiple if sentences and >>> matter - as you can see writing it in a single sentence and doing all data access through methods has not been a problem for me.
Are you searching through all sprites for collision detection with a single sprite? Maybe you can optimise that - change algorithm and data representation. Although it has never been necessary for the stuff I do.
Yea, for the cannon balls (whatever you want to call em) I go through each on and check for collision with any active sprites. All sprites are stored in individual arrays like CannonBall[] cannonballs = new CannonBall[MAX_CANNONBALLS] and so on… I use for loops to cycle through, test if active, then test anything else, then finally test collision.
Can you explain any other approach you maybe suggesting or maybe point me to some documentation or source. I would appreciate it. I want to do it the best possible way.
If you really want to look into it, then there is something in: Berg, van Kreveld, Overmars & Schwarzkopf: Computational Geometry, chapter 5: Orthogonal Range Searching.
Or google “orthogonal range searching”.