(Java) Timer objects 'running slow'

Hi. I have a java game I made in a course at Uni. It has three Timer objects.
When I run the game from Notepad++ it runs perfectly (sweet-as game if I may say so myself).
I have made executable .jar files so that I can share it with friends. Unfortunately sometimes the game runs 'slow' when run from the .jar.

I have the feeling this has nothing to do with errors in code (due to the randomness of the error's occurence) but rather a runtime problem (if that's the right word..).

Anyone know what the problem might be?
Also plz keep elitism to a minimum

more like sweet as-game hahahaha

Upload source code?   (I'm not going to run some random jar from 4chawn)


Make sure you're using
System.nanoTime()    returns time in nano seconds, so you'll have to convert to milliseconds if your using it to sleep.

http://www.mediafire.com/?jxts9k6gaabaj32

There's a rar of the source. Probably not the ideal way to share, what is?
I didn't do anything like System.nanoTime()..

Also, enjoy the game :D

Probably not the ideal way to share, what is?
github, imo.

This is actually pretty awesome.

Thanks anon :-)
I also made a 2player version.. All it does is adds a second player (WASD to control)
http://www.mediafire.com/?084hbhc85iy10ak

Anyone got any ideas about the slowing? Or even experienced it? It's a temperamental error I don't know how to recreate it.

something vague happens sometimes
Try hitting the computer on the side with a blunt object!!

Yeah seems that way.. But it happens often (on every system I've tested it on) and definitely isn't vague, it appears the Timer objects are firing slower than the set delay period.

Whatevs, just thought someone might've experienced the same thing before working with Timers, maybe even in a similar uni assignment.

Try asking @ Stackoverflow

I compiled it and ran it and it seemed smooth.

I'll take a look at the code in few hours.

Bump

Java running slow
What could it possibly be?

>>12
>>1
Also plz keep elitism to a minimum
So fuck off, faggot.

>>13
The link between those statements is tentative at best. Remember, not everyone follows the same train of thought as you, especially when it skips several steps and you don't care to explain it.
So fuck off, autist.

>>14
Fuck off, faggot.

>>15
I thought so.

>>16
Fuck off, faggot. You will NOT have the last word. This is the Citadel of Autism, you are the intruder.

>>13

Sorry but the JVM is slow, that is a completely unbiased opinion based on research. You may however compile Java to native machine code though.

>>17 could be in reply to any of the posts in half of the threads in /prog/.

>>17
Back to /b/.

>>20
Sorry, but I belong here.

>>21
Where's your sage, then.

>>22
Autists don't have to sage, duh.

>>23
Autists ALWAYS sage.

Autists likes to line things up and find them exactly where they left them, therefore a proper autist would always sage and throw a tantrum every time someone didn't.

An autist likes patterns, as you can see in the last few posts.

    public static final int UP = 0;
    public static final int LEFT = UP + 1;
    public static final int DOWN = LEFT + 1;
    public static final int RIGHT = DOWN + 1;   

Ugh,  I know their constants and it doesn't really matter performance wise, but this is much easier to read.


    public static final int UP = 0;
    public static final int LEFT = 1;
    public static final int DOWN = 2;
    public static final int RIGHT = 3;

>>27
IHBTEW

Looks like you could improve the collision detection. Right now you have rectangle hit boxes 3/4 the size of the circles they represent. This means you'll have collisions that are false positives and some that aren't detected.

Use the distance formula to get the distance between the two circles. If the distance is less than circleRadius + otherCircleRadius you have a collision.

    public boolean collision(Ball ball_1, Ball ball_2){
        double distance;
        int xDistance, yDistance;
        xDistance =  (ball_2.x-ball_1.x);
        yDistance = (ball_2.y-ball_1.y);
        distance = Math.sqrt(xDistance*xDistance+yDistance*yDistance); //distance formula  sqrt((x2-x1)^2+(y2-y1)^2)
        if(distance<0)//make sure we don't have a negative direction
            distance *= -1;
        if(distance<(ball_1.width+ball_2.width)/2)
            return true; //there was a collision
        else
            return false; //no collision
    }

>>29
Jesus, that is abysmal. I know it's Java, but you still shouldn't be programming.

You should randomize the starting positions of the enemies. That makes it impossible for the player to find  an always safe spot.

here's some random fps code that i found in some old test code of mine.  Good to get an fps option so you can see if your changes are making improvements.

        while(running) {
            // count Frames per second...
            lastTime = curTime;
            curTime = System.currentTimeMillis();
            totalTime += curTime - lastTime;
            if( totalTime > 1000 ) {
                totalTime -= 1000;
                fps = frames;
                frames = 0;
            }
            ++frames;

            update();
            render();
            paint();
        }

>Also plz keep elitism to a minimum
sorry, it is java. I can't

>java
>slow
gee, why I am not suprised

>>27
Yeah that's pretty anal. Most of the A3Constants class was provided with the assignment. I added a few things in there.
>>29
Thanks for the suggestion. My hitbox system is quite roundabout - there's a box 3/4 of the player, as well as a Point on each extremity of the player - The box or points make contact with the box of an enemyball (which are simply boxes around the circles). From all the playing I've done I haven't noticed any obvious false positives/negatives. Of course they're there, but in those cases a collision would happen in the next frame so it's not noticeable.
>>31
The enemyballs direction/speed is randomised every time they disappear. So the intial pattern is quickly broken, there is no 'safe spot'. I quite like the effect of them all starting in the corners.

>>29
You need to work on your math. That is hideous. Distance formula never returns negative values for real inputs.

>>33
They're more noticeable when the player is larger. You still have to look for it. It was interesting looking at how you did it though.
Didn't realize they gave you part of the code.
Did you do all of the graphics programming too? That had to be a bitch!

 >>34
Meh, code I was playing around with when I had free time at work. Just giving ideas.

>>35
I hope ``work'' doesn't require you to understand basic high-school math.

>>36
the code works....

>>37
You build Rube Goldberg machines instead of opening the door like a normal person, don't you?

>>38
More likely he rams his head into it until the hinges wear out.

you mad bro?

>>38,39

SAMEFAG

>>41 Are you mad, brother?