The application that I work on uses as many as nine GLCanvas objects on screen at once, and there's no noticeable slowdown (except when initially creating or resizing).

When you remove a GLCanvas from its container, the state of its context is lost. I'd guess that without the second popup sharing the context that your Main Screen's context is being lost when it is removed.

One option would be to create a PBuffer at application start and use that as the shared context object for all the other views.

(I'm not sure if GLJPanel has the same problem, since it uses PBuffers internally)

Personally I'd use <a href="http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html">ServiceLoader</a> - it's a bit more effort when creating your plugin jars, but it prevents you having to play around with custom classloaders or suchlike.

I've been considering that, but recreating the textures isn't a problem. We use quite a few GLCanvas objects with only a small number visible at once, so keeping the textures around would just use texture memory that would be better reused elsewhere. I can think of better approaches, but it's not really worth refactoring at this point.

Ah! I hadn't realise that init() was getting called every time the context is recreated. That makes things a lot easier.

Thanks!

I'm having an interesting problem with the context of my GLCanvas objects. The software I work on uses a number of GLCanvas objects to display views on a data set. It creates a number of textures to hold the views.

When a view is hidden, it's removed from its parent component temporarily; when the parent component is made visible again, the GLCanvas is added back in. However, the GL context has lost any textures that were associated with it.

Currently we deal with this by subclassing GLCanvas and overriding addNotify and removeNotify. However, this isn't a very nice approach. Is there some standard JOGL way of detecting this context cleanup instead, to allow textures and suchlike to be invalidated?

Your texture creation code looks right at a quick glance. By default, textures aren't shared between GL contexts (and each GLCanvas has a different context).

You can share objects (textures, shaders etc.) between components using the four-parameter version of the GLCanvas constructor, passing in the context you want to share with as the third parameter (on a sidenote, you can get the context from the getContext() method of GLCanvas). Alternatively, create a GLPBuffer as your shared context object, and pass its context into both GLCanvas when constructing them.

But for some reason, still no java plugin or webstart for 64-bit platforms.

Does the JVM do bounds-check removal on Buffer types? I know i does on arrays..

Ah! Thanks for that! I've tried that out in my code, and.. I'm afraid it was slower Even using if instead of ?: was slightly slower.

I guess that proves the maxim that you should always benchmark in your own working code..

OK, slightly off-topic, but while we're talking about wierd optimisations.. Anyone know a decent capping algorithm? My current code is:



Any wierd bitshifting things that can do this?

Apologies for the confusion - I saw jME-physics on the java.net games page, I hadn't realised it was an incubator project!

I voted -1, as I thought jME-physics would be much better off in the jME repository, as it is jME-specific. As I said, if it was a general physics binding library (or physics abstraction layer) I'd be very happy with it. Personally, I don't like the idea of fragmenting what would be better as a single project (IMHO). Surely jME would be better off as a scenegraph with built-in physics than as two projects?

Anyway, that's my personal feeling. I'm going to retract my -1 vote though - I've made my point, and I'm not going to stand in the way of the rest of the community

-CDF

I assumed this had been approved?

https://jmephysics.dev.java.net/

It seems to exist..

AFAIK UPnP was originally created by Microsoft - or at least they had a lot of influence on it..

Yep, no security at all in UPnP. But the way I see it, is that users who know enough to disable UPnP are the ones who know enough to be able to open a port in their router if you ask them to (and if they trust you, obviously). The main advantage of UPnP is that the program can do that if the user doesn't have the knowhow to do it themselves.

OK, it's been changed. Phew!

Doh! I was a half-asleep when I was adding it. I thought Balls4k described it more accurately - I'll go see if I can change it back..

Anyway, I actually prefer Spline4k as a name. I don't know what I was thinking 

My bad

Most GUIs seem to use a layout manager of some kind to arrange components in the window - so your widgets are the same pixel size at any resolution, but get moved around as you suggest to fill the available space properly.

Yeah, but they don't have IGD support built in. And I fancied a challenge, too..

Anyway, the code's there if you want it!

Hey, gameplay has to count for a lot! If the tech is amazing and the gameplay is sucky, I'd go find another game 8-) Which I imagine is what'd happen with a general vote. The really cool games that you keep coming back to (Fuzetsu and Miners have both grabbed me) would be the ones that would do best, surely?

Just my two cents..

I've written a UPnP implementation in pure Java. It's not complete, but it's enough for controlling a uPnP-compatible router with. So far it has wrappers for IGD (Internet Gateway Device).

It should be reasonably easy to use, but let me know if there's any problems. I've not documented much of it so far.

http://www.chaosdeathfish.com/cms/cdf-upnp

OK, I had a sudden urge to write a UPnP control point in Java. It still needs some work, but it can do port forwarding. And in theory it can control almost any other UPnP device, but I've written a simple wrapper that makes port forwarding easy.

Hopefully I can get it a bit more polished and release it for general consumption sometime in the next few days!

Vorax, whereabouts in the world are you? I worked out flight, hotel and conference pass (classic pass) at about £1000, about $1750. Of course with meals and spending and all that it'd be more than that..

edit: I meant 1750USD of course, not 1750GBP..

I assume you mean go to GDC

If I had the money I'd definately go, but it costs too much to fly over, stay a few nights in a hotel and get into the conference as well.

Although I'm tempted by GDC Europe..

I've actually found the relevant part of the uPnP spec now! Unfortunately I haven't got the time to do a proper IGD implementation. I've looked at cyberlink uPnP for Java (which is BSD license), which provides the framework but no profiles. It uses its own HTTP implementation, which seems a little odd - although it is ported from a C++ version I think.

Anyone feel like writing an IGD implementation?

I've played with the Maya Personal Learning Edition, and it seems pretty damn nice - much easier to use than Blender, more intuitive. Unfortunately I haven't dabbled much with it as you can't export anything from the personal learning edition, so it's not like I could do anything useful if I did..

Why not just put jME-Physics in the jME repository? I would've thought it'd fit better there, as it's tightly coupled with jME?

Although if you were going to reimplement it as a generic Java physics API that could wrap ODE, Novodex and others, I'd definately be all for it!

I started writing a TTD clone in java a couple of years ago, but got distracted before I'd written much.. All I did was load the the TTD graphics and levels in and display the landscape.

Still, if you're interested I can dig out my code and send it to you, there might be something useful in there..

Unless you use uPnP, which most routers I've come across recently support.

Speaking of which, does anyone know of a decent uPnP library for Java? (Just the Internet Gateway Device profile, not the rest of it). I was thinking of writing one, but the uPnP specs seemed designed to confuse me.

Sorry, my bad - I've fixed the main jar file now, it should work properly.

I've turned the speed down, since I've had many complaints Hopefully the new version should be easier to play.

In other news, I've done lots more optimising and got the jar down to 3772 bytes!  So hopefully more features to come. Current plans are bosses, multi-directional bombs and maybe more!

-CDF