CreativeJS と Flash

今日はウェブ上でのエフェクトのお話。
今回ボクが担当しているプロジェクトは期間が短いこともあり、余り凝ったことがやれない。とはいえゲームなので演出は派手に越したことはない。
そこで考えたのが、Adobe Flash で作ったものをそのままウェブ上で再生すること。実は以前にも別のプロジェクトでアバターのアニメーションなんかを Flash でやってたりするので、今回もそれで行こうと思ったのだ。

ん? スマフォで Flash なんて再生できないって?

Adobe Flash CC は作ったアニメーションなんかを HTML5 にコンバートできるのだ。
なのでできあがった HTML5 をあとは再生するだけ……!
って思ったんだけど、HTML5 化されるのはエフェクトやアニメーション部分だけなのね……orz
Flash の中で変数を使ったり、条件分岐したりしてるんだけど、それらは全部無視されるみたい。
で、結局どうしたかというと、その部分は Javascript で書いた。

Flash でコンバートされた HTML5 は CreativeJS というのが使われていて、この CreativeJS というのは元 Flash のプログラマが作ったようだ。なので、Flash で利用される様々なエフェクトは CreativeJS の中に関数として用意してあって、ほぼ同じように再現できるらしい。

まだ完全にファイルの構成を理解出来たわけではないのだけど、一応、Flash から HTML5 にコンバートされた Javascript を色々と制御できるようにはなった。
写真は今日食べたもの。かくやという立ち食いソバ屋。けっこう気に入っている。

1412090757 1412090758 1412090760 1412090762

