フリーゲーム・フリーソフトの開発過程を記録していく、TDtechnic公式ブログです。製品はカテゴリの「ダウンロード場」からダウンロードして頂けます。
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

こんばんは。広告消し更新です。

最近はレポートや他ごとの作業であまりプログラミングができない次第であります。
ShiroScriptについてもコードはこの間から全然変わっていなくて、特に今報告することはございません。失礼します。
スポンサーサイト

[2016/11/10 19:48] | (コードネーム:モンジュラ)
|
こんばんは。新学期のShiroです。

ShiroScript処理系第一号の実装が完了しました。完全にテストはしていませんが、予定していた一通りの機能はすべて揃いまして、一応スクリプティングもできなくはない状態です。

ただ、すぐに実用化できるかというと難しいです。柔軟性を求めた結果、変数や文字列の取り回しがかなり複雑になったため、全体的に動作が重いのです。一部の単純な命令は限りなくノータイムに近い時間で終わりますが、一般的な命令は数マイクロ秒かかり、一部の重い命令は十数マイクロ秒かかります。これは私のパソコンの場合、足し算を数千回行うのにかかるのと同じくらいの時間です。

マイクロ秒単位の話なので随分細かいことを言っているようにも見えますが、結構これが馬鹿にできない時間なのです。一般的なゲームは秒間60フレームの更新速度で動きます。すなわち1フレームを完成させるのにかけられる時間は最大で1/60秒 ≒ 16.667ミリ秒 = 16667マイクロ秒です。例えばすべての命令が10マイクロ秒で動くとすれば、1フレームを完成させるために実行できる命令は約1667命令しかないというわけです。

1600命令超となるとこれまた多いように見えるかもしれませんが、もし入力処理やキャラ移動処理、画面の描画など全てをスクリプト主体で書くのであれば到底1600命令程度では足りません。そしてなにより問題なのが、この数値がわりと速いCPUでの結果だということです。一般的なパソコンでは1600命令も使えず、古いパソコンやネットブックでは数百命令しか使えないかもしれないのです!

一部の速いパソコンでしか動かないようではまだ完成とは言えません。ただでさえゲームは重い処理が多いのですから、スクリプトなどにかける時間は最小限にする必要があります。幸い高速化できる余地の見当はついており、そのうちいくつかは実際に効果が見られました。まだ試していない最適化もあるのではっきりしたことはわかりませんが、遅すぎてノベルゲームにしか使えないなんてことにはならなくて済みそうです。

[2016/09/28 19:53] | (コードネーム:モンジュラ)
|
こんばんは。もう一ヶ月経ってしまいましたがまだスクリプト言語の仕様を考えているところです。
ただ、ずっと一貫してスランプ続きというわけではありません。先日までは確かに何の収穫もない日が続いていたのですが、数日前に大きな進展がありまして、それからは結構順調に仕様が決まっていっています。以下にこの言語の概要を述べます。

まず断っておきたいのは、前回申し上げた「タイムライン」システムはやっぱりボツになったということです(笑)自由度がないせいか、制御がしにくいせいか、とにかくサンプルコードを書くにも至りませんでした。発想としては(自分の中では)面白かったんですが、残念。

ではどのようなシステムかというと、やっぱり基本は、王道を征く、命令列の逐次実行です。そして、条件分岐を始めとする制御構文が存在するというのもセオリー通りです。ただ、ラベルは低水準すぎるので不採用としました。ちゃんとスコープのある構造化しかサポートしていません。

ですが、単なる逐次実行と制御構造であればCやC++で書けばいいだけのことです。ゲームで求められる複雑な制御構造に対応するため、この言語では擬似マルチタスクを言語レベルでサポートしています。つまり、別々のスクリプトを、見かけ上並列的に実行することができるのです。ただし、あくまで「擬似」なので、マルチスレッドやマルチコアの恩恵を得ることはできません。その代わり、命令レベルでの実行順が一意に定まるというメリットが有ります。

そして、この言語の最大の特徴は、擬似マルチタスクとメッセージシステムが統合されている点です。この言語でプロセスを中断する際は、処理を再開するためのメッセージを指定します。そして、他のプロセスからそのメッセージが送信されるまで再開することはないのです。しかし、実はこれを繰り返すことでマルチタスクを実現することができるのです。

要するに、複数のプロセスが存在する状態では、メッセージを送っているメインのプロセスの他は、基本的に全て中断状態にあるわけです。そして、メインプロセスから送られるメッセージを毎フレーム処理していくことで、マルチタスクとなるわけです。文章で説明するのは難しいんですが、このようにして逐次実行とメッセージシステムを融合させることに成功したのです。

現段階では、サンプルコードを書きながら仕様を決めていっているだけで、そのコードを実行できる処理系はまだ作っていません。もちろん実際にゲームを作って試すこともできていません。ですから実用性のほどについてはまだまだわからないんですが、机上の空論の限りではなかなか良いものになりそうです。では今日はこの辺で失礼します。

[2016/08/29 19:58] | (コードネーム:モンジュラ)
|
こんにちは。ようやく前期が終わりました。あとは単位が出ていることを祈るのみです。

さて、早速次回作に取り掛かりたいのですが、次回作には前回ご紹介したスクリプト言語を取り入れたいと考えております。そのため、まずは言語仕様を策定して実際に処理系を作ることが先決です。

今考えているのは、スクリプトに「タイムライン」という概念を導入することです。つまり、動画編集のような感覚で状態遷移の設計をするという考えです。

もちろん、ゲームの流れはプレイヤーの入力に応じて変化しますので、設計時にタイムラインの内容を決めてしまうことはできません。どちらかというと「プレイヤーの操作をタイムラインに反映する」あるいは「プレイ中に、リアルタイムに動画を生成する」というようなイメージです。何を言っているのかよくわかりませんね。

