gl4java-usergroup Mailing List for OpenGL[tm] for Java[tm] (Page 21)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi

Is there anybody using macosx 10.2 and netscape 7 and having proper
demos page? Is there any way else then closing window to properly
refresh the page?

Thanks.

regards,
Sergiy

Hi

Is there anybody using macosx 10.2 and netscape 7 and having proper
demos page? Is there any way else then closing window to properly
refresh the page?

Thanks.

regards,
Sergiy

Hi Peter,

Here is a little checklist that might help you solving your problem :

Your animation may be stuttering because of frequent runs of the garbage
collector. This can happen if you create and destroy a lot of objects per
frame. To avoid this, make sure you never create any temporary objects in
your rendering loop, having a preference using values that are global to
your classes.
Running your program using the option -Xincgc will smooth the garbage
collection over time (but also reduce performance) and this can help you
figure out if the gc is responsible of your problem.
-> java -Xincgc yourclass

You don't need to compile arrays into display lists (this is really useless=
,
I have not noticed any percent of performance increase testing this
feature), but it is always good to lock your vertex arrays. It allows the
driver to optimize the vertex data access in memory and thus gain
performance.

Make sure you don't recompile your display lists at each frame (this a
stupid advice, but we never know...)

Make sure your hard disk drive is not swapping during the rendering, this
would explain the poor / unregular access to the vertex data in memory.
If so, add more RAM to your computer.

Allocate more RAM than needed to the virtual machine, I've had the feeling
it was increasing a bit the performance. For this, use the flag -Xmx
-> java -Xmx256000000 yourclass  (to allocate 256Megs of memory to the
program)

Make sure you don't have 3dsMax or any third party openGL application
launched in the background when you execute your program. In some cases,
3dsMAX make me loose up 70% of my application performance, and I hask mysel=
f
"what the f%% is going on ?"..."oh max is running in the background..."

Don't use too small arrays. Small counts of polygons like 50-200 won't make
you benefit of a real performance increase. Prefer having several thousand
faces per array if possible.

I'm personnaly using vertex arrays having very good and smooth performance
under a geForce2MX. What 3d card do you have ?

Regards,

Alban Cousini=E9
Mind2Machine

> Probably not. If your application is multithreaded you may find
> it necessary to either adjust thread priorities or repartition
> the work that is being done by the various threads. Also take a
> look at the JCanyon demo and see whether any stuttering visible
> in that demo is similar to the behavior in your application.

Well, I finally got the demo downloaded (it took a while on my ancient
14.4kb modem!)

It ran extremely poorly - but reading the web site, I see that my
machine is under-specced (I have 128mb ram not the 192 recommended -
it's also a PIII500 as opposed to the 2ghz test machine)  The end
result: the test is inconclusive.

I suppose the next step is to profile my java code and find out where
its spending its time and see if that's something I can fix.

Does anyone know of any particularly good java profilers?

Peter.

> On Wednesday 30 October 2002 20:08, Peter wrote:
> > > > One definite difference between my code and JCanyon is that I'm
not
> > > > using the NIO direct buffers, though OTOH I'm using display
lists,
> >
> > so
> >
> > > > that shouldn't matter beyond the initial access.
> > >
> > > no, that is not correct. Java can move your vertex/normal/whatever
> >
> > arrays
> >
> > > around underneath you before your get the chance to call
> >
> > glArrayElement
> >
> > > (or
> > > similar).
> >
> > As I said in my post, I'm using *Display Lists*.  It doesn't matter
what
> > happens to the arrays after the lists are made (altering the arrays
has
> > no effect on the data stored in the list whatsoever)
> >
> 
> Your arrays can be moved around *before* you create the display list,
and
> after you specify the array. To create a display list your would do
> something
> like this:
> 
> float[] vertex_array;
> int[] indices;
> 
> ...
> 
> glVertexPointer(..., vertex_array);
> 
> ...  <- It it here, between the array call, and the draw call that
your
> vertex
> data arrays can move around.
> 
> glDrawElements(...., indices);
> 
> And yes, that gap between glVertexPointer and glDrawElements is
normally
> very
> small, but believe me, it can happen.
> 

Oh, ok - I see your point.  Sorry - I misunderstood what you were
getting at. ;-)

