■吉里吉里／ＫＡＧ／ＴＪＳ雑談質問スレ■その９

**名前は開発中のものです。** · 2006/10/10(火) 06:04:10

ノベル製作ツール吉里吉里/KAGを使用している人達が雑談や質問をするスレッドです。
本家BBSで聞きづらい質問や初歩的な質問などでもよいのでわからないことがあればどうぞ。
自分のゲームの進行状況や製作ツール等についての話、TJS等の質問もお待ちしています。
マルチポストはやめましょう。個人叩きも禁止です。

８　http://pc8.2ch.net/test/read.cgi/gamedev/1147590108/
７　http://pc8.2ch.net/test/read.cgi/gamedev/1138099311/
６　http://pc8.2ch.net/test/read.cgi/gamedev/1116774771/
５　http://pc8.2ch.net/test/read.cgi/gamedev/1095183786/
４(タイトルは３)　http://pc5.2ch.net/test/read.cgi/gamedev/1081199649/
３　http://pc5.2ch.net/test/read.cgi/gamedev/1067436686/
２(再利用)　http://pc2.2ch.net/test/read.cgi/gamedev/1044256119/
１　http://pc2.2ch.net/test/read.cgi/gamedev/1021890648/

吉里吉里２／ＫＡＧ３雑談質問スレ＿過去ログ
http://www.geocities.jp/kirikiri_log/

【公式】
kikyou.info
http://kikyou.info/

吉里吉里ダウンロードページ
http://kikyou.info/tvp/

**名前は開発中のものです。** · 2006/12/02(土) 23:38:35

>>692
乙ですー。
これから盛り上がっていくといいねー。

あーメルアド公開にしちゃったんだ。
まあ別にいいんだけど

BBSとかは置かないの？

**名前は開発中のものです。** · 2006/12/02(土) 23:45:41

KAGの中で eval で処理しても Conductor に決して -2 は帰らないからね。
waitTrigger で情報を登録した上で -2 を Conductor に返せないと処理としては意味を成さない。
あ、次回のなにかしらの wait処理で登録した情報が有効になっちゃてバグの原因になるね（笑）
pending にタグとして登録して実行させることで、waitTriggerして、さらに -2を返すことができるわけ。

**名前は開発中のものです。** · 2006/12/03(日) 00:10:28

>>731
pendingに直接アクセスすることが好ましくないってことを
言いたいわけなんだが（;´Д｀）
TJSはアクセス制限子ないからあれだが、
pendingは間違いなくprivateとして扱われるべき変数だろ。
変なバグを出さないためにもむやみに外部から参照すべきじゃないよ。
本来の実装方針無視してキモいコード書くことに何の意味があるのかと。
TJSのみこれからも使っていくんなら構わないかもしれんが、
おかしなコーディングばっかに慣れちまってどうする。

そもそも不満をこの際ぶちまけちまうと、シナリオファイルの中から
ところ構わずkagの関数に直接アクセスして中身書き換えたりが
ほとんど当然のようになっちゃってるあたりとか、
MainWindowクラスのごちゃごちゃっぷりとか、
Conductorの挙動とか、
kag自体の設計が何かおかしなことになっちゃってるよね
もう本当に捨て時なのかもしれない(´･ω･`)

**名前は開発中のものです。** · 2006/12/03(日) 00:12:06

>>729
KAG から操作するにしても callExtraConductor っスから、
どっちもどっちって感じはしますけど……どうなんだろう。

**名前は開発中のものです。** · 2006/12/03(日) 00:34:13

まぁ、βでなくなった時から考えても2002年から４年以上に渡って切った貼ったされてきてるからなぁ…
2002年の段階で、数年後ここまで膨れ上がるとはdeeさん自身正直予想もしてなかったんじゃないだろうか。

**名前は開発中のものです。** · 2006/12/03(日) 00:54:01

[eval exp="kag.callExtraConductor('first.ks', '*test');"]
サブルーチン実行中にこの文章は表示されないはず。
[s]
ここにはたどり着かないはず。

*test
callExtraConductor がちゃんとサブルーチンを呼び出せていれば、この文章は表示されるはず。
[waittrig name="testtest"]
waittrig でちゃんと停止していたら、この文章は表示されないはず。
[return]

……結果は、『サブルーチン実行中に～』と『callExtraConductor が』が表示されました orz
callExtraConductor 呼び出しても、元の KAG ファイルの進行は止まらないのですね orz

**名前は開発中のものです。** · 2006/12/03(日) 01:06:40

えーっと、タグを挿入する >>726 方式だと、クリック待ちの状態では一度クリックしないと挿入したタグを実行できなくて、
それを回避しようよ kag.skipToStop2() を挿入……っと。
すると、処理からクリック待ちのところまで戻りたいのに、クリック待ちは既に終わっていて…… orz

吉里吉里って本当に難しいですね｡･ﾟ･(ﾉД`)･ﾟ･｡

