Additive Alpha 関連の画像演算ルーチンのうちよく使いそうな物をアセンブラで書きました。Additive Alpha はやっぱり演算が単純でいいですね。KAG3の方も、メッセージレイヤのほうは Additive Alpha で表示するようにしました。

今はバイリニア補間を書いてます。C言語で試しに書いたルーチンは重いです。最低でもMMXが使えないと厳しそうですが、いまどきMMXが使えないCPUも無いでしょう。

Layer.faceとLayer.holdAlpha関連がわかりづらいので、ここらへんを整理したいです。もしかしたら下位互換性が少し損なわれるようなことになるかもしれません。

個人的なプロジェクトの情報管理の為にPukiWiki を導入しようと思ったのですが、全角文字を含むいくつかのページがうまく編集できないのです。

PukiWiki mod_encodingで検索したり、PukiWikiのFAQ「BracketNameの日本語名が文字化けする」を見ると、mod_encoding が悪さをしているようです。

mod_encodingは、kikyou.infoでWebDAVを使う為にApache2のモジュールとして入れてあります。検索した結果で見つけた解決策のとおり、 <Location> 指令で場所を指定し、WebDAVを使うディレクトリ以外には mod_encoding が作用しないようにしてみたのですが、そもそも <Location /> 〜 </Location> で EncodingEngine On 指令 (mod_encodingを有効にする指令) を囲っただけですべてのディレクトリで mod_encoding が作用しなくなってしまいます。なんどもいろいろ条件を変えて繰り返してみたのですがうまくいかず。ディレクトリごとに設定って変更できないんでしょうか。

mod_encodingがそもそも何をやっているのかというと、ファイル名に関して、サーバ側とクライアント側の文字コードの違いを吸収する為に文字コードの変換を行っています。これは、リクエストURI(とリクエストヘッダの一部)中の %記号 のエスケープを解除してから、クライアント側の文字コードをサーバ側の文字コードに変換しています。

どうも問題なのは、これが リクエストURI の '?' 以降 (通常 Query String になるところ) 以降も変換を行ってしまい、これにより PukiWiki に正しい BracketName が伝わらないといった物のようです。

しょうがないので'?' 以降を変換しないようにするパッチを作りました。mod_encoding for Apache2 20040616版 (2004/06/16) に対してのパッチですが、mod_encoding.apache2.20020611a-2 (2002/6/20?) やそれ以前のバージョンでもいけるはずです。aprの使い方とかよく分かってないですが、たぶんこれでいいと思います。

これでやっとPukiWikiがまともに使えるようになりました。めでたしめでたし。

最初探したときに既存のパッチ無いかと思ってたらNamazu-win32-users-ja(旧)アーカイブにありました ＿|￣|○

先日2.23 beta 3 を出しました。加算アルファ合成(ltAddAlpha)関連の改修が主ですが、下位互換性は保たれているはずです。

加算アルファ合成のメリットは前にも書いたかも知れませんが、アルファ合成と加算合成の両方を一度に計算でき、通常のアルファ合成に比べて演算が単純で高速という物です。ただし、beta3では、まだ加算アルファ合成関連の低レベルな演算ルーチンはすべてCで記述されてるため通常のアルファ合成よりも遅いです。これからその最適化を行いたいです。

画像フォーマットコンバータに、ltAddAlpha用画像の出力機能を追加しました。Photoshopデータや他のソフトが出力したPNGをltAddAlpha形式に変換できます。

でもそれだけだと、普通のアルファ合成を加算アルファ合成に変換しただけで表現力に違いがありません。加算アルファ合成はアルファ合成と同時に加算合成もできるのがメリットなのですが、これに対応しているグラフィックソフトは見かけたことがありません。

それではあまりにも素材が作りにくいので、ltAddAlpha形式(加算アルファ合成形式)を出力に選んだ場合は、Photoshop形式読み込み能力が拡張されます。具体的には、「通常」レイヤーの上に「覆い焼き(リニア)」が重なっている構造のPhotoshop形式を読み込み、加算アルファ合成用データとして出力することができるようになります。「覆い焼き(リニア)」は加算合成の事です。