Thanks for the feedback.

Peter.

On Wednesday 30 October 2002 20:08, Peter wrote:
> > > One definite difference between my code and JCanyon is that I'm not
> > > using the NIO direct buffers, though OTOH I'm using display lists,
>
> so
>
> > > that shouldn't matter beyond the initial access.
> >
> > no, that is not correct. Java can move your vertex/normal/whatever
>
> arrays
>
> > around underneath you before your get the chance to call
>
> glArrayElement
>
> > (or
> > similar).
>
> As I said in my post, I'm using *Display Lists*.  It doesn't matter wha=
t
> happens to the arrays after the lists are made (altering the arrays has
> no effect on the data stored in the list whatsoever)
>

Your arrays can be moved around *before* you create the display list, and=
=20
after you specify the array. To create a display list your would do somet=
hing=20
like this:

float[] vertex_array;
int[] indices;

=2E..

glVertexPointer(..., vertex_array);

=2E..  <- It it here, between the array call, and the draw call that your=
 vertex=20
data arrays can move around.

glDrawElements(...., indices);

And yes, that gap between glVertexPointer and glDrawElements is normally =
very=20
small, but believe me, it can happen.

 - elias

> thanks for the reply!
> 
> do you have a personal website with information regarding developments
> with
> your Myth game?  Any screenshots?

Sorry, no.  It's not much to look at now anyway.

> I too hope that it's possible to create a professional
game/application
> using gl4java (I really don't want to touch C++)  :)

C++ is okay if you use it like an OO language and avoid its zillion and
one unnecessary and inconsistent features (unfortunately, very few C++
programmers do).  My main reason for wanting to use Java is that I can
develop faster in it. 

> So have you played around with genetic algorithms before?
>

Yes - I did GAs in C a long time ago.

Peter.

> Hi Peter,
> 
> Reading your posts on the list over the last few days, I've become
rather
> interested in what you are developing with GL4Java.
> 
> Would you care to share?

At the moment I'm just investigating gl4java.  I had some code in c++
which did landscape generation and rendering with some billboarded units
on it (like Myth).  It hasn't come too far - basic terrain, units on
terrain, selection of units and keyboard and mouse manipulation of the
world.

Ultimately I'd like to finish it - ending up with a game very much like
Myth with some extras - but at the moment I'm just investigating whether
it would be possible to do it in Java. I hope it is, because I really
think that Java in an inherently better language than C++, but my first
priority is to complete my game and not be a language bigot :o)  Hence
the investigations.

> I'm relativly new to software engineering, but am trying to spend all
my
> time reading all the latest articles at the mo...
> 
> I'm currently in the process of creating two applications based on
gl4java
> (both for final year uni course):
>     1) An edutainment application to teach a user how to build a
modern pc
> system (using 3ds max models).
>     2) An application involving the use of genetic algorithms to
create
> self-replicating, evolving biocreatures. [planning stages at the mo
> though].

#2 sounds like fun - genetic algorithms are really great fun to work
with.

Cheers,

Peter.

> 
> ----- Original Message -----
> From: "Peter" <kaf...@xt...>
> To: <gl4...@li...>
> Sent: Wednesday, October 30, 2002 7:08 PM
> Subject: RE: FW: [gl4java-usergroup] animation stutters
> 
> 
> >
> > >
> > > > One definite difference between my code and JCanyon is that I'm
not
> > > > using the NIO direct buffers, though OTOH I'm using display
lists,
> > so
> > > > that shouldn't matter beyond the initial access.
> > > >
> > >
> > > no, that is not correct. Java can move your vertex/normal/whatever
> > arrays
> > > around underneath you before your get the chance to call
> > glArrayElement
> > > (or
> > > similar).
> >
> >
> > As I said in my post, I'm using *Display Lists*.  It doesn't matter
what
> > happens to the arrays after the lists are made (altering the arrays
has
> > no effect on the data stored in the list whatsoever)
> >
> >
> > >NIO direct (allocated through ByteBuffer.allocateDirect) buffers
> > > is
> > > the only safe way to use arrays that must remain at the same
address.
> > So
> > > in a
> > > way you're lucky your display lists work.
> >
> > Why?  The display list is made once, after which the address of the
> > original source data is irrelevant because the source values are
stored
> > in the list.
> >
> >
> > > None of this applies to your problem with stuttering though.
> >
> >
> > Sorry, but as far as I can tell, unless you have a special version
of
> > openGL with mutable display lists, then I don't think any of it
applies
> > at all.
> >
> > Cheers,
> >
> > Peter.
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Influence the future
> > of Java(TM) technology. Join the Java Community
> > Process(SM) (JCP(SM)) program now.
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> > _______________________________________________
> > gl4java-usergroup mailing list
> > gl4...@li...
> > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup

