オリンピックのボランティア募集が盛り上がってますな！

というわけで、私も応募に挑戦です！

「Webデザインでやっちゃいけないことを全部やってる」
って言われたら、やらないわけいはいけないでしょ。
BAD UI、気になりますよねー。

ってことでサクッと行ってみましょう。
忘れるといけないので、入力しながら、リアルタイムでこっちに気づいた点を記載するぜ。

まず皆に言われているが、応募したら英語ページに行くという罠。
右上に切り替えボタンがあるってことだったが、国旗マークがあるだけだった。
切り替えかどうかすら説明がなく、自分で気づけだったとは。

次。ログインアカウント。
Facebook等のアカウントを要求するのはレベルが高いということだったが、
アカウントがなくても、新規登録画面はあった。
なので問題なし。

しかし。ここからは問題！
まず、そもそも。
ボランティアの応募のはずなのに、「マイページ開設」にすり替わってる罠。
なんや、マイページて。
さらにここに来る前に、６ページ分の入力があるって注意書きがあるが、
なんで「プライバシーポリシーへの同意」が最後やねん！
それ最初に確認させる奴や。
入力し終わった後に、同意できない内容だったらどうするんだっての。

とかいいつつ、マイページ新規登録の入力ページを開くと。
６つのテキストフォームがあるのだが、
　パスワード*
という風に全部に * マークがついている。
このマークの説明一切なし。
また、説明の補足のためか、i マークがついているのだが、
パスワードの項目についた iマークをクリックしてみると…。

「９文字以上、半角英小文字、半角英大文字、半角数字を含む」という説明が。
いや、それずっと出しておけや。
わざわざクリックしないと読めないってダメやろ。

いくつかワザと間違って登録ボタンを押してみたが、どこが間違っているのか、
明確に指摘してないとか、もう全然ダメ。
（大文字で入力してくださいだけ言われてもな！）

次に表示されたのは、個人情報保護方針。
大体テンプレのような内容だが…。第三者から本人の個人情報を取得する場合があるという。
まあ、facebookなどから情報を得る、等の想定だろうが…。
「銀行口座、宿泊先、予定」
うーん、何気に変な項目も交じってるぞ。
つか、他の団体から情報を得る場合、まずは本人（私）が、そっちにOK出す必要があるんじゃないのか？
このポリシーはボランティア専用ではなく、オリンピック全般のもののようなので、チケット・グッズ販売とか、広告表示用とかでも表示されるものと共有だから、まあ、こういう書き方になるんだろう。

ネットでは、情報漏洩までが１セットって言われてるし、この保護方針は念のため保存しておこう。

というわけで、テンプレのある文章はそこまでズレてはいないが、
Webデザインは、ちょっとダメなレベル。
まだアカウント登録しかやってないが、それでも疲れたんで、次回へ続く。

cocos2d-xを始めてみる。

HSPでプログラム作っていたんだが、ちょっと浮気して、
別の言語を試してみようと思い立つ。

Windowsでゲームが作れるものといえば、Unityとか思いつくが、
ライセンスであったり、ロゴ表示の問題もあるので、
フリーで使用できるという観点で、cocos2d-xに決定。

スマホアプリを作るイメージがあるが、当然、Windows用も作れる。
導入から解説しているページを見て、サクッと作るぜ！

…。
…。

と思い立ってから、サンプルを実行するまで、５時間もかかったわ！！

VisualStudioはインストールしていたものの、C++での開発環境入れてないとか、
他にもcocosをビルドするのに足りないパッケージがあるとか、
導入について解説している内容では全然足りないって！

という過程を経て、ビルド環境と実行環境を得る。
３０分でサンプルが動くHSPとはえらい違いだ。

まあ、その分、C++（っぽいもの）で開発できる、実行速度が速い、というメリットはあるが…。

そもそも、AndroidやiOSで動くものも作れるという時点で、
素のC++ではなく、覚える作法（APIとか）はいっぱいあるわけで、
その点については、HSPから乗り換えるメリットは薄い。

逆に、ゲームを作るのに覚える量は変わらないので、乗り換えによるデメリットもないとも言える。
とりあえず１週間ほど触ってみて、無理ゲーだったら、HSPでがんばろう。

