marchのBLOG

  

とりあえず直接的な原因は分かったのでメモ。
どう対処しますかねぇ。

---
昨日のBLOGも参照。
---
LLFontクラス内のmRawImagepの先に、グリフのビットマップをキャッシュしておく。
縦かける横のサイズを持ち、左上から右(X)方向に1文字ずつ入れていく。
次に入れる位置はmCurrentOffsetX, mCurrentOffsetY で管理している。

このキャッシュがあふれた際は、
(1)キャッシュに乗っているグリフは、そのままでは表示できないようにする(mIsRender = FALSE)
(2)次に入れる位置を1,1に戻す。
としているが、キャッシュはクリアしていない。

続けて使うと、以前のゴミがある状態で上書きする。

mRawImagepは他のフェース、フォントファミリー内の他のフェースとも共用なので、(★この辺が未調査)
外枠のサイズが違うグリフの場合は、以前のゴミも表示してしまう。のかなぁ。

文字と文字の間を1ドットあけて表示するために、上述のキャッシュに1ドットあけて格納し、
表示する際にはあけた1ドットも含めて表示している。
そのため、キャッシュをグリフのビットマップで上書きしたとしても、
あけた1ドットの所には何も書かないため、ゴミが表示される。

---
mRawImagepの、clearとかfillとか試してみたがうまくいかず。memsetでゼロクリアしようとしたらメモリ違反^^;
あけた1ドットの所に何か書くようにするかなぁ。
  