> 
> > One definite difference between my code and JCanyon is that I'm not
> > using the NIO direct buffers, though OTOH I'm using display lists,
so
> > that shouldn't matter beyond the initial access.
> >
> 
> no, that is not correct. Java can move your vertex/normal/whatever
arrays
> around underneath you before your get the chance to call
glArrayElement
> (or
> similar). 

As I said in my post, I'm using *Display Lists*.  It doesn't matter what
happens to the arrays after the lists are made (altering the arrays has
no effect on the data stored in the list whatsoever)

>NIO direct (allocated through ByteBuffer.allocateDirect) buffers
> is
> the only safe way to use arrays that must remain at the same address.
So
> in a
> way you're lucky your display lists work.

Why?  The display list is made once, after which the address of the
original source data is irrelevant because the source values are stored
in the list.

> None of this applies to your problem with stuttering though.

Sorry, but as far as I can tell, unless you have a special version of
openGL with mutable display lists, then I don't think any of it applies
at all.

Cheers,

Peter.

I should have sent this to the list not Kenneth directly (sorry)

> 
> > I'm using the GLAnimCanvas with the GLEventListener paradigm (sorry
-
> > should have mentioned that)
> >
> > I've set the canvas to not receive repaint events, and not to limit
fps
> > (i.e. go full speed).  Perhaps it might run better if I did limit
fps?
> 
> Probably not. If your application is multithreaded you may find
> it necessary to either adjust thread priorities or repartition
> the work that is being done by the various threads. Also take a
> look at the JCanyon demo and see whether any stuttering visible
> in that demo is similar to the behavior in your application.
> 

It's not multithreaded.  

I'll check out that demo when I get home - it looks very nice BTW.

One definite difference between my code and JCanyon is that I'm not
using the NIO direct buffers, though OTOH I'm using display lists, so
that shouldn't matter beyond the initial access.

Kenneth - I notice that the JCanyon article was written by you and that
it says you work for Sun.  Can you comment on how committed Sun is in
getting Java to be a serious contender in the games market?  I notice
that NIO and the fullscreen rendering additions to the graphics API are
recent Java enhancements that seem to strengthen Java in that area -
does this signal a commitment from Sun to be taken seriously in the
games market?  Will we see more such developments?

Thanks in advance,

Peter.

I should have sent this to the list not Kenneth directly (sorry)

> 
> What animation technique are you using? I recommend using a
> GLAnimCanvas with the GLEventListener paradigm for getting the
> application code to run. If you're calling repaint() on the
> GLCanvas then the thread switching from the application thread to
> the AWT thread and back may be affecting your framerate.
> 
> See http://java.sun.com/products/jfc/tsc/articles/jcanyon/ for an
> example of this technique in the context of terrain rendering.
> 

Hi Kenneth,

I'm using the GLAnimCanvas with the GLEventListener paradigm (sorry -
should have mentioned that)

I've set the canvas to not receive repaint events, and not to limit fps
(i.e. go full speed).  Perhaps it might run better if I did limit fps?
I could try that when I get home (I'm at work at the mo ;-))

Also, I'll check out the example you mentioned - thanks for that.

Cheers,

Peter.

> I'm using the GLAnimCanvas with the GLEventListener paradigm (sorry -
> should have mentioned that)
> 
> I've set the canvas to not receive repaint events, and not to limit fps
> (i.e. go full speed).  Perhaps it might run better if I did limit fps?

