[quote=“CommanderKeith,post:20,topic:30557”]
Hmm, well I haven’t ran it on Linux or any other runtime environment, but on my system it is accurate using sleep!!! Really I should use the multimedia timer, which I probably will end up using
By the way, your jnlp file doesn’t work because you’ve named it castles.xml instead of castles.jnlp!
I just changed it after downloading the .xml file, renamed it and it worked, so you did everything else perfect
Cool game I’m playing it now 8)
This game is quality, did you think it up by yourself?
I really like this game! Here are some of my comments:
- The menu at the beginning is terrible, please make something that uses mouse input.
- It would be useful to see the cost of each unit when you mouse-over the button.
- It takes ages to destroy the opponent.
- More units, maybe flying ones
This game is a adaptation of Rescue Raiders…en.wikipedia.org/wiki/Rescue_Raiders
A small variation from original gameplay…Try SteamBrigade…www.pedestrianentertainment.com/
Thanks for the comments… 
btw this is not the complete game…just the prototype…i ll post the pictures of the work going on for the full game as soon as i get my blog up and running…
Don’t use Thread.sleep too!! It breaks the synchronisation with the graphics card. On my game, the FPS was twice lower when I used this.
On the other hand, when I click on the link, the jnlp file is displayed. If you want to solve it, watch my own config file which is included in a PHP file when you click on the link allowing to launch my game.
All of our games use this code, in LWJGL’s Display.sync() method:
/**
* Best sync method that works reliably.
*
* @param fps The desired frame rate, in frames per second
*/
public static void sync(int fps) {
long gapTo = Sys.getTimerResolution() / fps + timeThen;
timeNow = Sys.getTime();
while (gapTo > timeNow + timeLate) {
try {
Thread.sleep(1);
} catch (InterruptedException e) {
}
timeNow = Sys.getTime();
}
if (gapTo < timeNow)
timeLate = timeNow - gapTo;
else
timeLate = 0;
timeThen = timeNow;
}
and we don’t seem to have any problems at all, and our games run at only a small % of CPU.
Cas
I’m sorry but I checked what I said. Sometimes, the loss of performance can be lower than mine but there is a true loss. If you think I’m a lier, take my source code, add this “try {Thread.sleep(1);} catch (InterruptedException e) {e.printStackTrace();}” inside the main while loop in the method called runEngine(), in the class called “GameModel”, in the package called “main”, recompile all, execute the game and the FPS will be twice lower. I assume JOGL uses the same mechanism in the class called “FPSAnimator” but I’m not sure. However, I don’t use this class at all. I try not to give bad advice. I think that I gave piyush_3Squares a quite good advice. Your method is reliable but using Thread.sleep(1); may cause a loss of performance on my view. Maybe it depends on the context.
Umm yeah, you get a performance loss of 1ms when you use Thread.sleep(1) but that’s the whole point of throttling, isn’t it ;D
Of course, if you’re not careful with the amount of sleeping, you might miss frames when you make use of vsync, but that’s not Thread.sleep(1)'s fault.
FWIW, I’m using the same code for throttling as princec, no problems at all: Steady framerates, no performance loss.
Oh, and there’s really no need for e.printStackTrace() (just commenting on it since you posted that in bold as if it were important).
I don’t think I use vsync. When I use nanosleep instead of sleep even for a very short time, the performance falls hugely. Maybe I don’t express correctly what I mean. It is not a bug but I’m not sure it is good to use it here.
I find it cleaner. If there is something wrong, you don’t hide it silently.
Don’t forget that it only sleeps if there’s actually time to spare. If it’s using all 17ms or whatever to render then it’ll never sleep. So basically only wasted time is wasted anyway.
Cas
[quote=“princec,post:32,topic:30557”]
Well, sort of… sleep() gives an ‘ideal’ sleep time not a guaranteed one, so it might be longer (and usually is for small values). You must call it though or things go bad. I did loads of tests and found that (on a typical system) sleep(10) was faster than yield() or sleep(1) because the JVM needs a certain amount of time (>1ms && <10ms) to keep things stable. Anyone done more research on this? It’d be good to have some hard facts!
I agree with you and that was why it tried to use “static void sleep(long millis, int nanos)”. The JVM does not check if a VBO is being transfered and things like that on my view (related on the GPU) so the things might be unstable if you use very big VBOs (that’s my case) instead of splitting them into smaller ones. When I tried to check what sleep(long millis) was doing, I realized that often the true sleep time was close to exactly 6 ms when I asked a sleep for less than 6 ms. It is not new, it was the case in C, it is not a limitation of Java.
If y’all look at the code there the sleep is only called if the time since the last sleep is less than the required frame duration… so if your frames are taking longer than 17ms at 60Hz for example, it doesn’t call sleep…
Cas
cant play ???
[quote]La page XML ne peut pas être affichée
Impossible d’afficher l’entrée XML en utilisant la feuille de style XSL. Corrigez l’erreur, puis cliquez sur le bouton Actualiser ou réessayez ultérieurement.
La balise de fin information ne correspond pas à la balise de début description. Erreur de traitement de la ressource http:…
</information>
------^
[/quote]
It works in command line.
Enter "javaws " and the URL ending by .jnlp and it works.
thanks, it’s work
Could well be in some cases, but I’ve found this sleep(10) thing in J2ME as well - I think it’s the garbage collection looking for loose handles. Just a side-effect of java I guess…