PlayN 1.3.1

[Michael Bayne]

PeopleN,

Hot on the heels of the 1.3 release, I present the 1.3.1 release! This
patch release contains a few bug fixes, a revamping of the way PlayN
Game projects are organized with Maven, and instructions on how to
build for iOS (made possible by simplifications to the build process
that I got into this patch release). The release notes are up:

http://code.google.com/p/playn/wiki/ReleaseNotes

I have updated the Getting Started wiki page to reflect the new Maven
instructions. The summary of the changes is as follows:

Old command line:

Java: mvn test -Ptest-java
HTML: mvn package && mvn test -Ptest-html
Flash: never worked because this backend was totally disabled lest it
break normal builds
Android: mvn install && mvn -f android/pom.xml android:deploy
iOS: had no instructions for this because it was complicated

New command line:

Java: mvn test
HTML: mvn -Phtml integration-test
Flash: mvn -Pflash integration-test
Android: mvn -Pandroid install
iOS: mvn -Pios package

The other great thing about these simplifications is that Maven no
longer builds all the sub-projects any time you try to do anything. By
default it only tries to build the core and java sub-projects, which
are what a new PlayN user will want. Only when you specifically try to
test or deploy another backend will it trigger those builds.

This means that the fact that the Maven Android plugin blows up if you
don't have the path to your Android SDK configured in the Maven
settings is no longer an issue until the developer specifically tries
to deploy to Android by running "mvn -Pandroid install". Yay!

The procedure for building and testing on Eclipse is also vastly
simplified. It is no longer necessary to install the GWT plugins at
all. I wish it were no longer necessary to install the Android
plugins, but unfortunately Eclipse freaks out during the import
process if the Android plugin is not installed. I might revisit this
again later and eliminate this requirement by suppressing those
warnings directly.

To test the Java backend via Eclipse, one can either "Run as -> Maven
test", or if one opts to install the Maven Natives Plugin for Eclipse
(linked in the Getting Started instructions), then you can "Run as ->
Java application" and the LWJGL native library stuff will be
automatically set up. The Getting Started instructions mandate the
installation of the Maven Natives Plugin for Eclipse, because again,
Eclipse insists on freaking out during the import process if that
plugin is not installed. I could suppress that freakout directly, but
I think using the Maven Natives Plugin is actually a better approach
in this one case because it allows you to debug via Eclipse and allows
a slightly faster "press button to see app running" time than doing
things via Maven.

It is now trivial to deploy to an Android device or emulator via
Eclipse. Simply right click the foo-android sub-project and choose
"Run as -> Maven install" (assuming you have followed the Getting
Started instructions and configured Eclipse to use Maven 3.0.3 or
newer, tragically the version of Maven that is bundled with Eclipse is
3.0.2).

It is also now trivial to build and test the HTML5 version of your
game. Simply right click the foo-html sub-project, choose "Run as ->
Maven build..." and type "integration-test" into the Goal field and
press return. This will build the GWT version of your game and serve
it up on localhost:8080. No need to remove GWT developer plugin crap
from URLs or to do any other error prone wacky steps.

For people with existing projects that want to switch to this new
setup, this change set shows the changes you will need to make to your
POMs:

http://code.google.com/p/playn-samples/source/detail?r=dbf7ff37d3ba0f87c912143f9f01ee4012b35a80#

As I also mentioned, I have written iOS build instructions. Those are here:

http://code.google.com/p/playn/wiki/iOSBuild

They assume you have the new Maven setup and recent changes made to
the Maven archetype. If you want to add an iOS module to an existing
project, use the Maven archetype to generate a skeleton for your
project (in some scratch directory) using the same
groupId/artifactId/JavaGameName that you used for your existing
project, then replace your old ios directory with the new ios
directory. (You could probably also use this technique to update your
other POMs to bring them in line with the new Maven setup, just don't
change your core/pom.xml since that has your game-specific
dependencies and nothing has changed in that POM IIRC.)

Happy PlayNing (and no comPlayNing),

-- m...@samskivert.com

[Evgeni Gordejev]

How I can add ios module to an existing project in Eclipse, I have started project long before ios port and now I updated it to 1.3.1?

[Michael Bayne]

On Fri, May 25, 2012 at 9:20 AM, Evgeni Gordejev
<evgeni....@gmail.com> wrote:
> How I can add ios module to an existing project in Eclipse, I have started
> project long before ios port and now I updated it to 1.3.1?

Perhaps you didn't read all the way to the bottom of my email?