Probably not. If your application is multithreaded you may find
it necessary to either adjust thread priorities or repartition
the work that is being done by the various threads. Also take a
look at the JCanyon demo and see whether any stuttering visible
in that demo is similar to the behavior in your application.

What animation technique are you using? I recommend using a
GLAnimCanvas with the GLEventListener paradigm for getting the
application code to run. If you're calling repaint() on the
GLCanvas then the thread switching from the application thread to
the AWT thread and back may be affecting your framerate.

See http://java.sun.com/products/jfc/tsc/articles/jcanyon/ for an
example of this technique in the context of terrain rendering.

> I ported some C++/openGL terrain rendering code (uses triangle strips
> from indexed vertex arrays compiled into a display list) over to
> gl4java.  It runs with pretty much the frame speed as the C++ version,
> but it stutters slightly.  
>  
> I've checked to see whether it was GC causing problems - but I turned on
> -verbose:gc and found the GC isn't to blame - GC is happening only
> rarely and not causing any visual discontinuities when it does occur.
>  
> Any other ideas what I should look at to find the problem? 
>  
> System: Java 1.4.1, gl4Java 2.8.2.0, Windows 2000, NVidia Geforce 256

Hi All,

I ported some C++/openGL terrain rendering code (uses triangle strips
from indexed vertex arrays compiled into a display list) over to
gl4java.  It runs with pretty much the frame speed as the C++ version,
but it stutters slightly.  

I've checked to see whether it was GC causing problems - but I turned on
-verbose:gc and found the GC isn't to blame - GC is happening only
rarely and not causing any visual discontinuities when it does occur.

Any other ideas what I should look at to find the problem? 

System: Java 1.4.1, gl4Java 2.8.2.0, Windows 2000, NVidia Geforce 256

Thanks in advance,

Peter.

---
The existence of morning is final and incontrovertible proof of the
non-existence of a benevolent god.

Hello everyone!

Can you please explain me what is wrong?

I got the gl4java package and installed it on my macosx.
I executed that funny rolled cube exapmle - it worked perfectly.
Nevertheless I could not get executed properly some
gl4java applets at your demos page.
Neither Netscape nor ie worked with it.
Sympthomes were that the applet was leaving a white
box in the browser window and I could not remove that
empty window unless I restarted the browser.

Thanks.

Reagrds,
Sergiy

Thanks Kenneth, Harmo & Birkan, =20

I have followed all of your advice but to no avail - the propblem still =
persists.=20
Anyone with any further ideas as to what could be the problem?

Thank you.
> Thanks Kenneth, but I was trying to run the program with the following =
> prompt:
> 
> d:\jdk\bin\java -classpath =
> d:\jdk\bin\java;D:\GL4Java\libGL4Java2.8.2.0-Win32-x86 Lesson2
> 
> where D:\GL4Java\libGL4Java2.8.2.0-Win32-x86 is the location of the =
> GL4JavaJauGljJNI14.dll=20

This directory either needs to be on your PATH environment
variable or specified via -Djava.library.path. CLASSPATH
specifies the locations of .class files or jars.

Thanks Kenneth, but I was trying to run the program with the following =
prompt:

d:\jdk\bin\java -classpath =
d:\jdk\bin\java;D:\GL4Java\libGL4Java2.8.2.0-Win32-x86 Lesson2

where D:\GL4Java\libGL4Java2.8.2.0-Win32-x86 is the location of the =
GL4JavaJauGljJNI14.dll=20

Any further suggestions? Could it be a problem with the OpenGL =
dlls/drivers?

Thank you.
Looks like your PATH doesn't contain the directory containing
GL4JavaJauGljJNI14.dll .

