Quantcast
Channel: OPTPiX Labs Blog
Viewing all 263 articles
Browse latest View live

【CEDEC 2013】で紹介されたウェブテクノロジ製品

$
0
0

CEDEC が終了してから既に1ヶ月以上が経ちました。
セッションレビューなどの記事が出そろってきて、
当社の製品が紹介されたものがいくつかございましたので、
このブログ記事では、SEGA Game Jam での利用と、
拡散性ミリオンアーサーのPSVita版での利用をご紹介します。

採用事例 CEDEC2013

SEGA Game Jam

セガさんでは、OPTPiX SpriteStudio をご利用いただきました。
OPTPiX SpriteStudioとは、超汎用データを制作できる2Dスプライト
アニメーションデータ作成ツールです。
ゲームジャムではスピードが勝負になることが多いので、OPTPiX SpriteStudioのような
デザイナーさんが絵を描くだけではなく、動きまでつけられるツールは
重宝するようです。

こちらのセッションを紹介した記事は以下のページにございます。

 

またTGS に合わせて、インディーズゲーム(インディペンデントゲーム)
開発者向けに無料特別版を公開しましたので、ご興味がある方は
是非、一度体験してみてください。

» OPTPiX SpriteStudio インディーズゲーム(インディペンデントゲーム)開発者向けライセンス

拡散性ミリオンアーサー

スクウェア・エニックスさんが手がける「拡散性ミリオンアーサー」
こちらのゲームはスマホ向けからPSVita版向けへの移植というケースです。
PSVita版の中では、アルファチャンネル付きインデックスカラーPNGの画像を多用したため、
OPTPiX imesta で解決していただいたとのこと。

こちらのセッションを紹介した記事は、以下のページにございます。

またPSVita だけでなく、iPhone/iPad 向けで主流のPVRTC 形式は
ノイズが多いというご相談をよくいただきますが、
OPTPiX imesta 7 for Mobile & Social に搭載の「Clear PVRTC」という
機能を使っていただけると、キレイなままファイル容量を縮小することができます。

OPTPiX imesta 7 for Mobile & Social にもトライアル版が
ございますので、実際のその目でお確かめください。

» OPTPiX imesta 7 for Mobile & Social 無料トライアル申し込み

CEDEC 2013 | Computer Entertainment Developers ConferenceCEDEC 2013公式サイト

その他の事例紹介

ドリコム様(CEDEC2013 の事例)

ゲーム開発手法の転ばぬ先の杖 ~ "OPTPiX SpriteStudio" で作る、無駄にならない2D資産の作り方ゲームエンジンのコモディティ化、ブラウザ/ハイブリッド/ネイティブ・アプリなど、ゲーム開発手法は年々多様化。開発者には、多くの開発手法のなかから適切な手段を選択するスキルが要求されるようになりました。

ところが、企画当初の選択を誤ったために、リリーススケジュールが遅延した、などの事故が多発しているのも現実です。

CEDEC2013のセッションでは株式会社ドリコム様をゲストにお招きし、
「2D資産制作」という局面に焦点を当てながら、2Dアニメーションツール
「OPTPiX SpriteStudio」のユーザーが、どのようにしてゲーム開発手法の
多様化を乗り越えてきたのか、様々な事例を交えてご紹介しました。

このセッションの内容は以下のページでご覧いただけます。

ナウプロダクション様(GTMF2013 の事例)

記事より抜粋:「OPTPiX SpriteStudio」を全面的に使用しました。
このパッキング機能の方が大きかったですね。
ツールに頼って自動化する事で、かなりの効率化が図れました。

忍者ロワイヤル(CEDEC2011の事例)

忍者ロワイヤルでは、OPTPiX imesta を利用していただくことで、
高品質な画像のままアプリケーションのサイズを
縮小することができたとのこと、
具体的には「透過情報までインデックスカラーとして扱えるところ」が
効果的だと紹介されました。

少々古い、2011年のCEDEC の記事からとなりますが、参考にしてください。

CEDEC2013 のセッションの記事

工程の手戻りを最小限に 圧縮テクスチャ(PVRTC・DXTC・ETC)における傾向と対策8/22のCEDEC2013で行われたセッション「工程の手戻りを最小限に 圧縮テクスチャ(PVRTC・DXTC・ETC)における傾向と対策」の発表資料を公開しております。

開発現場での経験知と理論を融合させながら、わかりやすく解説してみたつもりです。

時間の関係で一部抽象的なサンプルを用いたところもありますのでご了承ください。


「ABC2013 Autumn」にウェブテクノロジが参加します!

$
0
0

こんにちは。ウェブテクノロジの佐藤です。

この度、2013年10月20日(日)に東京電機大学 北千住キャンパスにて
開催されるAndroid Bazaar and Conference 2013 Autumn に参加します。

今回もセッションに加え、ブース出展をおこないます。

セッション

知っておきたい、画像データ圧縮の仕組みと特長 ~ETC とPVRTC~

 

講演者

株式会社ウェブテクノロジ R&D部 マネージャー 小野 知之
主力製品のOPTPiX imestaシリーズだけでなく、まったく絵を描かなくても3Dで誰でも
マンガが作れる、マンガ作成ソフト「コミPo!」の開発ディレクターも担当。

 

講演概要

ABC2013 Spring で講演した『知っておきたい、画像データ圧縮の
仕組みと特長 ~DXTC とPVRTC~』の続編です。
プログラマや技術的興味のある方を対象に、Android 全機種で使用できる
画像圧縮方式「ETC」の原理と、前回解説した「PVRTC」についても更に
掘り下げて解説します。
Android・iOS マルチ対応アプリ開発における画像管理の運用上の
ちょっとしたコツなどもご紹介します。

 

ブース

超汎用データ制作 2Dスプライトアニメーションデータ作成ツール「OPTPiX SpriteStudio」
今月より、インディーズゲーム(インディペンデントゲーム)開発者の皆様を
サポートするために、無料ライセンスをご用意しました。
「Unity」、「Cocos2d-x」、「CoronaSDK」に加え「HTML5」にも対応。
もちろんコンシューマーゲーム機環境にも最適です。
英語モードやMac 版にもご注目ください。

[PNG・PVRTC・高画質→ファイルサイズ縮小] スマートフォンアプリ用画像最適化ツール
「OPTPiX imesta 7 for Mobile & Social」では、今春発表した新機能「Clear PVRTC」の
効果を直接ご覧いただけます。

「Clear PVRTC」とは、iPhone/iPad などで主流のテクスチャ圧縮形式
「PVRTC (PowerVR Texture Compression)」を生成するための変換プロセスで、
従来のPVRTC 形式と完全な互換性があり、ファイル容量はそのままに、より高画質な
画像変換を実現しています。
PNG24フルカラー画像ファイルを高画質のまま非可逆変換して
ファイルサイズを縮小する機能や、Unity 向け高画質テクスチャにも対応しました。

また、画像や音声などの素材をブラウザでアップロードしていただくだけで、
すぐにライブ壁紙のapkファイルが作成できる「ライブ壁紙メーカー」についても
サンプルを展示いたしますので、ぜひご覧ください。
もちろん、画像最適化ツールのエンジン OPTPiX を利用しているため、
ご準備いただいた画像や写真のクオリティを損なわず制作が可能です!

この機会にぜひウェブテクノロジブースへお立ち寄りいただき、ご覧になってください。
それでは、当日お会いできることを楽しみにお待ちしております。

イベント名 Android Bazaar and Conference 2013 Autumn
日時 2013年10月20日(日) 10:00~(予定)
場所 東京電機大学 東京千住キャンパス
» 地図はこちら
公式サイト http://www.android-group.jp/conference/abc2013a/

SSPlayer(SpriteStudio Player) for Cocos2d-xのご紹介

$
0
0

こんにちは、ウェブテクノロジ R&D部の黒岡です。

本稿では、SSPlayer(SpriteStudio Player) for Cocos2d-xについてご紹介します。

SSPlayer for Cocos2d-xは、OPTPiX SpriteStudioで作成したアニメーションデータをCocos2d-x上で再生するためのプラグイン・モジュールです。SSPlayerを使用することで、デザイナーがSpriteStudioで作成したアニメーションを簡単・忠実に再生できるようになります。

魅力あるゲームアプリには、エフェクトのようなリッチなアニメーション表現が不可欠ですが、デザイナーが作成した複雑なエフェクトをプログラムで記述するとなると非常に大きな工数がかかってしまいます。SpriteStudioとSSPlayerを組み合わせれば、デザイナーがSpriteStudioでアニメーションを作成し、プログラマはそのデータをゲームアプリに組み込んだSSPlayerで再生するだけですので、開発工数を大幅に削減しつつ、リッチな表現が可能になります。

このところSSPlayer for Cocos2d-x のお問い合わせが非常に増えています。Cocos2d-xというプラットフォーム自体も、最近ぐんぐんと広まっている感触があります。そのため、弊社で提供しているプレイヤー・コンバーターの改修の頻度が最も高いプラットフォームです。

この記事では、Cocos2d-xの簡単な説明と導入方法、SSPlayer for Cocos2d-xを使ったアニメーションの再生方法についてご紹介します。

Cocos2d-xとは?

Cocos2d-xは、cocos2d for iPhoneを基にC++で書かれたマルチプラットフォーム対応ゲーム・エンジンです。開発に使用する言語もC++ですので、C++での開発に慣れている人にはメリットが大きいでしょう。

私個人としては、以前の仕事で iOSアプリの開発を行ったときに cocos2d for iPhone のお世話になったのですが、当時、Android でも同時開発ができるとありがたいなと思っていました。その後、マルチプラットフォームを打ち出した Cocos2d-x がリリースされましたが、初期の頃は完成度がかなり低かったのを覚えています。今回プラグインを開発してみて、完成度が高まっているのを実感しました。

さて、以下に Cocos2d-x の特徴を挙げます。

  • 意外と歴史のあるフレームワーク
    もともと cocos2d というPython用に書かれたフレームワークがあり、そのフレームワークデザインをiOSのObjective-Cへ移植しcocos2d for iPhone になり、さらに拡張されて Cocos2d-x となりました。

  • 2Dベースのエンジン
    ​2Dベースで比較的高機能なクラスが用意されており、制作に必要そうな低レベル関数はそろっています。また、シェーダーの追加も簡単に行え、ソースの変更、カスタマイズも比較的容易なため、総合的に2Dベースとしては高性能エンジンなのではないかと思います。
  • 開発コミュニティの活動が活発
    開発は中国のオープンソース・コミュニティをベースに行われ、MITライセンスで公開されています(ライセンス条項の縛りが緩いので使いやすい)。この開発コミュニティの活動はかなり活発で、これは重要なポイントです。
    開発中のソースコードはGitHubにて開発状況の確認ができるので、「あの不具合はどうなったかな?」とか「実装されそうな機能」の予測などし易いです。
  • 豊富な対応プラットフォーム
    対応プラットフォームが比較的多いことが挙げられます。また、JavaScriptとLuaへのスクリプト・バインディングが用意されており、JavaScript、Luaでの開発もある程度可能です。ただし、スクリプト言語によって対応プラットフォームが制限されます(cocos2d-x-2.1.5)。具体的には、以下のようになります。

     

    • C++で開発可能な環境 : Android、BlackBerry、iOS、Linux、Mac OS X、Marmalade、Win32
    • Luaで開発可能な環境 : Android、BlackBerry、iOS、Linux、Marmalade、Win32
    • JavaScriptで開発可能な環境 : Android、iOS、Win32
      • 余談ですが、JavaScriptバインディングをちょこっと試してみたい方は最近出た Cocosinoがお勧めです。ビルドの必要がなく、Cocosinoをインストールしてコードを書くとシミュレータが動くので楽ちんです。遊べるサンプルプロジェクトも同梱されていますので、ぜひ試してみてください。

Cocos2d-x におけるデバッグについて

これは余談ですが、参考までに…。開発系のカンファレンスなどでは、Android、iOS両対応のネイティブ開発の際はまずiOS環境で作成し、Xcodeを用いてデバッグする手法がよく紹介されています。これはAndroidのネイティブ開発においてデバッガーの貧弱さとエミュレータの遅さが問題になっているためでしょう。

マルチ開発ではなく、Androidだけがターゲットの場合は、Win32でプロトタイピングという選択肢も考えられます。ご存じの通りMicrosoft Visual Studioは類似製品と比較してもデバッガーが非常に強力なため、ゲームロジックの部分はMicrosoft Visual Studioを使ってデバッグし、描画依存の部分はそれぞれの環境でテストを行うという方法を取るのが便利だと思います。

Cocos2d-xの環境構築

