Ok Egon, I added the same framerate scaling factor to the ship’s rotation, so you should be able to run your GPU at full throttle and still find Gravity Trap playable. Let me know if you find any more problems.
Oh, and I also modified the game so your the ships torpedoes cause more damage to your shields than before, to discourage indescriminate firing.
[quote]Ok Egon, I added the same framerate scaling factor to the ship’s rotation, so you should be able to run your GPU at full throttle and still find Gravity Trap playable. Let me know if you find any more problems.
[/quote]
Ship’s rotation speed seems to be fine now, but the bullets’ speed is not. After pressing fire, the bullets immediatly group together to a large white blob that eats me up… ;D
[quote]After pressing fire, the bullets immediatly group together to a large white blob that eats me up…
[/quote]
Serves you right 
I’m thinking that the problem is not the speed of the bullet, but rather the delay between shots, which I think is still frame based…so basically your shots are appearing on top of each other, which triggers the collision merge behaviour, thus building a large ball of antimatter in front of your ship.
Can you tell me what happens when you hit the space bar quickly and let go? Does the bullet get away from your ship? If you can fire single shots sucessfully, then I think I can fix this pretty easily.
I tried that (as fast as i could), but i wasn’t able to fire a shot that moved much more than one centimeter (on 19" monitor) away from the ship. After that, it always decided to head for my ship and after three of them…boom…
Edit: I’m sorry that i’m causing so much trouble just because i insist on leaving vsync disabled. But i think that i’m not the only one, so making it work on platforms without vertical synchronization could be worth it.
Egon,
Thanks for the details. The ship should have been able to survive 8 full strength shots, so that tells me that they are ganging up. I updated the code so that the firing rate is now based on the framerate as well. Let me know if this helps.
[quote]I’m sorry that i’m causing so much trouble just because i insist on leaving vsync disabled. But i think that i’m not the only one, so making it work on platforms without vertical synchronization could be worth it.
[/quote]
Don’t be sorry. I am a big fan of testing extreme cases…it has saved my butt more than once at work. Also, the quality of the game has improved in general I think. The guy with the 100fps machine will now get the same speed game as me with 60fps.
On a 1ghz pc, keyboard input had a 5-10 second lag before anything happened. Except for fire, which worked almost instantly (but maybe that was just an accident the few times I tried it).
Game is therefore unplayable - I’m assuming there is ONLY something wrong in the input handling; all the rest seemed OK, graphics were fine, animated smoothly etc.
There seemed to be a bit of flicker, but that might be because of your fullscreen stuff - see next para.
Bear in mind that fullscreen is not implemented for platforms other than Windows (allegedly; this seems to be true of linux and maybe MAC OS X? Solaris?). Dunno when sun intends to actually implement this feature in their VMs, but hopefully it’ll be soon. I tried it under linux, and it seemed to create a fullscreen window OK to run in, but this might/might not have anything to do with the problems I had. It’s really frustrating that they’ve added something to the API, and then not implemented it on the majority of java platforms; seems a little two-faced, given how much fuss they made about MS Java (ducks and runs for cover…this comment is tongue in cheek!).
[quote]Egon,
Thanks for the details. The ship should have been able to survive 8 full strength shots, so that tells me that they are ganging up. I updated the code so that the firing rate is now based on the framerate as well. Let me know if this helps.
[/quote]
It doesn’t help, the problem remains. Even if i manage to fire a single shot, the bullet moves away from the ship a few pixels and then it decides to head back for the ship. So i’m actually shooting myself and nothing else.
Arrrg! I’ll try to think about what else could be causing this. Do you still die after 3 shots? Also, if you accelerate, then turn 180 with the down arrow and fire, do the bullets get away?
[quote]Arrrg! I’ll try to think about what else could be causing this. Do you still die after 3 shots? Also, if you accelerate, then turn 180 with the down arrow and fire, do the bullets get away?
[/quote]
It needs some more shots now (or pressing the button a bit longer). I tried that maneuver you suggested, but i wasn’t able to let a bullet get away with it. The only time the bullets are getting away is, when i’m very close to an astroid (or whatever this red stuff is) and the bullets find it more attractive than my ship.
blahblahblahh:
Just need to clarify, are you experiencing keyboard lag on Linux or Windoze?
Egon,
Ok, think I got it. Gravity was pulling objects every frame, so when I slowed down the objects, they spent more time in gravity fields. I am now scaling the force of gravity to compensate. Let me know if it works.
[quote]blahblahblahh:
Just need to clarify, are you experiencing keyboard lag on Linux or Windoze?
[/quote]
Sorry, on linux. The only differences I’ve ever noticed between the sun windows and linux JVM’s are NIO implementations and that thread scheduling is different. This is expected, since they both use the OS scheduler instead of any VM-scheduler (according to hotspot docs), so this is a deliberate platform-dependency.
RGeimer,
Do you sleep() or yield() at least once per frame? If you don’t, events will back up in the queue until the OS ups the priority of the event thread high enough to run.
Jbanes,
I am doing a sleep(1) each frame before I process the keys. Here is my key checking code, let me know if you see anything weird:
private void setKeyFlags( KeyEvent e, boolean flagValue ){
switch ( e.getKeyCode() ){
case KeyEvent.VK_ESCAPE:
running = false;
break;
case KeyEvent.VK_UP:
upKey = flagValue;
break;
case KeyEvent.VK_DOWN:
downKey = flagValue;
break;
case KeyEvent.VK_LEFT:
leftKey = flagValue;
break;
case KeyEvent.VK_RIGHT:
rightKey = flagValue;
break;
case KeyEvent.VK_SPACE:
fireKey = flagValue;
break;
case KeyEvent.VK_CONTROL:
fireKey = flagValue;
break;
case KeyEvent.VK_ENTER:
if ( gameOver ){
gameOver = false;
level = 1;
startLevel();
}
break;
case KeyEvent.VK_S:
if ( flagValue ){
soundMgr.toggleMute();
// toggle sound on/off when s key is pressed
}
break;
default:
break;
}
}
public void keyPressed(KeyEvent e){
setKeyFlags(e,true);
}
public void keyReleased(KeyEvent e){
setKeyFlags(e,false);
}
// called during my render loop
private void checkKeys(){
sleep(1); // give the event thread a chance to run
if ( fireKey ){
spaceship.fire();
}
if ( rightKey ){
spaceship.turnClockwise();
}
if ( leftKey ){
spaceship.turnCounterClockwise();
}
if ( upKey ){
spaceship.thrust();
}
if ( downKey ){
if ( turnedAround == false ){
spaceship.turnAround();
}
turnedAround = true;
} else {
turnedAround = false;
}
}
[quote]RGeimer,
Do you sleep() or yield() at least once per frame? If you don’t, events will back up in the queue until the OS ups the priority of the event thread high enough to run.
[/quote]
I’ve noticed that when a system is under heavy load (CPU usage close to max, or maxed) then windows XP systems give the AWT event thread ultra-high priority, whereas linux systems give the AWT paint thread ultra-high priority.
It’s been the cause of some interesting problems in a game I’ve been doing - it took a while to realise why it behaved so differently between windows and linux on low-end systems, and virtually the same on high-end systems.
[quote]Jbanes,
I am doing a sleep(1) each frame before I process the keys. Here is my key checking code, let me know if you see anything weird:
... // called during my render loop
private void checkKeys(){
sleep(1); // give the event thread a chance to run
[/quote]
Yeah - this won’t work the way your comment suggests you hoped it would! I’ve found you can sleep for 10 milliseconds, or even more, and still the event thread gets very little running time.
I think that what you’re trying ought to work; I’m only saying it won’t based on recent experiences with 1.4.x, and maybe we’re both just making the same mistake somewhere else, and perhaps it does work actually ;D
OTOH, I’ve had the reverse problem on XP - if you’ve got a stream of events coming in, other well-behaved threads that are IDEAL for scheduling suffer starvation. This is normally the sign of a badly broken scheduler. I do not believe that the XP scheduler is that rubbish (after all, the NT and 2k ones were OK), so perhaps there is a problem with the latest Hotspot causing the OS scheduler to get confused? (I have no idea…I know how to write a really good OS scheduler, but I don’t know anything about how the current XP and linux ones work, and although I’ve asked Sun for details of how Hotspot in 1.4 interfaces to the OS scheduler, I’ve had no reply >:().