> Does anyone know why I am getting the following error message? :
> 
> Exception in thread "main" java.lang.UnsatisfiedLinkError: =
> gljFetchGLFunctions
>         at gl4java.GLContext.gljFetchGLFunctions(Native Method)
>         at gl4java.GLContext.doLoadNativeLibraries(GLContext.java:896)
>         at gl4java.awt.GLCanvas.<clinit>(GLCanvas.java:178)
>         at Lesson2.init(Lesson2.java:64)
>         at Lesson2.main(Lesson2.java:44)
> 
> I am using WIndows XP, Java(TM) 2 SDK, Standard Edition Version 1.4.0 =
> and libGL4Java2.8.2.0-Win32-x86
> 
> Thanks, John Day
> ------=_NextPart_000_0005_01C27B6F.74EDC100
> Content-Type: text/html;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Diso-8859-1">
> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2>Does anyone know why I am getting the =
> following=20
> error message? :</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>Exception in thread "main"=20
> java.lang.UnsatisfiedLinkError:=20
> gljFetchGLFunctions<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at=20
> gl4java.GLContext.gljFetchGLFunctions(Native=20
> Method)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at=20
> gl4java.GLContext.doLoadNativeLibraries(GLContext.java:896)<BR>&nbsp;&nbs=
> p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> at=20
> gl4java.awt.GLCanvas.&lt;clinit&gt;(GLCanvas.java:178)<BR>&nbsp;&nbsp;&nb=
> sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> at =
> Lesson2.init(Lesson2.java:64)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;=20
> at Lesson2.main(Lesson2.java:44)</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>I am using WIndows XP, Java(TM) 2 SDK, =
> Standard=20
> Edition Version 1.4.0 and libGL4Java2.8.2.0-Win32-x86</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>Thanks, John =
> Day</FONT></DIV></BODY></HTML>
> 
> ------=_NextPart_000_0005_01C27B6F.74EDC100--
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup

Does anyone know why I am getting the following error message? :

Exception in thread "main" java.lang.UnsatisfiedLinkError: =
gljFetchGLFunctions
        at gl4java.GLContext.gljFetchGLFunctions(Native Method)
        at gl4java.GLContext.doLoadNativeLibraries(GLContext.java:896)
        at gl4java.awt.GLCanvas.<clinit>(GLCanvas.java:178)
        at Lesson2.init(Lesson2.java:64)
        at Lesson2.main(Lesson2.java:44)

I am using WIndows XP, Java(TM) 2 SDK, Standard Edition Version 1.4.0 =
and libGL4Java2.8.2.0-Win32-x86

Thanks, John Day
Hello,
    I am trying to use a GLAnimCanvas in an application I am running on OS X (using the GL4Java OS X port, of course).  The actual canvas itself seems to be placed in the right location (I can tell since I set the background a certain color), but the actual rendering of the 3D space is displaced from the GLAnimCanvas by about 200 pixels in both directions.  Anyone seen this problem before, and if so, how do I fix it?  This is not a problem running GL4Java under Windows.  (Everything but this misalignment however, seems to work on the OS X port).

Thanks,
Josh 

> On any pointers to some decent documentation on this stuff? I have no 
> experience at all with the win32 api or jawt, so any tips before I start 
> bug hunting would be very welcome :)

http://java.sun.com/j2se/1.4.1/docs/guide/awt/1.3/AWT_Native_Interface.html

The JAWT documentation doesn't provide a lot of detail on the
semantics. All I would recommend at first is instrumenting the
GL4Java code with printf's to see the return values from the JAWT
routines, in particular locking the drawing surface. See if the
return value changes just before the crash on 1.4.1 and if it
remains the same on 1.3.1.

Documentation on SetPixelFormat and other Windows APIs can be
found at http://msdn.microsoft.com/ .

On any pointers to some decent documentation on this stuff? I have no 
experience at all with the win32 api or jawt, so any tips before I start 
bug hunting would be very welcome :)

Pepijn Van Eeckhoudt

Kenneth B. Russell wrote:
>>I'm not sure if this is correct for the official binaries, but the 
>>version of GL4Java that I compile from the cvs uses jawt in both the 1.3 
>>and 1.4 library. So I'm assuming this can't be causing the problem.
> 
> 
> Just checked the code in GLContext.java and you're right, for the
> Sun JDK 1.3 and above JAWT will be used. The IBM JDK will use an
> older fallback mechanism. Which are you using?
> 
> Regardless, a substantial portion of the core GUI system was
> rewritten in the Sun JDK 1.4, so I can believe that the JAWT may
> now be returning result codes (like JAWT_LOCK_SURFACE_CHANGED)
> that it was not returning before.
> 