このセクションで必要なソフトウェア

  • VisualStudio 2010/2012 (ExpressでもOK)
  • Python
  • Cocos2d-x

Microsoft Visual Studioのインストール

最初に、Microsoft Visual Studio 2010環境の構築を行います。インストール済の方は飛ばして結構です。ExpressでもOKです。

Pythonのインストール

次に、Pythonのインストールを行います。Mac環境では最初から入っていますが、Windows環境ではインストールが必要です。Pythonは、プロジェクトの作成やツールのスクリプトを動かすために使用します。私はActivePythonを使用しています。

http://www.activestate.com/activepython

Cocos2d-xのインストール

最後に、Cocos2d-xをインストールしましょう。GitHubからcloneしてくるのも良いのですが、最初はステイブルなバージョンをダウンロードして使用するのが良いでしょう。

http://www.cocos2d-x.org/download

Cocos2d-xを選びます。ここでは、v2.1.5をダウンロードした想定で進めます。ダウンロードが完了したらzipファイルを展開します。

cocos2d-x-2.1.5.zip を展開すると cocos2d-x-2.1.5 フォルダが作成されるので使いやすいパスへコピーします。ここでは、展開して作成された cocos2d-x-2.1.5 フォルダを cocos2d-x とリネームして C:\framework にコピーすることにします。

プロジェクトを作成してみる

インストール先の C:\framework\cocos2d-x\tools\project-creator\ でコマンドプロンプトを開きます(Explorer で上記フォルダを表示し、[Shift]キーを押しながら右クリックして「コマンド ウィンドウをここで開く」を選択します)。
コマンド プロンプトに下記コマンドを入力します。

> create_project.py

コマンドラインオプションを付けないと以下のようなヘルプが表示されます。

Usage: create_project.py -project PROJECT_NAME -package PACKAGE_NAME -language PROGRAMING_LANGUAGE

Options:
  -project   PROJECT_NAME          Project name, for example: MyGame
  -package   PACKAGE_NAME          Package name, for example: com.MyCompany.MyAwesomeGame
  -language  PROGRAMING_LANGUAGE   Major programing lanauge you want to used, should be [cpp | lua | javascript]

Sample 1: ./create_project.py -project MyGame -package com.MyCompany.AwesomeGame
Sample 2: ./create_project.py -project MyGame -package com.MyCompany.AwesomeGame -language javascript

Python が起動することが確認できたら、まずはサンプルプロジェクトとして、以下の設定で作成します。

  • project: SampleApp
  • package: com.hoge.huga
  • language: cpp (C++)

コマンド プロンプトに下記コマンドを入力します。

> create_project.py -project SampleApp -package com.hoge.huga -language cpp

[Enter]を押すとマルチプラットフォームに対応したプロジェクトが作成され、下記のようなメッセージが表示されます。

proj.ios        : Done!
proj.android    : Done!
proj.win32        : Done!
proj.mac        : Done!
proj.blackberry    : Done!
proj.linux        : Done!
proj.marmalade    : Done!
New project has been created in this path: C:\framework\cocos2d-x\tools\project-creator/../../projects/SampleApp
Have Fun!

このメッセージは、それぞれ表示されている環境に対応したプロジェクトファイルが作成されたことを意味しています。ここで作成したプロジェクトファイルは、C:\framework\cocos2d-x\projects\SampleApp\ に作成されています。

ビルド

C:\framework\cocos2d-x\projects\SampleApp\proj.win32\SampleApp.sln をVisual Studioで読み込み、ビルド&実行を行ってみてください。

ビルド

環境によってはOpenGLのdllを要求される可能性がありますが、必要なものを実行形式のパスにコピーすると実行できます。

実行すると、次のようなウィンドウが起動します。

HelloWorld

ここまでの手順でWindowsアプリが作成できることを確認できたら、いよいよSSPlayerの組み込みです。

SSPlayerの組み込みと実行(アニメーション再生)

サンプルのダウンロード

サンプルソースとサンプルデータはOPTPiX SpriteStudio ユーザーサポートページからzipファイル形式でダウンロードできます。本記事執筆時点では「SpriteStudio Player for Cocos2d-x/Corona SDK/HTML5 (2013/8/9)」という名称になっています。こちらからダウンロードしてダウンロードしたzipファイルを展開してください。

http://www.webtech.co.jp/spritestudio/ss5user/download.html

ここから先は、ダウンロードしたCocos2d-x用のサンプルを利用し、先ほど作成したSampeAppを改造しながら進めます。

プロジェクトファイル内の Resources にデータをコピー

まずは、今回のサンプルで使用するデータをコピーします。

ダウンロードしたサンプルの cocos2dx\Samples\Comipo\Resources\ から C:\framework\cocos2d-x\projects\SampleApp\Resources\ に.ssbaファイルと.pngファイルのコピーを行います。

プロジェクトファイル内の Classes にSSPlayerソースコードをコピー 

作成したプロジェクトファイル内のClassesフォルダ( C:\framework\cocos2d-x\projects\SampleApp\Classes\ )の中身を確認します。

  • AppDelegate.cpp
  • AppDelegate.h
  • HelloWorldScene.cpp
  • HelloWorldScene.h

以上4つのファイルが作成されているはずです。このClassesフォルダに、先ほどダウンロードしたzipファイルから、以下のファイルをコピーします。

  • SSPlayer.cpp
  • SSPlayer.h
  • SSPlayerData.h
  • ssShader_frag.h

この4つのファイルがSSPlayerのソースコードです。

プロジェクトにソースファイルを追加

さて、コピーを行ったら忘れずにプロジェクトに上記ソースファイルを追加しましょう。
今回はVisualStudioで作成するのでSampleAppのプロジェクトへ追加します。

SampleAppのプロジェクトを右クリック→「追加」→「既存の項目」を選択して上記を追加します。

 

既存の項目を追加

 

ソースファイルの編集

次にソースファイルを編集します。
まずは、ヘッダーファイル(HelloWorldScene.h)を編集していきます。SSPlayer.hのインクルードとアニメーションを再生するためのクラスをメンバとして定義しています。

#ifndef __HELLOWORLD_SCENE_H__
#define __HELLOWORLD_SCENE_H__

#include "cocos2d.h"
#include "SSPlayer.h"    //<< 追加 SSPlayer.hをインクルードします。

class HelloWorld : public cocos2d::CCLayer
{
public:
    // Here's a difference. Method 'init' in cocos2d-x returns bool, instead of returning 'id' in cocos2d-iphone
    virtual bool init(); 
    // there's no 'id' in cpp, so we recommend returning the class instance pointer
    static cocos2d::CCScene* scene();
    // a selector callback
    void menuCloseCallback(CCObject* pSender);
    // implement the "static node()" method manually

    CREATE_FUNC(HelloWorld);

private:                            //<<追加
    SSImageList*    m_SsImageList;    //<<追加 アニメーションで使用する画像リスト管理クラスを追加
    SSPlayer*        m_SsPlayer;        //<<追加 アニメーションプレイヤーを追加
};

#endif // __HELLOWORLD_SCENE_H__

次に、cppファイル、HelloWorldScene.cpp を編集します。bool HelloWorld::init()の最後の方に以下のコードを追加します。

bool HelloWorld::init()
{

    中略

    unsigned char* filebuffer = 0;
    //ssbaファイルを読み込みm_SsPlayerで再生できるようにします。
    SSPlayerHelper::createFromFile( &filebuffer , &m_SsPlayer , &m_SsImageList , "attack_attack.ssba" );

    //シーンのドローグラフへ登録します。
    this->addChild(m_SsPlayer);

    //画面中央に表示

    int width = CCDirector::sharedDirector()->getWinSize().width;
    int height = CCDirector::sharedDirector()->getWinSize().height;
    int x = ( width / 2 );
    int y = ( height / 2 );

    m_SsPlayer->setPositionX(x);
    m_SsPlayer->setPositionY(y);

    return true;
}   

プログラムの流れは以下の通りです。

  1. シーンの初期化時にssbaファイルをSsPlayerへ読み込ませてスプライトアニメーションの再生ができるように準備
  2. m_SsPlayerに対してポジションの設定

なお、SSPlayerは cocos2d::CCSpriteからの派生クラスなので、cocos2d::CCSpriteのプロパティがある程度使用できます。

今回、アニメーションのファイルは「attack_attack.ssba」を指定して読み込んでいます。これは、先ほどResourcesへコピーしたssbaファイルになります。

これでVisualStudio上で実行を行うとアプリが起動し、アニメーションが再生されます。

実行結果

OPTPiX SpriteStudioでアニメーションを作成し、それを再生する方法

上記では用意されたサンプルのデータを使用して再生を行いましたが、ここからは実際にOPTPiX SpriteStudioでアニメーションを作成したデータから、ssbaファイルを作成する方法をご紹介します。

現在、方法は二通りあります。

1.OPTPiX SpriteStudioのエクスポート設定から選択しエクスポートする方法
2.コマンドラインツールを使用して .ssax から .ssba を作成する方法

どちらの場合も作成した.ssbaファイルをcocos2d-xのプロジェクトフォルダの Resources にコピーして使用します。

1.OPTPiX SpriteStudioのエクスポート設定から選択しエクスポートする方法

OPTPiX SpriteStuidoからの.ssbaの出力は、メニューの「プロジェクト」から「エクスポート」もしくは「全てエクスポート」で行います。ただし、出力先の設定や、エクスポート内容の設定を行う必要があります。出力先の設定、エクスポートの内容の設定は、OPTPiX Sprite Studioのメニューの「ファイル」内「プロジェクトの設定」から行います。

出力先の設定は、図7の「基準フォルダ」タブからアクセスできます。この基準フォルダ設定は、プロジェクトファイルからの相対パスですが、ドライブレターから記述することで、フルパス指定も可能です。

エクスポート先の設定

エクスポート内容の設定は「エクスポート」タブからアクセスします。ssbaの出力には「SSP for Cocos2d-x(.ssba)」を選択してください。

ssbaの選択

これで、メニューの「プロジェクト」内「エクスポート」からssbaファイルが出力できるようになりました。メニュー内の「エクスポート」コマンドを実行するとエクスポートの項目を選ぶダイアログが表示されますので、項目を選択してエクスポートしてください。

2.コマンドラインツールを使用して .ssax から .ssba を作成する方法

SspForCCH_v0.8.12_20130808.zip のなかにコマンドラインツールが同梱されています。本ツールのzip展開時のパスは以下の通りです。

\SspForCCH_v0.8.12_20130808\SspForCCH\cocos2dx\Converter

このフォルダ内にWindows用、MacOS用のコマンドラインツールがあります。このコンバートツールは、コマンドラインオプションでエクスポート元となるssaxファイルを指定して実行します。下記にコマンドラインオプションの内容と例を記載します。

SsToCocos2d converter version 0.8.13
usage: SsToCocos2d Input files(.ssax) and/or a file list for image(.ssf) ...
option:
  -h [ --help ]         Display usage.
  -o [ --out ] arg      Output filename.
  -b [ --bf ]           Output as binary format. (default)
  -c [ --cf ]           Output as c source code.
  -e [ --encoding ] arg Encoding of output file (UTF8/UTF8N/SJIS) default:UTF8.
  -i [ --in ] arg       ssax, ssf filename.
  -v [ --verbose ]      Verbose mode.

   SsToCocos2d(.exe) <入力ssaxファイル名> [-h] [-o <出力luaファイル名>][-b][-c] [-e UTF8|UTF8N|SJIS] [-i <入力ssaxファイル名>] [-v]

hige.ssaxをhige.ssbaへ変換する場合は、コマンド プロンプトで以下のように実行します。

> SsToCocos2d hige.ssax –o hige.ssba

まとめ

Cocos2d-xは、無料フレームワーク、2Dゲーム、マルチプラットフォーム、商用利用という条件であれば有力な選択枝の一つに入るのではないかと思います。書籍も発売されていますし、ネット上のTipsも充実してきています。

SSPlayerを使用することで、Cocos2d-x上でもSpriteStudioで作成したリッチなアニメーションが簡単に再生できるようになります。Cocos2d-x上でゲームアプリを開発する際には、ぜひお役立てください。

ABC 2013 Autumn『知っておきたい、画像データ圧縮の仕組みと特長 ~ETC とPVRTC~』発表資料

$
0
0

ウェブテクノロジ代表の小高です。

ABC 2013 Autumn(10月20日開催)の「デザイン・開発トラック」で講演した「知っておきたい、画像データ圧縮の仕組みと特長 ~ETC とPVRTC~」の発表資料を公開いたします。

