Better Debugging
I've been having a problem for a few weeks with my game... I originally posted it at:
http://forum.java.sun.com/thread.jsp?forum=406&thread=305086
I still can't get it, and I haven't gotten any tips that have been all that useful, so I'm going to change the question I'm asking...
I know that for some reason, at certain times I'm getting long delays between my rendering loop calls. I'm guessing that there's a problem with a threading conflict or what not, but how do I track down exactly what's causing it? Short of spending $700 or a profiler, is there any way to tell what's interrupting (or slowing down) my painting?
[662 byte] By [
cbisbee] at [2007-9-27 23:06:10]
Probably doable... http://www.junit.org/ http://supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/junit/junit.html
Hey look, you need to understand your code. not better debugging.
Reread the full screen tutorial, you don't mix fullscreen active rendering with panels passive rendering.
I had a quick look at the code, the main problem i noticed was starterPanel. Instead should be a JDialog. And need to group you init code more, try making a Main class that is the game entry point, which inits all your static stuff and sets options, then shows the dialog. Then dialog then shows the game frame.
Think hard about grouping functions and layers of your game more logically.
There are too many classes doing one thing.
Alright i was a bit harsh, but help was offered before. If you did't resolve your problem, ask another question, but appreciate the help.
That said it looks like good project overall, look forward to see it.
Harley.
> Reread the full screen tutorial, you don't mix
> fullscreen active rendering with panels passive
> rendering.
Honestly, I must've read the thing about 20 times by now. While the VAST majority of the tutorials have been excellent and very helpful, this particular one has not helped me much.
> I had a quick look at the code, the main problem i
> noticed was starterPanel. Instead should be a
> JDialog. And need to group you init code more, try
> making a Main class that is the game entry point,
> which inits all your static stuff and sets options,
> then shows the dialog. Then dialog then shows the
> game frame.
OK, I understand what you're saying finally... Don't use any Panels at all because they'll cause issues with mixing passive/active rendering. I had thought that if I had all the components rendering actively, I'd be ok, but I guess not. So, I should paint directly to the Frame while in my game loop.
However... I STILL don't like the idea of starting the game with a separate frame/dialog/whatever. I've seen a lot of games where their main menu uses a full-screen approach... Granted, none of them have been in Java to my knowledge, but it SHOULD be possible.
The practical side of not wanting to do it, however, is more that I want to be able to do similar things later on in the game. For instance, I eventually want to have towns at various points in the world, and when you enter one, it'll take you off the world map and into a "Town" screen, for instance. If you've ever played a game like Elite or Pirates!, that's the sort of thing I'm talking about. I really don't want to have to shut down my full screen frame, pop up another undecorated Frame or something, and then have to start up the full screen frame again. It seems like there should be some better way.
> Alright i was a bit harsh, but help was offered
> before. If you did't resolve your problem, ask
> another question, but appreciate the help.
I'm sorry if I came off as being unappreciative... Part of it was that I misunderstood what you were saying about the Panels. After rereading it, I think I get what you're saying now, and it is helpful.
Honestly, I'm a bit frustrated with the forums too. I've gotten about 3 replies on what I consider to be a legit problem in what, a month? It bothers me that ppl would rather spend their time slamming kids that try to get their homework done for them instead of trying to help out with a real problem. Not that I think I somehow have the right to expect help, but it annoys me that some ppl have priorities that are so foreign to me. I'm sorry if that frustration led to me being a little short with you.
I do greatly appreciate the help, and you've certainly given me a lot to think about... I probably will end up starting the game with a JDialog for awhile at least, just so I can move on to other things. Like I said, I'd prefer a different long term solution, but I need to start banging my head on something else for awhile.
> Honestly, I'm a bit frustrated with the forums too.
> I've gotten about 3 replies on what I consider to be
> a legit problem in what, a month?
I have noticed something similar- I will answer what I can here but I don't know very much and it seems that a lot of other people have similar problems or simply cannot be bothered. I have noticed that on average there is a more defined community with more technical expertise over at http://www.javagaming.org - well worth a visit.
I would say the reason you havn't been overwelmed with replies is due to the nature of your problem.
From what I've read in your previous posts, it sounds like your problem is more with the design of your program, than a specific technical issue. (the latter being far ezier to answer)
The best solution is for you to work through it yourself and develop a better design. Then next time, you'll be more experienced, and know what not to do :)
Abuse at 2007-7-7 14:42:45 >
Hi, i agree that Dialogs arn't really the best way to go.
I used it on the first version of my game, now im rewriting it to use active rendering. The only Swing component is the GameFrame. There is a option screen which has a render(), which then calls render() on my custom buttons. The frame also is its own mouse listener, and passes events to the option screen.
I think its the best way to go. Use less memory than swing version, and looks good.
Now this is still a work in progress, updating prety much everything.
The main part thats working is the splash screen, and option screen. The actual game is still being worked on.
I really like the new starfeild with real 3D points,and scrolling text, the last one was just a dialog with a static picture at the top.
http://www.froggy.com.au/harleyrana/java/SpaceBattleEarth.zip
only 264k with source.
Have a look at OptionScreen, and util.GButton.
The code is pretty messy, but it give the idea.
Let me know what you think about the intro, and any questions.
Harley.
I tried running the game using the "run" batch file provided, and it didn't work. It's an IllegalArgumentException thrown by the SpriteStore.getBIImage method, line 187. Maybe I'm doing something stupid... I don't know.
I've removed the Panels from existance, and am now trying to paint directly to the Graphics of the JFrame itself. And, of course, it's still not working right. You can find that jar at http://c3po.lpl.arizona.edu/~biz/pirates/Pirates-latest.jar
I've also found out that my game won't run at all under Linux... Something weird happens to the AffineTransform. Another thing I'll need to look into.
And Abuse... OK, even if it does fall under the "design" issue category... I'm a relatively new programmer... I could certainly use advice on the program design as well. Sure, advice on technical issues is quick and easy, but is "here's an overview of how I'd go about this problem" really all that difficult?
Hi, it was't really tested, so it wasn't your fault.
Try and redownload
http://www.froggy.com.au/harleyrana/java/SpaceBattleEarth.zip
I striped all the non essenstial stuff out.
The default Size is 1280*1064, but you can change it in game.xml
Hope it works now, it looks cool!
Harley.
Especially impressed by the cool explosion...
Cool. The explosions are particle systems.
Still havn't finished tweaking them, but the basic system is done.
The main reason i posted it was to show it is possible to have active rendering with custom gui interface. You just need to make your own components, but look at the button class, its only about a page height.
Harley.
Right, I get that now, but... I still haven't gotten anywhere. I have a top level frame with things drawn to its graphics, and no other components... But it still gets really jerky. And again, the really odd thing is, all I have to do to fix it is to not render the main menu graphics and have the game automatically load when you run it. Two different approaches and the same result...
Id look at your run() to see how the options are being updated, and rendered.
Some thing like
run
if !paused & !optionsShowing
updateGame(time)// the game stands still with options showing
renderGame(g) // we always render the game
if optionsShowing
updateOptions(time) // only if the options are animated
renderOptions(g)// overlay options over the game withtransparent colors
Well you get the idea. Its really a design question.
There always a better way if its running slow.
Harley.
Right, but my problem is... Nothing's consistently slow. Here's a "debugging" setup for my run():
public void run(){
long lastTime=System.currentTimeMillis();
while(running){
long time=System.currentTimeMillis();
if(time-lastTime>=TIMEPERIOD){
Graphics2D bg2=(Graphics2D)bi.getGraphics();
System.out.println("Created BGraphics: "+(System.currentTimeMillis()-time));
switch(GameState){
case MAINMENU:
gsp.render(bg2);
break;
case GAME:
pg.update(bg2, time);
System.out.println("Painted BGraphics: "+(System.currentTimeMillis()-time));
break;
}
bg2.dispose();
System.out.println("Disposed BGraphics: "+(System.currentTimeMillis()-time));
lastTime=time;
Graphics2D g2=(Graphics2D)main.getGraphics();
System.out.println("Created ScreenGraphics: "+(System.currentTimeMillis()-time));
g2.drawImage(bi,0,0,null);
System.out.println("Painted SGraphics: "+(System.currentTimeMillis()-time));
g2.dispose();
System.out.println("Disposed SGraphics: "+(System.currentTimeMillis()-time));
}
else try{
Thread.sleep(lastTime+TIMEPERIOD-time);
//System.out.println("sleep "+(lastTime+TIMEPERIOD-time));
}catch(InterruptedException ie){}
}
}
And here's a sample of the data that I collected:
Run A| Run B | Run C | Run D | Run E | Run F
Created BGraphics 0|0 |0 |0 |0 |0
Painted "4016| 3995 |0 |0 | 3996 |10
Disposed " 4016| 3995 |0 |0 | 3996 |10
Created SGraphics7992| 3995 | 3986 |0 | 3996 |10
Painted "8012| 8011 | 4006 | 4005 | 4006 | 4016
Disposed " 8012| 8011 | 4006 | 4005 | 4006 | 4016
These are from 6 consecutive passes through the loop. Essentially, 5 different results (D and F are equal but for resolution).
And of course, if I start directly in GAME mode, I get a smoothly running game. The biggest number I saw was 141 ms, which is a heck of a lot better than 4-8 seconds for one loop pass.
This brings me back to my original conclusion... That my problems are caused by either conflicting threads or by garbage collection or something like that. If it were slow code in these methods, it would show up on a regular basis. And to debug that, I need to know better debugging techniques.
Have you tried running your code with the -Xincgc option? This will enable incremental garbage collection, which should smooth out any long garbage collection pauses and give you a better average frame rate.
I guess it's not garbage collection then, because that doesn't help a bit. Thanks for the idea though.
Are you creating any objects in either of the update()'s?also try getting rid of dispose(), you don't always need it.The slow down might be in the menu update(), try cut most of the stuff out of it, and then test for speed.Harley.
