1個目のキューブをカメラが追跡します。キューブ数を増やしたり、減らしたりします。(最大300個まで)当方のcore2ペンティアム,2.4GHz環境では、500個表示した状態でも、あまり処理落ちせずに60フレームで表示できてます。秒間約36万ポリゴン。頂点ジオメトリだけで考えれば、36万程度は全然余裕みたいです。最悪、数ポリゴン程度でも60フレームが不可能になってしまいます。希望:blikeのVRAM描画を、超高速で行う関数を、setPix()などとは別に用意してくれるとありがたいです。VRAMの配列を直接扱うことを、許可してくれるとありがたいです。ヘッダーで変数名を公開するなどによって、公式に使用を許可してくれるとありがたいです。用意してくれると、安心して使えていいと思います。現状はsin()などは公式に使用を許可されてない状態なので不安です。(kcubeでsin()が使用されてるから、「公式に、使ってもいい事になってる...のかも...しれない??」という認識です。▼いつもありがとうございます。sinやcosなどは、標準関数に入っているものをそのまま使えばいいかなーと安易に考えていたのですが、bl_化したほうが安心ですか・・・確かにそうかもしれません。C言語の教育用に考えていたので、標準関数でできることは標準関数でやったほうがいいかなと思っていました。グラフィックが標準関数の範囲の外なので、それだけをblikeに背負わせようと思っていたのです。別にbl_sin()があっても教材として教えるときは使わなければいいだけなので、kemeppoさんのような人の安心のためにつけるというのは反対ではありません。ウィンドウのイメージデータへの直接アクセスを許すかどうかは悩み中です。ドライバが作りにくくなったらどうしようとか心配しているわけですが、これはもう少し悩ませてください。▼>>ウィンドウのイメージデータへの直接アクセスを許すかどうかは悩み中です。ドライバが作りにくくなったらどうしようとか心配しているわけですが、これはもう少し悩ませてください。ウインドウのイメージデータと言っても、直接ドライバー側のウインドウが持つフレームバッファーに直接書くことは要求してません。それをblMain()から許可してしまえば、カラー形式は様々なので、途端にblMain()ソースの移植性が失われてしまいます。(24bit,0xBBGGRR形式を前提に直接あつかえば、そのblMain()コードは32bit,0x00RRGGBB環境では当然正常に表示されませんし、移植性に問題が生じてしまう)そうではなく、commonの扱うレベルのフレームバッファーへの直接アクセスを言ってます。ここは32bit,0x00RRGGBB形式で固定なので、直接アクセスを許してもblMain()の移植性に問題は生じないと思います。bld_内の、まさにウインドウの直接のバッファーを、直接読み書きすることを許可するような仕様変更に関しては、もちろん反対です。そんなことしたらblikeの意味(blMain()の移植性)が失われますし。<bl_play_pcm()などを使えるようにしたい>blikeでサウンドをサポートしようと思い、どうやれば移植性のある実装になるかを思案してみました。条件として考えたのは1:ドライバー側の開発負担を最も小さくできる方法。(つまり、commonではどうしても実現できない機能のみの、最小限の実装)2:ソフトウェアで可能な部分は、極力ソフトウェアによるエミュレートで行う。(機種依存せずに実現可能な機能は、すべてcommon側で行う)3:ウィンドウズ環境に有利な設計をする。(波形は、ウインドウズで一般的なwav形式(リトルエンディアン、符号あり16bit,44100Hz)の使用を前提とする)です。これにより、結論としてはドライバー側が担当する機能:wav形式の断片(16bit,44100Hz,モノラルの波形パケット)を、指定された側のスピーカーで再生する。common側が担当する機能:wavファイルのロード。複数チャンネルの波形を合成して、一つの波形パケットを生成し、それをドライバーに渡す。各チャンネルの再生の管理。(波形全体の再生が完了するまで、blMain()とは別スレッドで、波形パケット生成&ドライバー側へのパケット転送を独自に続ける)という形になりました。ドライバー側はシンプルなパケット再生機能のみ。(渡されたパケットを、指定されたスピーカーで、ただ鳴らすだけ。)(ミキサーのような高レベルなことは一切行わない)common側はミキサー全般と、波形再生の再生状況の管理全般を担当します。ドライバー側は当然スレッドで独立して動かさねばなりません。ドライバー側では、ソースコードレベルでの移植性を考慮する必要が無いので、スレッド化できます。問題は、common側です。common側はソースコードの移植性(ソースコードの変更無しにコンパイル可能)を満たすためには、スレッドが使用できません。blikeではスレッドがサポートされてないからです。いうわけで、commonでスレッド生成が可能になるように、bld_でスレッド関連の関数をサポートすべきだと思います。a);の3つで十分だと思います。これをbld_で提供すれば、common側でスレッドを使っても、移植性のあるコードになると思います。音を再生してる間はblMain()の他の処理が全て停止する、という、悲惨な状況になると思います。音を再生してる間、ゲームの動きが全て止まるなんてショボすぎます。これは現代のレベルでは許されないレベルのショボさだと思います。これら全て行うソースを書いてしまえば可能ですが、これだと、新規のドライバー移植作業がとてもシンドイことになります。driverに分割する設計よりも、ずっと効率的に処理できるのも事実だし、また、commonによるソフトウェアエミュレートによるミキサーではなく、ハードやALSAなどに依存したミキサー機能を直接使えるので、より高速・高効率になるメリットもありますが。)blikeは、同じソースコードがどこでもコンパイルできて、まったく同じように動くのが売りだと思うので、ソフトウェアエミュレートで可能なことは、極力common側で行うのが正しいスタイルだと思います。ミキサーと波形再生管理のような、ソフトウェアエミュレートで可能な部分はcommonに書くべきだし、ドライバー側に多チャンネルの合成や、波形再生管理のような、高レベルのコンポーネントを要求すべきでは無いと思います。ドライバーの仕様に、スレッドを扱う関数のサポートを、追加すべきだと思います。単純にスレッド関連の関数は空としてドライバーを書けば良いと思います。ドライバーのスレッド関連関数が空関数になることに伴い、commonに書かれてる関数のうち、スレッドに依存した関数も空関数として無効化するようにすれば、blMain()のアプリ中でも、commonのスレッド依存関数を使用した部分は空関数で無効化されるので、おそらく有効機能のみでblMain()は無事に動くはずだと思います。ドライバー側でスレッドを提供しても、スレッドの提供をcommonまでにしておけば(blMain()には提供しなければ)、とりあえずblMain()レベル(アプリケーションレベル)では、移植に問題は生じないはずだと思います。単純に、チープな環境では、blMain()がチープな環境なりに、一応、動くはずです。(それはたとえば音が鳴らない等の差として)ただ、個人的には、スレッドの使用をblMain()にも提供すべきだと思います。(スレッドを使えない環境では動かないblMain()アプリが書かれうるけど、それはそれで、「スレッドが使えないOSでは、動かないアプリも時々あるな...」程度で諦めてもらえば良いと思います。)...個人的には、あまりに極端にチープな環境は、切り捨てるべきだと思います。スレッドが使えない、音が鳴らない、マウスが無い、ネットが無い、モニターが無い、等々、あまりにもチープな環境はサブターゲット(おまけ)と考えて設計すべきだと思います。これをメインターゲットと考えて設計してしまってるから、サウンドが無い、ネットが無い、マウスが無い、そしてスレッドが無いなんて状況になってるんだと思います。新しくて、いまどきの普通のパソコンなら有って当然な機能は、遠慮せずにサポートしても、現実的なケースとして考えるにおいて、移植に重大な問題が生じるようなケースは稀だと思います。大体、古いパソコンの想定は、10年前のペンティアム3機程度の機能を想定しておいて、それよりも古いパソコンやOSへの移植性は、ついで程度に考えておけば十分だと思います。486レベルの古い低機能なパソコンを、おまけターゲットではなく、メインターゲットみたいに考えてしまうと、たぶん、身動き取れなくなると思います。blikeの設計の妙な制約って、まさにそこだと思います。20年前のパソコンが、亡霊みたいに後ろ髪を引っ張ってるような状況に思えます。おまけターゲットならぬ、おばけターゲットというか。おまけターゲットも、せいぜいペンティアム3時代までで十分だと思います。これから先、多コア化に伴い、スレッドのサポートは必須になると思います。スレッドが使えない環境は、今後、間違いなく廃れていくと確信してます。過去方向の普遍性ではなく、未来方向への普遍性を求めるべきだと思います。いう関数が作ってはありました。バージョン01fにもあります。これを正規のblike関数として認めてしまいましょうか・・・。