サイト運営者の日々の日記。2010年04月。
バグ修正版、全てのバグは0か1しかとらない1つの変数にあったというのはよくある話。並びにインターフェイスをとりあえず設置、マシンのパワーを試せる。fpsは超適当。
GoogleChromeなら全て動く・・・と思いきや、メイン機のクアッドコアなら06番でも60〜100fps,CPU負荷40％であるのに対して、下手なモバイル用のデュアルコアだと速度が半減するぽい。JSの動作がCPUの性能如何で変わるとか新鮮だなー。確かFirefoxのJavaScriptにマルチスレッドを記述するものがあったから、CPU4個をフルに使って今の倍速とかできるんだろうか(FF自体の速度がGCの半分足らずだけど)。
SFとかでよくある人工重力発生装置でよく、というよりほぼ見落とされているのは、重力加速を行うには対象となる重力源が必要な点。例えば、ある方向に重力を発生させて推進する宇宙船というのは表現として適切ではない。正しくは、ある方向にある重力源に対しての位置エネルギーを変化させることで推進する宇宙船であるべきだ。重力源に対する位置エネルギーに触れないなら、それは運動量を直接変化させる重力推進以外の何かだ。
これを使うとSFにおける重力推進の理由付けが簡単になる。つまり、加減速時に、捕捉した星に運動量を押し付けられるので運動量保存則を破らなくてよくなる。ついでに、直接重力の数値を変化させる物理法則を正面から破るようなやり方は重力制御アプローチとしては明らかに間違っているだろう、と個人的な妄想。
エヴァ破をBlu-rayで観るべく色々考えた結果、現在主機のXP+Opteronではなく、Win2kを入れてるAthlon64機を潰してメインを新調したほうがいいんではないかという流れに。映像のエンコードて3Dゲームの処理とは負担のかかり方が別物だから、3次元処理超苦手の現状のマシンでも動くとは思うんだけれど。2kのサポートがいよいよひどいことになってきたし・・・。
canvasはオマケ以前の問題で、ほぼJavaScriptによる衝突シミュレーションに。今までこういうことはJSの表現上の限界として手を出さなかったけど、GoogleChromeなら100個同時処理でもなんとか動くし、案外いけるもんだな・・・
初期配置で重なりを防ぐ処理なし、同時刻多重衝突は対応しているはずだが、場合によってはフリーズしたり衝突判定が全く掛からなくなるバグが残ってるので予め警告しておく。そのうち修正する。ちなみに、計算式上は力学方程式を解きまくって進路を決めており、ゲームの衝突判定のような中途半端な判定は利用していないため、すり抜け等が発生しない代わりに計算量は多いと思われる。当然ながらコード整理とかやってない。
ここに来て黒と白。今ポケモンを一時中断してるが、秋までに絞れる要素は絞っておかないと悔いが残るな。DSだから互換性ありで第4世代の莫大な資源を使いたい後進的考えと、いっそ互換性を廃止して全く新しい戦闘/育成システムを実現して欲しいという先進的考えが同時に存在しているのはよくあること。
製作時間が猛威の3年、なんという怠惰さ。尤も元から自分が作るページの資料参照用として機能していたから、作りかけで止めたっつーよりは作りかけのまま利用していたというべきか。
3年でブラウザの対応環境も割と変わったなぁ、おかげでブラウザについて深く突っ込んだことを書けない。扱い枠は小さいが、コンテンツの規模としてはそこらの単独Archivesより余程大きく、実際にArchivesとして処理してるが表面上の扱いはarch web配下。
Google Chrome入れたら動かなかったので修正。フラグを一度反転させなければ適用されない問題点はWebKit特有のものだが、別に他のブラウザでやって問題が起きるということはないので一律実行させている。以下修正版。
ChangeStyle = function( name )
{
var i,ss;
var sl = document.getElementsByTagName('link');
for( i=0 ; i<sl.length ; i++ )
{
ss = sl[i];
if( ss.type!="text/css" )continue;
if( ss.title || ss.title!="" )
{
ss.disabled = ( ss.title==name ) ? false:true;
ss.disabled = !ss.disabled;ss.disabled = !ss.disabled;
}
}
}
オマケとして、archives webの代替スタイルにCSSを整理していたら出てきたpink.cssを追加しておいた。
今度の改修でマークアップ面での新仕様対応はいつでも可能となった。次の問題点は当然のようにスタイルシートの処理。HTML4とXHTML1.1では同一スタイルシートを使っても差し支えないが、流石に要素と構造が大きく変わったHTML5では厳しい。defaultスタイルシートを別に用意して、そこからカスタマイズしたスタイルシートを接続するのが良い。この場合HTML4版もそのままとはいかず、デチューンされたとは言えHTML5の構造を部分的に残すためやはりこちらも若干の修正が必要になる。
現状でも抱えている問題であるが、XML文章でも使えるDOM処理はXML要素の処理にそこそこ手間のかかる構文の記述を要する。まして本格的に5を使えばDOMに頼らざるをえない。従って基本的なものを簡略化するライブラリがあると便利かと思ったり。ただ、prototype.jsや自前のものをcommon.jsに貼り付けるなどして外部ファイルに依存させすぎるのは好みではない。その場(スクリプト中)に貼りつける程度の軽量コードを作った方がよさげ。
HTML5組込に必要な作業を終えた。メインはXSLTの根本的な構造変更。その他基本的な読み込みファイルのディレクトリ構造を変更し一旦全てのXMLファイルを再度変換し全て再アップロード。古い読み込みファイルはある程度の時間をおいて削除する。
実際にHTML5を導入したわけではないが、これでXSLTの処理単位ごとに異なるHTMLバージョンを導入できるようになったので、部分的に新しいマークアップを導入することができる。このマルチHTMLの構造をもってVer.12とするにはやや大げさかと思いver.11.5とする。
HTML5組込について色々案を考えていたら、横から割り込ませる以上の現時点でのサイトの構造上の問題点に突き当たった。改良すればVer.12級の変更。
現在の方式は1種類のcommon.xslを使ってHTML4.01StrictとXHTML1.1を別個に生成する方式。そのために上位の変数を使ってところどころで動作を切り替えているが、HTML5の仕様が大幅にそれまでのHTMLと異なる以上、スイッチ方式では無駄なコードが多すぎる。よって、commonHTML4.xslやcommonHTML5.xslなりに分離して条件分岐させないほうが遥かにメンテナンスもコード量も少なくなる。全HTML共通部はcommon.xslで改めて定義する。
これにともなって第2レベルのbase.xslも分離させる方がよく思えるが、これについては内部分岐させてもメンテナンス量を抑えられる程度の規模に留まると考えられる。第1レベルのTrans.xsl群は現状維持。
XMLで所属するarchivesを定義しているが、実は形だけ。ここで定義される所属archivesのディレクトリは、厳密には所属するデザインテンプレートのディレクトリを示す。これさえ個別に示せば何もarchivesを宣言しなくてもテンプレートは変更できる。こうなるとarchivesという管理単位が完全にディレクトリを分けるだけの形骸化した管理単位に成り下がる。
以上の結果デザインテンプレートがパッケージ化されるほうが望ましくなった。特別なディレクトリを作ってそこに一式放り込む方式として、トップディレクトリに野ざらしにする現状の方針を改める。
というわけで頭が痛い。虚仮威しのようなcommon.xslを改めて再構成するところから始める。頭が痛いのはあちこち独自拡張が入り込んでいる点と、共通するXMLの処理に関して各HTMLバージョンに対する互換維持用の変換も行わなければいけない点の2点。思案の末、個別対処する必要のある要素と属性以外は各々の列挙せずに範囲指定で丸投げにしてやる方針になった。commonHTMLX.xslが相当軽量化されつつある。
リンク先より、現在のこのサイトで使われそうなHTML5新設の要素をリスト化し勝手に使い道を解釈してみた。これに則った上であえてXHTML化して改修を実施したいところ。
ところで以前XMLは内容に関する具体的な意味を定義することと対立させて、HTMLは汎用的な関係性のみを定義すると論じたのだが、このHTML5は中途半端に真ん中をとる現実的な考え方であるな。XML記述で既にそういうことをやっている私としてはさして新しい概念ではないが。
ポケモンが大気圏に再突入して燃え尽きたので、もう一度打ち上げるまで他のことをやろう。
とりあえずサイトをXHTML5に対応させるべく策を巡らしてみることにする。手間はさほどかからない。現状残っている問題点を含め、今サイトが使用している独自XMLの仕様はほとんどそのままで移行できる。特にHTML5で導入された構造定義要素、aside,article,section,hgroup,headerのうち、独自XMLがサポートしていない形式はわずか2つなのだ。meter、並びにprogress,detailsはこのサイトの指向性を鑑みるなら実に便利な要素と言える。
基本バックグラウンドでの改修作業となるし、XMLを使った管理形式をとっている以上、実際にどんなHTMLのバージョンを使うかなんてことは作業コストと必要性の問題に過ぎない。よって本気で表面化させるような大幅アップグレードに発展するかどうかは知らない。ところで、このver.11最大の特徴は一元管理とマルチな構造デザインを両立できる点なのだが、更に一歩進んで吐き出すHTMLのバージョンすらマルチ化するって考えはどうだろう。もう何やりたいのかわからないレベルだが、一応現在もHTML4.01StrictとXHTML1.1を1つのXSLTで共有しているため、実現不可能なことではない。
気分一新して4月開始するわけでも、4月1日にエイプリルフールネタを投下するわけでもなく、メモリーが壊れて4月1日早々からハードとOSの復旧作業をすることになろうとは。
天運に全力で作業妨害されたということで、今年は妙なネタを投下する準備をしなくてむしろ幸せだったと言える。ああグラフィックがまだ不安定だ、死ね。