**名前は開発中のものです。** · 2006/12/03(日) 01:12:52

@call
と
kag.extraConductor

の違いくらい理解しとけ。リファレンスに書いてあるから。
何の為にExtraConductorがあるのかも調べておいで。
本当いい加減うざいよ。死ねばいいのに。

**名前は開発中のものです。** · 2006/12/03(日) 01:14:00

kag.callExtraConductorでした。callが抜けていました。
ごめんなさい、俺も死んどきます。

**名前は開発中のものです。** · 2006/12/03(日) 01:20:42

まぁおいおい理解していけばいいんでないかい
とりあえず素直にKAGで処理したほうが無難だと思うがいかがか。

**名前は開発中のものです。** · 2006/12/03(日) 01:21:05

>>732

んー、pendings はわりとさわっていい部類に入るとおもうけどなー。処理を割り込みする手順としては正当だし。
まあ、このへんは感覚の差として、もう設計がぐちゃぐちゃになっちゃってるのは同意ね。
現実問題として内部関数よばないと要件みたせないことが多いからね。

個人的にはKAGそのものを拡張してタグを増やす方向で対応してるよー。
というかそれ以外は基本的にコンダクタの処理を妨害するからだめですね。

**名前は開発中のものです。** · 2006/12/03(日) 01:31:01

ごめんなさい。色々と迷惑をおかけしました orz

一応、色々と割り切ってみることにします。
完全停止しなくとも、スキップとか自動読みとかを表示前に切るだけで大分違うでしょうし……
お騒がせいたしました orz

**名前は開発中のものです。** · 2006/12/03(日) 01:38:53

>>739
KAGでは記述しようがないことだから困ってるんじゃない？

>>736
あー、それは方法論として間違い。
kag.conductor.status をみて待ち状態ならタグをつっこまないのが正解。
しかし、そのままだとクリックされると処理がすすんでしまって結局不幸に陥ると予想。
透明レイヤを全面にはってイベントが通らなくなくなるようにするとかこざかしい方法もあるけど、いまいち。

やっぱ一環した処理がほしいなら、
OnClick() など UI処理からの呼び出しなら conductor.interrupted は適切に機能する（次のコンダクタ呼び出しから
処理が停止する）から、それを使ってコンダクタの wait系の処理とは無関係にとめてしまうしかないんじゃないかなぁ。

ただ、conductor.interrupted は、処理中にタイトルに戻るとかの処理をされて復帰処理がよばれなかったりすると
地獄におちるので、kag.onConductorJump をフックして、別のシナリオに切り替わる流れではかならずその状態を
強制で戻す必要があります。自分ではまったのを忘れてたよ。あ、あと、そのレイヤ処理とやらの
強制後始末も忘れずにね。

本来は、こういった機構の汎用処理を KAG のコアが提供してくれると一番いいんだろうけどね。

**名前は開発中のものです。** · 2006/12/03(日) 02:27:25

まあ贅沢な悩みだよな
何だかんだと多彩な実装は可能なんだし
人の欲望はげに恐ろしい

**名前は開発中のものです。** · 2006/12/03(日) 03:06:12

いや贅沢なんかじゃない。
ゲーム作るのに煩わしい処理を隠蔽する為にフレームワークを使うんだから。

ただ単に当初予測されていた以上の使い方が現れただけ。

だから本当にKAG3を捨てる時期なんだろ。

利用のされ方に応じた同じジャンルのゲーム作るフレームワークがあっても良いジャマイカ？

同じ車でも軽のタイヤとダンプカーのタイヤは違うんだから再開発は必要なんだろう。

題してKAG3を窓から投げ捨てるプロジェクト（笑）

**名前は開発中のものです。** · 2006/12/03(日) 05:47:22

低レベルな質問なんだが「input」の入力画面と「edit」の入力画面の使い分けが分からん。
機能的にはほとんど大差ないよね？　こんな時はこっち使えとか暗黙のルールあるの？

**名前は開発中のものです。** · 2006/12/03(日) 07:34:41

> 機能的にはほとんど大差ないよね
大差あるよ

**名前は開発中のものです。** · 2006/12/03(日) 10:38:19

input のほうはモーダル（終わるまで次いけない）で edit はそうではない
というのが一番の違いなのでそこに着目して使い分けたい

決まった順番で順次入力するようにさせるときは input を使うといいし
自由な順番で何度も行ったり来たり直しながらのときは edit がいいね

**名前は開発中のものです。** · 2006/12/03(日) 17:33:48

今サラダけど>>706への回答ないのかな。
自分は706じゃないし吉里吉里での制作は未経験なんだけど、
こういう経験者ならではの話も聞いてみたい。

最初に設計をしっかりしておくってのは大前提だと思うけど。

**名前は開発中のものです。** · 2006/12/03(日) 17:48:19

それがよく言う「最初から大作は無理、まずは小さいのから」の中身でないかな、と。

確かに細かいTipsは知りたいかな。
ガキのころからやってる人だと「基本中の基本」で説明するまでもない事でも、
最近始めた人にとっては「そ～なんだ！」だったりするし。

**名前は開発中のものです。** · 2006/12/03(日) 19:33:40

その「基本中の基本」やTipsを纏めたものがリファレンスなんだけどな…。

**名前は開発中のものです。** · 2006/12/04(月) 01:36:57

Tipsで思い出した、そういや熊野なんちゃらって奴の解説サイト、書いてる事が嘘八百だらけなんだが。
初心者向けに敢えて間違ってても理解し易く、とかじゃなくて本人の思い込みや脳内補完だらけだ

やる気のある中途半端ほど手に負えないもんはないな

**名前は開発中のものです。** · 2006/12/04(月) 01:53:35

>748
>最初に設計をしっかりしておくってのは大前提だと思うけど。

冗長性もたせてたけど、その冗長性を忘れて結局組み直す俺がいる。
っていうか読み直すよりそっちのが断然早いし、
当時よりもいろいろわきまえて使い勝手良い物作れるし。
コーディング完璧、これ以上直す事はそうそうないって人じゃないと意味ない。

**名前は開発中のものです。** · 2006/12/04(月) 02:12:24

>>751
一部の例外を除いて、今ある講座の多くはシナリオライター出身が
書いてるみたいだから仕方ないんじゃね？
気になるなら指摘してやればいいと思う

**名前は開発中のものです。** · 2006/12/04(月) 03:36:52

そういうのをいちいち指摘してるとバカが叩かれてると思い込んで突然反乱起こすことがあるんだよな。
揚げ句の果てに人を悪者扱い。嘘八百が広まると究極的にweb pageがhome pageみたいな事になるから
嘘ばらまいてる奴のために言ってるんじゃなくて嘘を刷り込まれてる奴のために言ってんのに。

文だけじゃ分かり辛い話だな。

**名前は開発中のものです。** · 2006/12/04(月) 03:41:02

>>751
せっかくだからどのへんが間違ってるか例をあげてみてほしい。
そこのサイトをぱっと見た感じ、読んだ初心者が盲信しそうな雰囲気だと思った。
（きっぱりはっきり書いてあるあたりが）
ていうか初心者っておれだけど。
ぐぐって引っ掛かったのがこのページだったら100%参考にしてたと思う。

**名前は開発中のものです。** · 2006/12/04(月) 04:04:01

>上級者向けの命令はあえて「出来ない」と書いたり、正しくない用語を使う場合があります。
まずこれの意味が分からない

**名前は開発中のものです。** · 2006/12/04(月) 04:40:45

>756
そのサイトしらんから見てないけど好意的に解釈するなら
・前者は、出来ないことはないけど、初心者にはややこしいから出来ないことにしておく。

・後者は、厳密には違うけど説明が煩雑になるので一般的に広まってる言葉で統一。
　スクリプト→プログラム　ウェブサイト→ホームページみたいな。

ってところじゃないのかなぁ。

**名前は開発中のものです。** · 2006/12/04(月) 07:04:37

軽く読んでみたけど、確かに間違い多いな

基礎知識編
１．吉里吉里の定義
　　この時点ですでに怪しいorz
２．フォルダの中身を理解する
　　フォルダの名前が間違ってる
５．KAGと tjs
　　ksはKAGシナリオの略じゃ・・・
７．命令文の定義
　　@も[]もKAG2の頃から使えた
作成準備編
２．文字装飾をつける
　　R40% G90% B20% → 409020じゃねぇｗ
シナリオ編
３．別のシナリオに移動する
　　同一シナリオ内のラベルは全て違う名前を付ける必要があります→推奨なだけ
音声編
１．音声ファイルの種類
　　OGG（おっじ）形式→オッグですhttp://ja.wikipedia.org/wiki/Ogg

極め付けが企画管理編
８．動作環境
　　CPU 200MHz、メモリ64MBなんて、そもそもXPが動かねえｗ

この様子だとほとんどのページに何かしら間違いがあると思われ

**名前は開発中のものです。** · 2006/12/04(月) 07:15:46

h 切り忘れたorz

**名前は開発中のものです。** · 2006/12/04(月) 08:46:55

一つの講座サイトを作り上げた労力とやる気はすごいと思うんだが、
間違いが広まるのは何とも…
まぁ、ゲームは作れるだろうけどな

おっじ…

**名前は開発中のものです。** · 2006/12/04(月) 09:19:26

プラグインが拡張機能だもんな。
どいつもこいつもわざと言ってるとしか思えん・・・Plug-insとExtensionsを何故同一視するんだろうか？

俺のKAGにはKAGPluginクラスを継承したExtensionクラスがあるんだがｗ

因みにプラグインに必要なものをXP3に固めてスクリプトからXP3をロードすれば必要な処理と管理は勝手にやってくれるようになってる。

**tom@** · 2006/12/04(月) 12:58:42