とまあ、本当に実現可能かどうかと言われると微妙な仕様なんですが、とりあえずこの方針で研究していきたいと思っています。どうも私は、「ゲーム制作」そのものよりも「ゲーム制作のためのシステムの制作」に燃えるみたいです。では今日はこの辺で失礼します。

[2016/07/29 17:03] | (コードネーム:モンジュラ)
|
お久しぶりです、Shiroです。

前回は実装部の隠蔽をテーマに、PImplイディオムについてグダグダ述べて終わりましたね。それでその改善案なんですが、実はあれを書き終えた直後から改良の嵐で、なかなかブログに起こすことができませんでした。申し訳ございません。

とりあえず今現在採用している方法を簡単に説明します。まず、基本的にPImplイディオムそのままです。やっぱり先人の知恵とはよく言ったもので、試行錯誤すると結局行き着く先は同じようです。ただ、やっぱりPImplそのままでは「クラス間の通信の隠蔽」ができないため、ちょっとアレンジします。それが「Contextイディオム」です。

もちろんこれは私が勝手に名付けた名前です。Contextは「文脈」ですが、具体的には「データの共有単位」を表します。つまり、複数のクラスが共有するデータがあるときに、それをコンテキストクラスとしてまとめるのです。そして、各クラスは、コンテキストクラスを通じて通信するのです。これをContextイディオムと名づけました。

なぜこのような回りくどいことをするのでしょうか。肝は、「非公開なpublicメンバを作りたい」というそもそもの目的と、「Impl構造体は不完全型である」ということです。これを組み合わせると…そう!不完全型にpublicメンバを書けば、「クライアントは利用できないが開発者は利用できる」がまさに実現できるのです。ですから、そのような不完全型(を管理するクラス)としてコンテキストクラスを作って、各クラスはコンテキストクラスを参照して生成するようにすれば、各クラス同士はコンテキスト内のデータを用いて自由に通信でき、一方クライアントの名前空間は一切汚しません。ああ、不完全型とはなんと素晴らしいのだろうか!

なお、コンテキストクラス自体も、PImplイディオムっぽく設計します。ただし、本来公開メソッドが入るところには、「そのコンテキストに依存するクラス」のfriend宣言を書きます。普段はカプセル化を破壊するものとして忌み嫌われているfriendですが、この状況においてはなんと過不足ない効果を発揮します。コンテキストクラスでpublicでないのはもともとImplの宣言とpImplの定義だけですから、friendによって公開されるのはこの2つだけなのです。そしてまさに、コンテキストクラスを参照するクラスにとって必要なのは、この2つなわけです。私、初めてfriendを正しく使えた気がします…。

ちなみに、PImplは中継メソッドを大量に手書きしなければならないのが嫌だと前回申しましたが、それはある意味解消されました。コンテキストクラスの導入により、クラス間の橋渡しをする処理が必要になるわけですが、その処理をするのに最適な場所が中継メソッドだからです。つまり、もはや中継メソッドは単に引数と返り値を受け渡しするものではなくて、クラス同士が互いを参照できるようにするという立派な中間管理職となったのです。これで、PImplを使いたくない理由が全てなくなったのです。

というわけで、今まで書いていたタスクシステム(メッセージシステムとタスクリストに分離しました)をContextイディオムで書き直しました。クライアントは(インライン関数などを除いて)開発者用のものには一切触れません。完璧です。もちろん、これは単なる自己満足ではなくて、翻訳単位間の依存性を軽減するというれっきとした効果を持っています。さすれば、コンパイル時間が短くなるだけでなく、クラス同士の結合も極限まで疎にすることができるのです。

しかも、このContextイディオムは、かなりの汎用性があるようで、大概のプログラムはこれで書けそうな勢いなのです。少なくとも前述のメッセージシステムとタスクリストは、ほぼ機械的に同じパターンのコーディングでできています。ちょっと思い上がりかもしれませんが、これは私の中での一つのデザインパターンとして、これからも使えるのではないかと期待しています。

…まあ、これまでだってその期待は何度も裏切られてますからね、今回だってわかりませんけどね(笑)では今回はこの辺で失礼します。

[2016/02/25 00:30] | (コードネーム:モンジュラ)
|

こんばんは
Sva
お久しぶりです、Shiroさん。
以前もコメントで告知いたしましたが、ついに明日28日、もとい本日夜0時に『紛り物のダイヤ』新HPを公開いたします。
是非よろしければ遊びにいらしてください^^

こんにちは
Shiro (管理人)
> Sva さん

了解しました、遊びに行かせていただきます。

こんばんは
Sva
お久しぶりです。最近体調はいかがでしょうか?また悪化してなければよいのですが。
最近私はTOEICの勉強のため懐かしのターゲット1900を引っ張り出して読んでいるのですが、ターゲットといえばShiroさんというイメージがあって、ついコメントしてしまいました(笑)
ちなみにShiroさんはTOEIC受けましたか?

こんばんは
Shiro (管理人)
> Svaさん

ご無沙汰しております。最近は以前と比べて気胸の頻度も減っていて少し安心しているところです。

TOEICは受けましたが、結果は受け取りに行ってないのでまだわかりません。内容がビジネス寄り(らしい)せいか、非常にやりづらく感じました。まだTOEFLの方がやりやすかった気がします。

こんにちは
Sva
そうでしたか…。なんか、確かにやりづらそうですよね。
三年生になって履修も楽になるかと思いましたが教職組には関係なく、なかなか多忙な日々にまりそうですー><
お互い頑張りましょうね!

コメント:を閉じる▲
あけましておめでとうございます。Shiroです。

最近はSIREN動画にも手を出したりしてプログラムがおろそかになってきております。というのも、ライブラリ設計について悩んでいる部分があり、なかなか進める気にならないのです。

その悩んでいる部分というのは、「実装部の隠蔽」です。C言語では、ライブラリ利用者に実装部のコードが見えないように設計すると、インターフェイスの分離が明確になるだけでなく、ソース間の依存性が減り、コンパイル時間も短縮されるというメリットが有ります。具体的には、ヘッダーには関数のプロトタイプと構造体の宣言、typedefなどだけを書いて、関数と構造体の定義や、非公開の関数・構造体は全てソースファイルに書くというものです。

ところがC++のクラスは、この考えにとことん向いていません。C++のクラスは分割定義を許していません。つまり、利用者に見せたいメソッドだけをヘッダーに書いて、メンバ変数やprivateメソッドは.cpp内に書く、といったことができないのです。

なぜこのような制約があるのでしょう。考えられるのは、クラスのサイズを明確にするという目的です。先ほど述べたような分割定義をすると、ヘッダーだけが見える翻訳単位(利用者)と、.cppの翻訳単位(実装者)では、明らかにクラスサイズが異なります。クラス名をClassとすると、利用者にとってはsizeof(Class) = 1でも、実装者にとってはsizeof(Class) = 4だったりするわけです。

これは当然問題になります。もし利用者がClassのオブジェクトを作ると、そのサイズは1です(非virtualメンバ関数しか持っていない場合)。このオブジェクト(またはそのポインタ)を、実装者側で定義された関数に渡すとどうなるでしょう。実装者の方では、Classのサイズが1バイトである保証はありません(メンバ変数などを含んでいるため)。仮に4バイトだったとします。これでは、単なるコピーですらエラーとなります。利用者が作ったClassオブジェクトは実際には1バイトであるにもかかわらず。実装者側では4バイトだと思い込んでコピーを実行するからです。3バイト分は、謎のデータがコピーされてしまうわけです。

先も述べたとおりC++ではクラスの分割定義を認めていないため、上のような事故はまず起こりませんが、とにかく翻訳単位ごとにサイズが異なってはまずいということはおわかりいただけたでしょうか。クラス定義をヘッダーとソースに分けると、どうしてもサイズが異なってしまう問題が発生するわけです。

しかし、ここでちゃぶ台返しをしたいと思います。先の想定では、利用者でClassオブジェクトを生成するとサイズがわからないとうことが問題でした。しかし、それを言うなら最初に述べたC言語流の隠蔽だって、利用者には構造体のサイズがわかりません。ではどうしていたかというと、C言語ではオブジェクトの生成も実装者側で行っていたのです。つまり、生成用の関数のプロトタイプをヘッダーに書いて、実装部でmallocしてポインタを返すのです。そう、ポインタを使うだけであれば、構造体のサイズはおろか、定義すら無くても問題ないわけです。

じゃあC++も同じようにすれば良いではないか?ヘッダーに書いてあるクラスは生成禁止にして、実装部に生成関数を用意すれば良いはずです。正直私はなんでC++はこれができないのか疑問に思います。C言語での例を見ればわかるように、原理的には可能なはずです。「生成禁止」を表すキーワードが必要ですが、それは本質的な問題ではありません。

とはいえ、これだけのC++プログラマーがいて、誰もこの打開案を考えなかったわけではありません。私の知っているものは、「pImplイディオム」を呼ばれるものです。接頭辞pはポインタのこと、Implは実装クラス(Implementation)のことで、つまりpImplはImpl*型のメンバ変数です。以下に例を挙げます:

/* ヘッダー */
class SomeClass
{
class Impl;
public:
/* 公開メソッド */
int Func();
...
private:
Impl* pImpl;
};
/* 実装 */
class SomeClass::Impl
{
/* 本当の定義 */
public:
int Func() { return 100; }
...
};

/* 公開メソッドの実装(中継するだけ) */
int SomeClass::Func() { return pImpl->Func(); }
...

前述の「ポインタで持つことだけを許す」ということができない問題を、「ポインタを持つクラスだけを公開する」という方法で解決したものです。これで、Implクラスのメンバ変数やメンバ関数の定義が変わっても、ヘッダーだけを見ている利用者は再コンパイルの必要がありません。

しかし、私はこれはあまり好きではありません。第一に、中継メソッドを書くのが面倒です。関数から関数へと引数と返り値を渡すだけの簡単なお仕事…あまりやりたくありません。しかも、クラス外で定義する必要があるため、「SomeClass::」などの修飾が避けられず、記述量が増えます。
第二に、クラス間の通信がしにくいです。例えば、SomeClass2のあるメソッドにSomeClassへのポインタを渡すと何かが起こる…ということがしたいとしましょう。SomeClass2を同じ実装者が作っているなら、非公開な関数にもアクセスしたいと思います。ここでいう非公開とは、privateメソッドのことではなく、利用者に見せていないpublicメソッドのことです。つまり、実装者側での操作に使うだけで、利用者には必要ないメソッドです。しかし、そのようなメソッドはSomeClass::Implにのみ定義されているわけですよね。ということは、SomeClass*を受け取ったところで、そのメソッドにはアクセスできないというわけです!結局、このようなことがしたければ、SomeClassにGetImpl()みたな関数を作る必要があるのです(利用者にも丸見え)。

というわけで、私はpImplイディオムをそのまま採用する気にはなれませんでした。そこで、多少なりともこれらの問題を解決できそうなアレンジを私は考えました。それについては次回以降で述べることとして、今回はこの辺で失礼致します。

[2016/01/01 14:25] | (コードネーム:モンジュラ)
|

承認待ちコメント
-


コメント:を閉じる▲
お久しぶりです。気胸(肺に穴が空いてしぼんでしまう病気)のShiroです。特に書くべきことがないから放置しておりましたが、広告出しっぱなしなのが気になったので更新します。

今は、次回作以降の基盤となるライブラリを作っています。これをしっかり仕上げておけば、今後の制作で楽できるかなー、という目論見です(まあ、大抵そんなにうまくいかないんですがね…)。

次回作は、だいぶ前に立ち上げた「モンジュラ」プロジェクトを再開しようかと思います。未だにタイトルすら決まっていないという有様ではありますが、当時の理念は失われておりません。特に、不死女で3Dグラフィックやスクリプト化の練習を積んでおりますから、今後それらを再発明する必要はありません。同じアルゴリズムを使いまわせる部分はたくさんあると思います(そして、そういう部分を簡単に使いまわせるようにしたプログラムこそが、先ほどのライブラリというわけです)。

