FPS/optimizing thoughts
OK I tried it, but it dies giving some openAl error (or that's what it sounded like to me, but bear in mind I don't know Java).
Ok, i have tested it and it looks nice.
The spaceship and powerups moves smooth, but the background moves choppy, especially when my ship moves fast. My FPS is at a steadt 86fps, so that is no problem. However, i now and then get graphical artifacts on the screen in the shape of white bars flashing on the screen.
Ill try to describe them as well as i can. They look like horizontal and verical bars that are a few inches wide. They appear sporadically, and usually only stay for a frame or so, so they could be tearing.
I tried to shoot or pickup the powerups, but couldn't, but maybe that isn't in the game yet, so it's probably not a bug.
System Specs:
------------------
Intel P4 3.4GHz Hyperthreading
2GB RAM
NVidia GeForce FX-5950 Ultra
Creative Audigy 2 ZS Platinum Pro
The spaceship and powerups moves smooth, but the background moves choppy, especially when my ship moves fast. My FPS is at a steadt 86fps, so that is no problem. However, i now and then get graphical artifacts on the screen in the shape of white bars flashing on the screen.
Ill try to describe them as well as i can. They look like horizontal and verical bars that are a few inches wide. They appear sporadically, and usually only stay for a frame or so, so they could be tearing.
I tried to shoot or pickup the powerups, but couldn't, but maybe that isn't in the game yet, so it's probably not a bug.
System Specs:
------------------
Intel P4 3.4GHz Hyperthreading
2GB RAM
NVidia GeForce FX-5950 Ultra
Creative Audigy 2 ZS Platinum Pro
Author
mrbastard: I can't think of anything which could cause and OpenAl error =/
Allmight:
You should be able to shoot but there's no collission detection yet, so nothing happens when you "pick up" the power ups
Those bars appear because my logic behind teh background is kinda crapy. I have to do something about that. The background is built up by really big tiles 1024x1024 px. So those bars appear sometimes between the tiles.
I know of the choppyness of the background, but I don't really know why it's caused. You said the ship moves smooth but not the background. I know what you mean, it's exactly the same on my computer. The problem is, that the ship doesn't move at all. It's fixed in the center of the screen and I mvoe teh background relative to the ship. So I'm kinda confused when to look for why the background gives the impression of moving choppy relative to the screen, but smooth relative to the ship =/
Allmight:
You should be able to shoot but there's no collission detection yet, so nothing happens when you "pick up" the power ups
Those bars appear because my logic behind teh background is kinda crapy. I have to do something about that. The background is built up by really big tiles 1024x1024 px. So those bars appear sometimes between the tiles.
I know of the choppyness of the background, but I don't really know why it's caused. You said the ship moves smooth but not the background. I know what you mean, it's exactly the same on my computer. The problem is, that the ship doesn't move at all. It's fixed in the center of the screen and I mvoe teh background relative to the ship. So I'm kinda confused when to look for why the background gives the impression of moving choppy relative to the screen, but smooth relative to the ship =/
Ah, didn't notice the ship was centered, but now that you mention it. But the powerups move smooth as well, so that part of the code seems to work fine.
Maybe it has to do with the size of those bacground tiles, they get shuffled from system memory to gfx mamory. So when a new tile shows up on the screen you get a performance hit. But then the fps should drop as well. Hmmm. Are you moving the background at a fixed rate, or do move the background based on how much time has elapsed since the last frame? If you move it with a fixed number, then it probably gets choppy since every frame dont take the exact same time. If so, try to use a formula that use elapsed time as a base.
// Allmight
Maybe it has to do with the size of those bacground tiles, they get shuffled from system memory to gfx mamory. So when a new tile shows up on the screen you get a performance hit. But then the fps should drop as well. Hmmm. Are you moving the background at a fixed rate, or do move the background based on how much time has elapsed since the last frame? If you move it with a fixed number, then it probably gets choppy since every frame dont take the exact same time. If so, try to use a formula that use elapsed time as a base.
// Allmight
well, it crashes the jvm and the log mentions ALut a lot.
I've pm'd you the log in case it's any use.
I've pm'd you the log in case it's any use.
Um, just did a seccond check, and noticed that the other powerups actualy are as choppy as the background.
// Allmight
// Allmight
A few things come to mind from a Java perspective as to what could cause your problem. Recently the guys at LWJGL found a problem with System.nanoTime(), where on Hyper-Threaded processors it would report normal, accurate times, but would then spew out one insanely long time causing a good jerk in anything that is based on timing. You could try using something like LWJGL's built-in timer (which I think has fixed this issue), or the GAGE timer.
Second, creating/releasing too many objects during the game loop can cause the garbage collector to run. On a profile of frame times of my 3D engine, I drop about 1 frame out of every 50 due to this, but I haven't made any effort to optimize.
These are some of the more difficult things to track down, but it could just be something in your OpenGL or math code. Do you use any of Java's built-in math functions, i.e. sin, cos, tan, atan, sqrt, etc? When doing a test of Java's built-in sin(), versus a library I implemented natively in C++ using JNI, I found that Java's sin() is about 7 times slower. Calling this a lot could slow things down.
Bottom line: post some code.
Second, creating/releasing too many objects during the game loop can cause the garbage collector to run. On a profile of frame times of my 3D engine, I drop about 1 frame out of every 50 due to this, but I haven't made any effort to optimize.
These are some of the more difficult things to track down, but it could just be something in your OpenGL or math code. Do you use any of Java's built-in math functions, i.e. sin, cos, tan, atan, sqrt, etc? When doing a test of Java's built-in sin(), versus a library I implemented natively in C++ using JNI, I found that Java's sin() is about 7 times slower. Calling this a lot could slow things down.
Bottom line: post some code.
perhaps its choppy on the laptop cause of speedstep or something
if u use queryperformancecounter under windows this returns incorrect results with a lot of laptops and new desktop processors
if u use queryperformancecounter under windows this returns incorrect results with a lot of laptops and new desktop processors
Author
Allmight:
Actually..teh FPS could drop. I think you have v-sync on, that's why you get a fixed 86 FPS. I have the same thing. When I disable v-sync, i get around 224 FPS and then it usually goes up and down.
Anyways, I have to change how that background works. It's a really bad idea having 1024x1024 px tiles. That's probably why it flickers sometimes when new tiles show up. I did a different technique before where I had a smaller "world". Only one 1024x1024 tile and instead of moving the diles relative to the ship, I changed the s/t coordinates of the texture. Since that was much smaller texture than these one I have now, it should have been choppy but it still was. I think it might be my physics code which calculate the position of the background for the next frame. Though I calculate it depending on how much time has gone since last iteration. I don't use a fix sleep-value for the thread. I might have to take a look at that.
mrbastard:
I'll take a look at the log, see what happens. thanx
Optus:
I use Jogl and Not LWJGL, I'm not very familiar with the latter one. And I use the ms timer, not the nano one. The ms one is actually worse so maybe I should change like you suggested.
I do a lot of Math calculations: sin, cos, sqrt..too many. Maybe I should get a library instead?
I really don't want to post some code yet. I'm to ashamed, haha. I'll do it when I get it a little bit more structured :P
Thanx for the advice guys...really helps a lot...
Actually..teh FPS could drop. I think you have v-sync on, that's why you get a fixed 86 FPS. I have the same thing. When I disable v-sync, i get around 224 FPS and then it usually goes up and down.
Anyways, I have to change how that background works. It's a really bad idea having 1024x1024 px tiles. That's probably why it flickers sometimes when new tiles show up. I did a different technique before where I had a smaller "world". Only one 1024x1024 tile and instead of moving the diles relative to the ship, I changed the s/t coordinates of the texture. Since that was much smaller texture than these one I have now, it should have been choppy but it still was. I think it might be my physics code which calculate the position of the background for the next frame. Though I calculate it depending on how much time has gone since last iteration. I don't use a fix sleep-value for the thread. I might have to take a look at that.
mrbastard:
I'll take a look at the log, see what happens. thanx
Optus:
I use Jogl and Not LWJGL, I'm not very familiar with the latter one. And I use the ms timer, not the nano one. The ms one is actually worse so maybe I should change like you suggested.
I do a lot of Math calculations: sin, cos, sqrt..too many. Maybe I should get a library instead?
I really don't want to post some code yet. I'm to ashamed, haha. I'll do it when I get it a little bit more structured :P
Thanx for the advice guys...really helps a lot...
By ms timer, do you mean System.currentTimeMillis(); ?
Seriously do not use this, if it is the case.
Seriously do not use this, if it is the case.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement