That was never an issue. I made sure to read documentation thoroughly before doing something.
https://jogl.dev.java.net/nonav/source/browse/*checkout*/jogl/doc/userguide/index.html?rev=HEAD&content-type=text/html

Under the section "Writing a GLEventListener":

Sample init code:


Render code:





OP:
If I need to initialise a new object within the game, I use an existing renderable item (I load up everything in the first shot) and change it's properties. For instance, properties of shaders can be changed like:



On the other hand if you wish to pass new geometry it would be worth looking into various data structures and patterns (The state pattern looks suited to this) depending on your existing design.

I pass the GL reference to my constructor and initialise everything there, it works out very nicely. I'm big on RAII.

Threads are a good idea! The problem is that people don't know how to use them. I'm currently developing a game for advanced software engineering (postgrad) and I have to use Agent Oriented Software Engineering, to put it simply everything is in a thread.

Use executors.
Use atomic variables/data structures.
Create your own lock-free algorithms (if you have to, but this can be very difficult).

The easiest way of doing things is what the other suggest, but if you have the time and want to learn what every software developer will need to know in the next decade then go with a proper threaded model.

Sorry, my URL I use is:
http://community.java.net/games/

I get redirected to my above posted URL.
Stole it off my bookmarks. Maybe I should update them.

I get this:
https://games.dev.java.net/nonav/index.html

Everyone forgot about me that they didn't e-mail me about the fact that the forums work. 
I'm not smart enough to figure out that forums work despite the front page. 

Anyway, I just wanted to say "Hello" because it's been a while since I last participated in this wonderful community.

Sorry.
I'm a f'ing idiot, lets move on.

If you want to stick to doing this some other way that's fine, however I'm sticking to my dot products and differential manifolds.
It's obvious that I cannot tell what you are asking by the last several posts.

Why would you use the dot product and why did you ask how to calculate the dot product when it's not what you're after?

I wonder why that's yet to happen to me? Oh! I now what I'm doing.
Sorry but the dot product is defined as above. You seem to be having trouble modelling a situation by the looks of it, you obviously don't know what you are talking about or the solution given by reading your above posts.

I never directly work with angles.

acos(1)
   -5.313886335150516808261004276581286123443877333843750081075849201e-85

Which in effect is actually supposed to be 0.

I'm sure alternatives can be used within a given context. Why don't you just use differential equations to compute the angle if that's what you're really after?
There are hundreds of ways to derive the same thing via alternative methods.

Parsing 3D files is simple, you get the specifications about the format you will or are going to work in and parse it according to that spec.

u.v/|u|.|v| = cos(t)

When the only ASM you know is Java byte code.

As I remember the problem was that memory being copied from one place to another via clone wasn't being done properly. This was a good few years back.
It was even discussed en mass on these forums. Some members even mentioned clone() was slower than creating a new object with the current object's properties.

http://www.javapractices.com/Topic71.cjp
http://www.artima.com/intv/issues3.html

I consider this a bug.

Just wandering if the clone issue is fixed.
I've not heard of it since it's last mentioned that there was going to be a fix for Mustang, but that was several years ago.

Question:
Is gl_pixel_buffer_object_ext is supported?

1/8th of what I do.

That's what I said/meant.
I split my geometry up into 2MB junks in an oct tree and then buffer each segment in video memory via VBOs.

However, I usually test my algorithms with data greater than what my video card can handle, so then I have to use statistics to determine what objects are visible and what sub objects of those objects are visible.
It's far more complicated than that but in any case the way I do things now makes things performingly viable. I've yet to see anything faster than what I do now.

You grab your mallet, I'll grab my armour and we'll meet the Sun engineers responsible. 

Sorry, never actually used that method call.
I do everything on the CPU and then lump everything in large quantities via vertex buffers using glDrawRangeElements. Apparently that's the most efficient way of doing things.

How are you able to put anything on screen if you don't us an index pointer? 

I cannot believe I missed the Integer class.
I'm silly.

I was using these 2:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Math.html#signum(double)
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Math.html#signum(float)

Thanks.

The $1.0e6 question!
I could never figure this out on my own.

Learn to control myself when attempting to make a game.

Now I know about it thankfully.
Why haven't Sun done anything about this since 1.4 according to the bug report?

Funny enough, I didn't know this issue existed however I've always been copying buffers via get() and put(). Funnier still, I don't take this approach to copying batches of other data, just float buffers and byte buffers.

Am I possibly psychic and know when a problem might occur sub-consciously?

https://jdk.dev.java.net/verifier.html

I read it before, but now I'm thinking no run time performance cast from type erasure for objects after the type <E> has been inferred from an instance of a generic class?
It is a runt time (on-line) verifier right?
Generic classes need to be inferred at runtime due to erasure.
Each generic instance that has a different type requires it's own byte code.
So it's fair the new verifier will eliminate a cast and just do a lookup?

Am I drinking and taking drugs?
Am I sane?
How did I manage to reach this conclusion?

More importantly, am I wrong(I'm a pessimist)?

Interesting.
I wish e-mail had something similar.

I've been browsing the game ideas section and looking at a few 4K competition entries (My favourite being Dungeon4K) and it occurred to me recently that expectations of how to solve a problem are "do the simplest method available".

As I've said previously, all the solutions I create tend to be fancy.
One thing that got me was Matzon's advice to a newbie posting in the Game Design forum about creating a maze.

Matzon's advice to the newbie struck me as normal but I've actually been wandering if such simplicity is good? So I tried to make a maze game.
My previous maze games in the past when I was a noobie have all been using arrays.

While it is easy to knock up a quad tree, I've actually spent 2 days devising a method recently of avoiding all boolean checks and branches when adding a volume into a quad tree.
I ended up doing a calculation of step functions and dot products, for what it's worth and ended up being trashed as someone on a specific forum I frequent ended up asking me "What does it do?" and I just responded by saying that it's the world's fastest quad tree(simply because it reduces conditional checks to 2, both are calculated from a numerical function anyhow and memory is accessed by the results), again I haven't actually tested it however after all the work it ended up being quite simple.

Anyway it's amazing how a very simple problem that can be accomplished within a few lines of code ended up turning into a research project. 

NOTE: By saying "I haven't tested it." I mean that I haven't benchmarked it.
If anyone's interested in the code I can knock it up quite quickly.