Flickering applet

Newbie & Debugging Questions
#1

My applet:

http://www.otcsw.com/applet/DreadMaze/

Has some weird flickering issues (you need to play a couple minutes in to see them). I’m guessing it has to do with the fact that I originally made it an app then changed some things last minute to make it an applet, but I was wondering if anyone had any pointers as to why this might happen. I’m sort of double buffering. I’m drawing everything to a BufferedImage which is drawn into a JPanel that is within another JPanel within the Applet. I tried removing the BufferedImage part and just drawing everything right into the JPanel but then it got awful.

I am only creating the graphics for the BufferedImage once, then I’m drawing to that. I considered maybe recreating and disposing the graphics every draw call. Any idea if that would help?

Thoughts?

EDIT - I removed the super.paintComponent call and that seems to help, but it still flickers. Not sure what the deal is.

#2

I saw no flickering. I can’t think why changing an App to an Applet would affect flicker.

Very fun! Really great to be able to click any square and have it automatically do the path. Maze traversal could be rather tedious otherwise.

My hero’s health bar was always empty. I’m assuming that is the red bordered long skinny rectangle. After a couple of games being scared and running away from everything, I started exploring the entire maze and battling and picking up ALL the experience and stuff possible on each level. But I never saw my health bar change, if that is what it was. Thus, it was really hard to judge when I had enough to battle a boss or run away. (Hard to tell, for me, who was a boss or not, too.)

Is it possible to have an enemy boss get generated in between the hero and the requisite shield or potion? I’m not sure if this happened or not, as I had trouble ID’ing what was what. Are the potions time-based?

It might be interesting if the places one went (and could no longer see) faded from sight (and memory…). It might be interesting to have multiple paths if it does occur that “random” generation creates an impossible obstacle (boss between you and potion). If one is too weak to battle and runs away into a blind alley, that seems like it can happen randomly, and thus, with nothing one can do or anticipate to avoid this situation, one might give up hope or interest.

But really cool, and all the animation looked smooth as far as I could tell.
Windows XP, Mozilla Firefox 8.0

#3

I had/have this issue: http://www.java-gaming.org/topics/how-on-earth-do-i-stop-my-applet-from-flickering/25013/msg/214084/view.html

What platform/browser/jre are you using?

#4

Wow that was really fun. I really liked the sounds effects :stuck_out_tongue:
No flickering for me, everything ran smoothly and beautifully.

#5

The flickering is terrible here on OS X, which I think is what you’re using, right Eli? Maybe Orangy’s on the right track with it being a platform-specific problem.

#6

See my comment here.

It’s a known issue with Mac OS. Essentially the applet can’t own the context it is drawing to, because the JVM plugin now runs in a separate process. To get around this it does some copy/update magic, but the downside is that applications that update constantly (like games), flicker horribly. You can drag the applet out into it’s own window (I don’t know specifically how, as I don’t use Mac OS, but you can), where it owns the Window, and so avoids the copy/update issue.

Other OS’s are unaffected because Mac OS has a more restrictive security policy around window ownership between processes. I believe on Mac OS they have to be explicitly given from one process to another, which browser’s currently aren’t built to do.

I believe the 32-bit JRE is unaffected, as the JVM doesn’t run in a separate process; this is simply because it is out dated. But these days most browsers will use the 64-bit JRE by default (I believe you can only get 64-bit on Lion), and some browsers will only use the 64-bit version (if I remember correctly, Chrome does this).

#7

No, Chrome is a 32-bit process and it only uses the 32-bit version of Java on Windows. I don’t know about Mac though.

#8

you really have something on your computer right?

#9

Excellent thanks for the comments everyone. Great to know it’s Mac OS X only (that is indeed what I’m running on, with Safari/Chrome).

One thing I notice is that when I reconstruct the back buffer BufferedImage (which happens each time you get to a new level) the buffering seems to stop for a little while. I’m going to maybe create a new BufferedImage every single draw call (which seems mighty costly, but this game is pretty cheap) and see if that helps.

Also reading over Orangy’s post and other linked info.

As for gameplay comments - you will know when you’re fighting a boss. It’s every 5 levels and it says beforehand very loudly “BOSS BATTLE!!!1!!!1!” just so you know. The boss is also extra huge. It is possible to die during the course of gameplay before you reach the boss just from getting unlucky - because items are random and enemies can pick up items, if one gets a shield then the whole group following them will get the shield (as it will drop only to be picked up the next) which can sometimes make it take 3 times as long to kill each enemy. This can whittle down your health and screw you over. Usually if you make it to your first level up and you defeat the first boss, you’re golden.

I’m not sure what’s up with the hero’s health bar, did anyone else have that issue? It works fine for me locally. Some of the smooth animations (I think the health bar increasing/decreasing is included in this) are not framerate-independent so if you have a particularly high or low framerate I could see maybe it screwing up. Oh well, that’s what happens with limited time.

#10

No problems here (win7 32b), but you already figured your issue with OSX :slight_smile:
Excellent game btw, I spent a lot of minutes on it, it’s really entertaining and has an excellent gameplay! Reminds me of some game I had on my Texas instrument back in school.

#11

FYI reconstructing the backbuffer every draw cycle does nothing but hurt the FPS. Oh well. :-/

I just included a link to download the JAR directly, as it’s also executable as an app anyway. So Mac users can do that.