ABC2013 Spring で講演した『知っておきたい、画像データ圧縮の仕組みと特長 ~DXTC とPVRTC~』の続編です。 プログラマや技術的興味のある方を対象に、Android 全機種で使用できる画像圧縮方式「ETC」の原理と、前回解説した「PVRTC」についても更に掘り下げて解説しています。

ゲーム開発向けにさらに詳しい情報が必要な方は、CEDEC2013『工程の手戻りを最小限に 圧縮テクスチャ(PVRTC・DXTC・ETC)における傾向と対策』発表資料 もご参照ください。

アプリ開発における、より美しい画像表現のお役に立てれば幸いです。

発表資料(PDF)

OPTPiX imesta Tips:複数の画像に一つの画像を重ねあわせる

$
0
0

「生活の知恵」を「ライフハック」と呼ぶ現代社会に物申したい、けれども取り立てて一家言有るわけでもない。セールス&コミュニケーション部の浅井です。

スマートフォンアプリ制作の現場に定着してきたなー、と思う弊社の「OPTPiX imesta 7 for Mobile & Social」のお話。

OPTPiX imesta 7 for Mobile & Social

OPTPiX imesta 7 for Mobile & Social

とりあえず国内外のソーシャルアプリプラットフォーマー、SAPの皆さんに大変便利に使っていただいております本製品。・・・なのですが、何しろ数百の機能が搭載されているものですから、製品デモにお伺いした際に『こんなことは出来るの?』と聞かれてササッと該当する機能が出てこないことも。
今回は、つい先日とあるSAPさんからご相談をいただいた、

Q:複数のカードイラストなどのPNG画像に対して、1種類の画像を重ね合わせたい

というご質問を紹介したいと思います。いわゆるカードゲームに使う大量のイラストに対して、フレーム(額縁ですね)を一括で合成したいという用途でのご相談。そしてその折に、この口から出た回答ですが、

A:できますん

・・・いやどっちだよ、っていうか先に申し上げましたとおり、実は出来たということでご紹介です。さてその手順ですが、実は「フィルタ」メニューにある「スタンプ」機能でそれを実現できます。

スタンプ機能

スタンプ機能

 

こちらのスタンプ機能、元々は編集中の画像に対して、特定のフォルダに配置されたスタンプ役の画像を合成する機能』です。元々はコピーライトなどの表記を一括して合成することを目的とした機能ではあるのですが、今回のような「n:1」の重ねあわせにも使えるという。合成先となる画像の解像度に合わせて、スタンプ役の画像を3種類定義することも出来ますが、今回は1種類で。

 

そのスタンプ役を複数の画像に対して合成するには、「OPTPiX imesta 7 for Mobile & Social」自慢のマクロ機能を使ってバッチ処理。この方法を使えば、ファイルサーバーなどに格納されている画像に対しても、一括で処理をすることができます。

処理対象画像スクリーンショット

クリックで拡大

では、試しに。左の3種類が、処理対象にあたる「複数のPNG」、右がスタンプ役の画像。今回作成したマクロでは、左の3種類の画像が格納されたフォルダに対して、スタンプ機能を実行、合成結果をPNGで保存するという実にかんたんな手順。このマクロを実行しますと・・・

処理結果画像スクリーンショット

クリックで拡大

この通り、全ての画像にフレームを合成することが出来ました。例えばカードゲームのイラストを外部のデザイナーさんにお願いしておいて、社内ではゲームバランスや世界観に合わせたデザインコントロールをする、そんなワークフローの中で、手順を簡略化することが出来ます、と。

この他にも、「OPTPiX imesta 7 for Mobile & Social」には便利な機能をたくさんつめ込んでおります。『こんなことできないかな?』などのご相談がありましたらば、是非ご相談ください。使ったことがない機能の中に、それを実現する機能があるかもしれません。

 

・・・さてついでに浅井のお気に入りの画像も処理対象にしてみた結果、

処理結果麻呂_blog
六条公麿三位中納言のご尊顔も、これこの通り額縁入りで更に神々しく。誰得なのか。

当然ですがマクロの処理対象に予め麻呂も含めて置かない限り、出力結果に麻呂が登場することはないのでご安心下さい。

田中圭一のゲームっぽい日常 アニメで成功するなら昭和テイストが重要

$
0
0

アニメで成功するなら昭和テイストが重要

9月末に「宇宙戦艦ヤマト2199」が無事に完結した。劇場公開も成功しBlu-rayの売れ行きも大盛況、プラモデルも売れているとのことで、ヤマトファンとしては嬉しい限りである。

気になっているのは、この作品「旧来のファンから支持されただけではなく新規ファンの開拓にも成功した。」と言われている点だ。私の皮膚感覚では、新規ファンなんて、どこにいるの?って感じである。

「魔法少女まどか☆マギカ」の劇場版も大ヒットしているようだが、まどか☆マギカを観に行っているアニメファン(今のアニメファン)とヤマト2199を支持しているファンとは、あまり重なっていないように思えるのだ。

・・・つまり、何が言いたいかというとヤマト2199は、何年もアニメから遠ざかっていた40代50代の普通の人々を、アニメに呼び戻した結果の大ヒットだったのではないだろうか、ということだ。

事実私の周囲にも、数名の「最近のアニメはまったく観ないけど、ヤマトだけは観た。」という人がいる。

作品内容としても、昭和の代表的なアニメである「宇宙戦艦ヤマト」を現代風にアレンジし、40代50代のオトナが観ても十分に見応えのある内容に仕上がっていた。

ヤマト2199のヒットによって「遠ざかっていたけど、アニメってやっぱ面白いな。」と思ってきている40代50代が増えてきているような気がする。

そこに、この10月から「キルラキル」というアニメ番組がスタートした。これがまた「昭和の熱血少年漫画」のテイストを現在のパッケージで包んだ、40代50代の昭和アニメ・漫画が大好きな人にはたまらない作品だ。

学園支配をもくろむ一派に、単身で挑むアウトローの主人公。彼らの武器は身体能力を何倍にも跳ね上げる「服」だ。劇中では神衣(かむい)と呼ばれている。

画風も昭和アニメ・昭和熱血漫画のテイストをそれっぽく再現していたり、エンディング曲も昭和アイドルソングっぽかったり、とにかく40代50代のためだけに作られたような気さえする作品だ。

この「昭和アニメ・漫画」を現代風パッケージに包んだ新作ブーム、是非とも続いて欲しいものだ。

【Androidアプリ開発ドキュメンタリー】 虚空より突如蘇る、不死鳥プロセス ~前編~

$
0
0

こんにちは、開発の小野知之です。

今回は、私が実際にAndroidアプリを開発していて遭遇した体験を、前後編の2回にわたってお送りします。アプリ開発される方はもちろん、Androidの内部動作について興味ある方にも、何かの参考になるかもしれません。
なお、挿し絵や説明図は全部、私が コミPo! で作りました。

PID:1 復活

1-1: 実行中

それは私が、Android のウィジェット・アプリを作成していたときのことです。

ウィジェットというのは、ホーム画面に置いて常駐させて使う、時計とかバッテリーメーターとかの、あれです。私が作ったものも、非常にシンプルな単なるアナログ時計でした。

ところがある日、おかしなことに気付きました。 ところがある日、おかしなことに気付きました。

 

 

 

アプリ開発に使っている Android 端末で、システム設定の「アプリケーション」-「実行中」一覧を見ると、そこには、私のウィジェットの名前があったのです。

使っていないのに。ホーム画面に、そのウィジェットの姿は無いのに。

使っていないのに…。
ホーム画面に、そのウィジェットの姿はないのに…。

通常の Activity のアプリ(ウェブブラウザなど)であれば、別におかしなことではありません。使っていなくても非表示のままで動いているアプリは多くあります。

しかしウィジェットは通常、意図的にサービスを常駐させない限り、ホーム画面から削除すれば動作を停止し「実行中」一覧からは消えるはずです。もちろん私のウィジェットもそのように作ってあります。

どうやら、私のウィジェットには何らかの「正常に終了しない不具合」があるらしく、画面に表示されないにもかかわらず内部的な処理のみが動き続けているようなのです。
「ゾンビ化」というやつですね。
しかも、この状態でもCPUタイムやバッテリーはしっかり消費し続けているので大迷惑です。

早速、原因を調べることにしました。

1-2: 確認

まずはとにかく、症状を再現させないことには始まりません。ウィジェットを終了(ホーム画面から削除)したあと、すぐに「実行中」一覧を確認すればわかるはずです。

しかし、何度試しても、再現しないのです。

ウィジェットを起動すると「実行中」一覧に名前が現れ、終了するとすぐに消えます。まったく問題ありません。10台以上の、Android バージョンやメーカーの異なる端末で試しましたが、いずれも終了処理は正常に動作しているようなのです。

『やはりあれは、たまたま運悪く何かが起こって、終了処理に失敗しただけなのかもしれない。』

そう思うしかありませんでした。

1-3: 復活

ところが、数日後。

前日までは無かったのに・・・。

一つの端末で「復活」、していたのです。

 

 

画面には表示されていないのに、「実行中」一覧に私のウィジェットの名前があったのです。

前日まではなかったのに…。

 更に後日、他の端末でも復活していました。

ウィジェットを終了し、停止したはずのプロセスが、何かの「きっかけ」で数日後に再び動きはじめたのです。

「なんなんだ…こいつはいったい…!?」

1-4: 始まり

復活したプロセスは、見えないどこかで動いているので、普通に停止させることはできません。ところが、「実行中」一覧で選択して「停止」をしてもすぐにまた復活してしまいました。

そこで、「ダウンロード」一覧で選択し「強制停止」をしたところ、ようやく復活しなくなりました

謎のゾンビプロセスとの闘いが始まりました。

 

 

 

 

終了したはずのプロセスは、どこに残っているのか?

停止したはずのプロセスが、なぜ「復活」するのか?

不定期に発生する、復活の「きっかけ」とは?

復活を対策できるのか?

謎のゾンビプロセスとの闘いが始まりました。

※端末やAndroidのバージョンによっては、システム設定での表記が「アプリケーションの管理」「ダウンロード済み」「実行中のサービス」などのように若干異なる場合があります。

 

PID;2 輪廻

2-1: 流れ

まず、このウィジェットの処理の流れについて、簡単に紹介しておきます。
大きく分けて、3つの処理ブロックで構成されています。

時計ウィジェットの構造概要

ウィジェットをホーム画面へ設置すると「①起動処理」が実行されます。
OSのアラーム機能(タイマー処理)を使うことで、指定時刻(例えば1分後)になると「②描画処理」が呼び出されます。「②描画処理」では、「ウィジェット描画サービス」を実行することで時計の文字盤を描画します。そして次回のアラーム時刻をセットします。以降これを繰り返します。

ウィジェットをホーム画面から削除すると「③終了処理」が実行されます。アラームと描画サービスを停止し、ウィジェットは終了します。
構造は非常にシンプルです。

※実際にはウィジェットは複数同時に起動できます。この場合、「③終了処理」は、最後の1つのウィジェットが終了したときに実行されます。

2-2: どこから

終了したはずのアプリがどこから再び現れるのかは、すぐに見当がつきます。「キャッシュ」です。

Android OS は、アプリが終了したあとも、すぐにはそのアプリのプロセスをメモリーから解放しません。これは、そのアプリが再度起動されたとき、素早く処理を再開できるようにするための仕組みです。こうしてメモリーに残っているプロセスを「キャッシュしたプロセス」と呼びます。

※システム全体のメモリーが不足すると、OSは自動的に「キャッシュしたプロセス」を解放していきます。

Android 2.3 以降であれば、次の方法で「キャッシュしたプロセス」の一覧を確認できます。

  1. システム設定の「アプリケーション」-「実行中」一覧を表示する。
    ※「実行中のサービス」と表示されている場合もあります。
  2. 画面右上、または下部にある「キャッシュしたプロセスを表示」という文字をタップする。
    ※もしも見つからない場合は、メニューを開くとあります。

もちろん、私のウィジェットの名前も、終了直後に見るとこのキャッシュ一覧のなかにありました。どうやらここから復活したようです。

2-3: きっかけ

もう一度「2-1」の構造概要を見直してみると、再び動き出すまでの流れがなんとなく見えてきました。ウィジェットの終了後、アラームもサービスも停止したプロセスは、OSにキャッシュされます。この時点では「実行中」一覧から消えています。そして、そのキャッシュの「描画処理」が、何らかのきっかけで呼び出されるのが、復活のスイッチのようです。

「描画処理」が呼び出されると、描画サービスが再開され「実行中」一覧にウィジェットの名前が現れます。また、次回のアラームがセットされ、以降「描画処理」が繰り返し呼ばれ、無意味な描画処理によりCPUタイムとバッテリーを無駄に消費し続けてしまうということのようです。

