Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
21. April 2012

 

 

 

Over on the PlayN Google group PlayN 1.2 has been announced.  I have checked and it is up on Maven, although you need to click “Include snapshot archetypes” to find it.  To get started you can follow this install guide using these settings:

 

 

image

 

 

As to what’s actually new?

 

- You can now listen for mouse and pointer events directly on layers.
- Ray brought the Flash backend up to date. Christopher &co at
King.com shipped an awesome Facebook game using it.
- There's an experimental GL20 interface that allows you to make
OpenGL calls directly. It works on Android and WebGL.
- Image.subImage relieves you from having to roll your own image tiling code.
- The iOS backend is almost entirely done. There's an ios submodule in
the new Maven archetype. A getting started guide is still needed.
- Check the release notes for all the other awesome improvements, both
large and small.

In addition to playn-1.2, I have also released tripleplay-1.2 for your
user interface creating pleasures (along with a grab bag of other
useful things)

 

 

Flash and iOS maturing are both great news, and direct access to OpenGL are sure to be useful features.  More details of what’s new can be found in the release notes.

News


13. February 2012

 

On the PlayN discussion forum PlayN 1.1 was just announced.  Complete release notes are available here.

 

 

Key new features include:

  • add HTML Canvas backend ( in addition to the WebGL and deprecated DOM HTML5 back ends ) as a fallback for browsers that don’t support WebGL *cough* Internet Explorer *cough*
  • iOS support… probably the biggie of this release
  • removed GAE dependencies ( this was a pain in the butt previously )
  • Android properly supporting mp3
  • various other bug fixes

 

As was mentioned in this earlier post iOS support isn’t complete, yet.

 

 

Good job PlayN team!

News Programming


8. February 2012

 

logo

A couple days back, PlayN developers posted a handy little tablet showing what the current development status is for each supported platform.  The iOS support seems to be coming along nicely, but as you can see, there is still some work to be done.



  Java HTML5 Android iOS Flash
Analytics Stub Comp Stub Stub Stub
Assets Comp Comp Comp Part Comp
Audio Comp Comp Part Stub Comp
Graphics Comp Comp Comp Part Part
Json Comp Comp Comp Comp Comp
Keyboard Comp Comp Comp Stub Comp
Log Comp Comp Comp Comp Comp
Mouse Comp Comp N/A N/A Stub
Net Comp Comp Comp Stub Stub
Pointer Comp Comp Comp Comp Comp
RegExp Comp Comp Comp Stub Stub
Storage Comp Comp Comp Comp Comp
Touch N/A Comp Comp Comp Stub

Key:

  • N/A - not applicable to this platform (i.e. mouse on mobile).
  • Stub - non-functional placeholder implementation.
  • Part - partially implemented with some missing pieces.
  • Comp - fully implemented.

Also see the Roadmap.

 

 

Very cool news.  One of the items on the roadmap is better documentation, something I really look forward to.  Supporting iOS is definitely a huge deal, especially for Java developers that don’t want to go within a thousand feet of Objective C but want to be able to target the massive iPhone/iPod/iPad market, while still supporting desktop, Android and web targets.

News


26. January 2012

 

 

You may remember me discussing PlayN in previous posts, it’s a Google run cross-platform, open source game library.  Previously the most missing feature was iOS support and frankly that feature is still missing, but there is light at the end of the tunnel!

 

 

PlayN developer Michael Bayne recently made a post announcing he had successfully got the Peas demo running on an iPhone4. IMG_0935Without a doubt this progress is a “very good thing”, as iOS support is easily the most important missing feature of PlayN today.

 

 

Michael’s progress:

 

I got side tracked by trying to get things working on a real device.
The simulator runs the Mono VM in JIT mode (though with various
restrictions in place to ensure that you don't do anything that's
incompatible with AOT compilation), but actually doing AOT compilation
enforces substantially more restrictions. I had to "refactor" IKVM to
contain no references whatsoever to System.Reflection.Emit even if
they were never called. I also bumped into a Mono compiler bug and
spent some time digging into the internals of IKVM and mcs (the Mono
compiler) so that I could come up with a work-around and file a
sensible bug report. It turned out to have already been fixed in trunk
(which made my investigations that much more perplexing), but since
MonoTouch is commercial software, I was necessarily working with the
latest beta release, not trunk; annoying!

Performance of the Pea Physics demo is not stellar on an iPhone 4
(it's quite reasonable, it's just not silky smooth 60 FPS with twenty
or thirty peas moving on screen). It's pretty comparable to what I've
see on actual Android devices. Depending on what Box2D's interfaces
are like, there's a possibility that it could be improved by writing
an interface-compatible implementation of Box2D directly in C#. C#
supports value types, and in a physics simulator, being able to store
your Vec2s and Matrix3s directly inline, rather than separately on the
heap, can substantially improve cache performance. That said, the
Box2D implementation, as is, is not very data-oriented. Rewriting it
to store all of the entity geometry in big flat arrays and to perform
its calculations by iterating over those arrays, rather than following
a zillion pointers through the heap, would probably help a lot on
every platform.

