[java] Performance Q?

Started by
2 comments, last by Arch@on 23 years, 3 months ago
Ok, I''m somewhat decent java programmer and I''m wondering about making a RTS game. I really feel that my(and my friends) skills are good enough to do it. So, I kind of know that java''s performance is not one of the best, but we are not trying to make next CnC or Starcraft 5, not anything like that. The game would be in 640x480(800x600 if possible without slowdown) resolution and the map would consist from 8x8 tiles(a lot of them) and units would be even smaller. I would use fake fullscreen(full screen window), and during the game i would use multithreads, like one for graphics, one for AI and one for UI. The biggest thing I''m afraid of is the slowdown of the threads and how it would affect the playing experience. Is there any programmers who have tried that? I mean sometimes even trying to move 5 objects pixel by pixel makes the FPS drop real low. Time comes, time goes and I only am.
Advertisement
It seems to me that for multiple pics, like for units it would be better to use the image class and do them as gif''s. You can get serveral of them going without much of a slow down depending on how optimize your code, and what your target machine is.. As for the threads I cannot help you there buddy.

War doesn''t determine who is right, war determines who is left.
My Friends and I are also trying to do an RTS in java. So far we get o.k.ish speed by only copying to the screen the minimum amount possible, i.e. that which has moved since last redraw.
It gives fairly good results for not too many objects, but after it rises above a certain number of objects we have to go back to full screen copying.
Also we''re trying to minimise the number for threads we use as serious performance issues can arise (due to thread starvation and the need for synchronization). So beyond the usual threads (main loop and events) we only have one more for networking.

Cheers,
John

p.s. We''re nearly at a stage where we can actually play the thing!
The previous poster is right: you are better off doing a few small drawing operations than one big one. He''s right again in stating that too many operations will become slow again and one big one will be faster.

Do some tests yourself before you get started. I timed how long it took to finish a routine and did it ten times in a row and added them up. I tried one big one (second), a couple little ones (fastest), enough little ones to equal the surface area of the big one (slowest) as well as a few others.

Of course this was with Java 1.1.8 using basic graphics routines. The nice thing about Java 1 is that you can expect a lot of browers out there to have similiar compatibilty and I was writing applets. However, I''m saying screw it now and as I get back into Java I just downloaded the 1.3 SDK. Java 2 has a lot of specialized graphics routines that I''m excited about. I''ll probably just write applications with it though.

As far as multithreading: I don''t want to discourage you from using it (and thus learning it because it might land you a great job someday), but it''s not really necessary in game dev except for the networking part. You need a listener thread obviously. However, in Java the input handler is automatically a separate thread. Try to limit the use of threads.

This topic is closed to new replies.

Advertisement