　コンニチハ、今秋、KAGをはじめたモノです。
大体のことは、タグで間に合ってしまうけど、随所、tjsすると嬉しいこともあり・・・・・・
地道にノロノロ「吉里吉里&tjs」の腕を上げようか？小手先で済まそうか？思案の今日この頃。幾つか、質問させて下さい。

1.例えば、「MessageLayer.tjs」内の「setFocusToLink(n, true)」とか、KAGのtjsファイル内のメソッドとかで、
「もっとTJSを」に示唆はないけれど、シナリオファイルの中でも、
便利に使い回せそうなものを、まとめてあるみたいな文献ってWEB上で入手可能でしょうか？
解析の腕はないけど、手軽に利用できるものは、利用してみたいといったスタンスです。

2.「ｔｊｓマニュアル」を読んでも、「クロージャ」とか「incontextof」とか辺りの説明が、
ざっぱん理解できません、「猿でも解る」的な説明がどこかにないでしょうか？

3.もしかして、ストレージ(.mid)からファイルの属性(特にタイトルとコメントと作成者)を取得するプラグインとかってないでしょうか？

以上、よろしくお願いいたします。
（入手済みの資料には、「gutchie」氏の「TJS入門(ダンロード版)」があります）

**名前は開発中のものです。** · 2006/12/04(月) 13:39:59

単発tipならやってる所はあるだろうがある程度体系だったものとなると
質以前にリファレンスとTJS入門の２ヶ所しかないのが現状。

**名前は開発中のものです。** · 2006/12/04(月) 14:11:11

>>762
closure とか incontextof とかは、javascript やっていると理解しやすい……と思う
ある程度他のプログラム言語弄ったことがあれば、TJS にもそのまま応用利くよー

**名前は開発中のものです。** · 2006/12/04(月) 16:07:12

下記のボタンを画面上に常に表示し、クリックすることでヒストリ表示を
させたいと思っています。

[button graphic="hoe.png" exp="kag.onShowHistoryMenuItemClick()"]

しかし文字が表示しきっていない時やトランジション中に実行すると
おかしなことになってしまうので、それらの動作中は実行しないように
したいのですが、どのようにしたらいいでしょうか？

上記タイミングだとメニューバーの文字がグレーになるので
それと同じようにしたいです。

過去ログでconductor関係が書かれていたのでそれをやってみましたが、
トランジションまで止めるわけではないんですね。

**名前は開発中のものです。** · 2006/12/04(月) 16:40:59

>>765
そのメニューバーのグレー処理を行っているところの判定文をまねればよろしい。
具体的には setMenuAccessibleAll() を覗くべし。

　まあ、すでにそのメニューバーがグレーになってること自体をつかって
　if (kag.showHistoryMenuItem.enabled) kag.onShowHisotyrMenuItemClick();
とやればいいんじゃないかと

**名前は開発中のものです。** · 2006/12/04(月) 17:05:01

ボタンを押すと[stop～]が実行されればいいんでないかい

**名前は開発中のものです。** · 2006/12/04(月) 17:14:55

>>765
ttp://kgs.tenkyu.com/s2/028.htm
まぁここまでせんでもボタン表示直後にロック、
クリック待ちの直前でアンロックしてやるマクロで充分な気もする

**名前は開発中のものです。** · 2006/12/04(月) 18:03:57

>>765
onShowHistoryMenuItemClick じゃなくて showHistoryByKey を呼び出せば良いはず
この関数は、メニュー項目の有効・無効を調べて有効だったらクリックを呼び出しているから、ちょうど良いと思う

**765** · 2006/12/04(月) 18:16:31

>>766-769
みなさんありがとうございます！
>>768 さんに紹介していただいたプラグインで実現することができました。
確かに [l][s][p] で切り替えるマクロもありでしたね。

#発言番号「765（namco）」だったことに気付いてちょっと嬉しいｗ

**名前は開発中のものです。** · 2006/12/04(月) 20:03:32

>>764
tjsのクロージャはjavascriptとはまったく別物だぞ

**名前は開発中のものです。** · 2006/12/04(月) 20:45:31

チラシの裏ですよ。
右クリックサブルーチンで行きつ戻りつしていると、
[s]タグで停止しているのにページ末に出るクリック待ちのアレが出現。
操作に支障はないけど見苦しいから飛ぶ直前に、
kag.lastClickGlyphVisible = false;
として回避した。もう、力技ｗ

検索しても出てこなかったのでメモってことで。
…普通は別の手を使うのかもしれんが。

**名前は開発中のものです。** · 2006/12/04(月) 21:48:24

>>771
挙動は違っても、本質は同じだと思ってる

**名前は開発中のものです。** · 2006/12/04(月) 21:57:34

>772
サブルーチン中に無駄な改行かスペースがあるんじゃまい？

**772** · 2006/12/04(月) 23:03:52

