airアプリをStalingFrameworkで作っていた時、

StalingFrameworkに制御が移る瞬間(stage3Dに制御が移る瞬間でよいのかな?)に、

描画イベントが効かなくなるという問題があった。

簡単なコードは以下。

public class Main extends Sprite
{
    /**
     * starlingのエンジン
     */
    private var _starling:starling.core.Starling;

    /**
     * コンストラクタ
     */
     public function Main():void
     {
         stage.scaleMode = StageScaleMode.NO_SCALE;
         stage.align = StageAlign.TOP_LEFT;

         // 基本画面領域の定義
         var width:int = 640;
         var height:int = 960;

         // 基本領域
         var base:Rectangle = new Rectangle(0, 0, width, height);

         // フル領域
         var full:Rectangle = new Rectangle(0, 0, stage.fullScreenWidth, stage.fullScreenHeight);

         // 表示領域
         var viewPort:Rectangle = starling.utils.RectangleUtil.fit(base, full);

        // ※ここ以降に制御が移ったら、それ以前に定義しておいた描画イベントは効かなくなる
        // starlingのエンジンを生成
        _starling = new starling.core.Starling(Game, stage, viewPort);
        _starling.stage.stageWidth = width;
        _starling.stage.stageHeight = height;
        _starling.simulateMultitouch = false;
        _starling.addEventListener(starling.events.Event.ROOT_CREATED, function(e:*, game:Game):void
        {
            // ゲーム開始
            _starling.start();
        });
    }
}

自分の場合、iosでスプラッシュ画面がすぐに終了してしまい、

Starlingの初期化と同時に音声やら画像を一気にロードしていた時間がごまかせなくなった結果、

「now loading」的な描画処理をEnterFrameで入れていたら、

それが動かなくなったというものでした。

 

投稿日時:2014年11月25日 17:08   カテゴリー:air, as3  

airアプリをAppleStoreにサブミットしたところ、

AIRSDK15でビルドしたバイナリが、

アップローダでアップできなかった。

原因としては、AIRSDK15では、32bitバイナリしか作成できないためだそうだ。

 

AIRSDK16(βだけど)でビルドしたら、

ワーニングが出来たけど、アップできた。

ただし、ワーニング(注意書き?)の内容としては「2015年2月以降は64bitじゃないとダメよ」

みたいなものであった。

 

AIRSDK16では64bitバイナリが作成できたってことでよいのかな?

いまいちよくわからないが、AIRSDK16のリリースノートに書いてあるような。。

 

とりあえず、AIRSDK16の正式版が出てからでないと、

アップしても危険かも。

 

投稿日時:2014年11月25日 16:27   カテゴリー:air, as3  

さて、本腰入れて。

今回の比較に当たり、大きな前提として、

pub/subはなし(つまり、メモリ内で処理を完結可能)

というのをあげておきます。

というのも、pub/subがあるときと、ないときでは、

結構実装が異なってしまうためです。

(※うまく抽象化できればいいのですが、node.js側は上手に継承を使うのが難しいので)

 

この前提のもと、

javaとnode.jsの大きな違いは、

java:マルチスレッド

node.js:シングルスレッド

ということであります。

 

この違いは、プログラムを書く上で、

排他制御」が必要か、不要かということにつながります。

 

たとえば、対戦ゲームを作るとした場合、

ゲームには「マッチング」と「対戦中」で処理が大きく2つに分かれます。

マッチングは諸条件あるものの、基本的には来た順番にさばく手法がとられると思います。

このとき、javaでは必ず排他制御をかける必要があります。

それに対し、node.jsでは、シングルスレッドなので、排他制御をかける必要はありません。

 

ここが両者の最大の違いとなります。

 

※あくまでメモリ内で完結する場合です。(つまり1プロセス)

複数台を使う場合は、node.jsでも排他制御が必要となる場合があります。

投稿日時:2014年11月25日 14:23   カテゴリー:java, node.js, websocket  

websocketというと、チマタではnode.jsが流行っていますね。

 

しかし、javaもJSR356という規約の下、

各サーブレットコンテナで対応が完了しており、

個人的にはnode.jsと対をなす位までの能力があるかと思います。

 

javaでもnode.jsでもwebsocketを構築した筆者が、

数回にわたりお互いの特徴と実装の注意点などを書いていきます。

 

なお、バージョンは

【java】

jetty9.X(JSR356に対応した形)

【node.js】

v10.3X

となります。

 

 

投稿日時:2014年11月25日 13:37   カテゴリー:java, node.js, websocket  

さくらのVPSでwordpress入れて、今日からブログを作成していきます。

基本的には、IT系のネタをメモ代わりに残し、

閲覧してくれた人の助けになれば幸いです。

ネタ的には、

  • php
  • java
  • mysql(mariadb)
  • as3(air)
  • c/c++
  • python

あたりを書き留めておきたいかなと。

 

投稿日時:2014年11月25日 13:29   カテゴリー:other