ちょっと時間が出来たので、字汚れの件を調べている。
([#VWR-2410]noise dot appear in chat window when clien running long with chatting.)
https://jira.secondlife.com/browse/VWR-2410

●動作
文字列を表示するときには、表示したい1つずつの文字の形(グリフ)が必要で、
何度もファイルから取り出さなくてもいいように、一旦取り出した文字は
自前のキャッシュに入れておく。
表示する際は、まずキャッシュの中を探す。
キャッシュになければファイルから取り出して、キャッシュに入れてから表示する。
しかし何かのタイミングでキャッシュに入っているはずの文字を
何文字も続けて登録する場合があり、その処理が終わったときには字汚れになっている。

●状況の補足
SNSやJIRAにある状況に補足すると、
・英語でも日本語でも、同じ文字には同じノイズが載る。
・日本語の文字はアンチエイリアシングされていない(白黒2値)。
　だが、ノイズはグレーの点もある。
・日本語は文字の左右にノイズが出るが、英語は左右と上に出る。
・字汚れが出た後も操作を続けると、ノイズが変化する。

うちの環境では、文字の種類(=キャッシュに入っている文字)が
700ちょっとを越えたあたりで字汚れが起きる。
(英数字記号程度で再現できないのは納得)


・・・と、ここまで書いておけば、私が解析しおわる前に
通りすがりの勇者がちょちょいと直してくれるに違いない。
「せめてお名前を…」と言う準備をしておこう(笑)
  

SL内のメッセージカードなどで使われることの多いふい字フォントは、手書き風で読みやすいフォントです。
http://hp.vector.co.jp/authors/VA039499/

このフォントには独自の記号が21種類含まれています。
これらの記号は罫線記号(罫線素片)の場所にマッピングされており入力方法がわからない場合があるので、以下に一覧を示します。
コピーして貼り付けるなどしてお使いください。

注意：
・指定する文字のカッコ内はunicodeで調べる時の参考情報です。Unihan Databse(http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=2501 )などを参照してください。
・表示される記号の呼び方は私が勝手に決めたものです。


指定する文字　　　表示される記号
----------------------------------------
━ (U+2501)・・・ひらがなの「う」に濁点
┃ (U+2503)・・・白抜きのハートマーク
┏ (U+250F)・・・黒塗りのハートマーク
┓ (U+2513)・・・花マーク
┗ (U+2517)・・・太陽マーク
┛ (U+251B)・・・黒塗りの星マーク(U+2605とは異なる)
┝ (U+251D)・・・うずまきマーク
┠ (U+2520)・・・白抜きの三日月マーク
┣ (U+2523)・・・雲マーク
┥ (U+2525)・・・しずくマーク
┨ (U+2528)・・・長めの三点ダッシュ
┫ (U+252B)・・・雪だるまマーク
┯ (U+252F)・・・足あとマーク
┰ (U+2530)・・・温泉マーク
┳ (U+2533)・・・雨傘マーク
┷ (U+2537)・・・汗かきマーク
┸ (U+2538)・・・傍線・点マーク
┻ (U+253B)・・・平らな連桁付き8分音符 (U+266Bとは異なる)
┿ (U+253F)・・・おどろいたマーク
╂ (U+2542)・・・ふいマーク
╋ (U+254B)・・・ト音記号マーク
－以上－

  

なんでFePy(IronPython)だとエポックタイムが1970-01-01じゃなくて0001-01-01なんだよ。
ValueError: year is too low でしばらく悩む。
コマンドラインで手軽に確認するときは、元々入れていたActivePythonを使っていたので確認が遅れた。
---
ActivePython 2.4.3 Build 12 (ActiveState Software Inc.) based on
Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.gmtime(0)
(1970, 1, 1, 0, 0, 0, 3, 1, 0)
---
IronPython 1.1 (1.1) on .NET 2.0.50727.832
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import time
>>> time.gmtime(0)
(1, 1, 1, 0, 0, 0, 0, 1, -1)
---
参考：http://saekiyoshiyasu.org/pyb/pyblosxom.cgi/programming/python/gettimefromntp-2007-06-13-00-34.html
最初に気づいた人はえらいと思う。

他にも、DLLのバージョンが0.9.0.0だから安心していたら、同じバージョン番号で新しい物があったりとか、
いつものメニューも楽しくこなしています。  

「セカンドライフ依存度チェック！」http://kantei.am/22261/ をやってみる。

marchさんのセカンドライフ依存度は、 54 ％です。

ランク：C　(A～E)

偏差値：49.2

順位：262位 (505人中)

総評
あなたには若干のセカンドライフ依存傾向が見られます。
セカンドライフ内に楽しさを見つけ、ＳＬ内の人間関係も着実に築いている
事でしょう。
しかしあなたはＳＬとＲＬの区別がしっかりついているようですし、問題は無いかと思います。
ですが、今後のあなた次第では深刻なセカンドライフ依存症になる恐れも
あります。
今まで通りＳＬとＲＬとをしっかりと区別をつけ、自分を見失わないよう、周りから白い目で見られないようにね。


marchさんの今日のラッキーパーソンは
ttommy Loon


認定証



普通の人っぷりをここでも発揮した。

他の画像も貼っておく。


  

LSL convention Japan -2007- が10/20(土)～10/28(日)に行われます。
詳しくは下記オフィシャルサイトをご覧下さい．
LSL Convention Japan 2007
http://www10.atwiki.jp/xiao/

---
期間：10/20(土)～28(日)
メイン会場：MetaEgg （http://slurl.com/secondlife/Metaegg/130/163/29/?title=Metaegg）
展示会場：Oinari　（http://slurl.com/secondlife/Oinari/176/80/22/?title=Oinari）
1942 （http://slurl.com/secondlife/1942/128/128/20/?title=1942）

グループ： LSL convention Japan NEWS
検索して登録してください
当日のスケジュール変更や、会場案内などに利用します
※Group IMはご遠慮ください

スクリプターによる作品展示と技術交流がメインのイベントです．インワールドを動かす原動力，LSLの面白さをぜひ体験してみて下さい．

詳しくは下記オフィシャルサイトをご覧下さい．
LSL Convention Japan 2007
http://www10.atwiki.jp/xiao/
---

土日にはMetaeggで交流会も行われます。
集まった人がテーマに沿って意見交換を行います。
ふるってご参加ください。
＃私は20,21日は参加できませぬ(泣)


看板


準備中の様子



  

むしゃくしゃするのでついカッとなって、統計情報の数字をもてあそんでみる。
ラベルが変だが「そんなの関係ねぇ！」
X軸の数値が桁があってないので並べて比較がしづらいが「そんなの関係ねぇ！」

FPS値


SIMにいる人数


LSLの命令実行数



あー面白かった。  

ikebukuroにおいていた、第三回MagSL東京国際マラソンの大会記録の配布板を撤去しました。
今後お知りになりたい方は私まで連絡ください。
  

よく行くWEBページで、M/M/1型待ち行列のMはランダムと書いてあった。
ポアソン分布や指数分布じゃないのかと思ったが、パスワードを忘れてログインできず突っ込めない。
でもそんなの関係ねぇー(小島よしお風)

疲れてる場合じゃない。がんばろう！。  

問い：フットサルコートで、中から外が見えないようにすると、選手のクライアントへのテクスチャの転送量が減るのではないか。
私の答え：減らない。んじゃないかなぁ。。。


以下が調査内容と結果です。
---
---
●予備実験1
ある複雑なプリムの前に壁を作り、ログアウトして
キャッシュを消してからログインする。
ログイン後、60秒まってから壁を消す。
もし壁の向こうのテクスチャが転送されていないなら、
何もない地面が見えるか、灰色のテクスチャが貼られた状態で見えるはずである。

結果：消した瞬間に背景がテクスチャ付きで表示された。
(ためしに壁を消した状態でログアウトし、キャッシュを消してからログインしたところ、
最初は灰色のテクスチャで表示された)
#軽井沢から旧軽井沢の景色を見て確認。
---


で、ここからが本来の調査。実験=調査に読み替えてください。
---
●調査したいこと
・フットサルコートの壁を黒くすると、クライアントにかかる負荷が減るか?
　->見えない所のテクスチャは、クライアントに転送されないのか?

●前提の整理
[実験の前提条件]
・テクスチャは転送されると、キャッシュディレクトリにUUID名つきで格納される。
　->テクスチャが転送されたかどうかは、キャッシュディレクトリのファイル有無で判断できる。
　　(格納数に限界があるとしても)

●環境
[SIM]
・なるべくオブジェクトの少ない所
・高低差のない所
　->ベータグリッドで行う

[クライアント]
・最新のベータグリッド版で行う
　->SecondLifeBetaHavok.exe (製品バージョン 1.18.3.70780)


●状況
(図)


(1)アバター
・北向きで地上に立たせる。

(2)壁オブジェクト
・普通の(huge)でない、箱型プリム。
・10m * 10m * 0.5m
・以下の種類とする(まずは2aだけ確認)
　(2a)テクスチャなし。透明度0%
　(2b)テクスチャあり(デフォルト)。透明度0%
　(2c)テクスチャなし。透明度50%
　(2d)テクスチャなし。透明度100%

(3)隠蔽オブジェクト
・普通の(huge)でない、箱型プリム。
・5m * 5m * 5m
・Rez時のまま(回転させない)
・6面すべてに異なるテクスチャを貼る。
　・オブジェクトのUUID:-略
　・テクスチャUUID(上):0,0e634762-略
　・テクスチャUUID(下):1,e9666120-略
　・テクスチャUUID(東):2,0f5b479b-略
　・テクスチャUUID(西):3,a4fe9255-略
　・テクスチャUUID(南):4,bb312bc6-略
　・テクスチャUUID(北):5,1bd3edf7-略

●実験手順
1)各オブジェクトの設置、UUIDの取得
2)アバターを北に向かせたままログアウト
3)キャッシュを消す(リネーム)。
->確認のため、キャッシュディレクトリのファイル一覧を取得する。
4)ログインする
5)ログイン完了(バーグラフが消えたタイミング)から5, 10, 30, 60,120,150,180秒のタイミングで、
　キャッシュディレクトリのファイル一覧を取得する。
6)壁の横まで歩いていき、壁の後ろの隠蔽オブジェクトを画面に表示させる
7)キャッシュディレクトリのファイル一覧を取得する。
8)ログアウトする
9)上記1)で取得したUUIDと、キャッシュディレクトリの一覧を比べ、
　テクスチャが転送されたか否かを確認する。

