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

1. Display.sync() needs to be called each frame, and not at the start.2. Using an empty try-catch to 'avoid' null-pointers is bad.3. You are calling updateFPS several times a frame.4. Your are updating in the draw method? Please separate logic and rendering.6. PLEASE USE OOP!!

1) thanks, no wonder.2) True, need to clean up after debugging3) 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.4) The draw method should be renamed update(), granted.5) Did you skip this?6) 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.

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).

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.

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.

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]

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)

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.

@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)

1. Use a normal ArrayList. For iterating, create one copy, and iterate over that. Any adds/removals should be done to the original list2. You are loading textures EVERY FRAME! I'm not entirely sure how SlickUtil works, but maybe you should save the textures somewhere.

Found some new stuff:1. Use a normal ArrayList. For iterating, create one copy, and iterate over that. Any adds/removals should be done to the original list2. You are loading textures EVERY FRAME! I'm not entirely sure how SlickUtil works, but maybe you should save the textures somewhere.To lauch jvisualvm (Windows) Alt-R, type in jvisualvm, press enter.Find you application, double click, look at the graphs etc. do some sampling/profiling. Find wheter it's CPU or RAM usage that's causing the problem.

1) A normal arraylist gives me a ConcurrentModificationException. I read that I can't catch it, because catching it is only for debugging, and shouldn't be part of the final code.2) I am saving the textures in the objects' classes..? the only time I am loading textures is in the creation of new objects, or while evolving a star(nebula-star-pulsar-etc..)3) I don't think jvisualvm works with windows XP

1) A normal arraylist gives me a ConcurrentModificationException. I read that I can't catch it, because catching it is only for debugging, and shouldn't be part of the final code.2) I am saving the textures in the objects' classes..? the only time I am loading textures is in the creation of new objects, or while evolving a star(nebula-star-pulsar-etc..)3) I don't think jvisualvm works with windows XP

2. You evolve all stars every frame. Didn't see the random.nextInt().But still, you need to save the textures somewhere, you're loading the same texture over and over again each time you call loadTexture().

Just finished stress testing, frames still dropped, but at exponentially slower rates than before . I think my issue has been solved, I all need is to implement the changes . I will use the Array List, and maybe make an enum of textures, or simply define all the possible textures in the class, not just the default. So many months of development went down the drain after only ~11 days of programming . I'll write in the needed code, stress test, and tell you the results.

1) A normal arraylist gives me a ConcurrentModificationException. I read that I can't catch it, because catching it is only for debugging, and shouldn't be part of the final code.

I'm not sure I get what you're saying. Catching is not for debugging. Catching is for trying to recover from or do something useful with an error. If you can't recover from the error, don't catch it. If you want to debug potential errors, set your debugger to break on exceptions.

As for the ArrayList problem, use an iterator to traverse a collection if you think you might want to remove something from the collection. I've mentioned it before here with an example of how it's done.

As for the ArrayList problem, use an iterator to traverse a collection if you think you might want to remove something from the collection. I've mentioned it before here with an example of how it's done.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org