復活の「きっかけ」はまだ不明ですが、終了したウィジェットが「実行中」一覧に再び現れるまでの過程がわかった気がします。

※「実行中」一覧は、具体的には「サービスが動いているアプリ」の一覧です。「キャッシュしたプロセス」ではサービスは停止しています。

 

PID;3 召喚

3-1: どこかに

その復活の「きっかけ」を見つけ出すため、もう一度、ソースファイルを良く見直しました。「描画処理」が呼び出されるルートがどこかにあるはずです。

しかし、なかなか見つかりません。

真っ先にアラームの動作を疑いましたが、ウィジェット終了直後には間違いなく停止しているので、これは違うようです。数日後に突然アラームが動き出すというのも考え難いです。

では、他に何が…?

3-2: 可能性

実はここまで、「まったく関係ないだろう」との判断のもと、完全に無視していた処理がありました。「描画処理」部分には、アラームの他にもう一つ、呼び出される条件があるのです。

描画処理(onReceive)

OSから「端末の時刻が変更された」という通知(ACTION_TIME_CHANGED)が来たときにも「描画処理」を実行するようにしてありました。こうしないと、セットされている次回のアラーム時刻と現在時刻が噛み合わなくなり、ウィジェットの描画がしばらく中断してしまうことがあるためです。

通常、端末の使用者が時刻の設定を変更することは滅多にありませんし、今回のテスト中も私は一切変更していません。なので、「無関係である」と最初から切り捨てて考えていました。

しかしもうここ以外に、「描画処理」が呼び出される可能性は残っていません。

「試しに時刻を変更してみよう」

そう思ってシステム設定の「日付と時刻」を開いたとき、思わず「あっ」と声をあげてしまいました。

3-3: 不定期

そこには「自動」という設定があります。ネットワークの情報から自動的に日時を修正してくれる機能です。通常、この設定は「ON」になっています。

「自動修正が働いて、時刻が変更されたときに、OSから通知が来るのでは…!?」

これなら、不定期に現象が発生する理由も説明できます。とにかくまず、端末の時刻を変更してみました。

3-4: 通知

ウィジェットを終了した後、手動で時刻を変更すると、

「…現れた! 瞬時に!」

「『実行中』一覧に私のウィジェットの名前が!」

複数の端末で繰り返し何度も検証しましたが、間違いありません。端末の時刻を変更すると100%確実に「実行中」一覧にすぐに現れました。

更に確認のため、端末の時刻を数時間ずらした状態で放置してみましたが、予想通り、時刻が自動修正された端末では復活していました。

OSにより不定期に時刻が自動修正されると、その通知は「キャッシュしたプロセス」にある私のウィジェットにも届きます。「描画処理」が呼び出され、停止していた描画サービスが再開され、「実行中」一覧に現れたのです。

復活の仕組みが、これで判明しました!

あとは対策するだけです。

※時刻が自動修正されるタイミングは、Android バージョンや 端末によって異なるようです。

 

PID;4 悪夢

4-1: これなら

早速、ウィジェットのソースに対策処理を入れました。

「ウィジェットが終了した」ことを記録しておき、終了後に「描画処理」が呼び出されても無視するようにしたのです。

具体的には、メンバー変数として「終了フラグ」を用意しました。ウィジェットの起動直後は「OFF」になっており、終了したときに「終了処理」でこれを「ON」にします。
「描画処理」では、「終了フラグ」が ON なら何もせずに処理を抜けるようにしました。

時計ウィジェットの構造概要

これなら、終了後にもし「描画処理」が呼び出されることがあっても、描画サービスが再び実行されることはなく、アラームもセットされずに即停止するはずです。

4-2: これで

対策したウィジェットをテスト用端末にインストールし、一度起動してから終了させます。「キャッシュしたプロセス」にはウィジェットの名前が表示され、キャッシュされていることが確認できます。この状態で、手動で端末の時刻を変更してみました。

「復活…しない!」

10台以上の端末で何度も試しましたが、「実行中」一覧に私のウィジェットの名前が現れることはありませんでした。念のため数日間、毎日「実行中」一覧を確認しましたが、やはりもう現れません。

これで、「復活」を封じることに成功したのです!

4-3: まだ

それから一週間以上が過ぎていました。「復活」現象はもう対策できたので、安心して次のアプリ開発に着手していました。

そんなとき。

開発中のアプリの動作確認のため、「実行中」一覧を見たとき、信じられないものを目にしました。
そこには、私のウィジェットの名前があったのです。

使っていないのに…。
ホーム画面に、そのウィジェットの姿はないのに…。

あわてて他の端末も確認しました。すると、一部の端末でやはり「復活」していました。

悪夢のようです。

まだ続くのか……!?

「終了フラグ」は、「復活」現象の発生頻度を大幅に減らしただけで、まだ不完全だったのです…。

 

 後編へつづく...

11月9日開催の東京ロケテゲームショウに参加します

$
0
0

こんにちは。ウェブテクノロジ 大和です。

イベントへの出展のお知らせです。

今回もインディーゲーム開発の流れを意識して、東京ロケテゲームショウに出展します。

開催概要

イベント名 東京ロケテゲームショウ2013
日時 2013年11月9日(土) 11:00~16:00
場所 ヒロセ無線 5階ホール
» 地図はこちら
公式サイト https://sites.google.com/site/locategameshow/

「パソコン、PlayStation®Vita、iPhoneのようなスマートフォンで遊べるゲームを
実際に触りプレイしながらゲーム制作者の方とコミュニケーションを取れるイベントです。
展示されているゲームは、皆さんの参加を通じて、成長できる機会を探しています!」
という説明の通り、ゲームの自主制作者を応援するイベントです。

インディーゲーム界隈は、昨年のTGS で注目された頃から、改めて熱気を帯びているのを
感じます。

私たちも、インディーゲームが盛り上がって面白いゲームが出てくるのをワクワクしながら
待っています。今回の協賛は、ニコニコ自作ゲームフェスさんUnityさん
そしてウェブテクノロジです。

ウェブテクノロジからは、インディーズゲーム(インディペンデントゲーム)開発者の
皆様向けに、「超汎用」2Dスプライトアニメーションデータ作成ツール
『OPTPiX SpriteStudio』の無料ライセンスを用意しました。

つい先日もABC 2013 Autumnにお伺いしたところ、ご興味を持っていただく方が
多かったのが印象的でした。

当日は、OPTPiX SpriteStudioを中心に、最近はゲームでもご利用いただいている
漫画作成ソフト「コミPo!」を展示します。

ご興味のある方は是非ブースにお立ち寄りいただき、その場で体験してください。

ウェブテクノロジでは、インディーズゲーム(インディペンデントゲーム)開発者の皆様が
面白いアイディアを素早く実現するために、ゲーム開発ツールの側面からクリエイターの
皆様を応援していきます。

 


同人ゲーム即売会『デジゲー博』に、SpriteStudio開発チームが参加!

$
0
0

同人誌即売会なんて何年ぶりでしょうか。毎度おなじみ、セールス&コミュニケーション部の浅井でございます。

さて『インディーゲーム』の潮流は同人業界? にも波及、というか両者の住み分けって一体? なんて考えたりもしているのですが、11月17日(日)に蒲田にある「大田区産業プラザPiO」で行われる同人・インディーゲームの即売会、『デジゲー博』に、「OPTPiX SpriteStudio」も出展します。

digihaku-catalogue-2013

11/17(日)@大田区産業プラザPiO 2F小展示ホール

出展、なんていうんだから展示物はもちろん、9月に発表した「OPTPiX SpriteStudio for Indie」。今回は、私の他に開発メンバー「ほぼ」全員(つってもメイン開発者は2名ですが)が参加、同人・インディーゲームの現在を肌で体感しつつ、今後の盛り上がりに大期待、みたいなココロモチで臨みます。

当日は「OPTPiX SpriteStudio」の実機展示はもちろん、某老舗ゲームメーカー制作のアニメーションサンプルの現物を展示いたしますので、『あ、こんなことができるなら、こんなことも??』と閃いていただけると幸いです。また、せっかく開発の人間が参加いたしますので、既に「OPTPiX SpriteStudio for Indie」を触っていただいている方はもちろん、これから触ってみようかなぁ、とお考えの方ともお話できればーと思う次第です。ぜひぜひ、弊社ブースにお立ち寄りください。それでもって遠慮なくお声がけください。

※弊社のブースは、「A-33」です!

» 同人・インディーズオンリー デジタルゲーム展示・即売会 デジゲー博公式サイト

64bit Windowsを前提とした32bitアプリケーション延命法 ~ LAAオプションで32bitアプリケーションのメモリ不足問題を解消

$
0
0

こんにちは。ウェブテクノロジの清水です。

Windowsアプリケーション開発者向けに、ちょっとしたTipsを紹介します。今回はVisual Studioの「LAAオプション」(LARGEADDRESSAWAREオプション、4GBオプション)という機能です。かなり便利な機能なのですが、知らない人も多いようです。

64bit化したくてもできない事情

オンメモリでデータを処理するタイプの32bitのWindowsアプリケーションでは、メモリ不足が結構深刻な問題となることがあります。

アプリケーションを64bit化すれば解決すると分かっていても、動作対象OSを64bit版Windowsのみに限定するのはユーザにとっても営業面から見ても抵抗がありそうです。

Windows XPのサポート終了が迫っている最近では、アプリケーションの動作対象OSからWindows XPを外すことも、ようやく普通の仕様として認められるようになってきていると思いますが、まだまだ無視できないのが32bit版のWindows 7のユーザです。

また、

  • 使用している社外ライブラリに64bit版が用意されていない
  • ソフト規模が大きかったり、使用しているライブラリが多すぎて、工数的に全部64bit対応するのが困難
  • インラインアセンブラを使っている部分があるので64bit化できない(64bitコンパイラがインラインアセンブラに未対応のため)
  • 配布パッケージやアップデート差分などを毎回32bit版と64bit版の2セット用意したくない

など、様々な理由でアプリケーションの32bit・64bit両対応を諦め、引き続き32bit版のみでアプリケーションの開発を続けている場合も多いのではないでしょうか?

2GBの壁

Windowsの場合、PCに4GB以上のメモリを搭載していても、通常、1個の32bitアプリケーションで利用可能なメモリ容量は約2GBです。

32bitアプリケーションがnewやmalloc()やGlobalAlloc()などで確保できるヒープメモリの容量は、この2GBからプログラム本体や各種のDLLが占有するメモリエリアの容量が引かれるため、さらに少なくなります。

実際に簡単なプログラムを作って調べてみると、確保できるヒープメモリの総容量は約1.9GBでした(環境や一度に確保するデータサイズによって多少変わります)。

これでは、数百MBの巨大なデータをオンメモリで複数同時に扱うようなタイプのアプリケーションでは、すぐにメモリ確保に失敗してしまいます。

テストに使用したプログラム

▲クリックで拡大
テストに使用したプログラム

通常ビルド時の実行結果

通常ビルド時の実行結果

弊社のアプリケーションでは、使用しているDLLが多いためか、アプリケーションから利用可能なヒープメモリ容量は1.5GB程度になりました。

実際、「メモリを16GB搭載していて、空きメモリは十分にあるのに、どうしてメモリ不足エラーが表示されるのか?」という問い合わせが弊社ユーザーサポート宛に届くこともありました。

アプリケーションによっては、独自に仮想記憶のような処理を行って、32bitアプリケーションで2GBを超える大量のデータを扱えるようにしているものもありますが、そのような処理を全く想定せずに開発されたアプリケーションでは、後から独自の仮想記憶のような処理を追加するのは難しいものです。

「LAAオプション」でヒープ倍増

実は、Visual Studioで開発している32bitアプリケーションでは、「LAAオプション」(LARGEADDRESSAWAREオプション)というものを使用して、64bit版のWindowsで実行した場合に、32bitアプリケーションが利用可能なメモリ容量を4GB弱まで増やす方法があるのです。

32bit版のWindowsのユーザもまだまだ残っているとはいえ、すでにユーザの多くは64bit版のWindowsを使っています。

このようなユーザにとっては、32bitアプリケーションでも「LAAオプション」が設定されていれば、64bit版Windowsの大容量メモリの恩恵(の一部)にあずかることができるわけです。

32bitアプリケーションで「LAAオプション」を使用するのは簡単で、たとえば、Visual Studio 2012の場合、開発中のアプリケーション(EXE)のプロジェクトのプロパティを表示し、

構成プロパティ → リンカー → システム → 大きいサイズのアドレス

の設定を「はい (/LARGEADDRESSAWARE)」に変更してビルドするだけで「LAAオプション」が有効になります。

