▼ノベルゲームツールを作っちゃうぞ!Ver4.0
■ このスレッドは過去ログ倉庫に格納されています
ADVサンプル、完成しましたっ!
今夜にはアップロード予定ですっ…!
とりあえず今からはテストと添付テキストを用意せねば…。
そして231氏すみません、結局考えた結果クリア後の設定表示を省きました。
粋なインターフェースを思いつかなかったというのと、スタンダードなサンプルにするというのが主な理由です。
代わりに、設定のテキストファイルを添付する形にしようかと思います。
>設定のテキストファイルを添付する形にしようかと思います。
それでおk。readonly属性付けてね。
でもう夜なわけだが
マダカネ?AAry
wktk お盆休みのバイト納めにうきうきしていると…あ、こんな時間orz
はめを外しすぎました、明日中にはアップロードできると思いますorz
(一応、こそこそと色んな付加要素も作っていたり。こういうことも出来るぞ、的な) GJ!
さて話の続きは考えてあるのだが。どうしようか・・・。 さて、ADVサンプルをアップロードしたことで一区切りがつきました。
今後の予定は、
・大規模なアップデート(Ver1.100→Ver1.200に)
・画面効果・画面更新・命令の追加
・他サンプルの作成
上記のような感じです。
具体的には、
text(禁則処理、複数分割、表示位置調整(センタリング)、ウエイト、カラー、スピード、サイズ、フォント、文字間、行間、ルビ)
quake(揺れ回数)
update(より多くのパターンを実装する(シャッター、カーテン、スクロール))
volume(voicevolumeを実装する)(voiceあるいはtextvを用意するべきか?)
select(制限時間付きの選択肢も用意する)(新命令として用意するべきか?)
出来れば(桜・雪・雨・蛍などの特殊演出、乱数、for〜next、break;)
BaseDrawManager(テキストの最大縦幅を取得できるようにする)
テキストカーソルを絶対位置で設置可能
DefOut(ハードコーディング(define)をファイル外部から変更可能にする)
といった感じです(メモをコピペしただけですので分かりづらいですね/汗)
サンプルの作成は、
SLGサンプル、RPGサンプル、STGサンプルといったものを考えております。
希望があれば受け付けますので、レスして頂ければと。
>>231
そうですね、此方のスタンスとしては「何れゲームを作成する為にベース(AbyssLib)を作成している」です。
ですので基本的にはAbyssLibに傾注しますが、より本格的なADVをAbyssLibのテストも兼ねて作成してみたいと思っております。
長々とあれですが、要は「やるならプログラム・スクリプトは頑張るよ!」ということです。絵とか音楽とかは才能ないので無理です(笑
本格的に作るのであれば人材募集は必須でしょう、そういった面を行うつもりがあるのであればプロジェクトとして作るのもいいかもしれません。 java ME MIDP 2.0向け ADVエンジンのソース公開しますた。
ttp://sourceforge.jp/projects/lixm/downloads/32555/Ayane_src_2008_08_16.zip
このエンジンはプログラマ向けのADVエンジンフレームワークであってプログラミングできない人向けではありません。
開発には最低でもJDK+WTKを必要とします。
ちなみに私の開発環境は
JDK6u4
WTK2.2+パッチ
eclipse
eclipseME
です。
CLDC1.1+MIDP2.0な環境なら理論上動きますがRAMを多く食うのでjavaヒープの少ない端末ではOutOfMemErrがでると思います。
また、ターゲットとする端末向けにカスタマイズする必要がある部分があるかもしれません。
ライセンスはBSDなので著作権表示さえしてもらえればソースの改変等は自由です。
まだドキュメントを用意してないので知りたい事があればソースを読んで下さい。
・・・以上! わかったらとっととダウンロードしなさいよね!? お盆も終わりましたね、また忙しくなります(´Д`)
そろそろフルスロットルをと頑張り中です、とりあえず斜体と太字を扱えるように現在ソースを弄っております。
此処が完成したら、多分ルビとかは簡単に実装できるでしょうし………新バージョンは、今月末にはお披露目できるかなと思います(願望 お久しぶりです(´―`)
DAT落ち防止も兼ねて、報告をと。
現在、スランプ中にて遅々として進まぬ状態です…が、何とかコーディングは四割方終わらせました。
まあ、デバッグやテストを含めると全体の二割といったところですが………遅くとも、今月末には大規模アップデートを行ったAbyssLibをお見せできると思います(´Д`) 月末に、と申し上げましたがコーディングが遅々として進まず遅れる可能性大です(;´Д`)
それにしてもレス少ないですね、というわけでアンケートでもとってみようかと思います。
次期バージョンではテキストにルビを振れるよう、現在開発しております。
で、ルビの仕様を悩んでいるのです。
1.ルビのフォント
A.固定
B.スクリプト内で変更可能
2.ルビのサイズ
A.固定
B.スクリプト内で変更可能
3.ルビのカラー
A.固定
B.ルビを振った文字のカラーに順ずる
C.スクリプト内で変更可能(Bのように順ずるのも含めて)
4.ルビのスタイル
A.フォント・サイズ・カラーはルビ中で変更なし
B.フォント・サイズ・カラーはルビ中で変更可能
もう少し詳しく説明しますと、たとえば「命」に「ライフ」とルビを振ったとしましょう。
Aの場合はMSゴシック、10pt、#FFFFFFなら「ライフ」全てがそれに従い、
Bの場合はタグによって「イ」だけMS明朝、12pt、#FF0000が可能ということです。
個人的にはルビは見易さ重視で考えるとAの方がいい気はするのですが…(実装も楽ですし) 俺ならこれで実装する。
1.ルビのフォント
A.固定(ルビを振る文字のフェースを使う)
2.ルビのサイズ
B.スクリプト内で変更可能
3.ルビのカラー
C.スクリプト内で変更可能(Bのように順ずるのも含めて)
4.ルビのスタイル
B.フォント・サイズ・カラーはルビ中で変更可能
最低限、吉里吉里とNスクに出来ることくらい実装しないと再開発する意味がないかと。 変更可能なら固定のときの統一したのも作れるからいいんでない?とプログラミングの知識のないやつが苦労も知らず アンケートにお答え感謝です。
一応、B、B、C、Bにしておこうかと。
>>319
ですよね、ちなみに調べたところ
NScripterはB、B、B、不明(恐らくA)、
吉里吉里は不明(恐らくAか文字に順ずる)、A、不明(恐らくAかB)、不明(恐らくA)です。
>>320
苦労は然程ないのですよ、複雑で面倒ではありませんが難しくはありませんので。
ただ、スクリプトの自由度を高めれば高めるほどスクリプトが複雑怪奇になるのが問題です。
ルビのサイズを例にしましょう
まず、ルビの存在を認めるのなら文章に行間を設けなければなりません。
そしてルビのサイズを固定でなく可変にするなら、当然行間も固定でなく可変でなければなりません。
ところが、行間を可変にすると見た目が著しく悪くなることがあります。ルビのサイズをとある一行だけ72ptにした場合を考えてみてください。
また、ルビは通常文字に被さるべきものではありませんが文字に被せたいと思う人が居るかもしれません。
以上のことを考えると、ルビのサイズを可変にするなら1.各行の行間を個別に設定できるようにする、2.デフォルトの行間を設定できるようにする、
3.ルビのサイズ>行間なら行間を拡張するかのフラグの三つが必要になり、ユーザーはデフォルトの行間を設定、ルビのサイズを設定、
それに合わせての行間を設定、行間を自動で拡張するかのフラグの設定の四つを行う必要が生じます。
この方法は自由度が高い反面、設定しなければならないこと、覚えなければならない仕様などが増大します。
個人的に、こういった仕様は悪仕様だと思うのです。自由度を制限する反面、扱いやすいものを提供すべきかなと。
自由度の限りなく高いノベルゲームツールを求めるのでしたら、マイクロソフトのサイトに世界中でデバッグされてバグが限りなく少ないであろう
ものがあるわけですし(VS2008ですね) 個人的にはNScripter>吉里吉里です、扱い易いのが非プログラマには良いでしょうし。
今のところ、ライブラリ側では自由度を高くしておきスクリプト側で制限をかけるというのが一番いいかなと思っております。
(吉里吉里のKAGとかはそんな感じっぽいですね)
なので、今後はそういった方向で開発していこうかと思っております。 DAT落ち防止を兼ねて報告を。
今現在、AbyssLibのコーディングを六割方終わらせました。
今現在までに行ったことは、
・全ソースコードの見直し:いくつかバグを発見し修正(追加要素でエンバグする可能性大ですが)
・文字列の拡張:テキスト、発言者名、文字列スプライトなどでタグを用いて文中でフォントなどの変更が可能に。
・ルビ:文字列の拡張に伴い、ルビの使用が可能に。ルビでもタグを用いて文中でフォントなどの変更が可能です。
・音声を実装:SE、BGMに加えて音声関連のメンバ関数をサウンド用デバイスクラスに実装しました。
今後は、
・DefOut:現在、定数は#defineで定義していますがそれを外部ファイルから変更可能にします。
・シーンのクラス化:既読履歴、環境設定などのシーンをクラス化してNovelPlayerクラスから分離させます。
・オブジェクトファイルの追加ロード:オブジェクトファイルを追加で読み込むことが可能になるようにします。
といった感じです。AbyssLibの変更に付随して他も変更しなければなりませんし…恐らく、来月末ぐらいまではかかるかと思われます。 文字のフォントをいじれるのはいいですね
太文字とか使いたいし >>321
そもそも行間のサイズを行の文字列から計算するのはどうなんでしょうか。 ルビと文字をかぶせたい場合に備えて、
ルビと文字の間隔は指定できた方がいいかもしれません。
このあたりはTexとか吉里吉里を参考にするといいと思います。 月末にAbyssLibだけでも公開できればと思うのですが…間に合うのかなぁ?(;´Д`)
>>325
行間のサイズを行の文字列から計算すると言いますと?
ちなみに今現在の使用は「ライブラリ側では行間を一切考慮しない」です。
行間に関する処理は全て非ライブラリ側(DLL)側に委任し実装させます。
現在のところ、ルビと文字の間隔は指定可能です…裏技めいた方法で、ですが。
その辺の仕様はDLLで吸収し、何の変哲もない間隔指定をスクリプトに追加する予定で。 >>327
> 行間のサイズを行の文字列から計算する
表示する段階でおそらく一行分の文字情報(文字の幅や高さなど)はすべてそろってると思うので、
そこから一行の高さを計算するということです。
つまり、一番縦に長い文字が行の高さを決定します。 というか、yaneSDK使ってるのなら、
CTextFastPlane オブジェクトの UpdateTextAA() 後に
行の高さと幅が決まるので、
GetSize でその値をそのまま持ってくればいいのかもしれません。 >>328
各行の縦幅(高さ)はその方法で算出していますね、問題は行間(行と行、行とルビ)なわけで…。
>>329
リーディングとは何でしょうか?
>>330
ScriptPlayerのグラフィック機能とサウンド機能にyaneSDKを使用しておりますが、
AbyssLibそのものにはCとC++とWindowsAPIのみを使用しております。
yaneSDKをAbyssLibそのもので使うと、yaneSDK必須になってしまうわけで…。 なんだか曖昧な話をしてしまっているような気がしますので、今現在における文字列の実装を以下で説明致します。
拡張された文字列に関わるクラスは、以下の通りです。
RubyTextToken
ルビの文字情報(字単位) 格納する情報は、
テキスト、サイズ、カラー、フォント、透過度、ボールドか?、イタリックか?、横幅、縦幅
RubyTextTokenLine
ルビの文字情報(行単位) vector<RubyTextToken>に縦幅と横幅の取得関数を付加したようなもの
TextToken
テキストの文字情報(字単位) 格納する情報は、
テキスト、サイズ、カラー、フォント、透過度、ボールドか?、イタリックか?、横幅、縦幅、ルビ
TextTokenLine
テキストの文字情報(行単位) vector<TextToken>に縦幅と横幅の取得関数を付加したようなもの
TextTokenSection
テキストの文字情報(文単位) vector<TextTokenLine>に縦幅と横幅の取得関数を付加したようなもの
RubyTextTokenSectionはありません、実装しようかとも考えたのですが深く考えると脳味噌が死にそうなので止めましたw
(実装した場合、ルビを改行したりといった変態的なことが可能にはなるのですが) >>331
UpdateTextAA云いはyaneSDKの場合の説明ですが、
大抵のシステムでは文字の幅と高さを得る何らかの方法があるので
yaneSDK必須ということにはなりません。
あと、ルビについては、確かに大きなサイズを設定するとレイアウトは狂ってしまうかもしれませんが
普通はそういうことはしませんし、そういうことをして表示が少し変になっても多分誰も気にしないと思うのです。
単純に、
[その行で一番長い文字の高さ] + [その行で一番長いルビ文字の高さ] + [ルビがあるならルビと文字の間隔] + [何らかの固定マージン]
で行の高さを決めるのはどうなんでしょうか。 拡張された文字列を描画する処理は、以下の通りです。
1.以下のような文字列があったとします(「ばら」および「すいしょう」はルビです)
ば ら
薔 薇
すい しょう
水 晶
2.以下のような変数を使用します。
x, y:文字列全体の描画位置(左上隅)
dx, dy:文字の描画位置(左下隅)
drx, dry:ルビの描画位置(左下隅)
3.変数の初期化を行います:dx = 0, dy = 0, drx = 0, dry = 0
4.dx = 0, dy += 「薔薇」の縦幅(「ばら」の縦幅を含む)
5.「ば
薔」を描画します。
5-1.(x+dx+(「薔」の横幅>「ば」の横幅 ? 0 : (「ば」の横幅-「薔」の横幅)/2), y+dy-「薔」の縦幅)に「薔」を描画します。
5-2.drx = dx + (「ば」の横幅>「薔」の横幅 ? 0 : (「薔」の横幅-「ば」の横幅)/2)
5-3.dry = dy - 「薔」の縦幅
5-4.「ば」を描画します。
5-4-1.(x+drx, y+dry-「ば」の縦幅)に「ば」を描画します。
5-4-2.drx += 「ば」の横幅
5-5.dx += 「薔」の横幅>「ば」の横幅 ? 「薔」の横幅 : 「ば」の横幅
6.「ら
薇」を描画します、処理は5.と同じです(「ば」→「ら」、「薔」→「薇」)
7.dx = 0, dy += 「水晶」の縦幅(「すいしょう」の縦幅を含む)
8.「すい
水 」を描画します。
8-1.「水」を描画します、処理は5-1.と同じです(「ば」→「すい」、「薔」→「水」)
8-2.drx = dx + (「すい」の横幅>「水」の横幅 ? 0 : (「水」の横幅-「すい」の横幅)/2)
8-3.dry = dy - 「水」の縦幅
8-4.「す」を描画します。
8-4-1.(x+drx, y+dry-「す」の縦幅)に「す」を描画します。
8-4-2.drx += 「す」の横幅
8-5.「い」を描画します、処理は8-4.と同じです(「す」→「い」)
8-6.dx += 「水」の横幅>「すい」の横幅 ? 「水」の横幅 : 「すい」の横幅
9.「しょう
晶 」を描画します。
9-1.「晶」を描画します、処理は5-1.と同じです(「ば」→「しょう」、「薔」→「晶」)
9-2.drx = dx + (「しょう」の横幅>「晶」の横幅 ? 0 : (「晶」の横幅-「しょう」の横幅)/2)
9-3.dry = dy - 「晶」の縦幅
9-4.「し」を描画します、処理は8-4.と同じです(「す」→「し」)
9-5.「ょ」を描画します、処理は8-4.と同じです(「す」→「ょ」)
9-6.「う」を描画します、処理は8-4.と同じです(「す」→「う」)
8-7.dx += 「晶」の横幅>「しょう」の横幅 ? 「晶」の横幅 : 「しょう」の横幅
こうすることで一文字単位でのサイズやカラーやフォントの変更が可能となり、文字の下端は確実に揃います。
この実装だと字間・行間を調整する項目がありませんが、
縦幅と横幅を持った空のテキストトークンを挿入することで調整は可能です。
(実装上、下にしか間をもうけられないので最上行のルビの上に間はもうけられませんが)
>>333
WindowsAPIにありますね、AbyssLib内部ではそれで縦幅と横幅を得ています。
ルビに関しては考えすぎかなとは思います、ただ考えておかないと予想もつかない使い方をする方も世の中には居られるでしょうし…。
行の高さは、今現在は[その行で一番長い[文字の高さ+ルビの高さ]]で実装しています。間隔や固定マージンは上記のように実装する形を予定しております。 >>336
ああ、なるほど。結局、1文字とルビをセットにして、
・X座標はその文字とルビで横幅の短い方が長い方の中心にくるように
・ルビのY座標はその文字の真上になるように
各文字を描画していくということですね。
たしか、吉里吉里も同じようなことをしていたと思います。 ざっと命令眺めてみたんですが、立ち絵のクロスフェードが無いような気がします…
それと、つい10日前ほどから自分用の2Dのゲームライブラリを作っているのですが、
もし使えるところまで完成したら、ためしに組み込んでもらえませんでしょうか?
拡張された文字列に字間と行間をもうける方法ですが、
以前に例に使った文字列(薔薇水晶(ばらすいしょう))を使って説明しますと、
1.字間(薔薇水晶の字間)
2.ルビ字間(ばらすいしょうの字間)
3.最上行のルビの上(ばの上)
4.最上行のルビと文字の行間(ばと薔の行間)
5.最上行の文字と次行のルビの行間(薔とすいの行間)、最上行と次行の行間(ともいえる筈)
6.最下行の文字の下(水の下)
とまず分類できます。
1.空のテキストトークンを挟めば簡単に字間をもうけられます
2.1.と同じです
3.仕様上不可能です(下にしか行間をもうけられないため)が、特に必要ないでしょう(多分)
4.ルビの縦幅をもうけたい行間の分だけ大きくします、そうすることで描画位置が上に上がり下に行間がもうけられます
5.4.と同じです
6.4.と同じですが、特に必要ないでしょう(多分)
こんな感じだと思われます、理論上………まだ、コーディングが完全に終わってないのでテストしていませんが(駄目じゃん)
このモデルで現在問題となっているのは、「複数文字に複数ルビを均等に割り当てることができない」ということです。
ひとつのテキストトークンに複数文字を収めることで理論上可能ではありますが、ただし文字送りの際に
その複数文字はひとつの文字とみなされて一気に出力されてしまいます(文字送りの問題があるから一文字単位で分割したわけで)
まあ、これは「鬼畜(きちく)」とかを表示する場合「ち」をどうするのかという問題上必ずしも悪仕様とはいえないわけですが………。
>>337
はい、そんな感じですね。
こうやってノベルゲームのライブラリを作ってると、Nスクと吉里吉里のガイドは必携です。
(萌え絵だったりするのd持っていると微妙に恥ずかしかったりしますが) >>338
画面の更新はupdateという命令で一括で行うようになっています、それにクロスフェードを指定する引数がありますので。
詳しくはヘルプおよびサンプルを参照して頂ければと。
そうですね、より多くの動作実績を積みたいのでゲームライブラリへの組み込みは歓迎です。
ただ、その際に「ここが組み込みにくい!」とか「ここをこうしてほしい!」とかが出来れば欲しいのでご自分で組んで頂ければ嬉しいです。
ですが私が組み込んでも「組み込みにくい!」とかは感じられるかもしれませんので、ライブラリ開発の合間を縫ってではありますが
希望されるのであれば組み込みも承ります。その場合は、ライブラリの仕様とかを分かりやすいよう提供して頂ければと。 なかなか作業が進まない、以前よりも時間は取れている筈なのに………orz
細かく作ってると色々と仕様に悩んだりもして、そういうのが大きい一因だったりもしますが(汗
たとえば、今現在選択肢を作り直しているのですが………。
選択肢のインターフェースとして表示する画像を、通常時、
カーソル時、ホールド時(上でマウスボタンがホールドされている状態のこと)と用意したとします。
で、カーソル時には通常時の位置から右に1ドット下に1ドット移動したように見せます(凹みを表現するため)
この場合、マウスカーソルの判定矩形は
1.通常時と同じ判定矩形
2.判定矩形を右に1ドット下に1ドットずらす
3.両方の判定矩形を合体させる
という方法があるわけです、とりあえずは1で設計してますが…。 大分作業が進みました、今週末にはアップロードできそうです(といってもAbyssLibのみですが…)
あとはノベルエンジン本体のみ………!それにしても、ボトムアップでコーディングしていると途中の閉塞感が半端ないですね。 まだ作業途中ではありますが、アップロードすると言った手前もありますし一部アップロードしてみます。
残るはNovelPlayer、NovelPlayer2、BasicCommands、サンプル等々………。
http://abysslib.hp.infoseek.co.jp/AL1200a.zip
|
|Д`) ダレモイナイ・・
|⊂ ホウコクスルナラ
| イマノウチ
というわけで、進捗状況を報告してみます。
現在BasicCommandsに取り組んでおります、とりあえずVer1.200(with Ver1.070)は今週末にでも出せそうです。 >>346
おお、人がおられましたか!
チェックして頂けるだけでもありがたいかぎりなのですm(_ _)m
今週末に出すと申し上げましたが、間に合わなさそうな予感が………(急用が入ってしまったので)
現在デバッグ中、とりあえずはAbyssLib Ver1.200 + BasicCommands Ver1.07でリリースする予定です。
変更点を記しますと、
AbyssLib
・細かいバグを修正
・名前空間を導入
・演算子の拡張
単項と多項に分離:+、-
新規追加:^、~、!、|=、&=、^=
変更:!=(旧<>)
・汎用クラスの追加
vector_mystr(文字列の動的配列)、RubyTextToken(ルビテキスト(字単位))、
RubyTextTokenLine(ルビテキスト(行単位))、TextToken(テキスト(字単位))、
TextTokenLine(テキスト(行単位)、TextTokenSection(テキスト(文単位))を追加
・汎用関数の追加・削除・変更
削除:EditText
追加:SaveStringVM、SaveTextTokenSection、LoadStringVM、LoadTextTokenSection
変更:IsOpenedFile(非エクスポート関数に)
・TextTokenSectionにより、文字列管理の方法を変更(テキスト、発言者名、スプライトテキスト、既読履歴)
・今までマクロの書き換えでしか変更できなかった要素を動的に変更可能に
最大Z、最小Z、予約済みZ座標、ログの最大保持数、テキストウインドウのインターフェース、
ルビのフォント、ルビのサイズ、テキストの最大横幅/最大縦幅、発言者名の最大横幅/最大縦幅
テキストカーソルのインターフェース、選択肢のテキストのサイズ、選択肢のテキストのフォント、
選択肢のテキストの最大横幅/最大縦幅、選択肢のテキストのカラー(通常時、カーソル時、クリック時) ・選択肢関連のメンバ関数をTaskManagerからDrawManagerに移す
・SoundManagerにvoice関連のメンバ関数を追加
・DrawManagerからマウスカーソル関連のメンバ関数を削除
・各種シーン(通常、既読履歴、セーブ、ロード、環境設定、メニュー)をクラス化
今まで関数として実装していたものをクラス化、継承によりより平易にシーンのコーディングが可能に。
・オブジェクトファイルの追加読込が可能に
BasicCommands
・今回、変更点は一切ありません!
つまり、ソースコードレベルでのバージョンアップはあってもスクリプトレベルでのバージョンアップはありません。
理由としてはそこまで作り込むと(ただでさえ四ヶ月も時間使ってるのに)リリースが更に遅れること、
DLLの方まで大きく弄るとデバッグが困難になるからです。とりあえずはVer1.06との完全互換ということで。
(厳密には演算子の変更により完全互換ではありませんが)
バグフィックスを終え次第、
・禁則処理
・タグの導入(テキストの文中でサイズやフォントを変更可能に、ルビなども)
・複数分割(長すぎるテキストを複数のテキストに自動で分割)
・表示位置調整(センタリング等)
・画面更新、画面効果の新規追加
・voice関連の命令を追加
・その他色々(for〜next)など
といった感じのバージョンアップを行います。 それを終えた後には、ドキュメントとサンプルの制作を行う予定です。
大規模アップグレードは今回が最後だと思われます………多分、きっと、そう信じたい(;´Д`) 演算子のコンパイル処理が少し難航しています…。
それさえ直れば出せる状態(他は全部テスト済み)なので、明日か明後日には何とか…。 デバッグ&テストが完全に終了しました!
今夜にはまとめて上げられるかと思います(ヘルプの再構築にはもう少し時間が掛かりますが)
>>231
ありがとうございます、書いてくださるのは大歓迎です。
以前の続きでも、新たなものでも歓迎ですので。 一応、今夜中ということでぎりぎりセーフでしょうか(;´Д`)
とりあえずはうpしてみます、WEB等の整理は明日からということで…。
http://abysslib.hp.infoseek.co.jp/AL1200.zip 今日中にWEBを更新しようと思ったが間に合わない予感がひしひしと………orz
まあ、八割方書き上げてますので明日には何とかなるでしょうけれど。 なんか日記帳になっているような気がしないでもない感じが…。
新たに見つかったバグ修正に時間がかかっていました、恐らく明日にはきっと多分………。 漸くテストを終え、アップロードしました!
今後の予定は………
1.ADVサンプルを最新版に対応させる(簡単な筈、バグがなければ…)
2.最新版のバグフィックス(1でバグが発見された場合)
3.BasicCommandsのアップグレード(禁則処理やタグ対応など)
といった感じです。
その後は命令を追加しつつ、サンプルを作っていければと…。
もう大規模なアップグレードは勘弁です_(。Д。)_ 進捗報告です。
案の定、バグが見つかりましたorz
テキストとテキストカーソルにまつわる根深いものです…。
現在バグフィックス中、それを終えたらアップグレードを進める予定です。 アップグレード完了しました、これでめぼしいバグは消えた筈…?
ただ、いくつか気になる点はあるのでそれは次回修正ということで。
次回はAbyssLibは若干の修正、BasicCommandsはインターフェース系命令の追加+テキストのタグ&ルビ対応になるかと思われます。
http://abysslib.hp.infoseek.co.jp/index.html あけましておめでとうございます、保守兼ねて経過報告をしておこうかと。
現在、今年度末までに完成を目標に鋭意コーディングを行っております。
今週末〜来週末に公開予定です、現在30命令の追加を予定しております。 経過報告です、現在34命令の追加を終えデバッグを行っております。
残るバグはあとひとつ…!土曜は用事により作業を進められそうにありませんが、日曜までにはアップグレードできるかと思われます。 デバッグ終了!これで今のところ見つかったバグは全て取れた筈………!
明日(もう今日ですが)にはアップロードする予定で頑張りますので! アップロードしました!
現在、ウェブページは更新しておりませんが(まだ編集中です)
既に最新版をDLできます。リファレンスなどの更新もまだですが、サンプルが更新されていますので。
http://abysslib.hp.infoseek.co.jp/index.html サイト(+オフラインヘルプ)の更新を終えました!
今回のアップグレードによる変更点は、
AbyssLibは
・立ち絵の優先順位の不具合を修正
・オブジェクトファイルの追加読み込みの不具合を修正
・GETSYMBOLをGETSYMBOLNAMEに変更
・BaseDrawManager::DrawRect関数の仕様を変更
・NullDrawManager::DrawRect関数の仕様を変更
・BaseDrawManager::_DrawRect関数を追加
・NullDrawManager::_DrawRect関数を追加
・INovelEngine::Initialize関数を追加
・NovelEditor::Initialize関数を追加
です。Ver1.201との互換性はありません(少し修正すれば動きますが)
BasicCommandsは
・スプライトテキストの不具合を修正
・voicevolume、playvoice、stopallvoice、stopvoice、loadvoice、unloadallvoice、unloadvoice、
charaspace、textposition、textmaxwidth、textmaxheight、talkerposition、talkermaxwidth、
talkermaxheight、textcursorshow、textcursornone、textcursorclick、textcursorgonext、
textcursorbacklog、textwindowdraw、textwindowimage、selectwindowdraw、selectwindowimage、
selectwindowunderspace、selecttextfont、selecttextsize、selecttextmaxwidth、selecttextmaxheight、
selecttextncolor、selecttextccolor、selecttexthcolor、selectclickse、selectcursorse、initializeを追加
です。
より分かりやすく説明しますと、
・音声関連の命令が追加された(今はse相当の命令しかありませんが)
・レイアウト関連の命令が追加された(テキストウインドウ等のカスタマイズがコーディングを経ずに行えるようになった)
といった感じです、複雑なカスタマイズを行いたい場合はコーディングを経る必要がありますが…。
今後の予定としましては、
1.Ver1.080としてテキスト関連の命令を大量に追加する
今まで手をつけてこなかったテキスト関連の命令(タグ・ルビ等)を大量に追加する予定です。
今のところ考えているのは、
・禁則処理
・表示位置調節(字間、行間、センタリング)
・ウエイト、カラー、表示速度、サイズ、フォント、ルビ
といったところです。文中に立ち絵変更タグを埋め込めるとかも良いかもしれません(考え中)
2.Ver1.090として画面更新を大量に追加する
今は画面更新に限られたものしかありませんが、それらを大幅に追加する予定です。
今のところ考えているのは、
・シャッター(上下左右)
・カーテン(上下左右)
・スクロール(上下左右)
といったところです。
また、汎用的な画面効果ではありませんがプラグイン作成のサンプルも兼ねて
桜吹雪、雪、雨、蛍などの画面効果もお見せする予定です。
ここまで行うと、NScripterに大分近付けるかと思います。 ………大口叩いたようで怖いので補足しておきますと、コードの最適化(最低動作環境)、
モノクロ、マスクパターンを用いた画面更新、動画の再生などNScripterに劣るところはまだまだあります。
これは私の技術力の問題もありますが、組み込み前提のライブラリとしていることで「尖った」処理をライブラリ内に
組み込むことが困難なのも一因です。マスクパターンを用いた画面更新を一例にしますと、マスクパターンというのは
ピクセル単位の処理が必要になります。それをGDI(使う人は今時いないかな?)、DirectX、OpenGLなどのグラフィックス
ライブラリ(およびyaneSDKのようなそれらの補助ライブラリ)で簡単に組み込めるよう抽象的で直感的で汎用的なコードを
書くのは極めて難しいです。必ずどこかで無理が出てきますし、個々に特化したコードを書いた方が速度も確実に速いでしょう。
とはいえ、模索してみるよりも前に諦めるのも何でしょうし、
1と2を終えた時点で色々と模索してみる予定です。特にマスクパターンを使えると大きいでしょうから。
というわけで、
3.適宜バグフィックス、サンプル作成、「尖った」処理の組み込みを模索、要望に応じ新規命令を追加
といった感じになるかと思われます。2まで終わらせるとほぼ完成ということですね。
結構過疎ってますが、要望などは随時受け付けておりますので(´Д`) 経過報告〜。
現在、テキストの禁則処理とタグ・ルビの実装を行っています。
禁則処理は思っていたよりもずっと簡単で実装しデバッグも完了、
タグも現在実装中ですが今週前半には実装およびデバッグを終えられそうです。
恐らく今週末には公開できるんじゃないかなと………ただ、一連の処理でノベルエンジンが重くなりそうなのが懸念するところではあります。
(最適化は現在想定している命令を全て実装し終えてから行う予定です) ふう、永久規制解除された。
今回のテーマは鬱ゲーごちゃ混ぜでいってみようかと思うんだ。
ホワイトで永遠なデイズだぜ(タイトル未定)
長くなりそうなんで忘れた頃にやって来るよ。 マニアイマセンデシタ(カタカタ
バグはおおむね潰せたのですが、新たなタグの案が出るわ出るわ………。
公開は今週末に延期します、といいつつ今週前半あたりで公開してしまうかもしれませんが。 鬱ゲーの方は時間がかかるんでかわりにうp。
前回提供した話を小説として再構築した。読むにはOOoが必要
ttp://gamdev3.hp.infoseek.co.jp/cgi-bin/up/No_0385zip.html 現状報告です〜…すみません、スランプ入っていてなかなか進んでおりませんorz
残るはテキスト表示速度の変更と待機、タグの命令化あたりです。今週末には間に合わせたいと思いますが…かなり怪しいです。 お久しぶりです、忙しかったりスランプに陥ったりと開発が進行しておりませんでしたorz
が、ようやくテキスト周りが完成しました。サンプルなどを作成し、今週末までにはなんとか上げたいと思いますっ! お待たせしました!…待ってた方が居たかはさておいて、と自分でしても虚しいツッコミを入れつつ。
BasicCommandsVer1.080、ようやく上がりました!
アップグレードの内容は、
・タグ命令を実装
・禁則処理を実装
・字間、行間、揃えを設定する命令を追加
上記の三つです、ちなみに今回AbyssLibには手を加えておりません。
タグ命令の実装によって、表現の幅が広がったのではないかなと思います。
次回の更新では画面効果や画面更新を増強し、以後はサンプルを上げていく形でいこうかなと思います。
ほぼ完成系と考えておりますが、欲しい機能等ありましたらリクエストあればお応えしますので!
http://abysslib.hp.infoseek.co.jp/index.html >>379
住人そのものが少ないこの板で報告するよりもvectorなどの配布サイトなりに登録した方が
もっと反応があると思うけど。。。。 現在の開発状況です、
画面更新の種類を追加中でNScripterでいうカーテンとシャッターを実装しました!
あとはスクロール、時間制限選択肢、揺れの改良、あたりを行ってからアップロードする予定です。 >>380
まだ完成には至ってないので、公開するわけにもいかず…。
もうすぐで、一応納得いくところまではいけるとは思いますが。 保守です、社会人って時間がとれませんよねorz
ぼちぼち開発しております……五月中旬ぐらいには、アップロードできるかと。
上記に挙げた機能の他に、色々とささやかな機能を追加したりしていなかったりします。 久々に保守兼ねて、一ヵ月近くとあるバグに悩んでおりましたがようやく解決しました(´Д`)
まさか、ソースコードの方でなくスクリプトの記述ミスだなんて……orz
ともあれ、ぼちぼちと尚も開発は続行しております。報告遅れましたが、次バージョンは6月中旬の公開を目指しております。 AndroidかiPhoneとかの変態組環境でエンジン作ってるドMはいないの?
OSのないDSとかさ。 お久しぶりです、仕事とスランプにやられておりました(´Д`)
現状は、新バージョン公開にあたって実装すべき機能を全て用意し終えたところです。
残るはテスト&デバッグ&サンプル作成&マニュアル作成です、来週〜再来週中の公開を目処に頑張ります。 お待たせしました、延期に延期を重ねましたがようやく新バージョンの公開です!
更新内容を以下に記します
AbyssLib
・描画タスクの種類に「矩形」を追加
・画面更新(通常時)を上書き可能に変更
・環境設定の保存/読み込みをプラグインにて拡張可能に変更
・ローカルデータの保存/読み込みをプラグインにて拡張可能に変更
BasicCommands
・スキップの待機時間を変更する命令を追加(waittimeskip)
・禁則文字を設定/追加する命令を追加
(setleadingchs、setfollowingchs、setfollowingweakchs、addleadingchs、addfollowingchs、addfollowingweakchs)
・新規画面効果を追加(flash2、quakex2、quakey2、quakexy2、quakex3、quakey3、quakexy3)
・新規画面更新を追加(update2)
以上のような感じです。 次回更新の予定としましては、
・新たな画面効果を更に追加
・新たな画面更新を更に追加
・制限時間付きの選択肢(要検討)
・桜・雪・雨・蛍などの特殊演出(プラグインとしての実装を予定)
・乱数(要検討)
・for、next、break(要検討)
・オブジェクトファイルをダイナミックリンク(要検討)
といった感じです。要検討が多いのは、必要か不要かをまだ見極めきれていないからです。
見ておられる方は、コメント頂ければなと思います。
あと、次回までにはといきませんが
・インタプリタ化
・他言語での利用(Luaあたりを予定)
なども考えております、そこまで終わらせれば一応更新は終わらせるつもりです。
http://abysslib.hp.infoseek.co.jp/index.html 現在帰省中故に、EeePCにて作業を行っております。
なのですが……ScriptPlayer2が異様に重い!それに加えて、テクスチャのLockRectが上手くいっていない模様。
DirectX本のサンプルなんかは軽々と動くのに……! (大分時間が経ちましたが続きです)
で、ログ出力などして調べたところ……
DX9AのCreateDeviceにて、
・MaxPrimitiveCount<0xFFFF
・MaxVertexIndex<0xFFFF
・VertexShaderVersion<D3DVS_VERSION(1, 1)
・PixelShaderVersion<D3DVS_VERSION(1, 1)
上記の条件の何れかが成立した場合に、HALでなくREFを使用するようになっていました。
この条件のMaxVertexIndex<0xFFFFとVertexShaderVersion<D3DVS_VERSION(1, 1)が
EeePCのスペック的に引っかかるらしく、強制的にREFで動作していたようです。
条件分岐のところをコメントアウトしたところ、HALになり軽々と動きました。
作成する際に参考にする書籍を間違ったのかなぁ……?
現在、DX9Aのグラフィック部分を作り直し中です。以上。 現在の進捗状況です。
・以前のレスにもありますとおり、DX9Aを改良しScriptPlayer2の挙動を改善しました。
・新たな画面効果を追加しました(flash3:フラッシュを波関数を用いて実装)
・新たな画面更新を追加しました(移動補間:更新前の位置から更新後の位置に移動)
・制限時間付き選択肢を実装しました(制限時間は指定可、タイマ画像を表示可)
上記の実装を終えております、他につきましてはまだ検討中の段階です。 随分とお久しぶりです、スランプ気味であまり手をつけておりませんでした(´Д`)
現在、新たな命令の実装を終了したところです。これからテスト&デバッグに入る感じで。
新バージョンのお披露目は、11月中には行えればなと思います。 いつか使おうと思っているので、ゆっくりでもがんばってください! 命令のテスト&デバッグを完了、とりあえずは問題なさそうです。
実装したのは、
・乱数
・ループ(for、next、break相当)
・動的ロード(loadobject、gotod、gosubd)
以上のような感じです。
あとは、サンプルを用意してサイトも修正して……もう少しばかりかかりそうですね(;´Д`)
>>395
ありがとうございます、更新遅めですが生温かく見守ってくださいw 全作業を終えましたので、新バージョンをアップロードしました!
・BasicCommandsをVer1.090からVer1.100にアップグレードしました!
・他にはScriptPlayer2を低スペックPC対応に修正しました!
BasicCommandsの変更点を述べていきますと、
・実行時エラーチェックの不具合を修正
・乱数生成命令の追加(rand)
・繰り返し制御構造命令の追加(beginloop、endloop、break)
・オブジェクトファイルのダイナミックリンク命令の追加(loadobject、gotod、gosubd)
・時間制限付き選択肢命令の追加(selectl)
・selectl実行中に表示される画像の設定/消去命令の追加(selectlclearimage、selectlimage0、selectlimage1、selectlimage2、selectlimage3)の追加
上記のような感じです。
次回以降の更新予定は
・Vista対応(これは次回のアップグレードまでにを予定)
・桜・雪・雨・蛍などの特殊演出(プラグインとしての実装を予定)
・インタプリタ化
・他言語での利用(Luaあたりを予定)
上記のような感じです、大分終わりが見えてきました。 >・桜・雪・雨・蛍などの特殊演出(プラグインとしての実装を予定)
組み込み用だからパーティクルエンジン持っててくれれば自分で実装しちゃう気がしないでもない。 書き忘れてましたが、
・ScriptPlayerをVS2005以降でコンパイルできるよう修正(これはyaneSDKを弄くる必要があるので難しいかも)
・ジャンル複合サンプルの作成(ADV+RPGやADV+SLG、ADV+STGなど)
上記の内容も近いうちにお見せできたらいいなと考えております。
>>398
ええ、恐らくは可能かと。
あくまでもそのサンプルをひとつ作ってみようかなと考えてる感じですね。 HSPでノベルゲームを作っている者ですが……
いわゆるファイルを扱う命令の場合(WIN API関数も含む)、
ハードディスクに実際に存在するファイル名を引数に指定する必要があります。
こういった命令郡をメモリーにロードしたファイルデータで扱う
汎用的な方法ってありませんか?
複数ファイルをパッキングし、そこから欲しいデータの収得まではできたのですが
外部ファイルを引数に取る命令郡の場合、取り出したデータをファイルに書き出してやらないと
目的の動作を達成できません。
そして、そういった方法は、ちょと強引すぎるように感じています。
もとからデータのポインタを引数に取る命令ならよいのですが、
外部ファイルを引数に取る命令郡の場合では、どうしていいかわかりません。
なにかよい方法があればご教授願います。 HSPでノベルゲームを作っている者ですが……
いわゆるファイルを扱う命令の場合(WIN API関数も含む)、
ハードディスクに実際に存在するファイル名を引数に指定する必要があります。
こういった命令郡をメモリーにロードしたファイルデータで扱う
汎用的な方法ってありませんか?
複数ファイルをパッキングし、そこから欲しいデータの収得まではできたのですが
外部ファイルを引数に取る命令郡の場合、取り出したデータをファイルに書き出してやらないと
目的の動作を達成できません。
そして、そういった方法は、ちょと強引すぎるように感じています。
もとからデータのポインタを引数に取る命令ならよいのですが、
外部ファイルを引数に取る命令郡の場合では、どうしていいかわかりません。
なにかよい方法があればご教授願います。 何が聞きたいのか全然分からないぞ。
ファイル名を引数にとるAPIを、ファイル名を引数にしないで利用したいと
言っているように見えるわけだが…
ファイル名を引数にとるAPIの動作を、ファイルポインタで実現する方法が
知りたいのかな? もしそうなら、具体的に何をするAPIなのかを列挙しないと
個々のAPIでそれぞれ違うんじゃないの? >>ファイル名を引数にとるAPIを、ファイル名を引数にしないで利用したいと
意味としてはそのようなものです。
ですが、関数の仕様を考えれば
BMP表示API関数 LoadBitmap()はファイル名を引数にしないと使えないことはわかります。
BMPの表示なら SetDIBitsToDevice() で問題は解決できますが
いわゆる音楽再生系のAPI関数は音楽データのポインタを受ける関数が少ないように思います。
MCI系は全滅に近いような気がします。
素材ファイル郡をひとつにパッキングして、
適時そこからデータを取り出して使う方式をとった場合、
使えなくなる関数があまりに多かったもので、どうしたものかと困っている所です。
結局なにがしたいのかを例で示すと――
@ビットマップのデータはメモリーにロードされている。
Aしかし、ハードディスクにファイルは存在していない。
Bでも LoadBitmap() 関数を使いたい。(第二引数はLPCTSTR lpBitmapName)
上記のように
ファイル名を引数にとるAPIを、ファイルが存在していないのに使いたい(データはある)。
というわがままな願いです。
パッキングをあきらめることも、解決策のひとつであると わかってはいるのですが……。 >>404
LoadBitmapってことは、HBITMAPが欲しいのかな?
それなら、CreateDIBSectionあたりをつかって、DIBを作って得られたメモリに対して、
自分でアーカイブ内の画像を展開するコードを書けばそれで終了。
libpngでもlibjpegでも好きに使え。 説明がわかりづらくてすみません。
自分としては、hoge( LPCTSTR lpFileName ); のような関数郡、
LoadBitmap( LPCTSTR lpBitmapName )
mciSendString( LPCTSTR lpFileName )
自作関数( LPCTSTR lpFileName )
他人製作のライブラリ関数( LPCTSTR lpFileName )
このような関数郡をファイルをひとまとめにしたパックファイルしかない状況で
使用する一般的な方法があるなら知りたいです。
ただ……
市販のゲームでもoggファイルだけは**.oggのままリリースされているのを
見かけるあたり――一般的な方法は無いのかもしれませんが……。 無理にHSPを使うのをやめるのが一番簡単だと思うよ
かえって足枷になってる感じを受ける ■ このスレッドは過去ログ倉庫に格納されています