in advance:sorry for my bad english! ;D
what i have:
a canvas(800*500)
and two thread which do a lot of painting on this one canvas!
the one is leeping 50ms!
the faster 20ms!
both do their their own paiting!
it’s flickering like mad you can imagine!
so what can i do to “get that flickering out of my canvas”?
Double buffer it!
Only paint with one thread!
Sorted!
Cas 
now i have done the painting in one thread and the “mathematics” in two threads!
the flickering is better now!thanks!but what is double buffering?
Double buffering will remove all flickering. Heres the basic concept:
You create one blank image the size of your viewable area (Canvas). You do all your drawing to this image’s graphic context. When you are ready, draw this giant image onto your viewable area.
This prevents alot of blits being done in the viewing area which is causing flicker.
Creating a double buffer is pretty easy. Here’s an example:
db = createImage(width, height);
dbg = db.getGraphics();
The first line creates a blank image of some known height and width. In your case those values come from the size of the canvas you are using. The second line gets the graphical context for that image. This context allows you to manipulate that image. As such:
dbg.setColor(new Color(79,205,251));
dbg.fillRect(0,0,width,height);
When you are all done manipulating the background image, you can draw it to the current viewable area using its graphical context:
g.drawImage(db,0,0,this);
Remeber to also override the update method for the component though. It should look like this:
public void update(Graphics g)
{
paint(g);
}
This prevents the image from being destroyed if the component is repainted (if I remember right).
Last note: avoid using threads. Threads suck the life out of a Java games speed. If you can, try to do everything within the main thread.
[quote]Last note: avoid using threads. Threads suck the life out of a Java games speed. If you can, try to do everything within the main thread.
[/quote]
I disagree with that. Threads are very handy and not that bad if used right. This applet http://hannover.stadtmagazine.de/games/numbers uses up to 5 threads (if the server is not down, which happens quite often) (max of 3 at a time) and runs quite good.
Edit: Fixed the BS numbers i had in here before… 
yeah!i’ve done it with dublebouffering!very cool!thank u 4 help!
I disagree with that. Threads are very handy and not that bad if used right.
C/C++ programmers have wrote games for years without threading. They still do till this day. Why does someone really need them in a Java game?
Seriously, Threads have issues:
-
Speed loss. I wrote a stupid fish aquarium program one time in Java. Gave each fish its own thread. It worked but was not very quick. I removed all the threads and just ran in a loop on the main thread: big increase in speed. After some testing I found that with each new thread there is a slight loss in the total CPU processing speed due to the JVM having to handle each thread seperately.
-
Synchonization. This can cause unexpected bugs in an ill prepared program. It also effects speed if you write your methods synchronized.
-
Oddities between JVM’s and OS’s using threads.
This applet http://hannover.stadtmagazine.de/games/numbers uses up to 7 threads (if the server is not down, which happens quite often) at a time and runs quite good.
I was not very impressed by this demo. IMOH it ran rather slow for what it is doing. From my understanding its using a pure Java 3D api. Though a pure Java 3D approach (outside Sun’s Java3d) is interesting its also rather lame at the same time in that it lacks hardware acceleration. Try using an OpenGL port (like GL4Java), Sun’s Java3D, or even Direct3d (Wildtangent) to get some real power. The alien will really boogy then.
C/C++ programmers have wrote games
“Have written” (Smacks head)
Save me Patrick!
You don’t really need threads, but they have their benefits (that’s why somebody invented them… ;D ). The key sentence in my post was “if used right”…putting every fish in a single thread doesn’t seem to be a great idea then. But that doesn’t mean that threads are a bad idea in generell.
What else do you want to do to make the AI calculate its move and still render the scene??
Anyway, everyone may do it i a way he/she likes the most. The same is true for the decision software/hardware. You say the applet is quite slow for what it’s doing and i say it’s quite fast for what it’s doing, because it does render the board and the MD2-alien with texture mapping and lighting and bumpmapping all in software and in a 100KB applet. It runs without any hassle under everything that support Java 1.1 or higher. At least it is there and it works and it is “fast enough”. That can’t be said about most of these virtual Java 3D games.
Anyway, this discussion is as old as mankind, so…merry Christmas! 
I’m not going to resort to a huge font again this time! So listen up and listen carefully:
Threads were designed to interleave disk and network I/O with processing tasks, among other things. Their primary purpose is to ensure that the CPU is always doing some work if it can. What they don’t do is provide you with time-sliced task sheduling, which is what you want threads for. There is no such facility in Java. If you try to use threads to simulate this, it won’t work, because it’s not designed to. What you need to do is actually devise a time-slicing sheduler yourself, running in a single thread, which will then behave in a consistent manner on all platforms and all configurations. Limit your use of threads to do what they are designed for: network and disk I/O…
And merry Christmas to everyone too
Cas
First, i have to correct myself. The applet above uses 5 threads and only 3 of them are running at a time at max… During normal gameplay, 2 threads are active.
I disagree that threads are designed for I/O only. If that would be the case, multithreading would be rather useless for number-crunching tasks. Or were you refering to Java-threads? If they were designed with I/O in mind…so be it. I don’t see a reason not to use them in places where it makes sense though. And doing AI calculations while something is rendered is such a situation IMHO.
How should it work otherwise? The AI may take up to some seconds to calculate its move, depending on the speed of the machine and the depth of thought one choses. Meanwhile, the rendering should not be stopped, because that looks shitty…i had it that way before. Putting the calculations in an extra thread at low priority may increase the time it takes to calculate the move, but the game as a whole feels more responsive that way. What is so bad with that?
BTW: When the hyperthreading P4 becomes more popular, multithreading (native and in Java) will become more popular too for “normal” applications and even for games, IMO.
Anyway, this thread somehow went OT… 
Multithreading is indeed reasonably useless for number crunching tasks. (Java threading is neither here nor there, it works more or less like an O/S thread by and large). When does one thread finish a piece of work?
It’s very difficult to disagree on the purpose of threads! They’re an operating system fundamental concept, as a book on such things would go on to explain in tedious detail.
How many threads is it sensible to make? How much overhead does synchronizing multiple threads have? How does your application behave differently on uni- and multi-processor systems? Or with green threads? And so on.
A good example is SQL server, which has an option to use “Fibers”. These are basically … time slice scheduled tasks running in a single thread! You use Fibers to do intensive numerical work in SQL server instead of threads to get more even response times and increase efficiency; great for OLAP.
And by coincidence, great for games.
As a matter of interest, the terrain demo has a hidden multithreading option in it somewhere. It gets slower on single processor systems by about 5%, and gets faster on dual processor systems by about 5%. Definitely not worth the vast increase in complexity.
Cas
That may all be very true, but please: How do you want to complete the task above (AI calculations taking place while rendering) without using threads? You can’t interrupt the renderer and you simply can’t jump out of the recursion of the AI calculations just to render half the image and then return.
I’m not saying that threads should be used everywhere but if you can benefit from them…why not do so? In the task i’m describing, no synchronizing is needed and i’ve tested this on Mac, Linux, Windows 98/NT/2000/XP under Java 1.1, 1.2, 1.3 and 1.4 and i had not a single problem with it.
And about the number-crunching: Why are programs like 3DS using threads then???
Threads are a tool. Use them where it’s appropiate. Don’t “overuse” them but don’t condemn them either. I remember a program i had to write for a Solaris machine back in the days at the uni…we had to use threads and we had to synchronize them. That wasn’t fun at all, so i do understand what you are saying but i disagree on the absoluteness of it.
May original statement about threads was a bit short on detail and may have seemed absolute. Sorry about that. I was not trying to be absolute about using threads. Threads for network connections and streams is understandable since they can block (and thus lock up your game). Also, using them in a game is understandable if you are not having speed issues. But as a general rule, I try to avoid threads at all costs due to the performance loss if I am creating something where speed will possibly be an issue. If speed is not an issue, using Threads can make life easier.
I’m with Cas on this one, avoid multiple threads in game programming. Threads are not guarunteed to run at any particular time. Do you want that behavior for game AI? It’s possible your AI will never make a decision because the thread never gets signaled to start. Do you want that behavior for paints? You’ll never get a predictable framerate. Do you want that behavior for processing user input? The user’s actions may never get recieved, or recieved later than the player wants. Just don’t do it.
'nuff said.
-Chris
It’s time we made that FAQ / “10 commandments” official and got it stuck up here as an article.
Cas
[quote]I’m with Cas on this one, avoid multiple threads in game programming. Threads are not guarunteed to run at any particular time. Do you want that behavior for game AI? It’s possible your AI will never make a decision because the thread never gets signaled to start. Do you want that behavior for paints? You’ll never get a predictable framerate. Do you want that behavior for processing user input? The user’s actions may never get recieved, or recieved later than the player wants. Just don’t do it.
'nuff said.
-Chris
[/quote]
Sorry, but i really don’t get it. I’ve explained what i’m doing and why. It works in each an every case i’ve tested and does EXACTLY what i want without any problems or hassle. Now you are telling me, that i shouldn’t do it, because it may fail. You can be sure that i wouldn’t do it, if it would fail somewhere…but it doesn’t. It works perfectly on every machine/OS/VM i’ve tested it on. So basically you are trying to tell me that i shouldn’t do it, because…i just shouldn’t do it. Sorry, but that’s like saying “use 4bpp only, because anything higher may fail” or “avoid using fullscreen, because it may fail (which it does quite often on my machine btw).”
Anyway, i think that this discussion leads nowhere… ;D
Edit: None replied to my question how to do it in a different way then. On the one hand, i’ve a rendering engine which is basically a black-box (it’s my own work, but that doesn’t matter here) where i can setup my scene and then say “engine.doIt();” and some ms later i’ll get a rendered image. On the other hand, i’ve the AI which can be a human player or a network player too (they all implement a player-interface and can be “plugged in” on demand). So please: If threads are so evil…how can i achieve what i want to in a different way? I can’t think of a proper way of doing this without using threads.
Hmm I acknowledge that threads can be used wrongfully in games, however I think that there are instances where they can be used ( I am not talking Java here - but generally).
Having two threads isn’t a bad idea ™. When using one thread one does not use all resources availeable, especially with in these times using smp/smt machines (wow this took a long time to write, even considering how (christmas) drunk I am :)))
Cheers - and fucking merry christmas
Multithreading is indeed reasonably useless for number crunching tasks.
Uh what? That’s a naive statement at best.
When does one thread finish a piece of work?
That question is pretty much non-sensical. Yes, the use of threads requires synchronization - that’s why we have synchronization primitives.
It’s very difficult to disagree on the purpose of threads!
Apparently it’s not as hard as you think considering the disagreement floating around. Obviously, one purpose of threads has to be to utilize multiple processors. The only other alternative would be multiple processes, and I hope we can all agree that that’s just plain stupid in a large majority of cases - especially including that of games.
How many threads is it sensible to make?
It’s very reasonable to say that you want roughly the same number of threads as the number of processors in the system plus a small constant. Of course, this varies by the application and the type of work being done.
How much overhead does synchronizing multiple threads have?
If you’ve written your program well, very little. For example, in a previous life I wrote medical imaging software based on wavelet compression techniques optimized for MMX. On a dual processor machine, I was able to achieve almost exactly twice the performance than on a single processor machine.
How does your application behave differently on uni- and multi-processor systems?
Umm… it runs faster on the multi-processor?
Or with green threads?
That’s just plain ludicrous. This is akin to saying, what about DOS? Such systems exist, but that doesn’t mean they should be part of your target market.
A good example is SQL server, which has an option to use “Fibers”. These are basically … time slice scheduled tasks running in a single thread!
NT fibers are the equivalent of green threads - They are literally user level threads. You can’t use multiple fibers to utilize multiple CPUs. They suffer from their own problems, just like any other user level threads package.
As a matter of interest, the terrain demo has a hidden multithreading option in it somewhere. It gets slower on single processor systems by about 5%, and gets faster on dual processor systems by about 5%. Definitely not worth the vast increase in complexity.
That’s a bad comparison, Cas. The terrain demo doesn’t have any compute-bound logic in it. Rather, it’s just a pixel pushing demo. Almost any real game will require serious CPU - the most obvious application being for all sorts of AI techniques.
What are you going to do when manufacturers reach clock cycle barriers on their chips and they move to serious multiprocessing? Are you just going to give up all of your lower level programming to move to a platform like Java3D, where the engineers know how to use threads?
It disturbs me that you would ignore and encourage others to ignore the growing audience of users with multiprocessors (including me). That is akin to encouraging others to ignore the users who bought GeForce4’s. Good engineers take advantage of the extra processing power that is present.
God bless,
-Toby Reyelts
Sorry you don’t get it, I gave 3 instances where it fails. I’m just using real-life experience to come to my conclusions. If you need other’s testimonies, look no further than all the posts in the 2d and newbie forums asking why the f’ their animations run so jerky and the answer is to do all painting in a single thread. I helped put together a racing car game where 3 of the cars had their own collision avoidance and track-following code, and do you know what would have happened if they were just blindly put into separate threads? the’d be driving into walls and into other cars all over the place because the ‘game’ thread would move the cars’ positions while the AI was deciding where to drive. It’s madness. The solution there would have been implementing the proper thread synchronization, but that’s extremly prone to errors and would it have really gained anything? Maybe if there was 1 cpu per car and everything was being figured out in parrallel. I could imagine a system that uses multiple threads for each AI in a game, but you’d need to craft some sort of message queue to recieve commands from the various threads and synchronize the messages. Sounds more complicated than it needs to be.
-Chris