2013年2月9日土曜日

DXライブラリとLuaを使ってスクリプト側で画像をロード

内容はタイトルの通り。
ソースコードは こちら 。
Lua向けに専用のLoadGraph関数を用意してやり、それをlua_Stateに渡し、
lua_State側からその関数を呼び出して画像をロードするプログラム。

コードの説明はプログラム内のコメントと、コメントに書いてあるリンク先の参考文献を参照のこと。

記事内では、プロジェクトの設定について説明する。
まず、 DXライブラリ置き場 使い方説明 に従って、DXライブラリが動くプロジェクトを作成する。
DXライブラリがうまく動いたら、 その1 Luaのインストール に従って、Luaのセットアップをする。
リンク先では、コンソールアプリケーション向けの設定についての記述なので、Win32アプリケーションで行う設定を以下に列挙する。

  1. 追加のインクルードディレクトリにluaフォルダ内のincludeフォルダへのパスを追加
  2. 追加のライブラリディレクトリにluaフォルダへのパスを追加
  3. リンカ->入力->追加の依存ファイルにlua5.1.libを追加
  4. lua5.1.dllをプロジェクトフォルダの直下にコピー
以上である。

主要な参考文献

2013年1月3日木曜日

マルチデバイスとその逆


MacBookが主流のモバイル時代、かつてApple社の救世主となったiMacを使う意味はなんだろう?!

 この記事を最近読んで思った事をつらつらと書くなど。
私も、最近この記事に書いてあることと同じ事を常々感じている。CPUは大分前から言わずもがな、最近はIntelのチップセット内蔵グラフィックスでも最低限必要十分なスペックを提供してくれる。きちんとした(あるいは内部のアーキテクチャはモバイル向けアーキテクチャでも良い)デスクトップPCの必要性を感じるのは、精々ゲームをする時や、動画のエンコードをする時くらいで、日常的な用途、ウェブブラウジングやメール、軽いゲームくらいならCore iプロセッサの最低レベルで十分こなせる。
 Windows RTがARMタブレットで動くこと等からも、Atomに代表される省電力X86アーキテクチャと、ハイエンドなARMアーキテクチャが極めて近づいてきている事がわかる。そう遠くない内に今のX86程のパフォーマンスでARM並に省電力な高効率なアーキテクチャが実現することは疑う余地が無いように思う。
 スマートフォンとPCで同じGmailにアクセスしたりするように、複数のデバイスで同じデータにシームレスにアクセスする仕組みは整いつつある。ハードウェアも同じように、タブレットコンピュータを家に持ち帰り、大きめのディスプレイやキーボードと無線でシームレスに接続して自然体で使えたりするような、複数のデバイスをシームレスに扱える時代が来るといいなぁ。

2012年12月8日土曜日

Surfaceが目指す方向性とアーキテクチャ

次期Surface ProにあたるSurface Pro 2がAMDのアーキテクチャを採用すると噂だ。これがもし本当なら何を意味するのか。

まず、Windows 8タブレットの現状について。

IntelのClover Trail世代のAtomアーキテクチャを採用するWindows 8タブレットが多数見られる一方で、
AMDのHondo世代Z-60アーキテクチャを採用するものはまだ殆ど見られない。富士通の10.1型タブレット「STYLISTIC Q572/F」はZ-60を採用しているが、法人向けであり個人ユーザ間での認知度は極めて低い。その他も、Z-60を採用する製品で、ユーザ間での認知度の高い物は皆無と言っていいレベルだろう。

次、現行のSurface ProとSurface Pro 2の比較。

Surface ProがIntel Core i5を採用する一方で、その後継であるSurface Pro 2はIntel Atomの対抗馬にあたるZ-60の後継にあたるTemashを採用する、という噂はかなり興味深い。このリーク情報の信頼度は低くもないし高くもないが、これが本当なら、Microsoftは現行のAtomはWindows 8を動かすには力量不足で、Core iプロセッサが必要だが、次の世代ではAtomと同等のランクのアーキテクチャでもマシンパワーが足りる、と考えているということになる。あるいは、Surface 「Pro」なのであるから、採用するアーキテクチャにもある程度のプレミアリティーが必要だと考えていたが、その考えを改めた、とも考えられる。

最後に、Intel Core iアーキテクチャとAMD Temashの比較。

従来のIntelのアーキテクチャとAMDのアーキテクチャを比べると、AMDがAPUを自称する通り、AMDの方が比較的高性能なチップセット内蔵グラフィックスを実現していることも、Surface ProがFullHDのディスプレイを採用していることと併せて考えれば後継機での採用を後押しする要素となる(最近はIntelのチップセット内蔵グラフィックスの性能もあがったが)。つまり、X86互換のアーキテクチャを採用するにあたって、AtomではCPUは問題ないがグラフィックスの処理能力が足りないからCore iアーキテクチャを採用せざるを得なかったが、AMDのアーキテクチャを採用することでこれを解消しようと考えているのではないか、ということだ。現行のSurface Proで、軽快な操作を実現し、要求されるユーザ体験を実現するために、Atomアーキテクチャを採用せずCore iアーキテクチャを採用するという考えは十分に理解できる。
TemashがSurface Pro 2に採用されれば、現行のAtom採用Windows 8タブレットと同等、Windows RTタブレットに迫るバッテリーライフと重量、そして軽快な操作を両立できる可能性は高いと思われる。期待が懸かる。
本記事で私が述べたいことはTemashを採用することの意味と、それに対する期待だが、最後に述べる私の本音はこうだ。
「Surface Proは買い控えして、Pro 2を買おうかな」

参考文献



2012年11月26日月曜日

ブラウザに見る、各モバイルOSのデザイン哲学

 iPad miniの発表の際に、Appleのフィル・シラー氏は「iPad miniの7.9インチディスプレイは、Nexus 7の7インチより35%広く、ウェブ表示面積では最大67%も広い」(若干の意訳を含む)と述べた。個人的には、iPad miniというハードウェアについての発表をしているのに、突然iOSのSafariとAndroidのChromeを比較し始めるのは不自然に感じる(勿論、iOSとiPad miniはセットで一つの製品なので、全くおかしいとは言わないが)。この発言について、ウェブ上では様々な議論が交わされたが、これは両社のデザイン哲学の違いを表しているように思う。
 一番最初にAppleについての話をしたにも関わらず、この記事の主役はWindows 8/RTとAndroidだ。申し訳ない。

 Windows 8/RT(ここではタブレット向けUIの話をする)では、「コンテンツこそが王様」というデザイン哲学が貫かれているように思う。各種メニューは画面外に追いやられ、アプリケーションをスナップしない限り、1つのアプリケーションが画面全体を占有する。ユーザーが画面全体に表示されるコンテンツに対し没入することができるようOSのUIがデザインされている。Internet Explorer 10では画面全体にウェブサイトが表示され、広々とした画面で気持よくブラウズできる。しかし、タブを移動したり、その他各種操作を行う方法に習熟するには、些かの時間を要求される。はっきり言って、直感的に操作できるか?と言われれば答えはNOだ。Windows 8/RTのUIは、分かりやすさという観点ではあまりにもお粗末な出来と言わざるを得ない。

 一方のAndroidはWindows 8/RTとは対照的だ。分かりやすさを優先するため、画面下部には常にソフトキーとしてナビゲーションバーが表示され、各種アプリケーションではユーザが各種メニューに気付くよう、全てのメニューを出来る限り画面内のアクションバーに表示している(勿論、特にコンテンツが重要なギャラリー等のアプリについてはこの限りではない)。
 この仕様に対する私の印象は以前ほどネガティブではなくなった(慣れてしまったとも言う。分かりやすさはアプリによる)が、やはりコンテンツを広く表示したいアプリケーションにおいてはアクションバーもナビゲーションバーもステータスバーも全てを非表示にして、フルスクリーンでコンテンツを楽しみたい。そう、Chrome君、君のことだよ。

 両者は、分かりやすさを優先するかコンテンツを優先するかで対照的なUIデザインとなっている。画面内にUIエレメントを設置すればコンテンツ領域が狭くなり、画面外に追いやれば操作性が下がる。両者は二律背反的だ。

 これに対し、iOSはうまく中間的なアプローチを取っている。iOSのSafariでは、基本的に常に基本的な操作が画面下部に表示されるが、画面内にフロート表示されているフルスクリーンボタンを押すことで、表示を切り替えることができる。この点ではiOSのSafariが頭ひとつ抜けている様に思う。

 コンテンツを広く表示できることは非常に重要だが、その為にUIが分かりにくくなってはいけない。バランスを意識しつつ、自然に操作できるUIを心がけて頂きたいものだ。というかChromeはフルスクリーン表示させてくれ。頼むから。マジで。

