Fully utilising Multi cores/Multi cpus?

[princec]

Server VM pretty much lives up to expectations then eh?

Cas

[DzzD]

12.5 fps for exe
9.5 fps for jar (client jvm)

yup about 30% faster

jvm 1.6.03
cpu XP2000 1.6ghz
gpu ati x800
ram 768MO

[moogie]

Thanks for all your testing!

That is a surprising difference between the server and client jvms. Did i read some where that sun was thinking of making a jvm in which effectively the client jvm will be as good as the server jvm and thus just the one jvm?

Hmm, 175% is not bad... still better than the previous version. There are still parts of the program which are not parallerised some of which can not ever be but some which can however it does not make sense to do so until i implement a bounding volume heirachy.

So I am aiming to achive 190% utilisation.

About the FPS per run on version 10, i have changed the fps counter to use a smoothing average. For the first 3 seconds it uses the instant fps. However after 3 seconds it uses the following formula:

avgFPS= (prevAvgFPS*2+currentFPS)/3

perhaps this is causing the difference between versions? I am not sure why it would... all it will do is be less responsive to reflect change in fps.

Games published by our own members! Check 'em out!

[Linuxhippy]

Version8:

Client-jvm:
30fps - ~170% load

Server-jvm:
46fps - ~170% load

You should check for thread problems in your code, starting your app with -Xint gives me sometimes a wrong window-size.
Are you doing all modifications to Swing/AWT-Components on the EDT?

Core2Duo T7200 laptop, 2ghz
jdk1.7.0 build22

[moogie]

The JFrame and components are created and setup in the constructor of sub class of JFrame. The frame and its components are never modified at any other point in the program.

A buffered image is drawn onto a back buffer of a BufferStrategy and then flipped to be viewable.

The flipping does not occur on the EDT.  but i thought that it was not necessary with BufferStrategy you are determining when to "paint"... is this not the case?

[Linuxhippy]

The JFrame and components are created and setup in the constructor of sub class of JFrame. The frame and its components are never modified at any other point in the program.

This could be the problem, and I guess it maybe is the root of the problem on my machine.

You create the JFrame and your components on the main-thread, not on the EDT. This is a violation of Swing's threading rules, and it is best-practise to even do component setup in the EDT.

The rendering itself can be done by any thread, because as far as I know all Java2D-related stuff is thread-safe.

lg Clemens

[moogie]

Really?!  All these years I have been doing it incorrectly... Can you point me to an approriate example/tutorial? All the examples i have seen on the Swing Tutorial have the components set up in the main thread... e.g. http://java.sun.com/docs/books/tutorial/extra/fullscreen/example-1dot4/DisplayModeTest.java

[princec]

It should be completely possible to construct and assemble Swing components in any thread. What you can't do then is diddle with them or act on events in any thread.

Cas

[moogie]

Ah, I think i know what the problem is...

In order to get the frame's inset information, the frame has to be be set visible. I then re-size the frame based on these inset information. Is there a way of obtaining the frame's decoration dimensions before making it visible? Failing that I will put the re-size code in a swing worker to be performed by the EDT

[tom]

I think you can get the decoration dimensions after you call addNofity() on the frame.

Games published by our own members! Check 'em out!

[Linuxhippy]

All Graphical User Interfaces require some kind of main application frame in which to display. In Swing, this is an instance of javax.swing.JFrame. Therefore, our first step is to instantiate this class and make sure that everything works as expected. Note that when programming in Swing, your GUI creation code should be placed on the Event Dispatch Thread (EDT). This will prevent potential race conditions that could lead to deadlock. The following code listing shows how this is done.

http://java.sun.com/docs/books/tutorial/uiswing/painting/step1.html

lg Clemens

[princec]

I believe that restriction was relaxed some time ago. You can construct away and fiddle all you like until the components are actually realised on the screen.

Cas

[Linuxhippy]

I believe that restriction was relaxed some time ago. You can construct away and fiddle all you like until the components are actually realised on the screen.

I found quite different results - it seems like they said some time ago that that its ok until you realize the component, but now the consensus seems to be to do everything on the EDT.

Its no problem after all, so what is the downside of doing it like recommended and beeing on the safe side?

lg Clemens

[moogie]

I think you can get the decoration dimensions after you call addNofity() on the frame.

Thanks! didnt know about that. It seems to have done the trick.

[bitshit]

Hmm, 175% is not bad... still better than the previous version. There are still parts of the program which are not parallerised some of which can not ever be but some which can however it does not make sense to do so until i implement a bounding volume heirachy.

So I am aiming to achive 190% utilisation.

Did you made any progress on this? Is spawning code in a new thread enough to have it executed on different cores?

[moogie]

yes and no... i am achieving about 175%-180% utilisation. however without removing a barrier wait. i have been focusing on other aspects of the engine lately.