On Thu, May 24, 2012 at 12:52 PM, Michael Bayne <m...@samskivert.com> wrote:
> They assume you have the new Maven setup and recent changes made to
> the Maven archetype. If you want to add an iOS module to an existing
> project, use the Maven archetype to generate a skeleton for your
> project (in some scratch directory) using the same
> groupId/artifactId/JavaGameName that you used for your existing
> project, then replace your old ios directory with the new ios
> directory. (You could probably also use this technique to update your
> other POMs to bring them in line with the new Maven setup, just don't
> change your core/pom.xml since that has your game-specific
> dependencies and nothing has changed in that POM IIRC.)

Follow those instructions, move the ios directory into your game and
then import the ios directory into Eclipse just like you imported your
original project (or re-import your root project and it will notice
the new directory and add it).

-- m...@samskivert.com

[Evgeni Gordejev]

Thanks, I have read you post many times, but not all the way to the bottom :)

[Michael Bayne]

On Fri, May 25, 2012 at 9:40 AM, Evgeni Gordejev
<evgeni....@gmail.com> wrote:
> Thanks, I have read you post many times, but not all the way to the bottom
> :)

I do tend to be a bit wordy.

-- m...@samskivert.com

[Evgeni Gordejev]

Is it so that I have to add all the assets by hand to .csproj or did I miss something again? I have made a symlink.

[Evgeni Gordejev]

Now I have another problem when I start application in Monotouch, application stops at message:

Application windows are expected to have a root view controller at the end of application launch

What could this mean, do I still miss something?

[Michael Bayne]

That message is normal, harmless, and unfortunately unavoidable. Something else must be wrong with your app if it's crashing.

-- m...@samskivert.com

[Evgeni Gordejev]