加算アルファ合成をどう使うかというのはぱっと思いつきにくいのですが、強い光を反射してフレアの掛かったような金属体など、不透明で光の表現がある素材に適していると思います。

画像フォーマットコンバータで、TLG5/6画像に「タグ」として「mode」を入れられるようになりました。「タグ」はKAGの「タグ」とは違って、いわゆる画像そのものに対する情報(メタデータ)です。今のところ制定されている仕様では文字列情報として「名前=値」のペアを格納できます。これに伴い、Layer.loadImagesメソッドがこのタグ情報を含んだ辞書配列を返すようになりました。

KAGではさらに、ここに入っている情報がimageタグの属性省略時の値になります。画像フォーマとコンバータがTLG5/6に入れる「mode」はKAGのimageタグの「mode」属性に対応しています。mode属性はレイヤの表示方法(完全不透明か、アルファ合成で表示するのか、加算アルファ合成で表示するのか)を指定する物ですので、結果的に、KAG のimageタグでmode属性を省略した場合、その画像に含まれる情報に従って、適切な表示方法で表示されることになります。

画像フォーマットコンバータが現状格納するのはmode属性だけです。原理的にはleftやtopなど、他のKAGのimage属性に対応する情報も入れることができるのですが、これを編集できるようなツールは作っていませんし、作る予定も今のところはありません。

今後ですが、どうしましょうか………。

• 帯域制限を行っていないプロバイダあるいは帯域制限を行わないサービスに乗り換える</li>
• 他のサーバ屋さんにミラーして頂く</li>

この両方あるいはどちらかを行わないとなりません。

前者はお財布と相談です。納得できる価格で、いいサービスがあれば良いのですが。上にも書きましたが、地域IP網の構造上の問題もあるので、地域IP網を使っている限り超えられない問題もあるようです

kikyou.infoの運営は趣味であって、これ自体はなんら利益を生んでいませんから、これに出費できる額には限りがあります。正直言えば、今のBフレッツベーシック＋ASAHI-NETの接続料で手一杯です。広告収入は見込めるほどページビュー無いんじゃないかと思います(未確認)。できればバナー広告は無しでいきたいなあと希望です。

後者はツテかなぁ、と思いますが知り合いにそのような方が居ないのが悲しいところです。

何かよい方法ないでしょうか。どなたか良いお知恵をお貸しくださると幸いです。

今回は早急に対処できるような物ではなさそうなので、これは皆様にお詫びするしかありません。

この度はご迷惑をおかけし、大変申し訳ありませんでした。

＿|￣|○

15:00で解除はされたのかも知れません。上記の「回避策」を行ったのでそれよりも前にデータは快適に流れ出していました。その２時間ぐらい快適な回線状況の後、また帯域制限をくらいました。今度は個別のポート単位ではなさそうです。上り1MB/secほどで制限されています。

上記「回避策」はちょっと横暴すぎだったかも。

要約すると

• 一時間平均で24Mbpsに及ぶデータの転送が行われた為、帯域を制限した
• ASAHI-NETでは、お客様に対して実用上十分な帯域を保持した上での、自動化された管理システムによる帯域制限を行っている
• 08/12 15:00に解除予定
• 基準値(今回は24Mbps)はその時点でのネットワークの状態によるため、固定された値があるわけではない(一時間平均上りが10Mbpsを超えても制限の対象となる可能性がある)

とのことです。

「実用上十分な帯域」ということではこちらとの認識の違いがあるようです。

もっとも、もともとサーバ公開用途ではないサービスですから認識の違いはあって当然なのかもしれませんが、加入当初(２年ぐらい前)はこういう話は聞いたことがなかったので寝耳に水です。

これが「ベストエフォート」における「ベスト」かというとちょっと疑問が残ります。

お詫びの一言も返信メールに入ってないですし、文句を言っても改善されるような物でもなさそうなので、プロバイダ乗り換え時期なのかな、と思います。

