.そうです 。 MML は凝ると死ぬけど、凝らなきゃそれなりに楽なので。 でも、結構疲れましたがな :D .ちなみに、虹色〜は、一晩で打ち込んだっす。 楽譜とかどっかいっちゃったので、 記憶だけを頼りに楽器とか使わずに頭の中でアレンジして直接 MML へとダンプ。 めんどいからかなり手抜きで一切ベンダとか使ってないけど、 なんかバッキングでディストーションギターが鳴っておりますな。 そんなところだけこだわってどーする<俺。 .まあ、なかなか MU-80 は悪くないですな。 ディストーションギターも、コツを押さえればきれいな音が鳴るし。 タダでもらったんだけど :D |
.やっぱりこれくらいのが欲しいよなぁ… 。 あと、やっぱり USB カメも欲しいぞ。 |
.ふう。つまりだ、 ゲームの遊び方は遊び手の自由にはならない 、 ってことかいな。 .それを適用するか否かはプレイヤーの自由意志に委ねられているわけだし、 そこに混乱の余地も作り手側の不利益もないように思えるんだが。 |
.デフォルトではそうなりますな 。 だいぶ前に、この件に関して隣の隣の席の人に聞いたところ、 仕組みとしては区別して扱えるように作ってあるものの、 mule-2 との互換性から、デフォルトではわざと ASCII へ変換するような hook を入れてあるんだそうな。 .外す方法は忘れた :D |
.アキバへ買い出し。私をアキバに買い物に出すと鉄砲玉なのである(ぉぃ .千石でジャック類および線材、ザコンで CD-R 、 あぷあぷでアクティブスピーカ、ソフマップで闘魂列伝 4 (999 円)、 あと、メッセ横の怪しい店で DC のメモカなど。 って、 |
.X 版作った時にふと思ったのが 、 なんでデータが分離してないのかな、ということですな。 データだけ共用できるようにすれば移植は楽なんですが、 きっと Palm and/or DA 固有の深い理由があるか、 あるいは単に面倒くさかっただけだと思ったので、深く考えず。 |
.一方で、 やっぱり買い物かごに特許は変よね 。 |
.いつのまにか再開していた「文字の海、ビットの舟」 第3回 日本IBMが、0213原案に反対をした理由(2) 「●世界の文字コードとシフトJIS、そして0213」 のところ。 ただし、ISO/IEC 10646(≒Unicode)とISO/IEC 2022を多言語処理という 側面で見た場合、前者のISO/IEC 10646(≒Unicode)の方が、より実装が しやすいということが言える。 .やっぱりこういう誤解があるんですな。 ISO 2022 と Unicode での多言語化の容易さは、 控えめに言って変わりません。 ISO 2022 の外部エンコーディングの難しさなんてのは、 多言語化の難しさから言ったら屁みたいなもんだと思うぞ。 もちろん、本来の「開いている ISO 2022」なんて、 どうやっても有意な形では実装できないんで、 何らかの「閉じた ISO 2022」を実装仕様として規定する必要はあるんですが。 .「多言語化」ってものに誤解があると思うんだが、 「多言語化」というのは本質的に 「複数の言語を切り替えて使えること」なのですな。 同時に複数の言語が一つの文字に存在するなどということは基本的にあり得ない。 その切り替えの粒度は実装によって違うけれども、たとえば、 かなり高度な多言語処理実装では、 「りんごは英語で apple といいます」 という文字列があった場合には、 「りんごは英語で」は日本語だけれども、「apple」で一旦英語に切り替わる。 で、また「といいます」のところで日本語に戻る。 もちろん、ここでの「apple」が英語かどうかってのは、 ポリシーのわかれるところだけど、 メカニズムとして「それができる」のが、 「高度な多言語化環境」の一つの形だと思う。 .で、Unicode だからってこういう切り替えが不要か、 というと全くそんなことはありません。 詳細は省略。で、結論としては、どうせ切り替えが必要なら、 別に ISO 2022 でも構わんのよ。 .あと、どうもみんな、「多言語化」っていう言葉に騙されて、 大は小を兼ねる、みたいな印象をもってるみたいなんですが、 いや、大部分は「単言語」でしか使われんでしょ。 私がよく主張するのは、ISO 2022 の利点というのは単言語での処理効率にある、 ってこと。これは、ISO 2022 に register されてるコードってのは、 たいていその国の言語での「ワーキングセット」として良好なので、 その仕組みを使えば、何も考えずに最適なメモリ効率が得られるわけですな。 もちろん、多言語化した場合には、コードポイントの重複が増える、 という欠点もあるわけですが、それはテーブル一発で解決できるわけで、 多言語化のためのコストと考えれば安いし、 私はそのために使用頻度が高い単言語での効率が向上するのは 無視できないと思うわけですな。 別の立場としては「言語が違えば別の文字」っていうのもあるわけで、 この立場に従うなら、 「言語間でのコードポイントの重複」というのは 論理的にありえないことになるんだが。 .Unicode で単言語の処理をしようと思うと、この「テーブル」が 逆方向で必要になるので、メモリが貧弱な用途ではきついんですね。 ISO 2022 を dense encoding、 Unicode を sparse encoding なんて呼ぶのはこういうこと。 で、Unicode を多言語で使った場合にこのテーブルが不要になるか、 というと、ぜーんぜんそんなことはない。だって、言語に応じて 切り替わるんだから。そこでやっぱりテーブルが一つ必要になる。 .うーん、なんでこんな当たり前のこと、みんな気づかないんかな。 どうもやっぱり、世の中は ISO 2022 的分割統治ではなく、 Uni- とか Pan- に進みつつあるのかのう。 恐いのう。これって FUD? |
.いやまあそうなんですが 。 世の中所詮政治力ですな。あと英語力。 .個人的には Unicode の嘘もほら貝のホラも、そんなに変わんないと思うなぁ。 未だに Unicode 陣営は「固定長」とか言い張ってるし、この辺も 「すごくまことしやかな噂」があって、98 年ごろ、 Unicode.org のメンバーの一人の某氏が 「そろそろ固定長の看板を下げようよ」って提案したら、 猛反発くらった、って話とか。って、これ出典は加藤弘一の本だな。 内部の人間が提案した場合ですらそれだもん。 まあ、それは「すごくまことしやかな噂」に過ぎんが、 でも、未だに「固定長」っていう言葉が規格書に残っていて、 それが明らかな嘘なのは確か。 .この手の嘘を暴くのはすごく難しいのよ。 正々堂々正面から理詰めで攻めても flame にしかならないし、 その論議の結果どっちが正しいか、なんて、結局外からじゃ判断できない。 flame の隙に政治力と ad hoc 電撃実装でなしくずしにされたら 手の打ちようがない。今の XFree86 なんかそうだもん。 だから、残念ながら論戦になったら負け。やろうとおもったら、 姑息にゲリラ戦を仕掛けていくしかない、と実感した今日このごろ。 たとえば、やっぱり ad hoc 電撃実装で唾付けといて、 後でいかようにでもできるようにしちゃうとか、ね。 |
.使いもしない (7bit+4bit)*3 のパラレル DDA による Alpha fade を 実装してみたりして。 .つまり、RGB 各 8bit な 32bit frame データで、 桁上がりを無視して DDA する姑息な方法。 負の delta を足した時のボローが隣の LSB にはみ出すから、 0xFEFEFE でマスクしちゃう。 よって 7bit 。で、その誤差を補うために、 1.3 な固定小数点の DDA を持つわけですな。なんで 4bit かっていうと、 RGB 各 8bit な 32bit frame をもう一枚持って、 delta と加算値を 4bit ずつ分けるから。中間の計算は 5.3 でできるし。 .でも、どうせ人間の目なんてインチキだから、最後につじつま合わせれば 7bit*3 でも精度的には十分っぽい。 |
.ベーマガの BASIC は 、 ある時期から「基本」って意味にシフトしてたような。 .しかし、「砦の攻防」とは懐かしい。プログラムは無茶苦茶ですが :D。 Dr.D のつっこみきぼーん(ぉ。 |
.クレジットカードの暗証番号なんてそんなことしなくても(以下略) 。 明確なセキュリティホールだよなぁ…。 |