「LAAオプション」でヒープ倍増

▲画像クリックで拡大
Visual Studio 2008などでは「2GBを超えるアドレスをサポートする(/LARGEADDRESSAWARE)」という表現になっています。

この変更を行ってビルドされた32bitアプリケーションは、従来の32bit Windows上で実行した場合は従来と同様に2GB弱の制限のままですが、64bit版のWindows上で実行すると4GB弱のメモリが使用できるようになります。

簡単なプログラムを作って試してみると、この「LAAオプション」を有効にすることで、確保できるヒープメモリは約3.9GBになりました。「LAAオプション」を設定しない場合と比較して、使えるヒープメモリがほぼ倍増したことになります。

LAAオプション有効時の実行結果

LAAオプション有効時の実行結果

なお、「LAAオプション」の設定自体はEXE作成用のプロジェクトだけでなく、DLL作成用のプロジェクトにも存在しますが、実際に有効なのはEXE作成用のプロジェクトの方だけです。

DLL側のコードでヒープメモリの確保を行っているような構造のプログラムでも、EXE側のプロジェクトの「LAAオプション」の設定が優先され、DLL側のプロジェクトの「LAAオプション」の設定は無視されます。

弊社のアプリケーションで「LAAオプション」を有効にしたところ、利用可能なヒープメモリ容量が3.6GB程度まで増えました。お客様から「メモリ不足エラーになる」という問い合わせをいただくこともなくなりました。

4GBパッチ

Visual Studioの「LAAオプション」はコンパイラではなくリンカーのオプションで、実際はビルドされたEXEファイルのヘッダ部分に「LAAオプション」の識別フラグが設定されるだけです。

WindowsのOS側が、このフラグを見て、その32bitアプリケーションに対するメモリ管理を2GBにするか4GBにするかを自動的に判別しているのです。

従って、たとえば、既存の32bitアプリケーションのEXEファイルをバイナリ編集して、この「LAAオプション」フラグを追加することも可能です。

このバイナリ編集は、既存の32bitアプリケーションのメモリ不足に悩んでいるユーザの一部では「4GBパッチ」などと呼ばれているようです。

もちろん、ユーザによるEXEファイルのバイナリ編集は、改ざんチェックを行っているプログラムでは使えませんし、電子署名付きのEXEファイルの場合は署名が壊れてしまいますので、アプリケーション開発者が自らアプリケーションのプロジェクトのプロパティで設定を変更し、正規にプログラムをビルドしなおすのが正しい「LAAオプション」対応です。

32bit Windowsでも「/3GB」起動スイッチ付き環境で効果あり

実は、Windows XPなどの32bit版のWindowsでも、「boot.ini」で「/3GB」起動スイッチを有効にしていると、「LAAオプション」を有効にしたアプリケーションが利用できるメモリの上限が2GBから3GBに拡張されます。

(※「/3GB」起動スイッチの詳細についてはマイクロソフト社のサポートページ等をご覧ください。)

実際に「/3GB」起動スイッチ付きの32bit Windows環境を用意して簡単な32bitプログラムを作って試してみると、約2.8GBのヒープメモリが使用できるようになりました。1つの32bitアプリケーションでヒープメモリとして使用できるメモリが約1GB増えたことになります。

「boot.ini」の編集は非常にハイリスクなので(書き換えを失敗するとWindowsが起動しなくなる可能性がある)、一般のWindowsユーザに「boot.ini」の設定変更を勧めるのは不適切ですが、すでに自主的に「/3GB」起動スイッチを有効にしてる上級ユーザなどにとっては、「LAAオプション」を有効にした32bitアプリケーションが増えることは歓迎されるでしょう。

「LAAオプション」の注意点

こんな便利な「LAAオプション」ですが、ちょっとだけ注意点があります。
「LAAオプション」を有効にしたプログラムが利用しているすべてのコード(DLLなども含む)の中で、確保したヒープメモリに対して不適切な処理を行っている箇所があると、プログラムが誤動作してしまいます。

不適切な処理の例

  • 確保可能なヒープメモリの総容量が2GB以下であることを前提にしている
  • ヒープメモリのアドレスが0x7fffffff以下であることを前提にしている

おそらく普通のプログラムでは、このような不適切な処理を行っている箇所はまずないと思いますが、意図的、あるいは意図せずに、このような不適切な処理を行ってしまっている場合は、「LAAオプション」を付けることでアプリケーションが正常に動作しなくなる可能性があります。

「LAAオプション」を付けた場合だけ不具合が発生する、という問題が発生したら、その時は不適切な処理を行っている場所を突き止めてプログラムを修正する必要があります。
もし社外ライブラリなどソース変更が不可能な部分でこの問題が発生したら、その時は残念ながら「LAAオプション」を諦めるしかありません。

弊社の場合では、今のところ、「LAAオプション」を有効にしてリリースしている「OPTPiX imesta7」(C++ネイティブ)、および、「コミPo!」(C++/CLI)で、「LAAオプション」が原因と思われる問題は発生していません。

以上、Windows用の32bitアプリケーションを開発されている方々の参考になれば幸いです。

OGPを設定して、Facebookでシェアした時の画像を大きく表示させよう

$
0
0

こんにちは、ウェブ担当の嶋です。

Twitterと並んでSNSの代表格となったFacebook。ウェブテクノロジでは公式ページとともに「OPTPiX SpriteStudio ユーザー助け合い所」というグループも開設し、ユーザー様と情報を相互にやりとりしています。

Facebookは、URLを含む投稿やシェアをすると、自動的にそのURLからタイトル概要画像などを取得して表示してくれます。リンクをクリックする前にどんなサイトなのかなんとなくわかるのは非常に便利なのですが、こういう形でシェアされているのをよく見かけませんか?

share_sample

ページのタイトルや見出しは適切なのですが、サムネイル画像として表示されている画像の左右が切れてしまっています。また、表示されている画像もサイトのトップページを紹介する画像としては適切ではありません

これはOGP(Open Graph Protocol)の設定が行われていないことが原因です。自サイトに多くの人を誘導するためにも、OGP、特に画像に関する部分の設定はしっかりとやっておきたいものです。

※例示としてコミPo! のトップページを使っていますが、実際のページはきちんとOGP設定されてますので、この通りにはなりません。念のため。

OGP(Open Graph Protocol)とは

OGP(Open Graph Protocol)とは、ひとことで言うならば「リンク先のウェブページの内容を紹介するための仕様」のことです。もともとfacebookが提唱した規格ですが、mixiやはてなブックマーク、GREEなどでも利用されています。

実際にページにアクセスしなくとも、どんなページ内容なのか、誰が書いているのかといった情報を事前に知ることができます。FacebookのタイムラインにURLを貼り付けると自動で取得され、貼り付けられるようになっています。

なお、今回のエントリーではFacebook向けの設定を解説しています。その他のソーシャルネットワークに関しては本エントリーの設定がそのまま使えるものもありますし、別途設定が必要なものもあります。こちらはまた別のエントリーで解説したいと思います。

 

OGPを設定していないとどうなるのか?

OGPを全く設定していないページをFacebookでシェアした場合は、下記のような挙動になります。

タイトル <title> </title> に設定しているタイトル
※設定していなければページのURL
概要説明 <meta name=”description” content=”テキスト”> のテキストの部分
※設定していなければ本文テキストの冒頭部
URL ページのURL
画像 ページに使われている画像の中から一定の条件を満たす画像が無作為に3種類選ばれる。画像はトリミングされてしまう。

ほとんどのサイトでtitleタグやdescriptionは指定していると思いますので、そこで問題が出ることはほとんどないでしょう。

一番ネックになるのは画像です。「無作為」に選ばれた上に「適宜トリミング」されてしまうため、このエントリーの冒頭でご紹介したような見当違いな画像が表示されてしまう、ということが起こるのです。

試しにOGPを何も設定していないサンプルページを作成してみました。タイトルもdescriptionも設定していないという、あまり現実的ではないページです。シェアしてもタイトルは出ない、説明文も本文がそのまま使われ、縦長の画像の上下がトリミングされたものがシェアされてしまうという、なかなか悲しい状態になってしまっています。

ページの内容がどんなに素晴らしくても、そこへ誘導するための「看板」となる画像や説明文がが今ひとつだと、人はやって来ません。タイムラインに適切な情報と画像を流し、そこからの流入を増やすためにも、OGPの設定は非常に重要なのです。

 

OGPの書式

OGPはhtmlファイル内にmetaタグで記入するだけで設定が可能です。

まず、htmlタグを下記のように書き換えます。

<html lang=”ja” xmlns:og=”http://ogp.me/ns#” xmlns:fb=”http://www.facebook.com/2008/fbml”>

HTML5でコーディングしている時はhtmlタグの代わりにheadタグを書き換えます。

<head prefix=”og: http://ogp.me/ns# fb: http://ogp.me/ns/fb# article: http://ogp.me/ns/article#”>

その後、head要素の中に下記のmetaタグを追記します。

<meta property=”og:title” content=”ページのタイトル”>
<meta property=”og:description” content=”ページの簡単な説明”>
<meta property=”og:url” content=”ページのURL”>
<meta property=”og:image” content=”サムネイル画像のURL”>

最低限の設定ではありますが、これでシェアした際の画像やテキストが明示的に指定できるようになります。

OGPの公式サイトFacebookの開発者向けページでは更に細かな項目について記載されていますので、そちらも合わせてご覧ください。

 

OGPで画像を指定するときのポイント

2013年11月20日現在、FacebookはOGPで指定する画像として「1200px × 630px以上の画像」の指定を推奨しています。スマートフォンの画面解像度が上がっていることや、Retinaディスプレイを踏まえてこの数字になっているようです(最低でも「600px × 315px」とも書かれています)。

しかし、Facebookが推奨しているサイズを用意するだけでは、PC、Android、iPhoneといったすべてのデバイスに対して適切な画像を提供することはできません。環境によっては、こちらの意図しない形でトリミング処理が行われてしまうことがあるのです。

PCでもAndroidでもiPhoneでもなるべく大きく、かつ意図しない形でトリミングされないような画像を用意するにはどうしたらいいのでしょう。

ポイントは3つです。

  • 画像は正方形にする
  • 画像の中心に縦横比1:1.91の画像を配置する
  • 上下に余白を入れる

 

正方形の中に 1:1.91 の横長の画像を入れる理由

どうして正方形の画像の中に横長の画像を配置する、という面倒なことをしなければならないのでしょうか。それはFacebookのトリミングの仕様に合わせるためです。

縦横600pxの正方形のなかに、Facebookが推奨としている「600px × 315px」の画像を入れ込んだサンプル画像を用意しました。画像のオレンジの部分が600px × 600pxの部分、青い部分が600px × 315pxの部分です。下記の画像を「og:image」として設定してあるURLを実際にシェアしたときの見栄えを見てみましょう。

OGPテスト用画像(600x600)

まずPCブラウザのニュースフィード上では、画像は1:1.91の横長のサイズになります。OGPで画像を指定していなかった場合は、上下または左右がトリミングされ、強制的に1:1.91のサイズにされます。この法則はAndroid用のFacebookアプリや、Android標準ブラウザでFacebookにアクセスした際も同様です。

そのため、サンプル画像の中央部分の600px × 315pxの部分がトリミングされて表示されます。これは600px × 315pxの画像をog:imageとして指定した場合でも同じです(実際の表示サイズはPCの場合398px × 208pxと縮小表示されます。スマートフォンは画面解像度によって変わります)。

PCのニュースフィード上での表示 AndroidのFacebookアプリ上での表示
PCのニュースフィード上での表示 AndroidのFacebookアプリ上での表示

ところが同じ情報をPCブラウザのタイムライン上で見ると、サムネイル画像は正方形の画像になります。og:imageで指定した画像が正方形であれば画像の全域が表示されます。これが画像を正方形で用意する理由です(表示サイズは154px四方または90px四方の正方形です)。

ogp_pc_timeline▲PCのタイムライン上での表示

ogp_ipad▲iPadのFacebookアプリ上での表示

 仮にog:imageとして600px × 315pxの画像を指定していた場合、Facebookは余白なしで画像の中央部分をトリミングして表示しようとします。つまり画像の左右が切り取られて表示されてしまうことになります。

なお、上記ではFacebookが公式に「推奨サイズ」としているサイズに準拠させるため正方形の一辺を600pxとしていますが、「シェアした際の画像を大きく、トリミングさせずに表示させる」という条件を満たし、かつ画像サイズを一番小さくしたい場合の最小サイズは「一辺が468pxの正方形」となります。これより小さい画像はAndroidアプリで表示した際に画像が小さくなってしまうため、あまりおすすめしません。