>>774
えーと、俺も最初それを疑ったけどないっぽい。
ゲーム本編＞右クリサブ＞タイトル[s]＞
コンフィグ(サブルーチン)＞タイトル「▼出現」
と移動すると起こる現象で、ゲーム本編のクリック待ちサインをKAGが
覚えてて、ジャンプ前の状態復帰をしようとしてこうなるみたい。
安易にサブルーチンの戻り先いじるとはまるよって事すかね。

解決に二日かかったです。一日は原因の切り分けに無駄実験で浪費orz

**名前は開発中のものです。** · 2006/12/04(月) 23:28:34

こんにちは。
テキストの速度変更するのにこんな感じに書きました。

[button graphic="～" exp="kag.chNoWaitMenuItem.click()"]
[button graphic="～" exp="kag.chSlowMenuItem.click()"]

クリックするとメニューの「表示速度」は確かに目的のものに変わるのですが
実際の文字表示が変わってくれません。

もう一度クリックするとメニューのほうは同じように変わるのですが、
実際の文字表示は「直前にクリックした速度」になってしまいます。

なぜこんな現象になってしまうのでしょう？
メニューから選択すると目的の速度になってくれます。

**772** · 2006/12/04(月) 23:51:15

>>776
未検証だが
exp="kag.chNoWaitMenuItem.click();onChSpeedMenuItemClick()"
ではいかがか。

Menus.tjs
Mainwindow.tjs
を見た感じコレでいいかと

**名前は開発中のものです。** · 2006/12/04(月) 23:54:09

ごめん、うそ言ったorz

**名前は開発中のものです。** · 2006/12/05(火) 00:07:04

exp="kag.chNoWaitMenuItem.click();kag.setUserSpeed()"
でいいとおも
俺も始めて一ヶ月未満ｗ

**名前は開発中のものです。** · 2006/12/05(火) 00:21:51

chNoWaitMenuItem.click() を呼び出した後に呼び出されるであろう onChSpeedMenuItemClick では
ちゃんと setUserSpeed やってるはずなんだけど……どうなんだろうね。

exp="kag.onChSpeedMenuItemClick(kag.chNoWaitMenuItem);"
↑できたら、これも試してみてくれ

**名前は開発中のものです。** · 2006/12/05(火) 00:24:15

>775
ああ、なるほど。
タイトルへはgotostartで戻ったほうがいいと思われ。

**名前は開発中のものです。** · 2006/12/05(火) 00:24:16

>776
temploadとかしてるんじゃねえの

**名前は開発中のものです。** · 2006/12/05(火) 00:28:36

あ、ほんとだ。つーことは
kag.setDelay(elm)
してやるしかないか。elmって何だ？どうやって投げるのかね。
つーか素直に[delay speed=user cond="kag.chUserMode"]
しろってかｗ

**名前は開発中のものです。** · 2006/12/05(火) 00:32:43

>>781
あぁ、そんなタグもあったかｗ
その方が綺麗だ、うん。

確認ダイアログまで手作りした俺は何だったのか…

**名前は開発中のものです。** · 2006/12/05(火) 00:40:13

>>783
elm なら、kag.setDelay(%[ speed => "user" ]) な感じで辞書渡してやれば OK

**名前は開発中のものです。** · 2006/12/05(火) 00:46:57

>>785みたいな渡し方したときの辞書配列って関数やメソッド抜けたら開放されるの？

**名前は開発中のものです。** · 2006/12/05(火) 00:51:52

>>777-780,782-785
[tempload]が原因でした！！
設定画面の出し入れに [tempload] [tempsave] を入れていたのですが、
外しても特に問題なかったのでそれでいきたいと思います。
ありがとうございましたー。

**名前は開発中のものです。** · 2006/12/05(火) 00:56:15

>>786
効率の良し悪しは別として、一応リファレンス見る限り
＞invalidate 演算子を用いなくても、オブジェクトは必要とされなくなった時点で削除されます。
って書いてあるから、最低限のガベコレは実装されてるはず

**名前は開発中のものです。** · 2006/12/05(火) 01:16:26

でも吉里吉里のGCは循環参照見てないから
　(d=%[]).d=d;
とかで消えないゴミができるんじゃないか

**名前は開発中のものです。** · 2006/12/05(火) 01:24:09

>>786
式中辞書配列

**名前は開発中のものです。** · 2006/12/05(火) 02:25:52