Now that I've got things running on an actual device, I'll go back to
finishing up the platform implementation. IOSCanvas is substantially
done. IOSStorage is done (built on Sqlite). IOSTouch (and IOSPointer)
are done. I need to implement the font and text rendering bits of
IOSGraphics/IOSCanvas. Then IOSSound, IOSNet and other niggling bits.
I'm not sure what I'll do about IOSKeyboard. I'd kind of like an
additional interface for requesting a string of text from the user,
which would allow the keyboard to pop up in "edit a line of text" mode
so that the user can use the standard copy/paste and click with
magnification text navigation. Having the app respond to key events
and attempt to implement text entry directly is a massively bad idea
(on any mobile device), IMO.

 

 

Excellent news and great work Michael! 

 

So for the people looking to see if PlayN works with iOS, the answer is no, but it’s damned close!

Programming


12. November 2011

 

The new update should make the install process even easier. The process still works the same, just now with less annoying warnings and work around required.  Also, the Java (target) has been split out as an individual sub-project, a move which makes lots of sense.  I would describe why, but frankly the original author Michael Bayne did a good job already.

Howdy everyone,

I just released PlayN 1.0.1 to Maven Central (and the mirroring to the
public servers is complete).

This release corrects a bunch of pesky errors relating to building
PlayN that crept into the 1.0 release in the eleventh hour.

It should now be possible to import the PlayN sample projects and to
create a new PlayN project using the Maven Archetype without
encountering a single error or mysterious weirdness in Eclipse. I
would have liked to be able to say "warning or error," but annoyingly
my Eclipse complains that certain XML files lack a DTD specification,
which seems excessively anal to me, but that's how they like to roll
over there at Eclipse HQ.

One other important change was introduced in this release. The PlayN
archetype now generates a separate "java" submodule which contains the
Java backend entry point file (FooGameJava) and which has a dependency
on playn-java. The core submodule now only depends on playn-core.

Prior to this change, the core submodule depended on playn-java (and
by transitivity playn-core) and the Java entry point was in the core
submodule. This eventually causes problems, because all of the other
submodules (html, android) depend on the core submodule, and if one
added some Java-only dependency to their code submodule so that they
could use it when testing with the Java backend, it would show up in
the html and android submodules and cause problems. Now the core
submodule can remain "pure" with only PlayN-safe dependencies, and if
you need additional dependencies for your Java backend, you add them
to the java submodule where they won't cause problems with the other
submodules.

Because the Java entry point is in a separate project, it is now
necessary to test the Java backend via Maven in a different way.
Instead of "mvn compile exec:java" in the core submodule directory,
one now invokes "mvn test -Ptest-java" in the top-level project
directory. This is more consistent with the way the HTML backend
works, so that's nice. It's also unfortunately a little slower, and
when you're rapidly edit/compile/debugging, every millisecond counts.
The "ant run-java" target still works great in this new setup, and
remains very fast, so I recommend that command line users use that to
iteratively build and test their project. Eclipse users will now "Run
As -> Java Application" on the mygame-java project instead of the
mygame-core project, but otherwise everything is the same.

Due to current-working-directory related issues exacerbated by the
creation of the java submodule, I rewrote the Java asset manager to
load assets from the classpath (robust) instead of loading them
directly from the file system (fragile). This means that you'll need
to make a change to your Java entry point. Where you probably had
something like:

    platform.assetManager().setPathPrefix("src/main/java/playn/showcase/resourc es");

you should now use:

    platform.assetManager().setPathPrefix("playn/showcase/resources");

As a fringe benefit, this was one of the main challenges preventing
the packaging of the Java backend up for use as a Java applet. Now
that this has been fixed, there are probably only a few niggling bits
that need fixing, and PlayN games can be deployed as Java applets by
anyone crazy enough to want to do so. :)

Also, for those of you using sound in your games, the Java backend
used to require that you maintain separate .wav versions of your sound
resources. The HTML backend used .mp3 versions of said resources. The
Java version has been updated so that it uses the .mp3 versions as
well, so you no longer need to maintain .wav versions of your sounds.
Sounds on the Android backend remain largely untested (meaning they're
probably broken), but when I get a chance, I'll make sure that they
also work properly with .mp3 files, so that things remain consistent
across platforms.

Between these and other small improvements to the archetype, it is
probably worth the small bit of trouble to regenerate your project
from the latest archetype, and move your sources and resources into
the new project, just to be sure that all the little fixes that have
made it into the archetype templates are applied to your project.
Alternatively, you could generate a new project using the latest
archetype with specifications equivalent to your project and then diff
the files that were generated against those in your project and
migrate any fixes you find into your project. Whether one or the other
is easier will depend on how much you've customized your poms.

The flash submodule has been completely disabled in the latest
archetype. If the Flash backend is made functional again, it will be
reinstated.

 

The other key things to note is the removal of the Flash target ( which was apparently quite a ways from ready for prime time, and was breaking the build ).  Anyways, good job to the PlayN team.

Programming


AppGameKit Studio

See More Tutorials on DevGa.me!

Month List