Making my sequel to my game, now with 1 player! big issues though. :’(
To be frank, I have no idea what is going on.
I start my game all hunky dory, 160 FPS.
Afterwards, it studders and goes down to a lowly 5-15 FPS.
In those frame hogging moments, some textures are replaced with others.
Then it chrashes. This is my code for the main class.
http://pastebin.java-gaming.org/3b53079405f
down is my error log from JVM.
http://pastebin.java-gaming.org/b5309804f58
- Display.sync() needs to be called each frame, and not at the start.
- Using an empty try-catch to ‘avoid’ null-pointers is bad.
- You are calling updateFPS several times a frame.
- Your are updating in the draw method? Please separate logic and rendering.
- PLEASE USE OOP!!
Other than that, I can’t help you.
- thanks, no wonder.
- True, need to clean up after debugging
- I am notorious for leaving behind tutorials from youtbubers in my code, without cleaning it up afterwards. In result that whole FPS thing is more of a leftover thing.
- The draw method should be renamed update(), granted.
- Did you skip this?
- I do, this is only 1/15 classes I have.
I feel ashamed for having messy coding now :’( (no good for the client anyway.)
I’ll re-upload a cleaner version, and simply wait for replies, if my problem isn’t already fixed.
I did have a point 5, but I removed it since it was a part of point 6.
All you code is being called from the main() method. You shouldn’t really be doing that as it makes it harder to follow stack traces (in case you cut out some lines). Not to mention that you should be using more OOP.
[quote]4) The draw method should be renamed update(), granted.
[/quote]
NO! I said separate logic and rendering.
Btw, it’s spelt crash, not chrash.
XD ok, fine, more work on cleaning… got it.
I would recommend developing better habits from the beginning, especially since you can do a better job with less effort and fewer lines of code. The idea is to catch exceptions as late as possible by using throws instead of catch. Let them propagate up until either a) you can do something to recover from the error or b) can’t throw it any further.
Whatever you do, never just let your code carry on running. You’ll just get more errors later on, usually in the form of an avalanche of NullPointerExceptions which make debugging even more difficult
Never let your code carry on running? Isn’t that the point of stress testing? If my code didn’t need to carry on running, It wouldn’t be a game. Problem is there are no Exceptions, but rather Java Virtual Machine crashes. which doesn’t pinpoint exactly where the fault was caused. 
There are no exceptions because you silenced them all with your empty catch blocks.
Whenever you have a try-catch, make sure you always put the stack trace somewhere, whether you log it or just print it out.
And if you have a try-catch for a RuntimeException, you are likely to be doing something wrong (unless you’re using I/O).
Line 492 achieves nothing but turning off an exception. That’s like turning off a fire alarm and praying that the fire doesn’t spread. Even if you were to put a printStackTrace or something similar in there, it’s still no better than turning off the fire alarm and writing “there’s a fire” on a post-it note and walking away. At some point in time the program will fail spectacularly. You’ve just delayed the inevitable.
If your program starts to fail, you want it to stop so you can see what is causing the failure. Even in stress testing, you want to know why your program reached it’s limit. Only then can you decide if it’s a problem you can deal with.
All too true, removed that exception, as it was no longer needed, added printstacktraces to all exceptions I did need. I will finish up, and upload the new version.
NO! I said separate logic and rendering.
[/quote]
Oh well… separating logic and rendering is even much more than only making two methods for it. It’s certainly helping, just like every other kind of structuring code and abstracting stuff away and putting stuff in methods, but it’s not what all those people saying ‘separate logic and rendering!’ say.
[excursion]
What those people are talking about is that logic is working without rendering. This means, you could simply remove the rendering step and let the updating to what it is supposed to. This also means, that no LWJGL (or any rendering-relevant code or lib) is used during the updating.
This comes in incredibly helpful if you want to network your game. That’s what the MVC patterns were made for. It’s awesome’er than I thought 
[/excursion]
EDIT:
Added render conservation system, not rendering if texture is outside the screen (still doesn’t solve lag),
Removed much not needed code,
Separated drawing from updating gameobjects,
New code here:
http://pastebin.java-gaming.org/530909f4850
Crash is still the same.
What exceptions are you getting now?
(If you get any)
Try cutting down on the amount of stars and asteroids etc. and see if that helps.
@matheus23: For me at least, separating logic and rendering methods seems to separate logic and rendering completely. I assumed it would be the case for everyone. (Now I’m wondering how you could possibly mix logic and rendering when they happen in different methods)
No exceptions, simply java crashing. A quote from the JVM error log
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
While stress testing, I tested prior to this post, removing entities like meteors, stars, the planet, and removing any one of them still lead to a crash. I suspect it is slick util, as the player’s texture will always switch to a weapon texture, just before crashing. :clue:
What happens when you comment out the rendering code (glBegin-glEnd)?
Its already this:
public class Entity {
protected final Sprite sprite;
protected final Vector2f pos;
protected final Vector2f velocity;
public Entity(Sprite sprite) {
this.sprite = sprite;
// ...
// do stuff with pos and velocity
}
public void update() {
pos.add(velocity);
}
public void render(SpriteBatch batch) {
sprite.draw(batch);
}
}
Does this code run without LibGDX? Nope. We need a Sprite in the constructor. We cannot let it run without having LibGDX / A sprite.
The ‘correct’ way:
// Horrible code formatting. Formatted for low LOC
// The model:
public class Entity { protected final Vector2f pos, velocity; /* more stuff */ }
// The controller:
public class EntityController {
protected final Entity player;
protected boolean isMoving;
// ...
public void update(Input input) {
applyInput(player);
}
public boolean isMoving() { return isMoving; }
}
// The view:
public class EntityView {
protected final Sprite playerMoving;
protected final Sprite playerStanding;
public void render(EntityController contr, SpriteBatch batch) {
Vector2f entityPos = contr.getEntity().getPos();
if (contr.isMoving()) {
playerMoving.draw(batch, entityPos.x, entityPos.y);
} else {
playerStanding.draw(batch, entityPos.x, entityPos.y);
}
}
}
People argue a lot about how MVC for games should look like… This is one possibility for separating logic and rendering.
stress testing now.
The game ran, it stopped, no error message, huge lag, no JVM crash log. Eclipse thought the game was still running, had to stop it on eclipse.
Use jvisualvm to find the bottleneck.
It should be part of the JDK.
jvisualvm?