>>789
確かに。kirikiri2 だと参照カウンタだったですね (´･ω･`)
ttps://sv.kikyou.info/trac/kirikiri/browser/kirikiri2/branches/2.28stable/kirikiri2/src/core/tjs2/tjsObject.cpp#L120

kirikiri3 だと、ちょっと賢くなるみたいだけど……
ttps://sv.kikyou.info/trac/kirikiri/browser/kirikiri3/branches/risse/src/core/risse/src/risseGC.h#L26

**名前は開発中のものです。** · 2006/12/05(火) 05:11:32

>>782
地味にすげぇ。エスパーｗ

**762** · 2006/12/05(火) 08:58:05

レス、ありがとう、ございました。
<A href="../test/read.cgi/gamedev/1160427850/763"
target=_blank>>>763</A>
　KAG本体の.tjs
　体系的な資料があれば、何かと便利ですが、コメント文もしっかり付いている
ことですし、随所の親切なTipsな翻弄されながら、溜めが出来たら、気長に暇をみて、
少ずつ、自分なりに整理してみることにします。

<A href="../test/read.cgi/gamedev/1160427850/764"
target=_blank>>>764</A>,771,773
　「TJS入門」のサンプルコードをいじっていたら、少しだけ、イメージ涌いてきました。
　incontextofで、余所のオブジェクトのメソッドをさらって来て、同化しちゃうみたいな。
クラスの定義の時点でオーバーライドとか、しなくても、オブジェクト作っちゃってから
でもいいよ、とかいう事なのか？何が嬉しいのか？？？
　JavaScript、
　手元にある資料はド素人用のものばかりで、説明がなかったので、そのうち、
本屋にでも行ってきます。

**762** · 2006/12/05(火) 09:02:13

↑参照の書き方、失敗した。スミマセン。
>>763
>>764
で良いのか？また、違っていたらマジごめんなさい！

**名前は開発中のものです。** · 2006/12/05(火) 09:26:04

アンカーの付け方に萌えたw

**名前は開発中のものです。** · 2006/12/05(火) 15:25:45

>>794
あとはmail欄に sage って入れればおｋ

**名前は開発中のものです。** · 2006/12/05(火) 21:52:04

>>765だけど、kag.inStableを見るだけじゃ足りない？
教えてｴﾛい人！

**名前は開発中のものです。** · 2006/12/05(火) 22:38:26

>797
俺もinStableで判別させてるけど、変な挙動はしてないよ。
waitclick時には呼び出せないけど。

**名前は開発中のものです。** · 2006/12/05(火) 22:45:14

×>>765だけど
○>>765の件だけど
ね、一応。

>>798
waitclickはinStableがfalseになるってこと？

**名前は開発中のものです。** · 2006/12/05(火) 23:02:08

>799
うお、ごめん。
>waitclickはinStableがfalseになるってこと？
そう、クリック待ちや[s]タグで停止中のみtrue(安定走行中)になるみたい。
ちなみにmove中でもクリック待ちがあればtrue返すね。

**名前は開発中のものです。** · 2006/12/05(火) 23:15:11

move中でもtrue返すことがあるならkag.inStableみるだけじゃ場合によっては足りないかもしれないですね。

その時はトランジション判定（トランジション数が0か否か）も一緒にしておけばいいのかな。

**名前は開発中のものです。** · 2006/12/06(水) 00:18:59

複数の Layer が loadImage で同じストレージを読み込んだとき、
内部データは assignImages と同じように共有されるんですか？

**名前は開発中のものです。** · 2006/12/06(水) 00:48:03

されない

**名前は開発中のものです。** · 2006/12/06(水) 01:06:23

>801
確かmoveはtransCountに数えられなかったと思うな。
俺はlocklinkかsetSelProcessLockか、waitclick使う手もあるかな、くらいしか思いつかないorz
呼び出し先で弄らない限りmoveには影響ないし、俺はそのまま使ってるけど。
特に765の履歴くらいなら問題なさそう。

**名前は開発中のものです。** · 2006/12/06(水) 01:17:16

>>804
moveみたけりゃmoveCountで見れるんじゃね

**名前は開発中のものです。** · 2006/12/06(水) 01:33:01

>805
おお、どうもです。…俺アフォスorz

**名前は開発中のものです。** · 2006/12/06(水) 02:13:41

>>802
されます（ただし前回読み込んだ画像が画像キャッシュに残ってる場合）

**名前は開発中のものです。** · 2006/12/06(水) 09:50:07

予め大量の画像ファイルをキャッシュしておきたいのですが
どう書くのが効率良いですか？

visible=falseで全部指定？

**名前は開発中のものです。** · 2006/12/06(水) 12:10:35

>>803 >>807
thx

数十個の ButtonLayer に対し、ほぼ同時に同じ画像を読み込もうとしてたので、
多分キャッシュされていますね。ありがとうございます。

**名前は開発中のものです。** · 2006/12/06(水) 12:23:26

touchImage()

**名前は開発中のものです。** · 2006/12/06(水) 12:24:44

>808
OUTFOCUS WikiのKAGマクロ集に
システム関連でtouchimagesという画像データをキャッシュするマクロがある
ttp://hpcgi1.nifty.com/gutchie/wifky/wifky.pl?p=KAG%A5%DE%A5%AF%A5%ED%BD%B8
ので、このマクロのstorages属性に、
キャッシュさせたい画像ファイル名を「;」で区切った文字列を指定すると
効率が良さそうです。

**名前は開発中のものです。** · 2006/12/06(水) 13:16:18

touchImageが実際にキャッシュするかどうかはVMが決める。確実にキャッシュするならオフスクリーンに全部描画しかない。

効率もくそも確実にやるにはこれしかない。
それかキャッシュするネイティブコードを書くか

**名前は開発中のものです。** · 2006/12/06(水) 13:41:37

>touchImageが実際にキャッシュするかどうかはVMが決める。
いやいやそこはVMじゃないし

>確実にキャッシュするならオフスクリーンに全部描画しかない。
「描画」という言葉のイメージから想像できるようなことは
やらんだろうなぁ

ttp://devdoc.kikyou.info/tvp/docs/kag3doc/contents/TJSTips.html#id276

ここ参照

**名前は開発中のものです。** · 2006/12/06(水) 14:27:46

何か勘違いしてるようだけどキャッシュと画像の共有は別物ですよ

**名前は開発中のものです。** · 2006/12/06(水) 14:31:43

おっと、>>807宛てね。

**名前は開発中のものです。** · 2006/12/06(水) 16:59:34

どのレベルで「別物」って言っているのかわからないけど、別物だという根拠は？

**名前は開発中のものです。** · 2006/12/06(水) 17:11:15

>>802
画像に対して共有が解除されるような処理をしなければ
共有されますよ。

キャッシュは行わないようにも出来るので
共有とは別のお話しです。

**名前は開発中のものです。** · 2006/12/06(水) 18:06:58

touchImageは画像をメモリに置こうとしてるからフラグ立てて数値的なメタデータを同一にするだけでメモリいじってないassignImagesとは処理が違うと思うぞ？

レイヤが画像へのポインタ持ってるだけならデータは一カ所にしてtouchImageとloadImagesでアクセスするメモリは同じでよさそうだけどそれだとキャッシュ用メモリの指定プロパティいらないし

問題はloadImagesとtouchImageがどういう処理してるかだろ。

>>807はただのバカと吉里吉里の実装知ってるのとどっちなんだ？

**名前は開発中のものです。** · 2006/12/06(水) 18:52:16

>>816-818
touchImagesでの画像キャッシュっていうのは
loadImagesで読み込む際に外部ファイルから読み込むのではなくて
メモリ上のデータを読み込むのに使われてます。
外部ファイルから読み込むよりメモリから読み込む方がずっと高速なので
予めキャッシュに入れておくことで画像読み込みを高速化できます。
この場合、ただ読み込み元が違うだけで個々のレイヤのグラフィックハンドルは別々に作成されるから
読み込めば読み込むほどメモリを消費することになります。

一方、assignImagesの場合は、グラフィックハンドルをコピーするだけなので
画像の読み込み自体が行われません。assignImagesで複数レイヤに画像を使っても、
画像自体の使用メモリは最初に読み込んだ画像のみです。
ポインタをコピーするだけだから、最も高速です。

実際の操作として何が違うのかというと、
例えば、layer1、layer2、layer3の画像をそれぞれassignImagesで共有させた場合、
layer1の画像をfillRectなどで塗り潰した場合、layer2、layer3の画像も変化します。
キャッシュからそれぞれに同じ画像を読み込ませた場合は、
それぞれ異なるグラフィックハンドルなわけで、
layer1の画像に変更を加えてもlayer2、layer3は変化しません。

どういうレベルとか関係なく、キャッシュと共有とでは内部処理そのものが違います。
ちなみに、通常loadImagesで同じ画像を読み込んだ場合には画像の共有はされていません。

**名前は開発中のものです。** · 2006/12/06(水) 19:07:23

値渡しと参照渡し

**名前は開発中のものです。** · 2006/12/06(水) 20:12:19

えーと、じゃあ実装レベルでの説明します

>例えば、layer1、layer2、layer3の画像をそれぞれassignImagesで共有させた場合、
>layer1の画像をfillRectなどで塗り潰した場合、layer2、layer3の画像も変化します。
しません。というか変化したらたぶんバグです。
なぜかというと、画像に変更を加える直前に共有が解除されるからです。
(例)
tTJSNI_BaseLayer::FillRect()->tTVPBaseBitmap::Fill()->tTVPNativeBaseBitmap::GetScanLineForWrite()->
tTVPNativeBaseBitmap::Independ()

画像キャッシュと画像の共有は根本的には同じ処理です。
画像が読み込まれてキャッシュに入る場合は
ttps://sv.kikyou.info/trac/kirikiri/browser/kirikiri2/tags/2.29-dev.20061119/kirikiri2/src/core/visual/GraphicsLoaderIntf.cpp#L2464 TVPLoadGraphic()
ttps://sv.kikyou.info/trac/kirikiri/browser/kirikiri2/tags/2.29-dev.20061119/kirikiri2/src/core/visual/GraphicsLoaderIntf.cpp#L2081 tTVPGraphicImageData::AssignBitmap()
ttps://sv.kikyou.info/trac/kirikiri/browser/kirikiri2/tags/2.29-dev.20061119/kirikiri2/src/core/visual/LayerBitmapIntf.h#L133 tTVPBaseBitmap::tTVPBaseBitmap()
ttps://sv.kikyou.info/trac/kirikiri/browser/kirikiri2/tags/2.29-dev.20061119/kirikiri2/src/core/visual/win32/LayerBitmapImpl.cpp#L1749 tTVPNativeBaseBitmap::tTVPNativeBaseBitmap()
ここでBitmap=r.Bitmapとなっています。BitmapはtTVPBitmap *型で画像バッファを表しています。
つまり、実体であるtTVPBitmapへのポインタのコピーをしているだけです。
(TVPAllocGraphicCacheOnHeapはTVPAfterSystemInit()内で常にfalseに設定されている)

**名前は開発中のものです。** · 2006/12/06(水) 20:13:45

画像がキャッシュから読み込まれる場合は
ttps://sv.kikyou.info/trac/kirikiri/browser/kirikiri2/tags/2.29-dev.20061119/kirikiri2/src/core/visual/GraphicsLoaderIntf.cpp#L2438 TVPLoadGraphic()
ttps://sv.kikyou.info/trac/kirikiri/browser/kirikiri2/tags/2.29-dev.20061119/kirikiri2/src/core/visual/GraphicsLoaderIntf.cpp#L2103 tTVPGraphicImageData::AssignToBitmap()
ttps://sv.kikyou.info/trac/kirikiri/browser/kirikiri2/tags/2.29-dev.20061119/kirikiri2/src/core/visual/win32/LayerBitmapImpl.cpp#L1855 tTBPNativeBaseBitmap::AssignBitmap()
ここでBitmap = rhs.Bitmapとなっています。ここでも実体であるtTVPBitmapへの
ポインタのコピーをしているだけです。

画像の共有をする場合はたとえば
ttps://sv.kikyou.info/trac/kirikiri/browser/kirikiri2/tags/2.29-dev.20061119/kirikiri2/src/core/visual/LayerIntf.cpp#2090 tTJSNI_BaseLayer::AssignImages()
ttps://sv.kikyou.info/trac/kirikiri/browser/kirikiri2/tags/2.29-dev.20061119/kirikiri2/src/core/visual/win32/LayerBitmapImpl.cpp#L1835 tTBPNativeBaseBitmap::Assign()
ここでBitmap = rhs.Bitmapとなっています。ここでも(ry

というわけでどの場合も画像の実体であるtTVPBitmapへのポインタをコピーしてる
だけで、根底にある動作はどれも同じです。グラフィックハンドルが異なるとか
そーいうことは無いということです。

**名前は開発中のものです。** · 2006/12/07(木) 13:22:22

>>822
ソース読んできた。C++のソースがぐちゃぐちゃになりやすいのかDee氏のソースが汚いのか悩んだJava厨です・・・（°ω °）

メジャーver上げる度ソース捨てるのって保守性を確保する理由もあるんじゃ・・・ｗ

バイナリだろうとテキストだろうとファイルにアクセスするクラスは実装されてるのにTJSから直接使えんのね。

＃ところでお前ら実装の話になると黙るのに憶測で話すとレス伸びるなｗ

**名前は開発中のものです。** · 2006/12/07(木) 13:36:55

おまいらの話なんて＼(^o^)／ﾜｹﾜｶﾗﾝ

**名前は開発中のものです。** · 2006/12/07(木) 13:45:37

ほとんどKAGしか使えない人間の俺にはどうでもいい

**名前は開発中のものです。** · 2006/12/07(木) 16:27:49

コールスタックについて質問があります。

ロード画面を kag.callExtraConductor('savescreen.ks','*showLoad') で呼び、

*showLoad
[layopt layer="message0" visible="false"]
[layopt layer="message1" visible="true"]
[current layer="message1"]
ボタン表示
[s]
[return]

としています。実際はクロスフェード処理など入れてありますが省略します。
ここから栞のロードをするにしても、ロード画面を閉じるにしても、
[s] で止まったまま [return] に行かず、スタックが溜まったりしないのかと
心配になったのですが、実際はどうなのでしょうか？

**名前は開発中のものです。** · 2006/12/07(木) 17:43:56

止まるだろ。普通に考えて(´･ω･`)

**名前は開発中のものです。** · 2006/12/07(木) 18:27:47

>>826
[return]で戻らないなら
kag.process('savescreen.ks','*showLoad');
でいいじゃないか

**名前は開発中のものです。** · 2006/12/07(木) 18:59:51

>>682
瑣末な、気付き。
　[style linespacing=40]
　[link ～]・・・[endlink][r]
　[style linespacing=20]
　[link ～]・・・[endlink][r][s]
で、最後の[r]タグがないと、
リンクと半透明矩形の位置がずれるのネッ。

p.s.
＞795,796
ツッコミ、サンキュー。
mail欄に sageですね。おk?