Look at the code, its exactly the same as before, just that the Thread is started from your other class. I edited it because (without knowing your architecture), it just felt a little more right to me

Thanks for the help.

While I've been waiting a few minutes in between page refreshes for the answer which you've provided I came up with yet another question to ask anyone reading. I've seen that without double buffering there is very noticeable (I'll describe it as stutter I guess) when for example, moving a string by -10 pixels per few milliseconds on an applet. Because of this stutter I noticed when working with an applet awhile ago I decided to look up some information about buffering in Java; In my little google search I ran across http://c2.com/cgi/wiki?DoubleBufferedGraphicsInJava which, in my opinion, basically said that double buffering is a waste of memory and that you shouldn't use it.The previously linked (article?) made me a bit unsure about using a double buffer. Is a double buffer the best way to get rid of 'stutter'?

I honestly haven't read the most of the earlier posts, but what I do is make my rendering logic part of a class that implements Runnable and extends Canvas. Then at program startup I create a JFrame, attach my rendering class to it (as it's a canvas), pack, show the frame, then start the render control as a thread:

Please note that this is inside of a render() type function, not inside the run() directly, so the "return" only leaves the local render function, not the top level loop.

CreateBufferStrategy does the best it can to double buffer using your system's hardware acceleration, but hides the actual implementation from you. You simply draw what you want in the DRAW LOGIC HERE part, and the rest will be flicker free. There is no memory wasted because, at least with my (2), it only has a couple buffers.

You may want to read up more on threads, and in particular implementing classes as Runnable. With that and a global ExecutorService object, you can have worry-free threading where needed with minimal coding.

Not too much has been done in the past two days; I've spent around 5 or so hours attempting to figure out/implement collision but so-far my attempts have failed, if anyone can give me a few pointers it will be appreciated. Although I've not done too much I did manage to get keyboard controls working as I've previously stated and I've just recently expanded them so that you can move with either WASD or the Arrow keys.

It took a small chunk of my Christmas vacation but I finally managed to figure out a way to draw a map onto the JPanel. There are a few bugs to iron out and a lot to expand on but at least the basic idea worked.

Not too much has been done in the past two days; I've spent around 5 or so hours attempting to figure out/implement collision but so-far my attempts have failed, if anyone can give me a few pointers it will be appreciated. Although I've not done too much I did manage to get keyboard controls working as I've previously stated and I've just recently expanded them so that you can move with either WASD or the Arrow keys.

Pretty simple actually... If you don't want to have fancy stuff with Polygons and rotation and what-not, simply use java.awt.Rectangle. To test whether two rectangles collide use

Thanks for the collision tips. Over the past few days I've been thinking about easy ways to create a map and load it, after a bit of thought I decided that creating a text document with numbers to reference specific tiles would be best; After that I took some time tonight and figured out how to read from a text document and sort the tiles quickly.Now to write and test the actual tile loading!

Edit: It just occurred to me that loading a map this way, due to it's simplicity, would actually allow me to create a simple map editor very easily. I <3 Getting ideas from random places!

I'm back from my little two week long Java break. I'm more-or-less just throwing around random ideas of how to do things and that now. So-far tonight I've started writing a class to create and save JPanels and JButtons so they don't need to be re-created every time you move from menu to menu.

Why are you recreating them in the first place? Your JButtons/JPanels should be class fields, and you can just add/remove them at will.

Someone told me that I should create every menu on a different JPanel because it's a better way to do it, that's why. It seems like everyone else thinks that it's a bit of a ridiculous idea so I'll drop it.

Its not much of a hassle for Java to create a JPanel a few times. You shouldn't spend time trying to optimize before you see a need to. If it's not lagging or slowing you down, don't try to optimize it.

I use the approach you're talking about, where I have each view/menu on separate JPanels. It works like a charm, and it is very easy to control. But you're removing buttons and such when certain buttons are clicked, like in the actionlistener on the continue-button.

Instead, you could try a very different approach. The menus could be on several JPanels, which you can switch between by simply changing the contentpane on your gameframe. Roll in the menu on its own panel, menuPanel, and then when a button is pressed and all the needed information to start the game is in order, you change the contentPane of your frame from menuPanel to a new gamePanel, which handles rendering of the game.

If you want, you can add even more panels on top of your gamePanel...the frame won't mind. So if you want in-game menus, you're free to use Swing for those, without having to kill the gamePanel. You can even spawn extra JPanels IN your gamePanel!

About your buttons, I think they look fine. Actually, they're spectacular for a Paint-job. They might benefit from a little blur on the edges, but what would REALLY help them, is if they weren't on a monotonous grey background. The surrounding colors make a huge difference to an image (which is why AmbiLight is popular for TVs).

I did some quick n' dirty image editing to put your button on a vibrant game, so you can see what I mean. When surrounded by colors and graphics that aren't as unnatural as a completely monotonous grey, the pixelated edges even seem to give the button a more realistic look, than if it were blurred. Maybe a mix of the two approaches would be more spot on?

Hmm... I'll do a bit of messing around with JPanels and the button does look pretty good with more color, thanks!

Now for a small update; I've finally found out how to separate all my classes and have them in multiple files instead of having a 1000+ line file with multiple classes and stuff mashed together within. At the moment I'm separating the whole program into multiple files, I might end up doing a re-write but I'm not sure yet.

The code is being re-organized and partially re-written again as to separate the logic and rendering.

A few map tiles have been created by an acquaintance of mine. A few of them have been implemented and are working in the game.

The Derby database has been scrapped and I'm having to switch back to using text files to save data.

Because Ultroman wanted to see what's working at the moment, here you go (http://www.mediafire.com/download.php?zay8dt17vfdssit). All that you can do at the moment is to walk around on the map and get stuck on the pathway tiles because of bugs with the collision code.

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