HSPを少しずつ進める。

何事も放置すると、忘れたり、鈍ったりするわけで。
少しずつでもHSPのプロジェクトを完成に近づけなければ。

そもそも、何を作るかすら決まっていないけどな！

さて、今日の目標は、１０年前には無かった（はず）module機能についてだ。
追記：過去のソースコードに、#module が記述されていた。ただ、それだけで、modfuncなどは使ってなかった模様。

とりあえず、インスタンスを作り、モジュール関数をコールし、
いわゆる、セッターやゲッターの動作も確認できた。

一通りやった(つもり）なので、早速実践。
ゲームには必須である、画面のフェードイン/アウトアウト機能をmoduleで作ってみる。

基本は、過去に deffunc で作ったものをコピペ…する予定だったが、
目に余るコードだったため（笑）、１から作り直す。

とはいえ、ゲームプログラマなら、
簡単なフェードシステムのコード書くのに30分も掛からないはずだ。

というわけで、出来たものを実行っと。

　う　ご　か　な　い　！

いや、そんなはずは。
ちまちまとミスはあったが、そんなレベルではない、何かが違う。

試しに module外のメインループに移すと、きちんとフェードしている。
ということは、moduleが独立空間であるがゆえに、何かしらの障害が発生しているということだ。

さて、なんだろうか？
もしかして、module内では、gsel や gcopy などが使えない？
ありえそうだが、マニュアルには、そういうことは、一切書いてない。
さらに、付属のサンプルでは、思いっきり、moduleの中で、gcopyしてる。

まったくわからん！

が、独立空間という観点で見たときの問題が、もう１つあるじゃないか！

ゲーム作りの鉄則として、後から変更がありそうな部分は、define で一括で変更できるようにする。
Windowsのゲームだと、画面サイズなどが真っ先に定義される。
今回も、
#define screenW = 1280
#define screenH = 720
と定義している。
が、定義している箇所は、当然、#globalだ。

module内の gcopyは、

gcopy 1,0,0,screenW,screenH
になっている。

全くエラーは出てないが、これが悪いんじゃね？
というわけで、変更。

gcopy 1,0,0,screenW@,screenH@

ビンゴ！うまく表示されたわ。
うーむ、module内で全く定義せずに使用している変数は、
エラーを出さず、0として使われてるようだな。

マニュアルでは、module内から globalを参照するのは推奨しないとされている。
スクリーンのサイズを取得する変数や関数があるだろうか？

…あった。

画面の描画エリアXサイズ
ginfo_winx
画面の描画エリアYサイズ
ginfo_winy

定数をこちらに置き換えて、動作することを確認。
ま、なければ、セッターで画面サイズ渡せば良いだけか。

こういうのが、やってて面白いところだな。

追記：
#define の後に、global をつけることで、全module対象になるんだと！

#define global screenW 1280

これが正解の書き方ということだな。

再びHSPを始めたんだが。

過去に、HSPを使って商品を２つ作ってリリースしたことがある。
2006年頃、もう１０年以上前だから、HSP1.0だろうか？
もっともメインじゃなくて付録的な位置づけの作品だったが。

一応そのソースを持ってきたが、現在の HSP3.5では、互換性が無かった。
当たり前だが。

まあ、色々便利になっているし、サンプルやドキュメントが格段に整備されているので、過去に触れていたということもあるが、１０分程度で画面は表示できた。

module 辺りを中心にいじってみる。
うまく使えば、オブジェクトっぽいものが表現できると思われるが…。

module内に作成した関数、modfunc にアクセスする方法が
module関連のドキュメントで全く触れられてないのが残念すぎる。

モジュール変数とかコンストラクタとか、
だいたい一定のルールの記述方法なのだが、なぜモジュール関数(modfunc)だけ、

val = funcname(modVal)

という方式にしたんだ…。
ルールに従ったら、

val = funcname@modVal
val = funcname modVal

辺りが妥当なところじゃないか？
せっかく module関連をまとめたドキュメントが用意されてるのに、
これ説明しないでどうするよ…。

結局、moduleのサンプルコード見て探し出したが、
初見殺し過ぎる…。