1.3-SNAPSHOT lwjgl configuration issue

106 views
Skip to first unread message

nvosker

unread,
May 3, 2012, 3:36:41 AM5/3/12
to PlayN
I just recently upgraded my project to use 1.3-snapshot of playn.
When I try to run the java version, I'm getting a
java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path. Is
there some additional setup that needs to take place that I'm not
aware of? I searched the forum but I haven't found anything. I also
tried building and running the 1.3-snapshot of playn samples and I'm
getting the same error. Not sure if this is the right approach, but
I was able to get my project to run when I set -Djava.library.path=
in my jvm args in my IDE, but I get two issues. The performance is
really really sluggish now and I still can't can't clean and build the
project because my test cases fail to get the library path and again
gets a UnsatisfiedLinkError.

Bryan Alvarado

unread,
May 3, 2012, 9:37:13 AM5/3/12
to pl...@googlegroups.com
You have to setup lwjgl in your system, the instructions are here .

2012/5/3 nvosker <nvosker...@gmail.com>



--
Bryan Alvarado



Neil Voskeritchian

unread,
May 3, 2012, 10:34:32 AM5/3/12
to pl...@googlegroups.com

Ok thanks.  I did that, and I got it to run, but do you have any idea why my java version of the game would suddenly run extremely sluggish just from moving from 1.2 to 1.3?

Bryan Alvarado

unread,
May 3, 2012, 11:08:17 AM5/3/12
to pl...@googlegroups.com
How is your WebGL version of the game running? It could be your graphics card, remember that now your java backend is running on GL, I tried the lwjgl version and it ran just fine.

2012/5/3 Neil Voskeritchian <nvosker...@gmail.com>

Bryan Alvarado

unread,
May 3, 2012, 11:13:37 AM5/3/12
to pl...@googlegroups.com
How is your WebGL version of the game running? It could be your graphics card, remember that now your java backend is running on GL, I tried the lwjgl version and it ran just fine.

2012/5/3 Neil Voskeritchian <nvosker...@gmail.com>

Ok thanks.  I did that, and I got it to run, but do you have any idea why my java version of the game would suddenly run extremely sluggish just from moving from 1.2 to 1.3?

Neil Voskeritchian

unread,
May 3, 2012, 2:01:47 PM5/3/12
to pl...@googlegroups.com
Well, it looks like the sluggishness was do to using the deprecated setSourceRect on an image layer.  I switched it to use subimage like the docs recommended.  However, now performance is back to normal but my sprite sheet based animation is not showing like before.  It seems to shrink the entire sprite sheet image to the specified width and height instead of cropping out the specified area.  Do you have any guidance on what may have changed between setSourceRect and subImage?

Michael Bayne

unread,
May 3, 2012, 2:12:02 PM5/3/12
to pl...@googlegroups.com
On Thu, May 3, 2012 at 11:01 AM, Neil Voskeritchian
<nvosker...@gmail.com> wrote:
> It seems to shrink the entire sprite sheet image to the specified width and
> height instead of cropping out the specified area.  Do you have any guidance
> on what may have changed between setSourceRect and subImage?

You may have been calling setWidth/setHeight on your image layer.
That's no longer needed when you use a subimage.

-- m...@samskivert.com

Neil Voskeritchian

unread,
May 3, 2012, 3:25:53 PM5/3/12
to pl...@googlegroups.com
Well I figured out the issue with subImage.  Based on what I saw in the examples, it seems you have to keep setting the image back into the image layer while at the same time calling subImage.  Before I was able to just repeatedly call setSourceRect on the image that the ImageLayer already contained.  Is this by design?  Now I have to call imageLayer.setImage(image.subImage(x,y, width,height))  on every frame update I want animation to take place.  Also, I am still getting performance issues with the Java version of my game.  The HTML webgl version still runs just as it did in 1.2 playn, maybe even better.  Is there some additional jvm setting that need to be added for lwjgl to perform well?  I have a 2 year old dual core Macbook pro with 8 gigs of ram.  I can't imagine my computer being the culprit here.

Michael Bayne

unread,
May 3, 2012, 3:53:33 PM5/3/12
to pl...@googlegroups.com
On Thu, May 3, 2012 at 12:25 PM, Neil Voskeritchian
<nvosker...@gmail.com> wrote:
> Before I was able to just repeatedly call setSourceRect on the image that
> the ImageLayer already contained.  Is this by design?  Now I have to call
> imageLayer.setImage(image.subImage(x,y, width,height))  on every frame
> update I want animation to take place.

I recently added Image.Region.setBounds() for exactly this use case. I
haven't merged those changes upstream, I'll do that now. The
SubImageTest in playn/tests demonstrates the use of this API:

private float elapsed;
private Image.Region osci;

public void init() {
Image orange = assets().getImage("images/orange.png");
osci = orange.subImage(0, 0, orange.width(), orange.height());
graphics().rootLayer().addAt(graphics().createImageLayer(osci), 150, 300);
}

public void update(float delta) {
elapsed += delta;
float osciCurWidth = Math.abs(FloatMath.sin(elapsed/1000)) *
osci.parent().width();
osci.setBounds(0, 0, osciCurWidth, osci.parent().height());
}

-- m...@samskivert.com

Michael Bayne

unread,
May 3, 2012, 3:56:04 PM5/3/12
to pl...@googlegroups.com
On Thu, May 3, 2012 at 12:25 PM, Neil Voskeritchian
<nvosker...@gmail.com> wrote:
> Also, I am still getting performance issues with the Java version of my
> game.  The HTML webgl version still runs just as it did in 1.2 playn, maybe
> even better.  Is there some additional jvm setting that need to be added for
> lwjgl to perform well?  I have a 2 year old dual core Macbook pro with 8
> gigs of ram.  I can't imagine my computer being the culprit here.

I've never seen a situation where the (new LWJGL-based) Java backend
was not *way* faster than the HTML backend. Can you describe the code
that's performing slowly or can I see it on Google Code or Github or
elsewhere?

-- m...@samskivert.com

Neil Voskeritchian

unread,
May 3, 2012, 6:13:01 PM5/3/12
to pl...@googlegroups.com
Thanks Michael.  I think your setBounds pushed fixed my issue.  Performance just went back to normal by using that instead of setting the clipped image back into the layer on every update.  Guess maybe had a lot of GC's going on.
Reply all
Reply to author
Forward
0 new messages