Android 4.2でのフォント変更・AA対応

 先日Android 4.2がリリースされた。いくつかのバグを抱えていたりディレクトリ構成の変更による混乱等が起きているが、基本的にはブラッシュアップされており好ましいアップデートであるように思う。
 Android 4.2では4.1で追加されたfallback_fonts-ja.xmlが無くなり、fallback_fonts.xmlに再統合されている。これは実際にfallback_fonts.xmlを見ての予想なのだが、4.1では使用している言語によって使用するfallback_fonts-xx.xmlを変更していたものを、4.2ではfallback_fonts.xml内で言語を指定してフォントを設定するように使用変更したのだろう。
 上記の様なフォントの指定方法の変更の他、4.2ではフォント自体の種類も増えている。4.1がリリースされた際に追加された"sans-serif-light"で指定されるフォントの他に、"sans-serif-thin"で指定されるフォントが追加された。
 AAに対応させるための方法は、前回と同じように、system_fonts.xmlの先頭でシステムフォントを指定し、その次にMS Pゴシックを指定するように変更すれば良い。
 私としては、折角RobotoフォントがAndroidのために開発されたのだから、アルファベットには優先的にRobotoフォントを使いつつ、日本語には任意のフォントを指定したいので、基本的な日本語フォントについてはfallback_fonts.xml内で指定し、system_fonts.xml内ではシステムフォントにRobotoを、MS Pゴシックにtextarを指定している。細字フォントについては、文字のバランスが崩れるのを防ぐために直接日本語フォントを指定している。/system/fonts/ディレクトリに追加しているフォントは以下の通り。

 私が使用している変更済みのxmlはこちら。Rootに対応したファイラを使用して上書きし、パーミッションを644に変更するか、adb pushコマンドを使用してファイルをプッシュし、chmodコマンドでパーミッションを変更すれば良い。ここに書いていない細かい手順は関連記事を読んだりGoogleで検索する等して調べて下さい。


関連記事

2012年10月24日水曜日

iPad mini発表 ブレークスルーはまだ遠い

 以前から私は常々「ノートPCが3lbsを切った時にブレークスルーが起きる」(このブログで言ってはいないかもしれない)と言ってきた(この表現を私はしばしば多用する。思っているだけでアウトプットしていない可能性があるので、そういう場合は後出しになってしまっていている。申し訳ない。)。
 この3lbsと言う重さは、自身の直感に基づいたものだ。必要十分なスペックと普及価格帯という条件を満たした上で、「この重さを切ったら買ってもいい」と思える基準。その基準こそが「3lbs」という重さだ。
 そして、実際にブレークスルーは起きた。2010年末第4世代MacBook Airのリリースだ。それまでにも素晴らしいモバイルラップトップはあったが、20万円前後とかなり高額な物が殆どの高嶺の花だった。AcerのAspire Timelineによる価格破壊に続く形で、MacBook Airはその市場に求められる価値を大きく引き上げた。
 その後に訪れたのが現在のUltrabook旋風だ。AcerのZENBOOKやLenovoのThinkPad X1 Carbonに代表されるUltrabookは現在のラップトップ市場を代表する製品となっている。

 本題に入ろう。iPad miniについてだ。iPad miniの重量は308グラム。iPhone 5やiPod touchの大幅軽量化に続く形で、かなり軽量になった。流石にMedias Tab ULの249グラムには及ばないが、一般的な競合他社の製品と比較するとかなり軽量だ。
 確かに軽い。非常に軽いのだが、残念ながらiPad miniはブレークスルーを起こすには力不足であると思う。この軽さを実現するには仕方なかったのだろうが、スペックは前世代iPhoneであるiPhone 4Sの流用であるし、Retinaディスプレイも搭載しない。勿論これらのマイナス面は既存のApple製品と比較するからそのように思えるだけで、市場全体における立場を考えれば、Nexus 7とSurfaceの中間の価格、中間のディスプレイサイズを備え、重量ではこの中で最も軽量である事を考慮すれば、バランスに優れた製品である事には相違ない。
 しかしながらiPad miniはあくまでiPad「mini」なのだ。iPadという製品の本流ではない。iPadの主役はあくまでもiPadであり、「mini」ではないのである。

 次のブレークスルーは、10型タブレットが1lbs(453グラム)または500グラムを切った時だと思う。今回発表されたiPad Retinaディスプレイはまだその領域には達していない。1lbsの重量、3万円を切る価格、10型ディスプレイを搭載し、必要十分な性能を備えること。それがタブレット市場を次の段階へとシフトさせるための条件だ。