it seems that my app is running, the problem is that view is pitch black :(

though java,android and html5 ports works without any problems

[Michael Bayne]

On Fri, May 25, 2012 at 12:43 PM, Evgeni Gordejev
<evgeni....@gmail.com> wrote:
> it seems that my app is running, the problem is that view is pitch black :(
> though java,android and html5 ports works without any problems

I've never seen that. Have you run any of the sample apps in the iOS
simulator? Do they work?

-- m...@samskivert.com

[Evgeni Gordejev]

Showcase works, ok I'll try to debug my program and check for differences. Thanks Michael for help.

[Evgeni Gordejev]

I have found what causing black screen, it is surfacelayer any call to surface like fillrectangle() or clear() cause black screen. 

[Evgeni Gordejev]

I have tried same thing with showcase demo just added SurfaceLayer to Menu.java and now it doesn't work anymore. My paint function look like this:

@Override

  public void paint(float alpha) {

    if (iface != null) {

      iface.paint(alpha);

      sl.surface().clear();

      sl.surface().setFillColor(0xffff0000);

      sl.surface().fillRect(10, 10, 30, 30);

    }

  }

Could there be a bug in the IOS SurfaceLayer?

[Bryan Alvarado]

We are using ImmediateLayers, wich are kind of a surface layer, and it works fine in iOS.

Sent from my iPod

[Bryan Alvarado]

Sorry for the short answer, I was on mobile, we have been using ImmediateLayer for one of our games, and we have tested it in iOS, and it is working, the only problem is that the game only works in portrait, not in landscape, when in landscape there is part of the screen that just appears black, but the buttons and everything is there, it is just not getting painted for some reason, but you should try ImmediateLayer, it is a surface-based Layer as well.

2012/5/26 Bryan Alvarado <bryan.a...@gmail.com>

--

Bryan Alvarado

http://about.me/bryan.

[Evgeni Gordejev]

Sure I will try Immediate layer, I just thought that playn is now fully ported to IOS platform. The second thing what you said about landscape, thats very bad thing for my game I really need game in landscape view 

[Evgeni Gordejev]

I just tested "cute" demo in landscape mode on ipad simulator and it works fine and cute uses immediate layer.

lauantai, 26. toukokuuta 2012 19.30.05 UTC+3 Bryan Alvarado kirjoitti:

lauantai, 26. toukokuuta 2012 19.30.05 UTC+3 Bryan Alvarado kirjoitti:

[Michael Bayne]

On Sat, May 26, 2012 at 11:26 AM, Evgeni Gordejev
<evgeni....@gmail.com> wrote:
> I just thought that playn is now fully ported to IOS platform.

It is fully ported, but I didn't say it was completely free of bugs. :)

I have noticed some sort of bug with SurfaceLayer relating to their
use of frame buffers, which I have not been able to track down. The
vast majority of that code is shared between iOS, Android and
Java/LWJGL, and I haven't been able to find any obviously incorrect
code in the little bit of iOS specific code that creates, binds and
deletes frame buffers.

Not that this is an excuse for incorrect behavior, but you almost
certainly don't want to be using SurfaceLayer. There are very few
situations where SurfaceLayer is a sensible approach. Most of the
time, you're better off using ImmediateLayer, or a CanvasImage in an
ImageLayer.

-- m...@samskivert.com

[Michael Bayne]

On Sat, May 26, 2012 at 9:30 AM, Bryan Alvarado
<bryan.a...@gmail.com> wrote:
> the only problem is that the game only works in portrait, not in landscape

I have extensively tested the portrait and landscape handling of the
iOS backend, so you must be triggering a subtle bug. As Evgeni
mentioned, the samples work in portrait and landscape with no
problems. The playn/tests project also works fine in portrait and
landscape, and it specifically uses as many features of PlayN as it
can.

-- m...@samskivert.com

[Bryan Alvarado]

Thanks Michael and Evgeni, I probably should check the demos to see what it's triggering that kind of behavior, other than that, the iOS backend has been working perfectly :)

2012/5/26 Michael Bayne <m...@samskivert.com>

[Bryan Alvarado]

FWIW, I got it working now, I just deleted the 

IOSPlatform.SupportedOrients.LANDSCAPES

then built the project in MonoDevelop, and then putted back in again and built the project, and it was working in Landscape by default. :)

2012/5/26 Bryan Alvarado <bryan.a...@gmail.com>

[Evgeni Gordejev]

Great, now everything works with immediate layer.

I also have noticed that you don't need to use surface.clear() when you are using immediate layer with others layers, clear() function will mess everything it is probably not a bug but a feature :)

And seems that you don't need to call graphics().setSize(w,h) on IOS platform, this command will mess up with view transformation.

I have average of 10fps in ipad simulator, does anyone have any experience how much it will be improved on real device? I have iMac with 2.5 GHz Intel Core i5 and AMD Radeon HD 6750M 512 MB

[Bryan Alvarado]

How have you been measuring the FPS in the games?

2012/5/27 Evgeni Gordejev <evgeni....@gmail.com>

[Evgeni Gordejev]

Actually I'm not sure if this is the right way to measure, but here is mine implementation:

public void paint(float alpha) {

long elapsedTimeMillis = System.currentTimeMillis()-startTimeMillis;

float newFps = 1000f/elapsedTimeMillis;

fps = fps*0.99f + newFps*0.01f;

fpsLayer.canvas().clear();

fpsLayer.canvas().drawText("fps "+fps, 10, 10);

startTimeMillis = System.currentTimeMillis();

}

[Bryan Alvarado]

We don't have a implementation for that, but yours seems good, thanks, we're gonna give it a try :)

2012/5/27 Evgeni Gordejev <evgeni....@gmail.com>

[Michael Bayne]

On Sun, May 27, 2012 at 1:28 AM, Evgeni Gordejev
<evgeni....@gmail.com> wrote:
> I also have noticed that you don't need to use surface.clear() when you are
> using immediate layer with others layers, clear() function will mess
> everything it is probably not a bug but a feature :)

ImmediateLayer renders directly to the main frame buffer (the one that
is displayed on screen), so if you clear it, you will clear anything
that has been drawn on the current frame prior to your immediate layer
being rendered.

> And seems that you don't need to call graphics().setSize(w,h) on IOS
> platform, this command will mess up with view transformation.

Correct, setSize() doesn't even make sense on iOS (or Android, which
foolishly has a bunch of complex code that tries to support it). I
thought I made it a NOOP, but apparently not. I'll change it to issue
a warning rather than cause things to break. Actually, I'd rather just
remove the API altogether. It doesn't make sense on HTML (where you
should just size the <div> that contains PlayN), it doesn't make sense
on Flash (where you size the stage via various mechanisms). The only
platform that it makes sense on would be Java and it would be better
to pass your desired size to JavaPlatform.register().

> I have average of 10fps in ipad simulator, does anyone have any experience
> how much it will be improved on real device? I have iMac with 2.5 GHz Intel
> Core i5 and AMD Radeon HD 6750M 512 MB

The simulator is definitely slower than the device in some ways,
though I'm entirely sure why.

-- m...@samskivert.com