●結果
[1回目]
・テクスチャのうち、東側は0s、下側は5s、上側は30s後にキャッシュに入った。
　西側、南側、北側は壁をよけて南西から近づいたとき(上記7)にキャッシュに入った。
[2回目]
・テクスチャのうち、下側は15s、それ以外はすべて30sでキャッシュに入った。

●考察
・プレイヤーが見えるか見えないかにかかわらず、テクスチャは転送される。
・下側が先に転送される結果となったが、オブジェクトのSIDEと関係あるのかは不明。


●課題
・ワイヤーフレームにしたらテクスチャが転送されないのか確認。
・テクスチャの転送量が、性能に与える影響を確認
　->統計情報から取得(クライアント改造or画面キャプチャ)
---
時間切れでここまで。私の能力では3時間でこの程度の調査とまとめしかできません。
批判や意見を歓迎します。
  

SL内のスクリプトやオブジェクトの品質について
エラそうに語ろうとしていたが、
自分でも同じ誤りをやってしまった。
理論は知ってるつもりだったが、実際の基本動作が出来ていない。
人のふり見て我がふり直せ。人を笑えば穴二つだ。
他人のおせっかいよりも、自分のアウトプットの質を上げることに
注力しよう。
  

Hakataにあるプリクラに行ってみた。



椅子に座るとカメラ視点が代わり、上キーでポーズ変更、下キーで背景の絵の変更
というしかけ。



なんだか画面が寂しいので、HUDでフレームつけて撮ってみた。
HUDでTop, Bottom, BottomLeft, BottomRightにつけるので、
画面のサイズが違う人でも、それなりの位置に付いて見えるはず～。
SS撮るときに"Show HUD objects in snapshot"をオンにするのを忘れずに。
#RLが夏の暑い頃に海に行った帰りの車でふと思いついたネタで、あまりにくだらないので
#放っておいたののリサイクルというのは内緒だ＾＾；
##デザインをいくつか作っておきゃよかった・・・。



ここで気が付いたのは、画面が寂しいのはフレームが無いせいじゃなくて、
本来は二人用で4人でも撮れるこのプリクラに、野郎が一人で行くというさぶい状況。
近くで見ていた人に「フレーム付いてなければ、証明写真とごまかせる」という
暖かい声援をもらって、Hakataを後にしました。



まずは容姿を直そう。  

SecondLife内で2007-09-28に行われた、「第一回 Higashiosaka タイニー サッカー大会」の模様を録画したので、YouTubeにUPしました。

http://jp.youtube.com/watch?v=2Isis49rJRM