とはいえ、本命の首都高にも手を出したい気持ちは山々です。TDtechnicでは既存のゲームのパロディは(ネタとして以外)使用しないことにしておりますので、まずは「首都高バトルTD」以外の気の利いたタイトルをつけるところから始めなくてはなりません(笑)それから、道路データはどこまでを画一化してどこまでを自由定義にするのかとか、光はどう当てるかとか、物理計算はどうするのかとか、内容の課題も山積しております。そうそう、パロディ禁止となるとSPバトルもパクることができませんから、新しいバトル形式を考える必要もあります(下手すると、走り屋ゲームですらなくなるかも…)。

とまあこんな感じですが、まずすべきことは気胸を治すこと、そして中間試験を乗り切ること、というわけで、この辺で失礼します。

<「不死女 -Immortal girl-」好評公開中!(現在 1,092 ダウンロードで 3845 位)>
ふりーむ!様
フリーゲーム夢現様

[2015/11/20 16:32] | (コードネーム:モンジュラ)
|
あけましておめでとうございます。Shiroでございます。一応今のうちに更新します。

年も明けたことですし、受験後にとりかかるプロジェクトのカテゴリーに入れることにしました。名前はまだない。コードネームは「モンジュラ」としました。記憶の時の「富竹フラッシュ」と同じく、本編とは全く関係ありません。

これは記憶に引き続きホラーゲームになる予定です。多分続編ではありません。ようやくオブジェクト指向がわかってきた気がするので、その練習の意味もあります。内容としては、

・身近なホラー
・基本は脱出ゲーム
・マルチプラットフォーム(!?)
・まともなボリューム
・マルチエンディング(難易度分岐)

が実現できたらなあと思っております。私は本当に怖いものは身近なものだと思っているので、今回はそれを意識してみます。で、SIRENや零のようにアクションが多いのも怖くない気がするので(面白いかどうかは別。私はSIRENも零も大好きです)、脱出メインとなるでしょう。OS関係は法律用語でいうプログラム規定です。ひょっとしたらWindows以外でも動くようにするかもしれませんし、まことにざんねんですがWindows2000を削るかもしれません。ボリュームは記憶の反省です。記憶も私の中では量に配慮したのですが、一般的にはかなり短いのは自他共に認める事です。あとマルチエンディングは記憶と同じ難易度分岐で、これは目標というか皆さんへのお知らせです。これは、わかるわけない条件でED分岐するゲームを私が嫌っているということに起因します。その方が主流となりつつある気もしますが、方法もわからない分岐のために同じゲームをプレイする気になるでしょうか。よほど愛されてない限り、見ようとも思われないか、攻略できないかだと私は思います(もちろん、それぐらい愛されるゲームが作れれば一番なんですが…)。些細な隠し要素ならともかく、EDは作者も作りこむところですし、「見る気がある方には見て頂きたい」ものです。であれば作者はせめて方法を提示すべきと私は思うのです。ちなみにこのように一般的なマルチではありませんから、概要には明記しませんし、必要もないと思っています。「マルチエンディング」と書かれたゲームはやる気が削がれるのは私だけでしょうか?

さてなんだかんだ書きましたけど実際には何もしてません。すべて構想段階です。まずは受験が終わらなければ、始めることも出来ないので、とにかくそっちに集中しなくてはいけませんね(こんなもの書いておらずに集中しろ!と言われそうですが)。あと記憶は皆様のお陰で1974位(1760ダウンロード)を頂きました。夢の2000位以内です。ありがとうございます。

「記憶」最新版(2014/01/02現在2.0.0.0) ダウンロード

[2014/01/02 17:01] | (コードネーム:モンジュラ)
|

こんばんは
Sva
受験お疲れ様でした。
次回作の構想はもう出来上がっているんですね!
楽しみです^^

もし、もし自分に何かお手伝いできることがあるならば何でも言ってくださいね。受験が終わってから画材もどんどん増えて、ついに最強のPhotoShopを手に入れたので、以前よりいい画質で絵が描けると思いますし。(まぁここまで言えばもう何ができるのか言っているようなものですが 笑)

ところでですが、ふりーむさんの投票ってどうやればよろしいでしょうか?
一応記事の「投票」というところをクリックしたのですがそれからの投票方法が分からなくて…

コメント:を閉じる▲
今日は。何となく古い首都高を上げてみました。2Dの頃の製品で、一番安定しているものです。HSP製です。ダウンロードは左手の「ダウンロード場」からどうぞ。

[2013/06/04 16:41] | 首都高バトルTD
|
今日は。今日も時間が無いのですが、報告します。
ライトを全く使わない反射の表現に半成功しました。その仕組みは、水玉模様を上から貼り付けるだけというものです。計算量も少ないので、実装も簡単で処理も軽いであろうと思ってのものです。
ところが、我が家のネットブック(Win7Starter)では少々処理落ちするのです。TDtechnicの方針としてはWindows2000で動かす必要が有るのですが、ネットブックでこれなら結果は見えています。勿論起動オプションでON/OFFする手も有るのですが、そこ迄する程には思えませんでした。
というわけで、取り敢えずは不採用としました。原理は理解出来たので、今後改良できたら実装する可能性は十分に有ります。スクリーンショットだけ載せて失礼します。


<本日のスクリーンショット>
light.jpg