また、200px × 200px以下の画像はFacebookから無視されてしまう場合があるので小さすぎる画像も避けるようにしましょう。

 

【まとめ】Facebook用のOGPの画像はトリミングされる前提で画像を用意することが大切

FacebookはAndroidやiPhoneなど、様々なデバイスで見ることができます。OGPさえ設定してしまえば何で見ても画像は表示されます。しかし、「どのデバイスで見てもトリミングされない」という画像サイズは、今のところありません。

ですので、OGP用の画像を用意する際はトリミングされることを前提に、「トリミングされたとしても、見せたい範囲は切り取られない」という画像を用意するのが今のところベストな選択と言えます。それがさきほどご紹介した「正方形の中に1:1.91の画像をはめ込んだ画像」です。

そして、その1:1.91の部分をFacebookが言う「最低でもこの画像サイズにしてね」というサイズにしたのが、下の「600px × 600pxの正方形の中に600px × 315pxの画像をはめ込んだもの」ということになります。

今のところベストと思われるFacebook向けOGP画像

【下記のページを参考にさせていただきました】

 

画像の加工が面倒、そんな時に便利なOPTPiX imestaの各種機能

いざOGP用の画像をつくろうとしても、1:1.91という比率の画像は一般的なサイズとは言えません。更にそれを「正方形の画像の中にはめ込む」となると、手間もかかります。

そこでOPTPiX imestaの出番です。

1:1.91という比率でのトリミングを行う場合は「四角形選択」の際に縦横比を「100:191」に指定し、Shiftキーを押しながら範囲選択をするだけで簡単に1:1.91の画像を切り出せます。

1:1.91の画像をトリミング

また、画像を600px四方の正方形に収めるのであればマクロ機能を使うのが便利です。下記の順番で処理させればあっという間にOGP用の画像を生成することができます。

処理名 処理の内容
拡大縮小 アスペクト比を固定した状態で、「高さを指定:315」と指定して拡大縮小する。
イメージサイズ変更 新しいサイズを「600 x 600」、イメージレイアウトを「中央」にする。
「余白の塗りつぶし設定」は「白」を選択する。
減色 出力色数を指定して減色する。
※元画像が写真などの場合は256色、アニメ調の絵などで色数が少ない場合は任意の色数で。

ちなみに最後の「減色」はなくてもいいように見えますが、過去のエントリーでもご紹介したとおりFacebookは元の画像を減色処理しておいたほうがアップロード後の画像ファイルサイズも小さく、またPNGの方がキレイ、ということがわかっています。表示されるまでの速度も踏まえて、あらかじめ減色しておくことをおすすめします。

マクロ処理後に出力された画像がこちらです。左は1:1.91でトリミングを行ってから処理したもの、右はトリミング処理を行わずにそのままマクロ処理を行ったものです。

実際の画像には枠はついていませんが、わかりやすいようにhtmlで表示する際に薄い枠を付けてあります。サンプルページも用意してありますので、リンク先で試しに「シェア」ボタンを押してみてください。どういうイメージでシェアされるのかがお分かりいただけるかと思います。

あらかじめ1:1.91でトリミングしたもの トリミングせずそのままマクロで処理したもの
あらかじめ1:1.91でトリミングしてから
マクロ処理したもの
トリミングせずそのままマクロ処理したもの
サンプルページ サンプルページ

 

「シェアされた時の見栄え」を考えると、効果も上がる

専用の画像を用意する必要がある、という点だけ見るとOGPは手間のかかる設定と言えます。しかし、逆に考えれば「きちんと設定すればFacebookからの流入を増やせる可能性を秘めている」とも言えます。

URLをシェアしてもらえることは、その人とつながっている人たちのタイムラインにいわば「看板」を出してもらえるようなものです。だからこそ、表示される画像の質や説明文にはこだわっていきたいものですね。

 

※本エントリーの情報は2013年11月20日現在の情報を元に作成しています。

テクスチャ圧縮フォーマットDXTC・ETCのTIPS CEDEC2013復習編(1)

$
0
0

ウェブテクノロジ R&D部の上田です。

今回は、CEDEC2013の公募セッションから、テクスチャ圧縮フォーマットのDXTC・ETCに関するTIPSをピックアップしてご紹介したいと思います。

なお、CEDEC2013公募セッションの全スライド資料は、下記からダウンロードできますので、本記事で興味を持たれた方は、ぜひそちらもご覧ください。

 

1.DXTCのTIPS

1.1 ブロックノイズ対策

DXTCのTIPS一つ目は、以下のような輪郭線付近のブロックノイズに対する対処の仕方です。

dxtc01_lanc_50per上の図のように、輪郭線付近でブロックノイズが出てしまっている場合、思い切って輪郭線を太くする、もしくは輪郭線をなくすとブロックノイズが減少します。
dxtc02_lanc_50per
DXTCは4×4ピクセルを1ブロックとして独立して圧縮していますが、この1ブロック内に輪郭線の色・輪郭の内側の色・輪郭の外側の色という3つの傾向が違う色が入り込んでしまうと、ブロックノイズが発生する原因になってしまいます。

このため、輪郭線を無くす、あるいは輪郭線を太くすると、1ブロックに入り込む色が2つに抑えられて、ブロックノイズが減少します。

なお1ブロックは4×4ピクセルであるので、輪郭線の太さは3ピクセル以上にすると効果が高いです(逆に1~2ピクセルの輪郭線はブロックノイズの原因となりやすい傾向があります)。

1.2 DXT1~5の使い分け

DXTCのTIPS二つ目は、DXT1~5の使い分けについてです。

DXTCを使っていて、下の図のようにアルファチャンネルのグラデーション部分が段々になってしまったことはないでしょうか?
dxtc03_lanc_50per
これはDXT1~5の使い分けを間違ったことが原因になっています。

上の図ではDXT3が使用されていますが、このようなアルファチャンネルでグラデーションを表現するような場合、DXT5を利用したほうが綺麗に出力されます。
dxtc04_lanc_50per
DXT1~5の使い分けは、以下のようにするのがベストです。

  • アルファチャンネルなしの画像ではDXT1を利用する
  • アルファチャンネルありの画像では基本的にDXT5を利用する
  • DXT5を利用してアルファチャンネル部分の劣化が酷かった場合のみ、DXT3を試してみる
  • DXT2とDXT4は乗算済みアルファの指定があるときのみ利用する。それぞれDXT2はDXT3に、DXT4はDXT5に対応している

なお、最近の規格ではDXTCの代わりにBCと呼ばれるものが利用されていることがあります。この場合、BC1がDXT1に、BC2がDXT3に、BC3がDXT5にそれぞれ対応しています。

2.ETCのTIPS

2.1 ブロックノイズ対策

ETCのTIPS一つ目は、以下のような色の境目に出現するブロックノイズに対する対処の仕方です。
etc01_lanc_50per
こんな時は、DXTCとは逆に黒や白の輪郭線をつけてしまいましょう。
etc02_lanc_50per
ETCでは色の境目でブロックノイズが出やすいのですが、隣接している色が黒や白の場合はブロックノイズが抑えられます。この点はDXTCとは異なる特性なので、頭の片隅に記憶しておくとちょっと役に立つと思います。

2.2 ETCでアルファマスクを作るときの注意点

ETCではアルファチャンネルありの画像を扱うことができません。そこで、RGBチャンネルのみの画像とは別に、アルファチャンネル情報を持つマスク画像を別に作成し、表示するときに処理する、といった方法が考えられます。
etc03_lanc_50per
このとき、注意点が一つあって、マスク画像をRGBチャンネルのどれか1色で作ってしまうと、マスク画像が劣化してしまう、ということがあります。
etc04_lanc_50per
このようにマスク画像を作成するときは、RGBチャンネルのどれか1色を使うのではなく、RGBチャンネル全てを同じ値として、アルファチャンネルのマスク画像を作ると品質の良いマスク画像を作ることができます。
etc05_lanc_50per
理由としては、ETCでは圧縮後に1ブロック内で使うことのできる色は、代表色と呼ばれる色から、RGBチャンネル全てに対して同じ値を足したり引いたりして決定されます。

そのため、RGBチャンネル全てに同じ値が入っているものよりも、RGBチャンネルのどれか1色だけが使われている場合の方が、圧縮後に使える色と圧縮前の色が違ってしまうことが多いということがあります。


DXTCとETCに関しては、以下の記事でさらに詳細な説明を記載しています。そちらをご覧いただけるとDXTC・ETCに関する知識を更に深めることができると思います。

 

「第9回IPA情報セキュリティ標語・ポスター・4コマ漫画コンクール 2013」 表彰式レポート

$
0
0

こんにちは、ウェブテクノロジの大和です。

普段は裏方にいることが多いのですが、コミPo! の統括ディレクターという肩書でもがんばっています。

さて、今回は漫画作成ソフト「コミPo!」の話題です。

先週の土曜日、12月7日にIPA 独立行政法人 情報処理推進機構 さんが主催する、
伝えよう、情報モラル「第9回IPA情報セキュリティ標語・ポスター・4コマ漫画コンクール 2013」
の表彰式に行ってきましたので、ちょっとご報告します。

「第9回IPA情報セキュリティ標語・ポスター・4コマ漫画コンクール 2013」
では33,335作品もの作品が応募されました。
この過去最高の応募数には、応募する児童・生徒さん達の情報セキュリティに対する意識が上がっていることを感じました。IPA の方々のご尽力はもちろん、インターネットの普及だけでなく急速に進むスマートフォンの普及などを受けて、これだけの応募数が集まったことに驚きました。

ウェブテクノロジでは以前から、IPA さんの当コンクール向けに、コミPo! の特別版を提供してきました。そして晴れて、今回から協力企業としてこのコンクールに携わることができました。
しかも初めて協力する今回、コミPo! を使った作品が数多く受賞されたので、私たちとしては大変嬉しい表彰式になりました。

4コマ漫画部門受賞全19作品のうち、コミPo! を利用した作品は、当社からの賞以外に3点もありました。皆さんに聞くと、「自分は絵は描けないけどコミPo! があったから簡単に作れた」という声を聞くことができ、コミPo! が絵が描けない人でも簡単にマンガの表現力を利用することができるツールとしてきちんとお役に立っていることを実感することができました。
コンクールの受賞作品は第9回 IPA標語・ポスター・4コマ漫画コンクール2013受賞作品のページでご覧いただけます

ここでは、4コマ漫画部門の最優秀賞に輝いた、同志社高等学校1年の原麻梨子さんの作品をご紹介します。実は、この作品にもコミPo! を使っていただいており、ウェブテクノロジにとって記念すべき今年のコンクールで、コミPo! を使った作品が最優秀賞を受賞するなんて、本当に感謝の気持ちでいっぱいです。

第9回情報セキュリティ標語・ポスター・4コマ漫画コンクール授賞式

その内容をちょっとご紹介すると、
リアル社会の大切さを恐怖を煽るような表現ではなく、高校生ならではの視点で表現している作品です。
大人が考えるとどうしても説教クサイ内容になり、逆に伝わりづらくなりがちですが、この作品を読んだ人は、無意識にスマホの使い方を考えさせるような内容で、マンガ表現の可能性を感じました。
実際の作品は、第9回IPA情報セキュリティ標語・ポスター・4コマ漫画コンクール2013 受賞作品発表のページにございますので、是非ご覧ください。

最後に弊社からも企業賞を3作品選考させていただきました。
それらの作品は「受賞作品:4コマ漫画部門」のページにございます。

コミPo! は来週12月15日に発売3周年を迎えます。
新機能を含め、ちょっといろいろと準備をしています。

今後ともコミPo! をよろしくお願いいたします。

OPTPiX SpriteStudio :『プロの作例』シリーズ第一弾を公開!

$
0
0

今回は、インディーズデベロッパー向けライセンス、『OPTPiX SpriteStudio for Indie』が大好評! な、「超汎用2Dアニメーションツール OPTPiX SpriteStudio」の件で、大変面白いお知らせ。

セールス&コミュニケーション部の浅井です。 果たして?

って、タイトルに書いちゃってるんですねー左様、「OPTPiX SpriteStudio」の作例シリーズ第一弾をYouTubeにて公開いたしました。

今回の『プロの作例』は、株式会社アルファドリーム様による可愛らしい女の子のアニメーションです。

こちらのデモは、9月の『IndieStream』、11月の『デジゲー博』と、ここしばらくのイベントでの動作デモとしてお借りしておりましたものの一つ・・・なのですが、今回は「OPTPiX SpriteStudio」の機能とアニメーションをマッピングしつつ、解説コメント付きでご紹介しております。