24Mbps/hourでは他のユーザの速度低下などの影響があるとのことです。これは地域IP網の構造上の問題で、特定のプロバイダに依存しない話らしいです。だとすると24Mbps/hourで制限がかかるというのも故あっての事か。参考:http://pc5.2ch.net/test/read.cgi/network/1052354767/353-364 しかしいったん制限がかかると約8Mbps/secの状態が長時間続くのは勘弁。

制限がかかっているのが、ダウンロード用httpdを走らせている8080番ポートだけだと言うことに気づいたので、ポート8081〜8088で走っている同じhttpdのアドレスにランダムでリダイレクトするように設定し、とりあえずは帯域制限を回避できるようになりました(13:00頃)。ポート単位やプロトコルの種類を見ての制限はしてないとの事です。私の勘違いだった模様。

ポート8081〜8088なんていうヘンピな番号なので、ファイアーウォールによっては空いていないかも知れません。

どうしてもダウンロードできないという方は :808X のつかないアドレスでアクセスしてくだされば、一応ダウンロードはできます。

ご迷惑をおかけ致します。

埒があかなかろう、と思い、ASAHI-NETのカスタマーサポートにメールしました(17:10)。

回線負荷のグラフとともに経緯を説明した上で、以下のような内容のメールです。

• 帯域制限はASAHI-NET側で行っている物か？
• ASAHI-NET側で帯域制限されていないならば、どこでされているのかのアドバイスをいただきたい。
• ASAHI-NET側で帯域制限されているならば、kikyou.infoのユーザに迷惑がかかっているので、解除して頂きたい。
• 上り回線速度が1MB/secでは、光接続にした意味がない。
• 他のユーザに迷惑であるというならば、こちらでも帯域制限は行えるので、他のユーザに迷惑にならない目安を教えて欲しい。

さて、どういうお返事が帰ってくる事やら。ありゃー17:00すぎちゃったから営業時間すぎちゃったかな。

kikyou.infoがメインで使ってるインターネットプロバイダはASAHI-NETなのですが、もしかしたら帯域制限かけられちゃったかも知れません。

このグラフを見ると分かるのですが、本日の1:20ごろから上り(負のほう)がおおむね1MB/secになっています。

所々ツノのように下に伸びているのはなんだかよくわかりませんが、毎時10分ぐらいの場所にあるので、回線負荷計測の為に一時的に帯域制限を解除してるのかと思います。

帯域制限をかけらられたのは初めてなので困惑していますが、なんとかならないものでしょうかねえ。

asahi-netの帯域制限について検索すると、あーやっぱり使いすぎると制限されるのか、とか思ったり。

ちなみに今(16:00現在)は1MB/secでこちら側でも帯域制限をしています。時々こちら側での帯域制限を解除して、プロバイダ側の帯域制限が解除されたかどうかを見ているのですが、サッパリ解除されないようです。

これが続くようならば、サポートに文句をタレたいと思います。なにせ、kikyou.infoの運用に支障があるので。

いろいろとトラブルの絶えないkikyou.infoですが、皆様方にはご迷惑をおかけしますm(_ _)m申し訳ありません。

以前、2004年2月15日の日記で不具合としてあげた「プロローグ３日目、夜、屋上でゲームが落ちる」件の原因がおおよそ判明しました。

某所の「CDレス化パッチを入れるとFateが落ちるようになる」という書き込みを見て、「CDレス化パッチ」を入手しようとしました。

Fateの場合はCDレス化はすなわちCDプロテクト回避ということになるのですが、これ自体はその用途からみてもまっとうなものじゃなくて、ファイル共有ソフトじゃないと入手できないようでした。ともかく紆余曲折して入手。

で、やっぱりこれが原因のようです。バグというか、考慮不足による物です。詳しい説明は割愛しますが、エラーを無効化しようとして吉里吉里の例外機構に手を加えたのが原因のようです。

まあ吉里吉里のせいじゃないとわかって一安心です。

それにしてもこの症状が随所で聞かれたのはともかく、公式掲示板にもこういう報告が有った上で公式のFAQにもなりました。中には裏で不正に流通していたプロテクト回避済みのゲームを使用した人もいるでしょうし、こういう事やった上でよく公式のサポートを受けようとしますよね、ホントに………。