[2012/12/15 16:45] | 首都高バトルTD
|
今晩は。あまり時間が取れずに開いてしまいました。今日もあまり無いので早めにします。
テクスチャは成功しました。サイズが2の冪乗じゃなかったのが原因で、DISCARDは関係有りませんでした。
地形との当たり判定も完成しました。地面は今までのものを踏襲し、壁は新たにベクトルフル活用の判定を作りました。勿論例外-総当り法改め「隣接-総当り法」及び「対角線法」「ベクトル交差法」を採用しています。「カウンター法」のみ今回は関係有りません。
さらに地形判定と壁判定を統合し、一つのデータで地形も壁も判定できるようにしました。そして昨日これをクラスにまとめ、本日そのバグ取りを終了し、一段落です。
次は物理計算か車同士の当たり判定を作ります。失礼します。

[2012/12/13 21:35] | 首都高バトルTD
|
今日は。実は明日から一週間程学校のPCを触れない事情が有りまして、今日までに動いて欲しかったのです。なので今日、熱い期待を込めてベータ版(デバッグ用含めた様々なバージョンで五、六個)を持って行きました。

結果。

全てまたもや落ちました。
只、デバッグ用はログを吐かせているので、テクスチャ作成は出来ていると解りました。やはりフォーマットを見直したのは良かったかも知れません。
問題はテクスチャのロック(余談ですが、対象へのポインタ(鍵みたいなもの)を入手して操作出来る様にする行程なのに「ロック」というのには違和感を感じます。ロックと呼ぶ理由は一応理解しているつもりですが)が出来ない事です。そこで調べてみると、ロック時に一般的に「D3DLOCK_DISCARD」としている所を私はNULLにしていると解りました。
書き込み用として最適化するだけのフラグの様なのでこれが原因とは考え難いです。然し、手前には変数の宣言ぐらいしか無く、直ぐ後にはログの更新が有るので、ログ的にはこれが原因でないと矛盾する訳です。そして以前中途半端に動いていたものにもこのフラグが立っているため、これが功を奏す事は有っても逆効果に成る事は考えられない訳です。この二つの事から、つまるところ今度こそ-少なくともロックは-成功する筈なのです。
然しそれを実証出来るのは来週以降。残念でなりません。一台借りて来れれば良いのですが、色んな意味で無理でしょう。

[2012/11/26 14:07] | 首都高バトルTD
|
今日は。昨日道路(のみの)ポリゴンが完成し、今表示や移動の機構をまとめたクラスが整いました。プログラムの流れが非常に良くなり、捗りそうです。今日は特に困難は無かったので短文です。失礼します。

そう言えば昨日のスクリーンショットに映り込んでいますがTDロゴ及びTDtechnicロゴの正式な公開はしてないですね。TDロゴに関しては殆どの製品のアイコンに使用しておりますが。


<本日のスクリーンショット>
新しい江戸橋ジャンクションです。製作工程は簡単に成りクオリティは上がるという良いことずくめのポリゴンです。
edobasi.jpg

[2012/11/25 14:32] | 首都高バトルTD
|
今晩は。昨日はフォントクラスの完成後、道路のポリゴン(地面のみ)の、テクスチャを含めた読み込みに成功しました。という訳で、今日はその道路ポリゴンに起伏をつける事にしました。
ところが、これは前から見て見ぬ振りをしていたのですが、Google様を活用しても高低に関しては簡単で正確な求め方が有りません。以前適当にやった所、かなりガタガタになってしまい、それでいてかなりの労力を要するものでした。簡単にそして滑らかにポリゴンを作る方法はそれからも見つからず、高低に関しては今迄悲観視していたのです。
然し、「滑らか」という言葉でふと思いつきました。坂道を横から見ればグラフの曲線に似ています。だったら基準となる曲線を求めればいいのではないか、と。二箇所(坂の初めと終わり)で傾きが0になる曲線と近似出来ますから、三次曲線を求めればいい訳ですね。これは高二になった今だから出来る方法でもあります。式の定義に傾きが関わるという事は微分する必要が有りますから。
取り敢えず定義域[0, 100]で単調に増加し値域[0, 100]を取る三次関数を定義しました。これを利用して、CUIインターフェイスを作って「勾配計算機」を作りました。始点・終点の座標と分割数を入れると、それぞれの分点での高さと傾きを近似してくれるものです。この高さを見てひたすらMetasequoiaに打ち込めば、始点から終点迄に滑らかな坂道が出来上がります。始点・終点のx・z座標は本当は不要ですが、傾きを近似する為だけに取っています。この傾きは、60km/h高速道路の最大勾配である5%に収まるか確認する為に求めています。


<本日のスクリーンショット>
ちょっと大きめですがスクリーンショットです。右のコンソールが今日即興で作った勾配計算機です。それで求まったy座標を左のMetasequoiaに打ち込んでいます。
勾配計算機

[2012/11/24 18:15] | 首都高バトルTD
|
今晩は。久し振りの同日更新ですね。本日一回目の記事に誤りが有った様です。

>以前動いていたフォントクラスを調べた所、今回と同じフォーマットのテクスチャが作成できています。

記憶では一番最近のものは学校でも動いていたので、それのコードに実装してあるという事は作成出来ていた筈だ、とその時は思いました。然し調べ直した所、そのコードは古いもので本当に一番最近のものでは別のフォーマットが使われていたと解りました。テクスチャフォーマットが原因である可能性が飛躍的に上がったので、それに差し換えて実装し直す事にしました。ところが、テクスチャに貼り付ける部分はマルペケつくろーどっとコム様を参考にさせて頂いたもので、残念ながら件の学校で使えない新しいフォーマットが前提となっておりました。仕方ないので、この期に及んでビット演算を勉強しなおし、変換に成功しました。折角なので、共用体を用いて両方に対応させ、同梱の起動オプションで「高精度カラー ON/OFF」として選べる様にしました(因みにこのオプションをONにすると、同時にディスプレイフォーマットも高精度のものに成る。無論学校のPCでは動かないが)。序に、クラス全体を所謂「Unicode/MBCS両対応」にしました。と言っても、内部では変換して常にUnicodeで扱っているだけなのですが。