奏(sou

浅草橋にある大食い系の店を、もう一つご紹介。
』というイタリアン バー。
店そのものは大食い系を目指しているわけではない。ただランチタイムは何故かカレーとサラダがお代わり自由なのだ。
どうでもいいけど、バーのことを「バール」って言い始めたの、いつから? 最近よく見かけるようになったけど、正直、解りづらいんだけど(ぁ。最近の若い人にはバールって言った方が通じるのかなぁ??
店のシステムはこうだ。店の一角にサラダバーとカレー ルーの鍋と炊飯器が置いてあって、ランチを注文すると、そこから好きにとっていってイイというわけだ。ランチのメニューはパスタやグリル料理など。
パスタを頼むと炭水化物祭りになってしまう。

冒頭で大食い系の店ではないと言ったのは、店の雰囲気もオシャレ方向だし、女性客が多い。そして炊飯器の大きさが小さい。なのでバカバカお代わりされることは前提としてないのである。
なのでボクのような客が来ると迷惑であろう(ぁ
現にご飯の供給が追いつかなくなってしまった(^^;

味の方はカレーはまろやかで食べやすい。パスタはなかなか腰のあるパスタで、味も濃くなくて、つるっと行けてしまった。夜、イタリアンをちゃんと食べに来たくなるお店。

1412090750 1412090752 1412090754

レスポンシブ デザインのめんどくささ

今回はレスポンシブ ウェブ デザインの話。レスポンシブ ウェブ デザインって何かっていうと、一つのデザインですべてのプラットフォームとブラウザに対応することである。つまり PC でアクセスしてもスマフォでアクセスしても、同じデザインで出力される……というわけではなくて、一つのデザインしか定義してないんだけどそれで PC でもスマフォでもちゃんと表示されることである。

今やっているスマフォのゲームも最初、レスポンシブ デザインで作っていた。
このレスポンシブ デザインの肝は簡単に言ってしまえば%で作ると言うことである(ぁ
どういうことかというと、例えば 2 段組をするとき、全体幅が 1024 ドット、左側がメイン コンテンツで 640 ドット、右側がメニューとかで 384 ドットにしよう……ってのが今までの作り方。
レスポンシブ ウェブの場合は、全体幅は 100% で作り、本文左側は 62.5%、メニューとかの右側は 37.5% にしようってこと。そうすればどんな機器だろうが割合で区切られるので、それらの機器に従った大きさになる。
これはレイアウトだけでなく、画像の大きさに至るまで何もかも%で指定する。

ところが、この作り方には二つの欠点がある。

  • 文字の大きさは変わらない
  • ドット単位の微調整は不可能

ブロック要素や画像などは画面の大きさに従って勝手に変わってくれるのだが、文字の大きさはそれに追随してくれない。なので細かいディスプレイに出しても、荒いディスプレイに出しても同じ大きさ(ドット)で表示されてしまうため、要素の中に表示される文字数が変わってしまい、結局レイアウトが乱れる。
これはディスプレイの画素数と CSS ピクセル比ごとに文字の大きさを定義しておく必要がある。
さらにゲームではインターフェースに凝るため、ドット単位でのボタンやゲージ(メーターやプログレス バー)などの表示が必要となる。ブラウザは小数点第三位くらいまでの%値しか見てくれず、ドット単位での微調整はできない。これの回避方法は、ドット単位で組んだあと、Javascript や CSS の ZOOM を使って最適な大きさに表示するのだが、iOS の Safari などでバグが発生し使えないことが多い。これに関しては、まだボクの中では特に解決策は見いだせていない。
今回はドット単位で調整が必要なところは、合成した画像を変化する種類分作って対応するというわりと原始的な方法で回避した(^^; どういうことかというと、下地があってその上にボタンをドット単位で並べなければいけないような場合、下地とドット単位で並べたボタンを合成してしまい、どのボタンが光っているかというパターン分の画像を用意することによって、ドット単位での調整をしなくて良いようにした。ただこの方法は、パターンが膨大にある場合は使えない……。

まぁ、一番いいのは Javascript の ZOOM である。コイツさえ正常に動いてくれれば、レスポンシブ デザインは一気に楽になる。何故かというと、ドット単位で自由に作れるからだ。従来の作り方のように、例えば全体幅を 1024 ドットとか 640 ドットとかと固定して自由にレイアウトした後に、Javascript で機器のディスプレイの大きさに合わせて拡縮するようにすれば楽ちんなのである(爆。

他にも Table を使うのが難しかったり、横幅を必要とするモノがどうしてもスマフォなどだレイアウトが崩れてしまったりなど、一つのデザインで様々な機器に対応するのは一筋縄では行かない。TAMA Networks も燃費なんかの表の部分や、説明付きの画像の場合はスマフォで見ると崩れてしまう。
この辺、何とかしたいなぁと思いつつ……。
写真はこの日食べたもの。バーガーキングのブルーベリーのハンバーガーと、秋葉原の万豚記。

1412080730 1412080731 1412080737 1412080740 1412080741 1412080747

平和島 P.A.

今日は弟一家を羽田に送りに行ってきた。
その羽田から会社に向かっていたら、平和島 P.A. の看板を見付けた。そういえば首都高のサービスエリアやパーキングエリアに入ったことないなぁと思い、ちょうど、朝食も摂っていなかったので寄ってみることにした。

想像したものより立派なパーキングだった。

ただやはり狭い(^^;

ところでサービルエリアやパーキングエリアの定番メニューと言えば、ボクはカツカレーである。特に食べたいものがない場合は、だいたいカツカレーを頼む。と言うわけでここでもカツカレーを注文。
なんかぬめっとしたルーに、味のぼやけたカツであった。
まずい!
まぁ、そんなもんか(ぉ

売り場の方は思ったよりお土産とか充実していて、面白かった。
下町のお土産が多い。とりあえず飴を買って帰った。

首都高のパーキングエリア巡りってのも、面白そうだなぁ。
わりとすぐにできそう。

1412070720 1412070725 1412070726 1412070722 1412070723

Webkit オンリーで組んでも……

スマフォの開発を相変わらずしているんだけど、今回の案件は別に PC で動作する必要はない。で、スマフォというと iOSAndroid が主流で、他のプラットフォームに関しては、ほぼ無視して良い(ゲームの場合の話ね)。となると、ボクが思ったのは「じゃぁ、Webkit に対応して作ればいっか」であった。
iOS に搭載されている Safari も、Android の Chrome も Webkit というレンダリング エンジンで作られているからだ(Chrome は Webkit からさらにフォークして Blink となった)。

ところが、けっこう iOS と Android で表示が違うんですな。
更に困ったのが Android の標準ブラウザ。
実は Android に最初からついてくるブラウザというのは Google Chrome ではない。なんでなのかというと、これはボクの予想でしかないのだが、Android デビューに Chrome は間に合わなかったからだと思われる。ちなみにエンジンは Webkit である。
Android 版の Chrome は Android のバージョンが 2.3 だか 2.4 だかくらいにようやくデビューした。なので Android には「標準ブラウザ」という、別のブラウザがずっとついてきている(Android 4.4 でようやく標準ブラウザが Chrome となった)。

この標準ブラウザがとにかくタコい。
まず Javascript の実行速度が圧倒的に遅い。そして HTML5 からついた修飾(ぼかしや縁取り、グラデーション)などの再現率が低い。特にぼかしがおかしい。

次に Safari。コイツのフォント処理はおかしい。とにかく文字の大きさが合わない。
なんだこれー!?
しかもバグがあって、Javascript で拡縮をやると正しい大きさにならないという……orz(CSS でも ZOOM を使うと同じ症状が出るらしい)
これが実に問題で、先の記事の CSS ピクセル問題で、CSS を書き直しせず、Javascript で最適な大きさに拡縮するという風に逃げたのだが、この Safari のバグのおかげで結局この方法は使えなくなってしまい、CSS を全面書き直さなければならなくなった。

だ、ダメすぎる……orz

だが今回、「ブラウザの場合分けはしない」というポリシーで組んでいる。これは別にボクの勝手なポリシーなんだけど。場合分けってのは何かっていうと、Safari だとこっちの処理、Chrome だとこっちの処理というようにブラウザことに処理をわけることだ。
CSS / HTML は一種類の定義ですべてのブラウザで通用するように書いた。まぁ、なんだかんだ言ってもレンダリング エンジンが一つだったというのが大きいだろう。これが PC だとこうは行かなかったと思う。

被害低減ブレーキかぁ……

Google をはじめ、自動運転の実地実験が色々な所で始まりつつある。いつか自動車は、人が運転しなくても良くなるのだろうと何となく思っている。そして人が運転してはならないものになる可能性も……。ただそれは、ボクが 70 歳を過ぎてからにして欲しいと何となく願っているけれど。
なぜならボクは運転が大好きだからだ。

まぁでも、各メーカーの自動ブレーキの動画を見つけたので張ってみる。スバルでもダメな車種があるんだなぁ。ただこの動画の車はどれもぶつかりそうだというのは、警告音で教えてくれるようだ。
ボクには不要の機能だけどね。次、車を買い換えるときもこの機能のない車を選ぶと思われる。

どごーん!

[youtube id=”apAZOLgw3zU”]

念願の『癒空間』へ…!

TAMA Networks では何度も登場している博多水炊きのお店「いたや」。高校時代からの友人が教えてくれたお店で、非常にボクも気に入っているお店だ。しかし、立地が悪かったのか店を畳んでしまった。
その店主が大泉学園でお店を新しく始めたのは、聞いていた。
なかなか行けなくて(大泉学園に行く用事があんまりなかった)、前回の時は満席で行けず……今日、ようやく行くことができた……!

名前は『癒空間』(食べログ)。たぶん「いくうかん」って読むんだと思う。

結果、ほとんど変わってなかった!!
嬉しい~~。
具もほとんど同じ。〆のソーキ蕎麦も一緒。
一品料理は鮮魚系が減って、煮物・焼き物が多くなった気がする。
お酒は……詳しくないから、解らない(汗)。

でも、この脂分がまったくない鳥のスープがなんと言っても、美味しい。お塩だけでも充分美味しいし、ポン酢をこのスープで割っても美味しいし……あの味が二度と食べられないかもと思っていたので、満足でした。

1412040668 1412040672 1412040675 1412040677 1412040680 1412040681 1412040687 1412040690 1412040693