「OPTPiX SpriteStudio」のユーザーの皆様にはもちろんのこと、これから「OPTPiX SpriteStudio」を触ってみようかなor導入してみようかな、触っているけどちょっと難しい! と、お考えの皆様の参考になれば幸い! です。

さて、この『プロの作例』については表題の通り『シリーズ』化を目指しております。実際にゲーム中で使われた現物データはちょっと難しいかもしれないのですが、もし『我こそは!』とお考えの方がいらっしゃいましたらば、お知らせください。

田中圭一のゲームっぽい日常 アフターファイブのおつきあい

$
0
0

田中圭一のゲームっぽい日常 アフターファイブのおつきあい

3年ほど前の話、老舗の商社に勤めている方と話す機会があった。

商社マン
「君たちIT系のサラリーマンって、仕事帰りに上司と一杯・・・みたいなのって、ほとんどないんだって?」
田中
「会社によりますけど、私の勤めている会社は、まったくないです。」
商社マン
「ダメだよ。職場の仲間なんだから仕事以外の時間でもちゃんとコミュニケーションを取らないと。」
田中
「そうですね。でも、お酒が飲めない人が多いんですよ。IT系の人って。」
商社マン
「じゃあ、みんな仕事が終わったらなにやってんの?」
田中
「ネットゲームとか・・・」
商社マン
「ダメダメ!そんなのやってちゃあ!仕事仲間とのコミュニケーションって重要なんだからさぁ。」
田中
「そ、そうですよね・・・ははは・・(苦笑)・・・」

その時は「コミュニケーションのために、わざわざ飲めないお酒を飲むというのも無理な話だし、どうしたものかなぁ。」と思った。

だが、その日の帰り道にふと気がついた。

その会社では仕事が終わったらネットゲームで職場の人たちがパーティーを組んで冒険している。例えば会社を辞めた人も仲間に加わって近況報告とかしていたりと、ちゃんとコミュニケーションを取っているじゃないかと・・。

なんのことはない、コミュニケーションのツールが「お酒」から「ネトゲ」に変わっただけで、ちゃんとIT系でも社員達の情報交換の場があるのだと。

そんなワケで、業界が変わっても時代が変わっても社員同士のコミュニケーションは滞りなく続いていますよ、商社の方!


【Androidアプリ開発ドキュメンタリー】 虚空より突如蘇る、不死鳥プロセス ~後編~

$
0
0

こんにちは、開発の小野知之です。

先月の続き、後編です。
今回は余力不足で挿し絵が無いです。後で追加するかもしれません。

ところでこの話、ウィジェット作成時に発生した現象ではありますが、結論から言えば Activity を使った普通のアプリでも同様に発生する可能性があります。Android アプリを開発する方は、知っておくと何か役に立つことがあるかもしれません。

» 「前編」はこちらからご覧ください。

» 「まとめ」を先に読みたい方ははこちら。

【前編のあらすじ】

終了したはずのアプリのプロセスが突如復活するという怪現象が発生。

一度は原因が判明し、対策も万全と思われたが、平穏な日々はそう長くは続かなかった。

消滅したはずのプロセスが、いったいどこから、どうやって蘇ったのか。そして、復活を阻止する手段はあるのか…?

 

PID;5 深淵

5-1: ルート

ここまでにわかった、復活現象発生までの流れをもう一度整理してみます。

  1. アプリが終了すると、そのプロセスは、終了したときの状態を保持したまま、「キャッシュしたプロセス」としてメモリー上に残っている。
  2. 端末の時刻は、OSの自動修正機能により不定期に変更(修正)される。その通知は、キャッシュ上のプロセスにも届く。
  3. キャッシュに残っている私のウィジェットのプロセスは、時刻変更の通知を受けると「描画処理」が呼び出される。そして停止していた「描画サービス」が再開され、「実行中」一覧に再び現れる。

これと、現在の最新の構造概要を見比べてみます。

時計ウィジェットの構造概要

この構造なら、ウィジェット終了時に「終了フラグ」が ON になっているのだから、時刻変更の通知が来ても「描画サービス」が再開されることは無いはずです。実際に今まで何度も手動で時刻を変更し、決して復活しないことを確認してきています。

ところがこれでも一部の端末では、描画サービスが再開され、プロセスが復活することがあるのです。

まだどこかに別の復活ルートがあるようです…。

 

5-2: クリア

改めてソースファイルを見なおしましたが、可能性としてはもう、

『時間が経過すると、キャッシュしたプロセスは、中身がクリア(初期化)されてしまうことがある』

というくらいしか考えられませんでした。

つまり、「終了フラグ」がいつのまにか OFF になり、その状態で時刻変更の通知が来れば、プロセスは復活してしまいそうです。

問題はこの「クリアされる」現象の正体です。これがわからないと、対策しようが無さそうです。

そして、あれこれと調べて、気になる点見つけました。

 

5-3: 残骸

Android OS は、システムの空きメモリーが不足すると、「キャッシュしたプロセス」を自動的に解放していきます。解放されたプロセスは、システム設定の「アプリケーション」-「実行中」にある「キャッシュしたプロセス」一覧からも消えます。

しかし、もしもこの時、

『解放されたプロセスは、変数などの中身がクリアされるものの、実行プロセス自体はまだメモリー上のどこかに残っている』

としたら…?

そしてその「残骸」にも通知が届き、反応するとしたら…?

 

5-4: 不可視

「いやいや、いくらなんでもそんな都合の良い話は無いだろう。」

そう思いますよね。

なにしろ、OS がプロセスを「解放した」はずなのに、まだメモリー上の見えないどこかに残っているだなんて。

でも、試す方法はあります。

「キャッシュしたプロセス」一覧でアプリの詳細を開くと、「停止」というボタンがあります。これを押すと、OS が行うのと同様に、そのプロセスは解放され、一覧から消えます。この、不可視になった状態で、時刻変更の通知を送ってみればいいのです。

「ここまで来たらもう、何でも試してみよう…」

 

PID;6 虚空

6-1: 消滅

まず改めて、「終了フラグ」の効果を確認してみます。

ウィジェットを終了させ、「キャッシュしたプロセス」一覧に名前がある状態で、端末の時刻を変更してみます。

「復活…しない。よしOKだ。」

「終了フラグ」の効果が想定通りに現れています。

では次に、「キャッシュしたプロセス」一覧からアプリの詳細を開き、「停止」ボタンを押します。アプリ名が一覧から消えます。
完全に消滅したようにしか思えないのですが、本当にこの状態からでも復活するのでしょうか…?

 

6-2: 蘇生

端末の時刻を変更し「実行中」一覧を見ると…

「…あ、アプリ名がある! 復活している!」

なんと…。

「キャッシュしたプロセス」は、解放しても、中身がクリアされたプロセスの残骸がまだ、見えないどこかに存在し続けていたのです。

そして、時刻変更の通知はこの「残骸」にも届いており、それがきっかけで「蘇生」していたのです!

 

6-3: 不死鳥

これが、「終了フラグ」で対策しても復活してしまうことがある現象の正体のようです。

端末を使い続け、他のアプリにより端末の空きメモリーが減ってくると、OS によってキャッシュのプロセスが自動的に解放されていきます。しかし解放されたプロセスは、中身がクリアされ停止してもなお、まだメモリー上で眠り続けており、通知を受けて復活もするのです。

「こいつは…不死鳥!?」

 

しかし、ようやくこれで、次の対策手段が見えてきました。

 

PID;7 封印

7-1: 阻止

キャッシュしたプロセスは、解放された後も、中身がクリアされた状態でまだメモリー上に残っているらしいことがわかりました。
この残骸に OS から時刻変更の通知が来ても、「終了フラグ」は OFF なので正しく機能せず、プロセスは復活してしまいます。

ならば、「まだクリアされていない状態」かどうかを判別できれば、時刻の変更通知を適切に無視することで、残骸からの復活を阻止できそうです。

そこで、「終了フラグ」と同様に、メンバー変数として「起動フラグ」を追加する方法を考えました。このフラグを、初期状態では OFF にしておき、「起動処理」の中で ON にすれば、クリアされているかどうかを区別できるはずです。

 

7-2: 再戦

こうして、「起動」と「終了」、両方の出入り口にフラグを立てることになりました。

アプリが起動する前、または終了後に OS により解放された状態では、いずれのフラグも OFF になっています。
そして、「起動フラグ」が OFF、または「終了フラグ」が ON のときは、「起動中ではない(アプリ終了後である)」と判断し、時刻変更の通知が来ても無視すれば良いはずです。

二つのフラグを反映した構造概要は下記のようになりました。

時計ウィジェットの構造概要

アプリが起動し「起動処理」が正常に実行されたときのみ、「起動フラグ」は ON になります。
アプリが終了し「終了処理」が正常に実行されたときのみ、「終了フラグ」は ON になります。

この対策で、謎の不死鳥プロセスとの再戦に挑みます!

※ここでは、「起動フラグ」と「終了フラグ」を別々に用意していますが、実際には他の同様の方法でも可能なはずです。

 

5-3: 完璧

まず、ウィジェットを一旦起動し、終了します。

「キャッシュしたプロセス」にアプリ名が現れるので、詳細を開いて「停止」。一覧から名前が消えたことを確認します。

そして、端末の時刻設定を変更し、「実行中」一覧を開くと…。

「現れ…ない! 復活しないぞ!!」

 

直後に「キャッシュしたプロセス」一覧を開くと、そこにはこのウィジェットの名前が再び現れていました。
つまり、時刻変更の通知により起こされたプロセスが、二つのフラグの判定処理により復活を阻止され、そのままキャッシュへ移されてしまったというわけです。

今度こそきっと、完璧です!

 

5-4: 終焉

二本のフラグによる対策を施したウィジェットを、10台以上のテスト用端末にインストールし、何度も動作確認を行いました。そして、ウィジェットを終了してから何日も何日も、監視を続けました。

しかしもう二度と、復活現象が発生することはありませんでした。

更に、ある程度の時間が経過すると、端末の時刻を変更しても「キャッシュしたプロセス」にすら現れなくなることも確認できました。
見えないどこかに眠っているプロセスも、いずれはOSに本当に削除され、跡形もなく消滅してしまうのでしょう。

 

今度こそ「封印」に成功したのです!

長い戦いの日々が、ようやく終焉を迎えました。

第二第三の不死鳥プロセスが現れぬことを願いつつ…。

~ 完 ~

まとめ

まとめ-1: 同様の現象

今回は、「ウィジェット」に対する「時刻変更の通知」がきっかけで、アプリ終了後にプロセスが復活する現象が発生しました。
しかし、これは一例に過ぎません。ウィジェットではない通常のアプリでも、または他の種類の通知であっても、同様の現象が発生する可能性があります。

例えば、Intent を sendBroadcast() で投げて連携する2つのアプリがあったとします。
この場合、Intent の受け取り側アプリが終了していたとしても、投げたIntent が、メモリー上にまだ残っているプロセスに届いてしまう場合があります。

もしも受け取り側アプリが、Intent を受け取ることでサービスを開始するような作りになっていた場合、プロセスは復活してしまうわけです。

「受け取り側アプリが終了していれば無視されるだけだろう」と思って余計な Intent を投げたりしないよう、注意してください。
特に、OS からの通知に反応するようなアプリの場合は、単独アプリであっても発生します。今回紹介したような何らかの対策が必要だろうと思います。

 

まとめ-2: プロセスの状態推移

今回の件に関連し、Android OS のプロセスの状態推移について、参考になる解説文書があるので紹介します。

Processes and Threads
http://developer.android.com/intl/ja/guide/components/processes-and-threads.html

(日本語訳)
https://sites.google.com/a/techdoctranslator.com/jp/android/guide/processes-and-threads

この「プロセス」の章を見ると、プロセスが5つの状態に分類されていることがわかります。

今回の件と絡めて簡単にまとめると、こんな感じです。

Android OSは、システムの空きメモリー量が不足すると、優先度の低いプロセスから順に停止・解放し、空きメモリーを確保する。優先度の高い順に書くと下記のように分類される。

1.Foreground process
ユーザーが画面で現在操作しているプロセス。

2.Visible process
操作はしていないが画面に見えているプロセス。

3.Service process
見えていないが、Service を実行することでバックグラウンドで動き続けているプロセス。たとえば音楽再生やファイルダウンロードなど。
システム設定の「アプリケーション」-「実行中」一覧に表示されるのは、このような Service を実行しているアプリの名前。

4.Background process
画面に見えず、かつ Service も実行されていないプロセス。
他アプリに切り替えられ裏に回ったアプリ(ブラウザやメーラーなど)や、終了したウィジェットなど。
「キャッシュしたプロセス」一覧は、この Background process を表示している。