[2012/11/23 21:08] | 首都高バトルTD
|
今日は。文字列表示クラスは、昨日基本機能が完成しました。因みにその時点でprintf系の書式に対応しておりました。そして今日、改行に対応し、空文字列は無視する様にし、スペースにゴミが映るのを防止し、更にプロポーショナルフォントに対応しました。個人的にはプロポーショナルはあまり好きではないので非対応でも良いかと思ったのですが、意外と小修正で済んだので良しとしました。プロポーショナルフォントの重なりに対応する為、文字は全て一つのテクスチャに描画しています。少々メモリの無駄遣いで、ノベルゲームの様なタイピング風表示が遅いという欠点が有りますが、高速で安全な筈です。又、テクスチャを作るだけですので、スプライト等で描画する際にかなり自由に設定が変えられます。
残る問題は学校のWindows2000で動くかどうかです。昨日は落ちたと述べましたが、以前動いていたフォントクラスを調べた所、今回と同じフォーマットのテクスチャが作成できています。他に思い当たる節は有りません。仕方ないので要所要所でログファイルを吐かせる事にし(学校のPCはフルスクリーンしか対応していない為ダイアログ類が使えない)、それを見て考える事にしました。
因みに私は開発中は常時コンソール画面を表示し、printfやsystem("pause")等でデバッグ出来る様にしています。未だ使ったことは無いですがscanfにも対応しています。私の様にVCの高度なデバッグを覚えるのが面倒な方にお勧めです。


<本日のスクリーンショット>
描画してみました。上がMS Pゴシック、中がMS ゴシック、下があんずもじ等幅です。右端の「jj」は、プロポーショナルフォントではみ出しが生じて他の文字と重なっても問題無い事の証明です。流石にテクスチャからはみ出す場合は切り捨てますが(修正するには文字列全体をずらす必要が有る。しかしフォントによってテクスチャを弄るのは避けたい)、その際ははみ出す部分に半角スペースでも入れて対応して貰う事にしました。又足跡マークは、特殊な記号も(環境が対応している限り)使える事の証明です。
DXFONT.jpg

[2012/11/23 14:50] | 首都高バトルTD
|
今日は。結局忘れませんでしたね。今日はTDtechnic二周年記念日です。
先日首都高が進まないと述べましたが、何故か調子良く進んでしまいました。道路用ポリゴンの基盤が完成し、DirectX9.0bの使い方にも割と慣れてきました。またSIRENで発見し培った技術「カウンター制御法(勝手に命名)」を採用し更にコードが書き易くなりました。そして先月くらいに思いついた「例外‐総当り法(勝手に命名)」により当たり判定やAIも高効率で書けそうです。所でこれらの技術は本当に私が発明したのか、それとも私が無知なだけで実は当たり前のものなのか。後者が有力な気がしますが、キーワードが無く調べるのも難しいので、当面は私が付けた名前で通します。
今はDirectXで使える高速なフォント表示を構築しています。似たようなものを作っている方がいらっしゃるのは存じていますが、Windows2000で正常に動くものは少なく見受けられるので自作しております。因みに昨日一文字の表示が出来たので今日学校に持っていった所、見事に落ちました。DirectXの初期化は出来ているみたいなんですが(古い首都高バトルTDのコピペだから当然)、フォント表示の何処か(恐らくテクスチャ・スプライト周り)で落ちている様です。一コマも表示出来ませんでした。

[2012/11/22 16:55] | 首都高バトルTD
|
今晩は。首都高の更新は実に5ヶ月半以上振りです。Google Mapsをトレースしたマップ製作の内、ナビゲーションポイントの原型が完成しました。ここから必要な情報を抽出して、プログラムで使える様変換して(そのツールも作らねばならない)…とまだまだ課題は山積みです。更に受験が来年に迫ってきた事も有りますし、なかなか進むことは出来ないでしょう。当分はSIRENで遊んでて下さい。ではまた。

[2012/10/19 21:00] | 首都高バトルTD
|
御久し振りです。当たり判定は移植したので、物理計算を改良しました。ギア比によって加速を鈍くする部分で、係数を1.0以下にする為に(トップギア比)÷(ギア比)という計算をしていたのですが、よく考えたらこれでは反比例の式になるので抵抗値のグラフは双曲線になってしまいます。今迄抵抗の差が大きすぎると思っていたのはこれに因るものでした。取り敢えずy切片が1.0に成る右下がりの一次関数として書き直し、それらしく成りました。次は新AI「SHIRO」を制作します。「アキオ」「マサタカ」「ユウマ」「UMA」に次ぎ五代目です。今回もスクリーンショットを撮るほどの変更点は有りません。失礼します。

[2012/05/05 11:11] | 首都高バトルTD
|
今晩は。OpenGLから未移植だったものの一つであるメーターを作りました。後OpenGLから移植していないのは、3Dモデルからの当たり判定範囲自動取得位ですね。


<本日のスクリーンショット>
件のメーターです。デザインがすっきりしたのは、作れなかったからではなくデザインの見直しをしたからです。以前のものと比べて如何でしょうか?
meter.jpg

[2012/04/22 19:05] | 首都高バトルTD
|
今晩は。やはり高速フォントライブラリが原因の様でした。但し、だからといってDirectX標準フォントを使ってみた所、複数の文字列を表示した時点で結局処理落ちしました。他の高速フォントライブラリを見付けましたが、其れも学校のPCではまともに動きませんでした。只、前のものよりは相性が良く、色とサイズが出鱈目ながらも表示はしていました。御陰で透過ビットマップが確実に使える事が判明したので、原始的なビットマップフォントライブラリを自作する事にしました。都合の良い事に、首都高バトルTDの文字列ではアルファベットしか使っていないので、此れも現実的な選択でした。ペイントで等間隔に文字を並べた画像を作りプログラム側で切り出して表示する、というものなので、表示する時に背景の透過さえ出来れば依存性が生まれるという事は考えられませんでした。そして今回は透過が出来る事も確実となったので、何ら障害は無くなったという訳です。案の定、今日ビットマップフォントに移植したものを試した所、正常に動作しました。此れでメニューが表示出来る様に成ったので、やっと走行部分の発表が出来るという事です。走行部分の完成から随分と間が空きましたが。今回は見た目の変化は有りませんので、スクリーンショットも有りません。失礼します。