> I'm not sure if this is correct for the official binaries, but the 
> version of GL4Java that I compile from the cvs uses jawt in both the 1.3 
> and 1.4 library. So I'm assuming this can't be causing the problem.

Just checked the code in GLContext.java and you're right, for the
Sun JDK 1.3 and above JAWT will be used. The IBM JDK will use an
older fallback mechanism. Which are you using?

Regardless, a substantial portion of the core GUI system was
rewritten in the Sun JDK 1.4, so I can believe that the JAWT may
now be returning result codes (like JAWT_LOCK_SURFACE_CHANGED)
that it was not returning before.

I'm not sure if this is correct for the official binaries, but the 
version of GL4Java that I compile from the cvs uses jawt in both the 1.3 
and 1.4 library. So I'm assuming this can't be causing the problem.

Pepijn Van Eeckhoudt

Kenneth B. Russell wrote:
>>I don't know if it's the same problem but I'm also having problems with 
>>GL4Java-based apps when creating and destroying OpenGL components. After 
>>a random number of create/destroy operations application hangs without 
>>any error and has to be killed from task manager. This happens after 
>>init() is called and before first display() call. I was just preparing 
>>to track the problem down to specific line of code :-)
>>
>>I'm using JDK 1.4 with GNU/Linux.
>>
>>If someone needs any help in fixing this problem please let me know.
> 
> 
> Please do try to narrow down the root cause if you have time. The
> major change in GL4Java between JDK 1.3.1 and 1.4 is the use of
> the JAWT for acquiring the native window handle. If the code
> which uses JAWT doesn't handle all of the error cases properly
> then that is probably the source of the problems.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
> 

1999	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (12)
2000	Jan (39)	Feb (22)	Mar (41)	Apr (44)	May (47)	Jun (25)	Jul (28)	Aug (39)	Sep (35)	Oct (31)	Nov (31)	Dec (3)
2001	Jan (18)	Feb (43)	Mar (47)	Apr (38)	May (9)	Jun (20)	Jul (8)	Aug (11)	Sep (15)	Oct (43)	Nov (27)	Dec (73)
2002	Jan (42)	Feb (47)	Mar (49)	Apr (58)	May (12)	Jun (68)	Jul (42)	Aug (9)	Sep (19)	Oct (36)	Nov (28)	Dec (12)
2003	Jan (13)	Feb (24)	Mar (40)	Apr (52)	May (39)	Jun (46)	Jul (17)	Aug (5)	Sep (4)	Oct (9)	Nov (13)	Dec (12)
2004	Jan (1)	Feb (17)	Mar (4)	Apr (2)	May (1)	Jun (1)	Jul (1)	Aug (1)	Sep (1)	Oct (6)	Nov (6)	Dec (3)
2005	Jan	Feb	Mar (8)	Apr (1)	May	Jun (1)	Jul (2)	Aug (5)	Sep (4)	Oct (3)	Nov (3)	Dec (1)
2006	Jan (2)	Feb	Mar (3)	Apr	May	Jun (1)	Jul (1)	Aug (5)	Sep (8)	Oct (9)	Nov (8)	Dec (5)
2007	Jan (3)	Feb (11)	Mar (5)	Apr (5)	May (1)	Jun (2)	Jul (1)	Aug	Sep	Oct (1)	Nov	Dec (5)
2008	Jan (7)	Feb (8)	Mar (30)	Apr (17)	May (20)	Jun (8)	Jul (19)	Aug (10)	Sep (7)	Oct (2)	Nov (1)	Dec
2009	Jan (13)	Feb (7)	Mar (13)	Apr (27)	May (95)	Jun (77)	Jul (43)	Aug (25)	Sep (24)	Oct (32)	Nov (6)	Dec (6)
2010	Jan	Feb (2)	Mar (30)	Apr (58)	May (60)	Jun (72)	Jul (32)	Aug (45)	Sep (19)	Oct (4)	Nov	Dec
2014	Jan	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec
2016	Jan (2)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec