You can get most of the way there with the @NonNullByDefault annotation - you can apply this at the package, type or method level so it's not a lot of work to cover the entire codebase, and you can leave bits out if you want.

Vertex arrays should be far, far faster than glVertex calls. How are you using them? Can you describe your render loop?

Recordmydesktop works fairly well.

You don't have to go outside the repository to install a Sun/Oracle JDK - the package is called "sun-java6-jdk"

I had the same question.

Sounds like what you want can be solved by a doubly-linked list whose nodes are stored in an array, plus a stack to keep track of empty array locations.

Check out base 64 encoding

Is this in 2D or 3D?

Yes, java.lang.Integer is immutable. You would have to define your own mutable integer wrapper class.

As gouessej says, java passes everything by value - passing an object passes the value of the object reference.

No need to disable depth buffer, just either draw the glow quad further away (bump the z-coordinates or use glPolygonOffset), or set your depth test to LEQUAL and draw the glow quad first.

Sounds like successful tuning to me.

Android has both LWJGL and JOGL style ways to get at OpenGL, so porting is not a big problem.

Use Math.atan2( y, x ). It'll handle the division of mY over mX (and the attendant risk of divide-by-zero) for you. Note the order of arguments though - it's very easy to get used to entering the x value as the first argument when doing geometry stuff.

It's awful. Don't waste your time with it, especially for OpenGL stuff (software rendering FTL).

Edit for posterity: have since discovered that it's broken in scarily fundamental ways: Version 1.2 does not implement glGetFloat. Admittedly, it will log messages when you call it. The problem is that the message is "unimplemented API", so not too helpful.

I'm having difficulty understanding why this restriction is necessary. It seems like an arbitrary rule that can only reduce the quality and amount of help that the forum can offer. Could you perhaps explain what undesirable outcome it is protecting us from?

Use System.currentTimeMillis() to track the time between frames

Is this any good?

Aye, use delta time if you want to update not in multiples of frames. i.e

Good news!

Thanks for the feedback: So it seems that this is at least not embarrassingly obviously my fault. The possibilities that I can see:

• Malicious users: they've altered or fabricated the error reports. I've had reports from 3 different people, I'd hope that they'd have more to do with their lives than conspire to troll me with bizarre error reports.
• Some error in the reporting mechanism. I can't see it if it's there. Anyone else?
• VM error. I've encountered some worrying stuff in android before, but this is on a different level entirely...

I suppose the android mailing list would be the next step...

As I noted just before the outage, spammers are still managing to register. It seems that there are actually three certainties in life: death, taxes and spammers.

Huge props to Riven for his efforts. It sounds like this attack was a shuddering nightmare for your server, so to have the forum back up so soon deserves more than an appreciate++. Thankyou.

Does a more secure forum package exist? From reading the #lwjgl logs it sounds like SMF is a gaping orifice of fail on the security front, and our installation in particular is thoroughly compromised. If it's going to be a ball-ache to fix up then I wouldn't be opposed to a fresh start: stick the current forum into a read-only archive, everyone re-registers and carries on as before.
It's happened before IIRC, when we moved to YABB.

I'm going to change my vote to minus A. I want the red eye without highlight, but I also want no highlight on the head or text. Minimalist FTW.
Icons and logos should be as simple and bold as you can get away with, not made out of polished plastic.

I wish it were that easy. The code was lifted straight from somewhere else, java-fied and committed.  I haven't touched it since, so I don't think there are any other versions of this class out there (at least from me). Also, the crash report was versioned :-/

Can anyone see how this frustum code can cause the following exception?


The offending line 180:

The declaration of the frustum arrays:

The only instances of "new" in that file are the 4 at the start, so there's no way that the arrays are being changed after construction.
To put it mildly: 

I've had 5 reports of this from 3 different users. The only possible explanation that I can see someone out there has taken my (freely available) code, b0rked it, and is distributing broken apks.

Does anyone have an alternative?

Well that seems to have worked, I haven't seen a spam post since
Bizarrely, there are still spam profiles getting through. I find it incredible that there are real people out there who have the knowledge to compile and run a java snippet who find it worthwhile to spam forums. Do we know if they try to post, or is their objective just to get the signature into the DB? Does the verification snippet change? Is it possible that the solution is being shared amongst spammers?

I also note that I've gained a "Delete this account" ability that purports to nuke a user and all their posts. Is this safe to use? Have the potential DB problems been resolved?
I have to admit, its presence makes me slightly nervous. I'm pretty sure I'm not going to abuse the awesome power it affords, but who knows what evil lurks in the hearts of men? It's like a big red button labelled "DO NOT PRESS" 

It is a ridiculous piece of interface design - the most useful link is the smallest, least obvious thing to click.
In fact, would it be possible to make the thread title link go to the first unread post rather than the first in the thread?

Something like http://www.java-gaming.org/index.php?action=unread?

A++

You still NDA'd?