[2012/04/19 22:17] | 首都高バトルTD
|
今晩は。あれからというもの、Windows2000では一度も正常に動作しておりません。只、初期化方法のみ現在のもので再び作った「930を画面中央に回転表示させる」プログラムは動きました。取り敢えず初期化方法は確立出来た様です。又動作しない本編でも、描画されないだけでBGM再生や操作受付は出来ています。相違点から考えると、次のネックとして怪しいのは文字表示ライブラリです。DirectX標準のものは遅いという事で、他人様のライブラリを使わせて頂いているのですが、高機能・高性能な事も有り古いPCと相性が悪いのかも知れません。其処で今日DirectX標準文字のサンプルを起動してみた所、思っていた程重くはなかったので、もし其のライブラリが原因だと確実に判明したら其方を使おうと思います。


<本日のスクリーンショット>
起動出来ないという弱点の為長らく公開出来ずにいましたが、コード的にはOpenGL時代の機能を殆ど移植してあります。私のPCでは正常に起動出来るので、スクリーンショットだけでも公開しておきます。OpenGLの時より遥かに軽いです。

ap1.jpg

[2012/04/15 00:39] | 首都高バトルTD
|
今日は。前回述べたプログラムですが、どのバージョンも起動しませんでした。又共通してどれも「IDirect3DDevice9コンポーネント取得エラー」と成りました。取り敢えず原因を絞ることには成功したので、学校のPCで確実に動いたサンプルを改造して、IDirect3DDevice9に関係する変数を全て吐かせました。すると、案の定違っている所が有ったので、全て揃えたものと怪しい所だけ揃えたものを様々なパターンで用意して起動してみた所、全て揃えたもののみ正常に起動出来ました。然し全て揃えた場合、リフレッシュレートを「0x3c」にしなくては成らないというのが疑問だったので、今日はリフレッシュレートのみ0にしたもので数パターン作って起動してみました。するとフルスクリーンのもののみ起動しました。又謎が増えたのですが、学校のPCでビルド出来ない以上変数を変えて調べられない為、ヒントを求めてサンプルを漁っていた所、画面モードを切り替えられるものを見付けました。其の一覧によると、主な画面モードの「ウィンドウモード可否」と「バックバッファフォーマット」と「リフレッシュレート」にかなりの制限が有りました。此等を中途半端な総当たりで試し続けていた為今迄動かなかったと思われるので、明日はリストに載っていた値ばかりをデフォルトにして起動してみようと思います。因みにウィンドウモードが不可でフルスクリーンモードのみというのには驚きました。


<本日のスクリーンショット>
OPTIONの項目が増えました。RESOLUTIONはウィンドウ解像度の選択で、設定はVGA(640*480)、SVGA(800*600)、XGA(1024*768)、フルハイビジョン(1920*1080)、NATIVE(ディスプレイの解像度に合わせ、ディスプレイ一杯に表示)を用意してあり、FULLSCREENはフルスクリーンか否かの選択です。因みにNATIVEはフルスクリーンがオンでもオフでも見た目が同じに成りますが、オフだとディスプレイをDirectXで初期化しない代わりにフルスクリーンでありなから他のウィンドウと共存出来ます。
option.jpg

[2012/03/30 21:34] | 首都高バトルTD
|
今日は。DirectX9.0cの件ですが、動きませんでした。どうやら丁度9.0b迄しか入っていないようです。HSP時代のHGIMG3やZGPのDirectXモードが動なかったのも当然ですね。9.0bのSDKは非公式ながら見つかり、添付されていたサンプルも(全部は試していませんが)動きました。残念ながら私が試しに作った「DirectXで画面中央にトレノを表示するプログラム」は起動できませんでしたが、サンプルが動く事から此れは画面モードを適当に指定した事に因るものだと思われます。明日は「DirectXで画面中央に回転している930を表示しながらFPS表示するプログラム」を持って行こうと思います。今回は画面モードを自動にしたバージョンも作り、又全バージョンに於いて全てのエラーについて原因を示すダイアログを表示させる様にしていますので、何らかの進展は有ると思います。結局不本意ながら此の方向で決定致しましたので、当初の「Windows2000プリインストールマシンでも動く3Dストリートレースゲーム」という肩書きは無くなってしまいましたが(DirectX9.0b以降のインストールが必要となる為)、その分「Windows2000マシンでも動くハイクオリティ3Dストリートレースゲーム」として頑張っていこうと思います。ハイクオリティと言っても、今の所此れ迄との違いはテクスチャを使っている点位ですが。


<本日のスクリーンショット>
明日テストするプログラムです。テスト用と言っても、文字さえ追加すればショップやガレージが出来るという割りと実用的なプログラムではあります。それにしてもOpenGLでXファイルを表示させるのは苦労したというのに
、流石に専用ライブラリだとあっさりですね。
dx.jpg

[2012/03/25 17:32] | 首都高バトルTD
|
今日は。今迄首都高バトルTDに意地でもDirectXを使わずOpenGLを使っていたのは、学校のPCに搭載されているDirectXのバージョン(7.0のまま更新できない)に合うSDKが手に入らない(と思っていた)からでした。然し、今日「Drivism」という他人様のレースゲームを学校のPCで起動してみた所、かなりグラフィックに拘っているにも関わらず何の問題も無く(フレームスキップでどうにかなる程度の処理落ちはしている)動きました。DrivismはDirectX9.0b以上のハードウェアレンダリングを要求します。という事は最低でもDirectX9.0bはインストールされている筈で、其れだけ最近のSDKなら手に入りそうです。又OpenGLのVBOという技術はDirectXのハードウェアレンダリングに近い仕組みなので此方も捨て難いと思っていたのですが、2002年以降程度のPCでないと動作しない可能性が高いという事も今日解りました(学校のPCはWin2k)。結局DirectXで決まりの様なので、明日DirectX9.0cが動くかどうかだけ確かめて(9.0cの方がより入手し易い為)DirectXの勉強を始めます。