2012年10月18日木曜日

Google Dart対Microsoft TypeScriptという構図の意味

 TechCrunch Japanの記事でも述べられているが、どうやらGoogleはやはりDartに対してかなり本気らしい。それもその筈、GoogleにとってDartが極めて重要なプロダクトであることは疑う余地が無い。それは何故か?

 それはDartがGoogleにとって次代のプラットフォーム戦争における覇権を握るための極めて重要な切り札であるからに他ならない。
 以前から私が常々言っていることではあるが、現在行われているAndroid対iOS(+その他大勢)の構図によるプラットフォーム戦争は、その実体を徐々にウェブ上に移していく筈だ。Facebookはパフォーマンスの問題から同社のアプリケーションにおけるHTML5の利用を中止したが、これはつまり「パフォーマンス(と生産性)の問題さえ解決すればHTML5を採用する」ということに他ならない。実際にはこの他にも、各々のプラットフォーム間での挙動や実装、作法の違いからくる不調和等の細かな問題は山積みであるが、それも徐々に解決していくだろう。ゲーム等の非常にリッチなコンテンツをウェブというプラットフォームで動かすのは当分先になるかも知れないが、そうでないアプリケーションの主流がウェブに移っていくのは時間の問題だ。多くのアナリスト達は現在のようなOSは徐々に息を潜め、プラットフォームの主役はブラウザになると分析する。その次に言うことはこうだ。「今はまだ早い」。

 MicrosoftのTypeScriptやGoogleのDartは、このブラウザ上でのプラットフォーム戦争を担う次代のプラットフォームである、ということだ。現在のHTML5が抱える主な問題、「パフォーマンス」「生産性」「仕様の乱立」の3つを全て解決するために両社が尽力している事は、そのプラットフォームの性質から明らかだ。言語としての機能の充実だけでなく、エディタまで提供している事がそれを裏付けている。
 GoogleがChromeの普及に対して殆ど異常とも言えるほど執着していることも、これを更に裏付けている。現在のChromeブラウザにはまだDart VMが搭載されていないが、Windows、Android、Mac OS、Linuxの全てのChromeに大してDart VMが搭載されれば、Dartは一躍巨大プラットフォームへと変貌する。Chrome以外のブラウザに対してはJavaScriptとして提供すればよいし、Chrome上ではネイティブアプリと見紛う程の速度で動くとなれば、同社のシェアは一気に加速するだろう。更に言えば、優れたVMとエディタが合わされば、Android上でのアプリケーション開発における生産性の低さも同時に解決する。

 とは言え、どのプラットフォームがこの次代のプラットフォーム戦争における勝者となるかはまだまだ未知数だ。先行開発したプラットフォームが結局頓挫するケースは数え上げればきりが無いし、後出しで漁夫の利を狙ったプラットフォームが勝利することもあれば結局先行するプラットフォームに追いつけずに負けるケースもある。今後も各々のプラットフォームの動向を注視していきたい。