このサイトは今まで各主流ブラウザで正しく動くことを優先してましたが、
余裕が出来てきたので、（何故か）HTML 4.01の（何故か）Transitional基準に
ミスコードを書き直しときました。
（ただし、プラグイン系、target属性、divの中が空とかそういう細かいのは無視）

最初は少量直せばすむかなと思っていたのですが、
思いのほか書き直さなければいけない箇所が多く、
いろいろと弄くってしまったので崩れなどもあるかもしれません。

ところで、なぜHTML5やStrictにしなかったかというと、
IEで英数字がくっつき過ぎちゃう問題が回避できなかったのと、
今まで使ってたスペーサ方式（spacer.gifタイプ）が手軽に使えず、
別のスペーサ方式にしないといけなかったため。

くっつきすぎる問題は、letter-spacing:0.17ex;にすれば他のブラウザと同じ感じに
なりますが、今度は日本語の空きが増えるので対策が見つかるまでは保留。

なお、W3C公式のチェックツールはこちら。
【The W3C Markup Validation Service】
【W3C CSS 検証サービス】

ブラウザ専用CSS命令とかでもエラーがでるので、エラーがたくさん出てもめげない方が
いいと思います。
賛否両論ですが、私はブラウザで正しく動作すれば常にエラーゼロを目指さなくても
いいんじゃないかなという緩い考え。
こっちを優先する前に各ブラウザで崩れないようなマークアップをしてほしいかなと。

ちなみに今日（といっても昔からですが）、大手サイトでも上記W3Cのチェックツールで
エラーが無いサイトを探すのは結構大変なレベルだったりします。
昔からこの辺しっかりしているので有名なmsn.com、opera.comとかぐらいかなぁ…。

PSSを触ってみる第5回目。

プログラミングガイドを読むところ、
1フレーム待ちには、垂直同期待ちを行うSwapBuffers関数を使うように書かれている。
PSVitaのリフレッシュレートは60fpsなので、
この関数に到達したとき、自動的に16.666msの周期を待ってくれるということになる。
しかし、「Androidデバイスの中には60fpsでないものもありますので、ご注意ください。」
とも書かれている。

リフレッシュレートの違いはゲームプログラム界隈では常に問題視されるところだが、
Androidは初めから切るつもりなので（要するにVita専用プロジェクトにするつもりなので）、
この辺を気にしなくていいのは非常にありがたい。

今回は関係しないので、フレームレートの解説については割愛してもいいのだけれど、
せっかくなので軽く触れておこうと思う。

このリフレッシュレート問題はゲーム系でコアを触っていると度々問題になるところで、
例えば、リフレッシュレートが120Hz設定のマシンでなんの仕組みも持たない
60fps想定で作った垂直同期ゲームを起動すると、ゲームスピードが2倍になったりする。

その理由で昔から独自で60fpsにするプログラムが組まれることも多い。
他にも、fpsを固定せず前のフレームとの差異でゲームの進行状況を変化させるなどの
方法もある。

前者フレームレートの固定の仕方は処理をぐるぐる回しておいて、
特定秒をオーバーしていたら処理を実行などの設計となる。

後者、フレームレートを固定せずに経過秒数で変化させる方法は、
移動や当たり判定の計算、リプレイの実装が困難だったりと上級者向きな印象が強い。

私は昔から固定タイプの人間で今でも可能な限り60fps固定方式を使おうとする傾向にある。

ただ、前者後者どちらにしても、本来結構面倒な設計をしなければならず、
ゲームの基盤ともいえるメインループの作成を行う際は最初に悩みつまずく箇所ではある。
しかし、今回に限っては垂直同期いったくでいいので、この問題を完全にスルーできるのである。
正直、こういうのは初めての経験かもしれない。

Windows+DirectXなんかでも垂直同期信号を待つ機構は存在するがその場合だと、
「このゲームはフルスクリーン、なおかつ60fpsに設定できるパソコンでの
　起動しかサポートしません」と言い切らないと
「垂直同期進行を待つ関数を呼ぶだけでOK」なんて事は出来ない。
今のご時勢だと即座にクソゲー認定をうけかねない仕様である。
また、ユーザサポートでてんてこ舞いになり、
初めから設計しておいた方が苦労しなかっただろうと後々後悔する可能性も大いにあるだろう。

さて、VitaはPCと違いリフレッシュレートが全く変わらない点に加え、
クロスプラットホームにしないと決め込んだ恩恵は思った以上に大きいようだ
――と、今のところは思っている。

というのも、まだ触ったばかりでどんな落とし穴があるか分かったものではないからである。
もしかしたら、既にこの手法は独自に機構を作るのが主流かしているのかもしれない。

あとこの辺で気になっているのは、処理落ち系がどういう処理になっているかが不明なので、
場合によってはコマ落ちなどの仕組みを作らないといけないかもしれない。
その辺は後日、気が向いたときにでも調べようと思う。

PSSを触ってみる第4回目。 せっかく、プログラミングガイドがあるので書いてあるのを辿りながら作ってみる。

【PS Suite SDK: 1.プログラムの構造】では、初期化部（Initialize関数）と
毎フレームの演算（Update関数）・描画（Render関数）の構成。

基本は、While文などでぐるぐる回す。
ツールでもゲームでも大体のプログラマなら馴染み深い基本構造構成である。
（GUIでフォームが作れるタイプ・Unity・Flash等の人には馴染み浅いかも？）

何か特殊な仕組みが組み込まれていない限りはWhileの上に初期化文。
Whileの中に毎フレームの処理という考え方でいける。

その為、UpdateとRenderなどを消して下記のような表記でも同じように動作をする。

public static void Main (string[] args)
{
	int colorValue=0;
	GraphicsContext graphics = new GraphicsContext();
	
	while (true)
	{
		SystemEvents.CheckEvents();
		colorValue++;
		if(colorValue>255)
			colorValue=0;
		graphics.SetClearColor(colorValue, colorValue, colorValue, 255);
		graphics.Clear();
		graphics.SwapBuffers();
	}
}

UpdateとRenderが分かれているのは、割と良くある設計で、
演算と描画の同期を取らない設計への対応のしやすさがあげられる。
リフレッシュレートの違いや、処理落ちしているときは描画部を省くなどの
対応もしやすい。

XNAなどでもその辺がしっかり分断されているようなので、
このような設計に慣れておくのも良いことだと思う。
（XNAの場合、GameクラスのUpdateとDrawをオーバーライドする）