[2012/03/22 22:52] | 首都高バトルTD
|
今日は。エンジン音を別スレッドで再生する等の改良でFPSがより安定する様にしました。只、今でさえCPU使用率が高過ぎる様に見受けられる為、今後モデリング、特に首都高のクオリティを上げていった場合に要求するスペックが非現実的に成るかも知れません。其れを危惧しながら他の部分を作り込むのもなんですから、先に製品クオリティの首都高を作り、必要に応じて要求スペックの削減等を行い、其の後他に取り掛かろうと思います。再びC1のみの予定ですが、今回は外回りも作ろうと思います。内回りからも見えますからね。又、地図により忠実に設計し、直方体で見える範囲の建物を作り、道路の壁には厚みを持たせようと思います。因みにモデリングソフト(メタセコイア)に下絵機能が有るのを発見したので、GoogleMap等を貼り付けて作業出来そうです。他には、オプションへのテクスチャ有無の設定の追加を予定しています。SEやBGMとは違い、低スペック化だけの為の項目ですが。


<本日のスクリーンショット>
モデリング中です。中央付近に貼り付けられている灰色の物がポリゴンです。
モデリング

[2012/03/11 18:23] | 首都高バトルTD
|
御久し振りです。判定範囲を自動で最適化する様にして、テクスチャを貼りました。実は数週間前から出来ていたのですが、テスト週間が途中に有った事とレンダリングが重過ぎて使い物に成らないという事から随分と発表出来ませんでした。取り敢えず、昨日の時点で、CPU使用率が2.20GHzCorei7マシンで平均一桁と成るレベル迄抑え、コマ落ちもかなり減りました。PS2エミュレータが実速度で動く環境ですから、自作ゲームがこんなに重いというのはやはり改善の余地が有るという事でしょうが、Win2000でも紙芝居という程でもないので、実用レベルかと思われます。因みに、知識が乏しかった為に無駄にマルチスレッドで設計されている事や、そもそもOpenGLを使用している事にも原因が有るのかも知れません。もしかすると、シングルスレッドで設計し直し、DirectXに移植するという事にも成るかも知れません。


<本日のスクリーンショット>
取り敢えずラインを除く地面と壁にテクスチャを貼りました。ディスプレイリストの使用でかなり軽く成りました。因みに左上の31は実測FPSで、設計がFPS30なので維持出来ているという事に成ります。
テクスチャ

[2012/03/10 14:17] | 首都高バトルTD
|
今日は。壁の当たり判定を移植しました。地面と同様、此方もMACKMANさんのモジュールをC言語に書き直した物です。更なる改造も考えて居りますが、当面は此のまま使用させて頂こうと思います。


<本日のスクリーンショット>
壁の当たり判定のテストです。判定は正しく行っていますが判定範囲を正しく設定していない為今はめり込みます。
wallhit.jpg

[2012/02/21 20:22] | 首都高バトルTD
|
今晩は。地面の当たり判定を移植しました。入力だけ書き直したら直ぐに動きました。序に、ドライバー視点を搭載し、更に其れを車体の傾きによってカメラも傾く仕様に致しました。此れが首都高バトルTD史上初のタンジェントの使用と成りました。又、先日エンジン音の追加に因る負荷を危惧して居りましたが、フレームスキップと同時に音もスキップする事でWINDOWS2000でも実用速度を確保する事が出来ました。但し、スキップする場合、途切れ途切れとは言わない迄も滑らかさが損なわれ若干不自然では有りますが。


<本日のスクリーンショット>
ドライバー視点にはミラーを搭載致しました。勿論、此方も車体の傾きによって角度が変わります。因みに、タコメーターも進化しました。
mirror.jpg

[2012/02/19 22:57] | 首都高バトルTD
|
今日は。先日一人プログラマーをやってて良かったと実感できる事が有りました。数Ⅱでラジアンが出てきた時、戸惑っている人が居ました。其の時、昨年の今頃sin関数やcos関数を使おうとして初めて見たラジアンに混乱していた自分を思い出しました。今の私は一年程止むを得ず使っていたので多かれ少なかれ慣れていますが、今から覚えて三角関数を始めるのは、少なくとも私だったら大変だったろうなと思いました。
其れはさて置き、エンジン音の搭載に成功致しました。初めて首都高バトルTDが走行可能と成ってから凡そ一年の事でした。実は先日から試行錯誤はしていたのですが、数フレーム毎に停止、巻き戻し、音程変更、再生を繰り返すとどうしても途切れ途切れに成りました。又、インターネット上で拾ってきたエンジン音プログラムはHSP製の上、プログラム上で鳴らしているので音色を変えるのも難しそうでした。其の為、再び後回しにしようと思っていました。然し先日、例えば同じエンジン音をA、Bの二つの名前で開き、Aを再生中にBを停止、巻き戻し、音程変更し、Bを再生中にAで停止、巻き戻し…を繰り返せば遅延を誤魔化せるのではないかと閃きました。実践した所、連続再生はされるものの雑音が入り、とても聞いていられる物では有りませんでした。其処で、原因は停止時に有ると見て、停止の代わりに音量ゼロにしてみました。すると大分改善され、其の後試行錯誤の結果、二フレーム毎に四つの音源を切り替えると最も其れらしく感じられたので、コードをクリーンアップし、取り敢えず完成と致しました。因みに、音源は音声ファイルを使用しているので、其れを変えればエンジンによって音を変える事も出来ました。後は、Win2kで動作確認をするのみです。


<本日のスクリーンショット>
タコメーターを新調しました。恐らく此のまま製品化されると思います。
タコメーター2

[2012/02/11 14:28] | 首都高バトルTD
|
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。