画面から見えなくなったときの状態(変数や確保したメモリーなど)を保持しているため、再度実行された時に素早く起動し、直前の状態を復元する。

5.Empty process
Background process (キャッシュしたプロセス)がOS によって解放させられたもの。
空きメモリーを確保するため、確保したメモリーなどがすべて解放(クリア)され停止している、「空の」プロセス。

アプリの再実行を少しでも早くするためにメモリー上に残っているが、システムの空きメモリーが不足すると OSにより最優先で削除される。

今回の件は、この 4 と 5 の状態にあるプロセスに対し、端末の時刻変更の通知が送られたことで、ウィジェットの描画サービスが再び動き始め、3 の状態に推移したというわけです。

また、Empty process は最優先で削除されていくので、時刻変更の通知が届く前に完全に消滅している場合もあります。当然ですが、この場合にはもう復活しません。

 

まとめ-3: 覚えておいてください

ところで、Background process や Empty process にも端末の時刻変更などの「通知」が届くことや、それがきっかけで Service が再開される可能性については、ほとんど紹介されていないようです。

わかってしまえば、どのような状態のプロセスであっても、OS から「起動しろ」という「通知」を受け取れるようになっているのだから、当然かと言えば当然です。

しかし、完全に消滅したように見えるプロセスに対し、再起動とは全く無関係であろう通知でも届くということには、実際に遭遇してみないとなかなか気付きにくいのではないでしょうか。

しっかり対策をしていないと、終了したはずのプロセスがいつのまにか「実行中」に復活し、CPUタイムやバッテリーを消費し続けるという非常に困ったことにもなりかねません。

是非、Background process と Empty process について、覚えておいてください。

[おわり]

» 「前編」から読んでみたい方はこちらから。

ニコニコ自作ゲームフェス3

OPTPiX imesta Update:PNGが更に小さく! テクスチャの事前チェック機能追加!

$
0
0

いよいよ2013年もあとわずか! ・・・って、30過ぎてから時間が進むのがやったら早く感じるセールス&コミュニケーション部の浅井です。来年40なんですけれども、この調子だと更に加速度が増すんでしょうか。プッチ神父のスタンドみたく。

さておき、この年の瀬に弊社の画像最適化ツール『OPTPiX imesta 7 for Mobile & Social』のちょっと大きめのマイナーアップデート(Ver.7.55)がリリースされました。 そこで今回は、その「ちょっと大きめ」な見所を2つほどご紹介いたします。

まず、スマートフォンアプリ、特にWebView型のアプリで定番の画像形式PNGについて。このPNG形式の圧縮率が、更に向上しました。

新しくなったPNG保存オプション

新しくなったPNG保存オプション

今回のアップデートでは、従来から搭載されていた『PNG オプティマイザー』を分割、更に改良ロジックを追加することで、最大で10%程度もPNGのファイルサイズが小さくなりました。 インデックスカラーに減色したPNGにはもちろん、24bitのPNGに対しても効果的な機能です。

PNG保存結果の比較

PNG保存結果の比較

左から、通常のインデックスカラーPNG(212KB)、中央が旧バージョンの「PNG オプティマイザー」(210KB)、右が今回リリースした新しいロジックでの実行結果(198KB)です。画像のタイプや解像度によりその効果は異なりますが、WebView型のアプリではアクセス量の軽減に、もちろんネイティブアプリではクライアントのデータ量の削減につながります。

 

続きまして、ネイティブアプリケーション用テクスチャ形式、PVRTCやETCへの変換時に便利な機能、『縦横サイズチェッカー』を。

縦横サイズチェッカーのメニュー

縦横サイズチェッカーのメニュー

PVRTCやETCなどのテクスチャ形式は、GPUの支援を受けることができる反面、その解像度に様々な「制約」があります。うっかりその制約を忘れて画像を作りこんでしまい、後で泣く泣く修正、というご経験が有る方もいらっしゃるんじゃないでしょうか。

縦横サイズチェッカーの実行結果

縦横サイズチェッカーの実行結果

この「縦横サイズチェッカー」は、指定のフォルダにある画像ファイルに対して、その制約に合致しているかどうかを一括診断。テクスチャの圧縮保存「前」に実行することで、事故を未然に防ぐ事ができます。

またこの他にも、PVR形式の保存機能が話題の「Unity4.3」の仕様変更に対応するなど、スマートフォンアプリ開発環境の日進月歩に歩調を合わせた機能強化になっています。既に「OPTPiX imesta 7 for Mobile & Socialをご利用のユーザーには、そのまま「Web Technology Update」から。まだお使いでない皆様は、早速以下から製品トライアルをお試し下さい!

» OPTPiX imesta 7 for Mobile & Social 製品ページ

あけましておめでとうございます

$
0
0

謹賀新年 2014

新年明けましておめでとうございます。本年もどうぞよろしくお願いいたします。

ウェブテクノロジではこの数年間、ソリューション(提案型受託)開発部門を強化してきました。ツール開発部門とのシナジーを目指し、今年、その成果が結実します。
アプリ開発・組み込み開発・放送分野(Hybridcast)共通のニーズを集約した、デザイナーと開発者の橋渡しをするツールで、今春のリリースを目指しています。

また、弊社の看板娘「コミPo!」は先日3周年を迎え、これまで製品を支えてくださった方々から、たくさんのお祝いメッセージをいただくことができました。

この感動を忘れずに、わたしたちウェブテクノロジはこれからも、

クリエイターの悩みや希望を積極的に察し
将来に渡って価値を提供することを通じ
社会に貢献します

株式会社ウェブテクノロジ
株式会社ウェブテクノロジ・コム
代表取締役 小高 輝真

テクスチャ圧縮フォーマットPVRTCのTips CEDEC2013復習編(2)

$
0
0

ウェブテクノロジ R&D部の上田です。

今回は前回に引き続いて、CEDEC2013の公募セッションから、テクスチャ圧縮フォーマットのPVRTCに関するTipsをピックアップしてご紹介したいと思います。

なお、CEDEC2013公募セッションの全スライド資料は、下記からダウンロードできますので、本記事で興味を持たれた方は、ぜひそちらもご覧ください。

 

PVRTCのTips

1.1 UIパーツ圧縮時の劣化対策

PVRTCのTips一つ目は、UIパーツをPVRTC圧縮した時に発生する劣化の対処法です。

cedec2013_pvrtc01_lanc_per50上の図のように、UIパーツのような画像サイズが小さくて色のクッキリしている画像をPVRTC圧縮すると、色がにじむように劣化してしまうことが多いです。

このような場合、劣化を回避する一つの方法として、文字・輪郭・背景などをそれぞれ別パーツにして圧縮し、表示する時に合成する、というものがあります。

cedec2013_pvrtc02_lanc_per50このように、文字・輪郭・背景とそれぞれを別パーツにしてから圧縮し、表示する時に重ねて表示するようにします。

cedec2013_pvrtc03_lanc_per50こうすることで、UIパーツを直接圧縮するよりも、綺麗な表示を実現することができます。ただし、画像を別パーツに分割することで、全体のファイルサイズの増加や表示する時のリソース使用量が増加してしまう、といった副作用もあります。

1.2 テクスチャアトラス作成時の注意点

二番目のTipsは、テクスチャアトラス作成時の注意点です。

下の図はカラーバーをPVRTC圧縮したものですが、接触していないカラーブロックの間で色が干渉してしまっています。(カラーブロック間の薄緑部分は透過色部分です)

cedec2013_pvrtc04_lanc_per50このように、PVRTC圧縮ではパーツが接触していなくても、色が干渉して劣化してしまうことがあります。

このような劣化が発生した場合には、単純にパーツ間のマージンを増やすことで解決できます。

cedec2013_pvrtc05_lanc_per50マージンを倍にすることで、色の干渉による劣化を防ぐことができました。

実際のところ、テクスチャアトラスをPVRTCで圧縮する場合、各パーツ間のマージンは8ピクセル程度は作っておく方が良い結果が出る傾向にあります。

1.3 アルファグラデーション対策

PVRTCでアルファグラデーション画像を圧縮すると、アルファチャンネル部分が劣化していることが多いです。

cedec2013_pvrtc06_lanc_per50上の図では、オリジナル画像に比べてアルファグラデーションがもやもやとした雲のように劣化しています。

この原因としては、PVRTCはアルファチャンネルの扱いが苦手、ということがあります。

cedec2013_pvrtc07_lanc_per50上の図は、PVRTC4bppモードで4×4ピクセルに割り当てられるビット数を、アルファ有りの場合とアルファ無しの場合で比較しています。

PVRTCではアルファがある画像も無い画像も、4×4ピクセルに割り当てられるビット数は64ビットで一定になっています。

そのため、同じようにアルファチャンネルを扱うDXTCが、4×4ピクセルあたり64ビットをアルファチャンネルに割り当てるのに対して、PVRTCではアルファチャンネルに割り当てるビット数がすごく少なくなっています。

結果として、PVRTCはアルファチャンネルの扱いが苦手となっているのです。

それならば、アルファグラデーション画像を綺麗に圧縮するにはどうすればいいの?ということなんですが、こんな方法があります。

cedec2013_pvrtc08_lanc_per50つまり、アルファグラデーションは劣化しやすいので、RGBプレーンのみで同じグラデーション表現が使える場合であれば、アルファグラデーションを使わない、という方法です。特定の条件でのみ使える解決法ですが、ちょっとしたテクニックの一つとして覚えておくと良いでしょう。

1.4 PVRTC 2bppモードの特性

Tipsの4つ目は、PVRTC2bppモードの特性についての話です。

例えば次のような例を考えてみましょう。

cedec2013_pvrtc09_lanc_per50PVRTC2bppモードは、PVRTC4bppモードと比べて、圧縮率が2倍になっているので、当然劣化の度合いも大きくなっています。特に上の例のような、色の変化がクッキリしていてファイルサイズの小さい画像は、かなり劣化します。

ところが、PVRTC2bppモードにはその圧縮特性に特徴があって、ちょっとした工夫で少しだけ劣化を抑えることができます。

cedec2013_pvrtc10_lanc_per50上の解説のように、PVRTC2bppモードでは8×4ピクセルあたり64ビットを割り当てて圧縮しているのですが、PVRTC4bppモードに比べて、割り当てられているピクセルが水平方向について2倍になっています。

このため、PVRTC2bppモードは水平方向に劣化しやすいという特性があります。

この特性を先程の「あ」の画像を使って検証してみます。

cedec2013_pvrtc11_lanc_per50このように、縦と横の一方だけを半分にしたものと、両方を半分のサイズにしたものを比べてみます。

cedec2013_pvrtc12_lanc_per50こうしてみると、わずかな違いではあるんですが、縦に半分のサイズにしたものを拡大した場合が、他の2つの場合と比べて劣化が少なくなります。

ちなみに、同じことをPVRTC4bppモードで試してみると、

cedec2013_pvrtc13_lanc_per50分かるほどの違いは出なくなります。

このようにPVRTC2bppモードの特性として、垂直方向に比べて水平方向に劣化しやすいということがあるので、特に水平方向にダウンサイジングする時には注意する必要があります。

1.5 Clear PVRTCを使ってみよう!

最後に、CEDEC2013では公募セッションだった関係上、あまり触れることができなかった弊社の「Clear PVRTC」についてご紹介しましょう。

弊社製品 OPTPiX imésta 7 for Mobile & Social に付属している機能「Clear PVRTC」を利用すると、標準ツールでPVRTC圧縮した時には、こんなに汚くなってしまう画像も、

pvr_sample_nashipvr_sample_nashi_up

こんなに↓綺麗になります。

pvr_sample_clearpvr_sample_clear_up

※ピンク色の部分は透過色です
※Web掲載用にPNG画像に変換しています

また、

cedec2013_pvrtc14_lanc_per50こんな劣化に対しても、「Clear PVRTC」を使うことで、

cedec2013_pvrtc15_lanc_per50劣化の度合いを抑えることができます。

「Clear PVRTC」は従来のPVRTCと互換性を維持しているので、ファイルサイズや実行時のGPUパフォーマンスはそのままに、画質の向上を実現しています。

また、書き文字やUIパーツといった画像については高い効果を発揮することが多い特性をもっていて、1.1でご紹介したテクニックを組み合わせることで、さらなる画質向上が期待できます。

「Clear PVRTC」ぜひ一度お試しください。
無料トライアルはこちらから。


PVRTCについては、以下の記事でさらに詳細な説明を記載しています。そちらをご覧いただけるとPVRTCに関する知識を更に深めることができると思います。

Viewing all 263 articles
Browse latest View live