■掲示板に戻る■ ■過去ログ倉庫めにゅーに戻る■
PS2【低レベル】プログラミング
1 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 02:17
ここでは一筋縄では行かないVUや、
EE、GSなどの実用性の無さから敬遠されがちな
低レベルプログラミングの話題を積極的に扱うスレッドです。
*もちろんプログラミング全般、アルゴリズム、
その他アイデア等の話題もアリです扱います。

PS2Linuxに付いての話題はこちら
http://cocoa.2ch.net/test/read.cgi?bbs=linux&key=992958478&ls=50

各種情報、リンクは以下をどうぞ。
>>2-10


2 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 02:17
テスト
■GSのブロック図
http://www.watch.impress.co.jp/pc/docs/article/20010622/p08.jpg
■東芝レビューVol55.VUなど
http://www.toshiba.co.jp/tech/review/2000/10/a07.pdf
■VLIW
http://www.atmarkit.co.jp/fpc/rensai/zunouhoudan004/vliw.html

■「PS2 Linux Kit」ハードウェアレポート
http://www.watch.impress.co.jp/pc/docs/article/20010620/ps2.htm
■〜とりあえず動かしました編〜
http://www.watch.impress.co.jp/pc/docs/article/20010622/ps2linux.htm


3 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 02:18
■PS2マニュアルで何かと問題になる「引用と転載」に付いて。
http://www.geocities.co.jp/Milkyway-Kaigan/2534/quotation.html


4 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 02:26
http://www.playstaion.com


5 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 02:29
http://www.geocities.com/yuko_hamano/yuko_hamano010.jpg


6 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 02:31

■FCの画像処理について(家庭用ゲーム機での画像処理テクニック)
http://ton.2ch.net/test/read.cgi?bbs=retro&key=983894890&ls=100


7 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 02:47
自分で削除依頼だしてこい


8 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 03:00
■GNU
ftp://ftp.gnu.org/
■GCC
http://gcc.gnu.org/
http://www.sra.co.jp/wingnut/gcc/gcc-j.html
■SDL CVS snapshots
http://www.libsdl.org/cvs.html
■とある専門学校で使用した授業用の資料
http://www13.big.or.jp/~akasata/dycoon/vanta/vanta.html
■OpenGL プログラミングテキストRelease 0.91
http://www.nk-exa.co.jp/mmtech/OpenGLEdu/Documents/OpenGL-text-091.pdf
■mesa
http://www.mesa3d.org/
http://www.nk.rim.or.jp/~jun/mesa/mesa_ins.html
■WinGL
http://www2a.biglobe.ne.jp/~hirapon/winglfan.html
■GTL
http://demo.and.or.jp/gtl/distinction.html


9 名前: 注意事項 投稿日: 2001/06/28(木) 03:58
今さらですが、
注:DVD吸出しネタや守秘義務違反、その他アンダーグラウンドネタはご遠慮願います。

環境上Linuxネタと重複しますが、そこは各自判断に委ねます。
話の成り行き上出てきた話題については、
その話題が早期に完結するならそのままここで、
長引きそうなら適したスレッドに移動、と言う事で。。

PS2Linuxスレッドと柔軟に使い分けていきましょう。

何が出るか判らないチェインリンク
>>100-110


10 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 04:22
糞スレですか?
荒していい?
荒していい?
荒していい?
荒していい?
荒していい?


11 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 04:25
■Cygwin
http://www.jaist.ac.jp/~fujieda/cygwin/
http://www10.u-page.so-net.ne.jp/fa2/riue-s/cygwin-ug-net/cygwin-ug-net.html
http://www.sosb.com/hp/apache/cygwin.htm
■David Baraff's Homepage
http://www.cs.cmu.edu/afs/cs/user/baraff/www/baraffhome.html
■Rigid Body Simulation
http://www.merl.com/projects/rigidBodySim/
■Open Dynamics Engine
http://www.q12.org/ode/ode.html
■物理法則に基づく剛体運動シミュレーションについて
http://www.cim.pe.u-tokyo.ac.jp/~kawachi/thesis/pbm-j.html
■こってり屋
http://village.infoweb.ne.jp/~tsuyozou/
■Kano's Web page
http://cgi3.tky.3web.ne.jp/~tkano/
■宇治社中改
http://www.cc.rim.or.jp/~devilman/
■シミュレータのための剛体力学理論
http://www.mirai.ne.jp/~mitsuman/mag/lab/rigidbody1.html
■クオータニオンについて
http://www.mirai.ne.jp/~kagii/rep/quaternion_fin.pdf
■Compute Navier-Stokes Eqns.
http://web.pe.to/~uchiyama/dns/


12 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 04:28
なんでばかみたいにリンクばっかりはってんの?


13 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 04:42
basic3d やら blow やらのソースを見ると,
3Dレンダリングに関してはよくわかるんですけど,
サンプルの数がこれだけだと結構きついんですが.
(あとmesa)
他にサンプルありました?


14 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 05:56
いまさらWinGLが何か役立つの? PS2で?


15 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


16 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


17 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


18 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


19 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


20 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


21 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


22 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


23 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


24 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


25 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


26 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


27 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


28 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


29 名前: sage 投稿日: 2001/06/28(木) 06:02
氏ね


30 名前: sage 投稿日: 2001/06/28(木) 06:09
.


31 名前: sage 投稿日: 2001/06/28(木) 06:09
.


32 名前: sage 投稿日: 2001/06/28(木) 06:09
.


33 名前: sage 投稿日: 2001/06/28(木) 06:09
.


34 名前: sage 投稿日: 2001/06/28(木) 06:09
.


35 名前: sage 投稿日: 2001/06/28(木) 06:09
.


36 名前: sage 投稿日: 2001/06/28(木) 06:09
.


37 名前: sage 投稿日: 2001/06/28(木) 06:09
.


38 名前: sage 投稿日: 2001/06/28(木) 06:09
.


39 名前: sage 投稿日: 2001/06/28(木) 06:09
.


40 名前: sage 投稿日: 2001/06/28(木) 06:09
.


41 名前: sage 投稿日: 2001/06/28(木) 06:09
.


42 名前: sage 投稿日: 2001/06/28(木) 06:09
.


43 名前: sage 投稿日: 2001/06/28(木) 06:09
.


44 名前: sage 投稿日: 2001/06/28(木) 06:09
.


45 名前: sage 投稿日: 2001/06/28(木) 06:09
.


46 名前: sage 投稿日: 2001/06/28(木) 06:09
.


47 名前: sage 投稿日: 2001/06/28(木) 06:09
.


48 名前: sage 投稿日: 2001/06/28(木) 06:09
.


49 名前: sage 投稿日: 2001/06/28(木) 06:09
.


50 名前: sage 投稿日: 2001/06/28(木) 06:09
.


51 名前: sage 投稿日: 2001/06/28(木) 06:09
.


52 名前: sage 投稿日: 2001/06/28(木) 06:09
.


53 名前: sage 投稿日: 2001/06/28(木) 06:09
.


54 名前: sage 投稿日: 2001/06/28(木) 06:09
.


55 名前: sage 投稿日: 2001/06/28(木) 06:09
.


56 名前: sage 投稿日: 2001/06/28(木) 06:09
.


57 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 07:52
>>13
あれ?mesaにPS2の機種依存部分のコードって入ってましたっけ?


58 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 10:02
>>57
入っているらしい、みたいなことが「README.PSX2_jp」には、
書いてあったような気がする。


59 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 11:27
っつうか実際VPUのアセンブラをバリバリ書ける人って
どのくらいいるんだろう?
VLIWのアセンブラなんて人が書くもんじゃないじゃん。ものすごい
特種技能だと思うんだけど、そんなのゲーム業界にそうそういない
んじゃないかな。
インテルのSSEも結局インテルが要員を派遣して最適化を手伝って
るみたいだし、速くなればなんでもいいってもんじゃないでしょ。

と泣き言を言ってみるテスト。


60 名前: けろ 投稿日: 2001/06/28(木) 11:29
>>57
/usr/doc/PlayStation2/mesa/src/PSX2
の下見てみて。少し幸せになれるよ。


気味が悪いのでまたサイコさんが現れたらサゲよっか?


61 名前: けろ 投稿日: 2001/06/28(木) 11:33
>>59
そういわれると燃えて来る...^^;

超最適化を考えずに単なる並列エンティティとして見れば
なんとかかけるんじゃないでしょうか?

今夜あたり僕も手を出してみようかと思いまあっす。


62 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 12:09
>>60
マリガトー。幸せになりました。OpenGLのサブセット+αで
グラフィックエンジンを設計してみようかな〜。
それはそうとサゲたほうがいいですかねえ。

>>61
サンプルコードを見た限りでは最適化は置いておいてひとまず
書けるレベルには到達出来そうです。
EEとGSではやっぱEEのほうに工夫のし所がありそうです。
GSは結局ただのビデオカードって感じがするんで。


63 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 12:38
サンプルについていたソースを書き換えて..というところから入って
いますが,実際そこで改変した内容でソースコードやバイナリを公開
してもいいのでしょうか?

引用:ttp://www.ps2linux.com/license.html
>当社の許諾なく、本ソフトウェアの全部または一部を複製し、賃貸し、
>改変し、公衆送信または公衆送信可能化することはできません。
とか書いてあるって事は..?

引用ならいいとか(w


64 名前: 7月組 投稿日: 2001/06/28(木) 15:26
現状では傍観しかできないが、持ってる皆様頑張って下せぇ!!


65 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 15:36
えっと本職ですが、VUアセンブラ、バリバリ書いてます。
コツは、まずアルゴリズムはできればEE+VU0(マクロモード)で確認しておくこと。
次に、アッパーとロワー命令を重ねずに、つまり片方はNOPで書く。
レジスターはあとの最適化を考え、贅沢に使う。つまり、あまり使いまわさない。
で、レジスターは何を使ったかはしっかりコメントを残す。
その状態で動作確認。次はNOP段入れ。例えば、
SUB.w VF25w,VF08w,VF25w NOP
MAXy.w VF25w,VF25w,VF00y NOP
ってあったとして、VF25wをすぐに使用しているが、実際にはレイテンシティの問題で、
SUB.w VF25w,VF08w,VF25w NOP
NOP NOP
NOP NOP
NOP NOP
MAXy.w VF25w,VF25w,VF00y NOP
と、全く同じわけ。で、レイテンシティを考慮したこういうNOP段をいれておく。
これからが、いよいよ最適化。いかにNOPをなくせるかを考えて、命令の入れ替えなどを行うわけ。


66 名前: けろ 投稿日: 2001/06/28(木) 16:55
>>65
ありがとー。そーゆーのめちゃくちゃ趣味です(マイクジョンソン
本に噛り付いてたタイプですので)。今夜やってみますです。
またよろしくー


67 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 17:26
>>65
だから最適化されたソースにやたらとNOP命令が入っているんですね.
(確かにそう組んでいかないと最適化できそうに無いな....
DIVとか使うと37もレイテンシがかかっちゃうんですね.

レジスタは32-2本を上手に使えということか...
#D3D8のピクセルシェーダーみたいだな


68 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 18:02
>>65
ウップ、吐き気が・・・。
でも一般的な計算、例えば行列の乗算や逆行列の計算とかは
十分に最適化されたコードがあるだろうしあとは組み合わせ
を考えればいいのかな?そんなムシのいい話は無いかな・・。

>>67
ピクセルシェーダーは知らないんだけどVertexProgramの
アセンブラとほぼ一緒なんでビックリ。
マイクロコードうまく使えばとっても面白そうな事が出来る
かも。最適化は置いておいて(ダメ?)。


69 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 18:02
>>67
>DIVとか使うと37もレイテンシがかかっちゃうんですね
何のはなし? VUならDIVのレイテンシは7だけど?


70 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 18:13
このスレだけ世界が違いますな


71 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 18:21
命令の並べ替え→ループアンローリング→データの最適化→ウマー


72 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 18:42
VUのアセンブラは別に難しくないよ。
C言語で高速なレンダリングルーチンを書くのよりは相当簡単。
高速なレンダリングルーチンをCで書こう度すると
内周では関数を呼びたくないし、関数を展開することによって
省ける処理とかもあるからビローンと関数を開いて
最適化することになるんだけど、大概同じ処理を
えっちらおっちらxyzにしたりするんだけど
コピーペーストのミスや、同じようなもので
ほんのちょっと違うだけのものがずらーっと並んでしまい
ちょっとした「ウォーリーを探せ」気分。
おまけに、キャッシュの問題でたまに関数化して
追い出した方がいい部分なんかもあったりして結構厄介。
これと比べたら3D計算を強く意識して作られた
SIMDであるVUは大分楽、ちょっとぐらいアホやっても速いし。
3Dをある程度わかっていればVUの命令セットには
結構喜べるんじゃないかな?
著しくアセンブラが苦手とか出なければだけど。

VUの難しさは、デバッグのし難さと、DMA周りだと思うよ。
この辺はなかなか相乗効果を持って難易度を上げてくれるので
要注意。
それと、仕様変更は泣けるかな。
後は無茶をしなければ問題ないかと。

とりあえず、Cで普通に3Dが扱えるようになってから
VUに挑戦したほうがいいと思うよ。
そうすれば全然難しくない。


73 名前: けろ 投稿日: 2001/06/28(木) 19:10
>>72
本当にありがとー。今から始めてみます。
なんかお礼がしたい気分です。


74 名前: けろ 投稿日: 2001/06/28(木) 20:25
聞きっぱなしで申し訳ないのですが、、、

市販のゲームの場合、やはり全部カーネルモードで kseg? で直接
アクセスしてるのでしょうか?


75 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 20:34
カーネルモード? kseg? 何それ?(爆)
これでも市販ゲームのプログラマーだが(藁


76 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 20:51
いや、ゲームでも一応ユーザーモードで動いておりやす。
物理アドレス=論理アドレスでそのまんまマップされてるので、
I/Oは直叩きしほうだいですが。
ただ、メモリは同じ物理アドレスがcachedとuncachedの両方で
マップされてるので、アドレスをずらすだけでcached access
するかどうか制御できて、ちょっと便利。


77 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 21:14
72は意味のあることを何も言ってない。口先だけで他人を動かそうとしてるぞ...。皆気を付けろ。
初心者はドットプロダクトのVUコード書くだけで一日潰れるぞ。覚悟しとけよ!


78 名前: けろ 投稿日: 2001/06/28(木) 21:17
>>77
んなことわかってるけど、楽しいから良し。
僕らみたいなヘタレ学生にはああいう扇動してくれる先輩
は正体なんであれ、めちゃくちゃありがたいです。


79 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 21:28
>ただ、メモリは同じ物理アドレスがcachedとuncachedの両方で
>マップされてるので

おおう、エレファント! じゃないエレガント!


80 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 21:46
>>77
VUコーディングしてるけど、
カリカリの最適化を考えなければそんなに難しくないです。
X86でFPU駆使してプログラム書く方がはるかに難しいです。

普通にソフトウェア3Dエンジンが描ける人なら余裕だと思います。


81 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 22:28
すごく参考になるなぁ…。メモメモ。


82 名前: ケロ 投稿日: 2001/06/28(木) 22:43
>>80
そんなの数人しかいねーだろ.ま、その数人が書いてくれりゃ十分なんだがな.フツーなやつはそんな低レベルどうせ書けやしねんだし.っても書けねーヤツは高レベルもマトモにゃ書けねーから困ったもんだ.


83 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 23:09
>>82
何が数人なんだか不明。
ま、井の中の蛙ケロってとこですか


84 名前: けろ 投稿日: 2001/06/28(木) 23:13
紛らわしい。HM変えようかなあ。


85 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 23:13
>>80
ということは結構な数の人ができることになるね。


86 名前: げろ 投稿日: 2001/06/28(木) 23:18
>>85
そうか?マトモな3Dエンジンなんてそうそうないぞ?


87 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 23:22
>>86
求めるレベルにもよるだろう。
ゲームの場合、それらしく見えればOKなので、
「非線形FOGってなに? オレは単純にZ値に定数掛けてFOGパラメーターにしてるけど?」
ってな奴でもアリだよな。それをマトモな3Dエンジンじゃないなんていえばそうだし、それがどうしたとも言える。
スペキュラー? そんなの適当に8乗ぐらいでいいよね?とかな。
あ、全部オレだ(藁


88 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 23:23
>>84
ただの煽り厨房だって。気にしなさんな。


89 名前: けろーん 投稿日: 2001/06/28(木) 23:43
やっぱりゲーム屋ってレベル低いのね……


90 名前: デフォルトの名無しさん 投稿日: 2001/06/28(木) 23:47
大量のポリゴンを短い時間で処理するなら自信があるぞ。
OpenGLみたくまじめな実装書けたって、処理時間がかかるんじゃゲームプログラマーとしてはヘボ。
わかったかな、煽り厨房君。


91 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 00:02
>>90
なんだそれ.で、何千マンポリゴン/秒出せるんだ?


92 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 00:05
GSのマニュアル一通り読んだのだけどCRTCの機能が奥深そう。
マージ回路とフィードバック出力はどう使えばいいんだろう。
ちょっと使い道考えてみた。
・矩形出力1にフレームバッファとα、矩形出力2にBGColorでフェードIn/Out
・インターレスモードで矩形出力1にフレームバッファ、
矩形出力2に1ラインアドレスずらしたフレームバッファを設定して、
フリッカーフリー。
・矩形出力1にRGBA32bitフレームバッファ、矩形出力2に縮小したフレームバッファ
で転送先αブラー。
・YYYフィードバックで徐々にグレースケールになる効果

YCbCrフィードバックは何に使うのか謎だね。


93 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 00:21
>>92
1ラインアドレスずらすってどうするの?
フレームバッファは2048wordアラインだから不可能だと思うのだが。

それから縮小したフレームバッファとCRTCでマージしても、
バイリニアかからんので、綺麗にボケないような。

またYYYでフィードバックしても、次のフレームでしか使えんから、
1レイテンシ送れるぞ。
フィードバックを保存しておくバッファも余分に必要になるな。


94 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 00:25
うちの会社、VUかけるの俺だけなんだけど。(15人中1人かな)
他社ではどうなんでしょう?

VUは簡単だよ。
光源・シザリング・ワンスキンで1、2日ぐらい。
性能はケースバイケースだけど、秒間300〜400ってとこかなぁ。


95 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 00:29
>>94
単位はナニっすか?


96 名前: 92 投稿日: 2001/06/29(金) 00:31
>>93
マージプロセスによるフリッカーフリーだけど、

例えば640×480のフレームバッファの場合、
矩形出力1と矩形出力2に同じフレームバッファを設定して、
矩形出力1と2のMAGVを2(通常の2倍)に設定。
矩形出力2のDVを1に設定すれば、いけそうな気がするんだけど。

どうなんでしょ、プロの方々。


97 名前: 92 投稿日: 2001/06/29(金) 00:36
これじゃダメだ。
矩形出力1と矩形出力2に同じフレームバッファを設定して、
矩形出力1と2のMAGVは1、 インターレスモードで、
矩形出力2のDVを1に設定すれば、いけそうな気がするんだけど。


98 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 00:54
>>95
万じゃないのかなぁ。300万。でもその次の単位がわからならい。たぶんトライアングルだと思うけど。
つまり、秒間300〜400万トライアングル。
ポリゴンって言い方だと、いろいろ不明なんでね。ごまかしも聞くけど(w
うちはそのぐらいかな。あまり正確には測ってない。必要もないし。
描画時間の問題もあって、描画面積が大きいともっと少ないポリゴン数になる。
カメラむちゃくちゃ引いた状態であれば、そのぐらいは出てるよ。
つまりクリッピングなしで、そのぐらい全て画面に描画されてるってことね。
数字だけ見て、全然ダメじゃん(一千万もでないのか)と思う奴がいるなら、勝手に思えばいい。


99 名前: プロのひと 投稿日: 2001/06/29(金) 00:59
個人的にはvclマンセーなんですが、みなさんどうですか?


100 名前: 海女 投稿日: 2001/06/29(金) 01:11
vclてなんだよ?それでPS2低レベルプログラミングできるのか?


101 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 01:13
>>98
シザリングまじめに全てのモデルに適用したらそれくらいでは?
シザリングしなければ1000万頂点いくのは当然だし。


102 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 01:14
SCEAマンセー
http://www.devnet.scea.com/research/gdc2001/gdc_procedural.htm


103 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 01:15
>>100
>>102のPDFに書いてあるよ。
SCEAのdeveloper向けページに入りてぇ


104 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 01:19
>>101
ゲーム屋はシザリングとクリッピングの区別もつかんのか……


105 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 01:21
>>104
ハァ。一応理解しているつもりですが102の文章になにか不都合が?


106 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 02:03
>>105
別に無いが、何か問題か?


107 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 02:03
VCL : VU Command Line preprocessor

シングルストリームのVUコードを、
レイテンシとペアリングを考慮して自動で最適化してくれる。
これを使うと
2wayスーパースカラ、インタロックありのCPUと同じ感覚で組める


108 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 02:14
vcl、まだ使ってないんよ。
次回、何かVUコード書くときに使ってみてもいいけど。
で、どうよ? そんなにいい?


109 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 02:18
>>108
やっぱ楽だよ。
NOPに埋もれたコードより遥かに可読性が高いし、修正も楽。

ただ、Lower/Upperの振り分けをアルゴリズムレベルで考慮することも
重要なわけで、万能ではないな。


110 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 02:30
>>101
> シザリングまじめに全てのモデルに適用したらそれくらいでは?
> シザリングしなければ1000万頂点いくのは当然だし。
シザリングすると300〜400万で、しないと333.333…トライアングルってこと?

単位揃えてくれないと訳わかんないよ。


111 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 02:32
>>109
それはPS2Linuxに入っているのか!?


112 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 02:37
>>111
スマソ ライセンシー向け開発ツールの話。
なんか気がつくと、ここ、同業者が数人集まっていると思われ(藁


113 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 02:38
>>111
入ってるわけねー。


114 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 02:44
>>102
そのpdfのVCLについての解説

No more writing VU code in Excel!
もうVUコードをエクセルで書くことはない!

笑える。エクセルでコーディングしてたのか。


115 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 03:00
聞いた話では、EmacsでVUコードを編集するための作られた、vu-mode.elが
この世のどこかにあるらしい。


116 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 03:01
>>114
しかし、エクセル使った方がコーディングしやすいぞ、VUコードは。


117 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 03:05
>>110
>シザリングすると300〜400万で、しないと333.333…トライアングルってこと?

イマドキ独立頂点で三角形書いてるところなんて無いと思うけど…。(煽りだよね?)

大まかなところだけど、1000万頂点"以上"、実際に1000万ポリゴンのシーンを
(テクスチャの転送の量、スケジューリングとか、頂点データ量、部分的に
頂点データを固定小数点化する事で帯域を圧縮する、ADCビットを使って
パイプラインを出来るだけ持続するなどの工夫で…大抵のドキュソメーカー
でもやってる…)書くことは可能。ただしそれだけ頂点を出しても大体1頂点
にかけられるクロック数が20クロック前後なんでプログラム的に面白い絵は
出ないので、全部そういう頂点処理を行うわけじゃないから(たとえば人型
のモデルを描く部分はスキニングを行うので圧倒的にスループットは落ちる
し、画面手前まで迫ってくる背景はシザリング平面で新たに頂点なんかを
生成するのでそういう場合パイプライン化しにくくなるからスループットは
落ちる等)実際の複雑さではそれよりもずっと落ちるけどね。
#単純な頂点のスループットを上げる「だけ」なのは時代遅れと思ってみたり。


118 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 03:07
性格の悪い117はオフラインでも嫌われ者。


119 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 05:44
>>117
>単純な頂点のスループットを上げる「だけ」なのは時代遅れと思ってみたり。

ハゲシク同意。


120 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 14:33
PS2の開発機にはどんなライブラリ等があって,
つまりPS2Linuxのキットには何が無いんだろうか?

IPU周りとかか?


121 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 16:58
HiGやHiPはどうよ?
タイトル開発中に出てきたライブラリなんで全くノータッチなんだが、結構使える?


122 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 17:50
>>120
すごく乱暴に言うと、一年ちょっと前のライセンシー向けの内容とほとんど変わらない。
無いのはIOP関連ぐらい。
プロも何にも無いところから全て作ってる。がんばれ。

>>121
ゴミ以下。


123 名前: デフォルトの名無しさん 投稿日: 2001/06/29(金) 19:08
H O V E D P R O S J E K T - H I G
http://higstud5.hig.no/playstation/


124 名前: デフォルトの名無しさん 投稿日: 2001/06/30(土) 01:20
>>121-122
HiGいい感じの設計になってると思うんだけどなぁ
なんでゴミ以下なの?


125 名前: デフォルトの名無しさん 投稿日: 2001/06/30(土) 02:48
>>124
LibGSみたいなもんだからなぁ。
PS2で期待される画面クオリティを追及しようとする向きには使えないでしょう。
非リアルタイム系のゲームでなら使えるかもしれないけど。
フォーマットだけ使ってライブラリは使わないって手もあるか・・・


126 名前: デフォルトの名無しさん 投稿日: 2001/06/30(土) 07:52
>>125
LibGSみたいなもんってのがわかんないですが、
付属のマイクロコードがタコとかなの?
サンプル見る限りそんなに遜色なかったけど。


127 名前: デフォルトの名無しさん 投稿日: 2001/06/30(土) 15:07
サンプルすら見てないのでわからんが、汎用性を求めるあまり、速度やメモリー効率が無駄になるってのはよくある話だけど、
そんな感じだろうか?
結局のところ、HiGより良いコードを既に持っているかどうかにかかるとは思うのだが、
自分のコード(ライブラリ)とHiGのどちらが良いかは、HiGを理解して使ってみないと判断できないしなぁ。
鬱だ。


128 名前: デフォルトの名無しさん 投稿日: 2001/06/30(土) 15:11
>>127
理解できりゃ使う必要はないと思われ.
判断できないのは理解できてない証拠と思われ.


129 名前: デフォルトの名無しさん 投稿日: 2001/06/30(土) 16:06
HiGそれほど悪くないよ。あのプラグイン構成は賛否の分かれるところだろうが、
付属のマイクロコードの質は高いと思う。


130 名前: デフォルトの名無しさん 投稿日: 2001/06/30(土) 16:06
結局SCEAマンセーになるんだろうな。
どうも新しいサンプルはSCEAで作られているくさい。


131 名前: デフォルトの名無しさん 投稿日: 2001/06/30(土) 21:25
HiGのVUコードを見てみた。
ライティングやテクスチャマッピングの組合せに応じて、何通りもマイクロコードがあるんだね。
これって、何の問題もないのだろうか。全てのマイクロコードがVUメモリーに載る?
>HiG使っている人

今使っているVUコードは1つのコードでいろいろな処理をしている。
条件分岐を多数使っているので、単純な処理だと遅いんだよね。


132 名前: デフォルトの名無しさん 投稿日: 2001/06/30(土) 22:29
>>131
必要に応じてロードしなおしゃいんじゃねーの?
つーか、守秘義務違反だろ.今ケーサツ向かってるぞ.


133 名前: デフォルトの名無しさん 投稿日: 2001/06/30(土) 22:40
>>132
コードを漏らさなければ大丈夫だよ。
特許とられてない限り問題ないし。


134 名前: 投稿日: 2001/06/30(土) 23:05
>>132
で、そのロードのペナルティってどれくらい?

汎用のVUコードを1つつくるか、専用のVUコードをたくさん作るのはどっちがいいのか
って話題くらいいいっしょ。


135 名前: デフォルトの名無しさん 投稿日: 2001/06/30(土) 23:13
>>134
コードが1kwなら1/300000秒でロードできるがな.
毎フレーム1kwのを10個ロードするとすると60*10/300000で0.2%だ.
どうだまいったかコラ.


136 名前: 134 投稿日: 2001/06/30(土) 23:41
まいった。

そっか、そんなにVUコードを載せ変える事はないのね。>>10個


137 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 00:25
いや、てきとにーして100個だとしても2%だぞ.


138 名前: 投稿日: 2001/07/01(日) 01:32
それが、500個だと10%だね。
ここまで、来ると不利になるのか。


139 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 03:05
PS2は転送・計算・描画を並列で処理してナンボ。
SCEのクソコードなんか参考にするな。


140 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 12:24
>>139
特に初期のサンプルコードがクソだというのは同意するよ。
けど、最近のサンプルは結構いい部分もあると思うけどどうよ?
一応
>PS2は転送・計算・描画を並列で処理してナンボ。
このへんも出来るようなつくりにはなってるし。


141 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 12:41
>>140
最近はSCEAだからじゃないか?
SCEIにはバ●しかいないからな.


142 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 15:22
なんでこんなに低レベルなの?
もっと踏みこんだ技術系のお話しようよ。


143 名前: けろ 投稿日: 2001/07/01(日) 15:23
>>142
つー前に自分で話題を提供しろよ.
まったく低レベルだな.


144 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 15:27
>>143
なんか口調が180度変わってない?


145 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 15:33
>>144
偽者です。


146 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 15:37
>>142
所詮ここには、ゲーハー厨房と底辺業界人しかいません。
技術交流などどいった推敲なことを期待する方が無駄です。

まだこっちのスレの方がましでしょう。
VU周りの話が発展するのに期待。
http://cocoa.2ch.net/test/read.cgi?bbs=linux&key=993965253


147 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 15:39
>>92
1ラインずらしてマージ -> フリッカーフリー
は正解でしょう。
つーか、プロの方?


148 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 18:05
>>145
あっちのスレ見てきたけど恐らくけろに邪魔!とか言われた
やつの仕業だろうな。程度低いこと。。


149 名前: けろ 投稿日: 2001/07/01(日) 19:38
>>147
正解ってなんだ?
バンド幅食うからスプライトで重ねた方がいいよ.
ソフトを楽にしたい時には有効だね.


150 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 19:58
>>149
スプライトで重ねた方がバンド幅食わない?


151 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 20:01
>>150
>>149>>82だと思われ。
たんなる知ったかぶり野郎の言うことだ相手にするな。


152 名前: 147 投稿日: 2001/07/01(日) 20:15
>>151
まあ、いろいろ方法あると思うから
検証してみるのもいいんじゃない?
マージ回路使うとすると、640x448のダブルバッファになるはずだから
少ないvramがさらに少なくなるわけだし。

しかし、素人の人がサクっとこんなこと思いつくとは・・・
ちょっと打つ気味・・・侮れないね


153 名前: 92 投稿日: 2001/07/01(日) 20:54
>>152
PS2のフリッカーフリー対策は前からいろいろ妄想していたので、
CRTCの機能を見たときピンときました。
他にも
640×448のバックバッファと640×224のプライマリを用意して、
V-BLANKタイミングでバイリニア補間で転送とか、

640×224のバックバッファと640×224のプライマリを用意して、
V-BLANKタイミングでプライマリをバックバッファにαブレンドで
フィードバックすれば、ジャギは残るけどフリッカーは消えるかな

とかいろいろ考えてたんですけどね。


154 名前: 92 投稿日: 2001/07/01(日) 21:02
そういえばフィードバックを考えると
フレームバッファのサイズは512×512の方が良いですね。


155 名前: けろ 投稿日: 2001/07/01(日) 21:23
>>154
縦の512は無意味と思われ.


156 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 21:32
>>155
お前墓穴掘ってるぞ。
テクスチャとして使うには幅、高さともに2のべき乗でなければ
ならない。そんな基本的なこともわからないの?
それにPALで適切な解像度を得るには縦は512(256)である必要もある。

あーあ、
ついに知ったかぶりのゲーハー厨房であることを証明しちゃった(藁


157 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 21:36
>>156
(藁
ねえ、まさか君はプロじゃないよね?


158 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 21:36
>>156
いや、君の方が恥ずかしい。指摘する気にもなれん。


159 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 21:38
>>155=157=158
指摘してくりくり。


160 名前: けろ 投稿日: 2001/07/01(日) 21:40
フィードバックってテキスチャでやんなくてもできるんだけど.
ついでにいうと、テキスチャマップ使う場合でもレジスタに512なり
256なり指定すればいいわけで、ゴミ領域使わんようにすればいんだよ.
リピートも範囲切ってできるしね.
あ〜あ.


161 名前: 156 投稿日: 2001/07/01(日) 21:53
>>160
すまん、ぼけてた。


162 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 22:10
なんぞ微笑ましいやり取りをしているな。


163 名前: ゲームアマグラマ 投稿日: 2001/07/01(日) 22:12
ときに、CRTCに支援機能があるのに
なぜフリッカー低減してあるソフトが少ないの?とか訊いたら
ゲーハー板になってしまうでしょうか。


164 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 22:24
>>163
方法はいくつかあるのだが、それぞれ一長一短だから。
たとえば上の話題では、わざわざ余計にVRAM確保しなきゃならない。


165 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 23:17
>>164
結局全てVRAMの少なさに起因するのね。


166 名前: けろ 投稿日: 2001/07/01(日) 23:23
いや、少ないなら少ないなりにもう少しGSの方をなんとか
しといてくれればよかったんだが…


167 名前: 92 投稿日: 2001/07/01(日) 23:42
今日はEE,VU周りのマニュアル読んでました。
ポリゴン数稼ぐには、できるだけ頂点情報を圧縮して、
無駄なバス転送を避けてVU1の並列性を高めるしかないみたいですね。

三国無双とか大量に人出してますけど、
全オブジェクト共通の、手とか足とかのパーツ単位でVUメモリに全部乗せて、
人数分のマトリクスを送って、一気に描画するとか、
そういうアプローチが効率的なんでしょうかね。

オブジェクトをモーフィングして再利用するとか、
小物を着けかえるとか、特殊なモデリング技術が要りそうですけど。


168 名前: デフォルトの名無しさん 投稿日: 2001/07/01(日) 23:55
>>167
そいつを検証してみて頂戴。手元にマシンがあるんだしね。

バス転送とVU1計算とGS描画のうちどこがボトルネックになっているか。
こっちの感覚だとVU1計算だね。


169 名前: けろ 投稿日: 2001/07/02(月) 00:07
>>168
そんなのやるまでもないと思われ.
あんたの感覚で正解だよ.GSうならせるためには2サイクルで1つデータ
送らないけんよ.内部バスはさらに倍速いしね.


170 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 00:23
ん? 描画がネックになることもあるよ。
大きなポリゴンを何枚も出してみれば解る。
無駄に重ねるとすぐに描画ネックだYo!


171 名前: 147 投稿日: 2001/07/02(月) 00:32
>>167
いいセンスしてるなぁ・・・うちの会社来ない?(ワラ
どんどん思ったこと書いてくだされ。
良いアイデアあったらパクらせていただきます。。。

>>169
まあ、状況によりけりだから一概には言えないけどね。
描画面積が多ければGSが落ちるだろうし、
テクスチャとかを大量に転送すれば、DMA転送で落ちるだろうし。
あたりまえだけど、ちゃんと状態を調べてから最適化することをお勧めします。


172 名前: 147 投稿日: 2001/07/02(月) 00:35
あ、かぶりました。すみません>>170
文章書くの遅いんです。。。


173 名前: けろ 投稿日: 2001/07/02(月) 00:36
>>170
当たり前.
そんなこと言い出したらプログラムを特定しないと無意味だ.
無駄に重ねる意味ないわけだし、フツーはポリゴン増えーのサイズは
減れーのだろ.


174 名前: けろ 投稿日: 2001/07/02(月) 00:40
>>167
そこらの雑誌やwebの受け売りと思われ.

>>171
程度が知れるぞ…


175 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 00:48
>>173
別にプログラム特定しなくても、ゲームにおいてはありがちな話だと思うけどな。
タイトルまで特定しろなんて言わないでね。
だから特殊な状況だとは思わない。普通に考慮すべきことだと思うけど<描画ネック
知らない人が >>169読んで、描画ネックなんてありえないのかと思われると間違いなんでね。


176 名前: 147 投稿日: 2001/07/02(月) 00:58
>>174
いや、まあ、程度知れてしまっても良いんですがね・・・
ただ、PS2をはじめて触ってるわけでしょ、彼らは。
そのときに、いままでの雑誌やwebでの情報を実機と照らし合わせながら
実際に理解していくってのも立派な能力だと思うんですよ。

>>175
アルファブレンドとかまじめに考えると奥からすべて描いてく必要あって、
そのときにはけっこうな描画量になるだろうしね。

で。
あんまり初学者をイジメてもしようがないわけだし、
うちらの持っている情報で、出せるものがあったら出していって、
なんらかのフィードバックを期待しても良いんじゃないかと思う今日この頃。


177 名前: けろ 投稿日: 2001/07/02(月) 01:01
>>175
大抵は計算ネックでGS自体は遊んでる時間があると思うがな.
GSはそれ以外のグラフィックチップに比べて異様にラスタライ
ズのバンド幅があるわけだから、そういう状況になるのはバラン
スの悪いくそゲーくらいだろ.


178 名前: けろ 投稿日: 2001/07/02(月) 01:04
>>176
それは無駄に重ねてるわけじゃねーだろ.だいたい奥から描くかどうーか
なんてバンド幅に関係ねー氏.ソートしてたらかえってGSネックになら
ねーだろ.


179 名前: 147 投稿日: 2001/07/02(月) 01:13
>>178
Zテストではじかれれば、それ以降の描画処理はしないよね?
奥から順番に描く -> デプステストはあってないようなもの
ということで、GSの負荷になるでしょ?

俺って、なんか勘違いしてる?


180 名前: けろ 投稿日: 2001/07/02(月) 01:19
>>179
マトモな絵にしたい&&ソートしないとマトモな絵にならない
状況であればもちろんそだよ.
わかるかな?


181 名前: 92 投稿日: 2001/07/02(月) 01:20
>>168
残念ながらモニタがないので実機で検証できないんです。
現状はマニュアル読んでいろいろ考えているだけで・・・。

ただ例えVU1の計算がボトルネックであっても、
1オブジェクト×複数マトリクスというアプローチは
ループが一段増えるだけで、むしろ効率は上がると思うのですが。

>>147
どうもです。
何か思いついたら地道に書きこんでいこうと思います。

>>174
なぜそんなに否定的なんでしょう。
一応自分で考えているのですが・・・。
むしろPS2の最適化の情報が載ってる雑誌やwebがあったら教えて欲しいぐらいです。


182 名前: けろ 投稿日: 2001/07/02(月) 01:24
>>181
通常3σくらいはそうだからだよ.
君がそれ異常のところにいるんだったらゲーム業界を助けてやってくれ.


183 名前: けろ 投稿日: 2001/07/02(月) 01:27
>>180
あぁ、&&じゃなくて||だな…鬱だ


184 名前: 147 投稿日: 2001/07/02(月) 01:47
>>180
いや、たいていのゲームはちゃんとした画面をめざすわけでしょ。
しかもできるだけきれいなエフェクト満載で。
そうするとGS落ちもありえるってことです。

計算ネックに遭遇することのほうが多いことは認めます。
でも、最適化で計算ネックなくしていったら、
結局GS描画落ちにぶち当たってしまった
っていう悲しいこともありえるから、
やっぱ、ちゃんと調べよう、ってことで、良いよね? >けろ


185 名前: けろ 投稿日: 2001/07/02(月) 01:54
>>184
だから調べるにはプログラムの特定が必要だろうが…
>>167から始まったわけだが、こういうものだとするとアルファ
ブレンドなんて使わんだろが.
もともと無駄に重ねたらとかいってたヤツがなんだそれは…
まったく支離滅裂だな.
ま、ひまつぶしなんでかまわんのだが.


186 名前: 168 投稿日: 2001/07/02(月) 02:13
>>181
昔やった事があるんだよね。あんまり速くならなくて失望した覚えがある。
で、別にバスはボトルネックになっていないんだなぁと分かった。


187 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 02:15
>>185
現実のプログラムあげるわけにいかんから、テストしてみたかったら重ねてみって言ったんだよ、このタコ。
おまえ、いったいどんなゲーム作ってんだ? それともゲーム屋じゃねぇのか?

格闘ゲームのような閉じられた空間ならいいだろう。
だが、広いフィールドで、遠くまでビルが立ち並ぶようなものはどうだ?

あと、オレは >>147じゃないからな。


188 名前: 147 投稿日: 2001/07/02(月) 02:15
>>185
すまん、論点が良くわかんなくなってしまった・・・
とりあえず逃げます。お邪魔しました。また来ます >けろ


189 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 02:22
sage


190 名前: けろ 投稿日: 2001/07/02(月) 02:30
>>187
DOOMとかQUAKE知らんのか?

>>188
待ってるぞ.来てくれないとひまつぶしができなくなるからな.


191 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 10:55
>>190
思い切り閉鎖空間じゃん。
DOOM/QUAKEでくそ広かれた空間作ったら
どういうことになるか知らんのか?


192 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 11:09
Tribesになります。


193 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 11:12
>>191
>>190は脳内ゲームプログラマと思われ。


194 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 13:33
DOOMを挙げた時点で、何も分かっていないのが分かった


195 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 21:40
>>194
レンダリングじゃなくてocclude cullingのつもりなんだが.


196 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 21:48
>>195
相手にすんなって。全てのプログラマがカーマック並みだったら
PS2の悲惨なソフト郡は出てこないし。300万ポリ出す事と
100万ポリでやりくりする事とどっちが有効か解ってないみた
いだし。


197 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 22:00
>>195 == 196
妄想は脳内だけにしとけ。


198 名前: けろ 投稿日: 2001/07/02(月) 22:08
>>196
いや、目的はDQNなゲーム屋の排除によるレベルの底上げと暇つぶしだからいんだよ.


199 名前: もうひとりのけろ 投稿日: 2001/07/02(月) 22:13
>>198
ちょっとやりすぎじゃない? 良い意見まで潰しかねないよー。


200 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 22:29
まあ、まあ。ちんこに毛がはえればいいもんだよ。


201 名前: デフォルトの名無しさん 投稿日: 2001/07/02(月) 22:32
>>198
やはりお前はゲーハーヲタだったんだな(藁


202 名前: 196 投稿日: 2001/07/02(月) 23:52
>>198
 なーんか、これじゃいくつスレが立ってもゲハ指名厨房が
はびこっちゃってまともな展開出来ないすね。今時の開発な
んて分業制で個人で情報偏差があるのは当たり前なんだから
つまんない突込みでゲハ扱いしてもしゃーないだろうに。


203 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 00:28
>>202
まともな展開とは、まじめな書き込みを煽ったり、ハードに愚痴ったりすることなのか?

どっちがマトモな展開を阻害しているかは明らかに見えるぞ。


204 名前: 196 投稿日: 2001/07/03(火) 00:35
>>203
 どちらにしても他人を見下して厨房扱いしてるヤツがまとも
な開発者とは思えんよ。201みたいなのがまともなんかい?
 煽りも愚痴も現場の生の声だと思えばいいんじゃないのん?
奇麗事を求めてるなら2chでやらなくてもいいじゃん。


205 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 00:40
どっちかやめろ。自分の方が賢いと思うほうが内容ある書き込みせい。


206 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 00:46
>>205
君がバカでないのなら既に破綻しているな.


207 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 00:56
>>204
違うだろ。
>>198みたいな奴がいるから、>>201みたいなのを呼び寄せるんだろ。
綺麗事を求めてるんじゃなくて、有益な方向性を求めてるんだよ。
何百万ポリゴン出したとか、そんなくだらない見栄の張り合いじゃなくて、
どうしたらポリゴン稼げるかとか、そういうマトモな話題だよ。
まあ2chに期待する方が無駄なのかもしれんがね。

折角>>92が良い方向にもってこうとしてたのに残念だね。


208 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:04
質問です。

1280*896*16bitで描画するのに、
640*448dotのZバッファを適用したとします。
すると当然ポリゴン境界面にジャギが発生する訳ですが、
V-Brance時、1/4縮小するときに、
1280/1、896/1(640/1、448/1では無く)ずつずらしてサンプリングする事により、
ポリゴン境界面のジャギは消してしまえませんか?
それとも全体をぼかしたようになってしまうのでしょうか?

飛躍した質問でしたら無視してください。
出そうかどうか迷ってたネタなんで。


209 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:07
ブランクも違いますね。。


210 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:18
>>208
フレームバッファとZバッファのサイズは同じである必要があると思う。
ソフトレンダならできんこともないが。


211 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:18
>>208
あれれ?描画バッファと違うサイズのZバッファってもてました
っけ?だとしたら目からウロコだなぁ。もう一度GSマニュアル
見直してみようと。(昔過ぎて覚えてない)


212 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:19
>>208
>1280*896*16bitで描画するのに、 640*448dotのZバッファを適用したとします。
そんなことできるんですか? フレームバッファとZバッファは同じサイズである必要がありませんか?
それとも別の意味?


213 名前: マニュアルまだ読んでません。 投稿日: 2001/07/03(火) 01:21
そうですか。残念です。


214 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:21
>>207
なるほど的を得ました。
ただ、ゲハ行け!の1行レスは見てて寒いっす。幾ら相手が
流れを読んでいなくてもガキな煽りした方が負けかと。


215 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:24
的は射てね。


216 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:25
>>214
的は射るんだよ。
得るのは当。
DQNだなやぱーり。


217 名前: 投稿日: 2001/07/03(火) 01:26
まぁ、4回描画すればいいという話ではある。
>>208 が言っている事は、要はフルシーンアンチですな。


218 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:32
まあPS2で妥当なアンチ手法は、
フリッカーは縦倍サンプリングのCRTCマージで消す、
ジャギーはエッジアンチで消す、
エイリアスはトライリニアで消す、
ってのが正しい方向性でしょうな。

それ以外の手法使っても良い結果は得られなさそう。


219 名前: 208 投稿日: 2001/07/03(火) 01:33
ネックはZバッファだと思ってたのです。
そんでZサイズを省略できない物かと考えて、
実質Zの解像度って言うのは最終解像度さえあれば十分ではないかと考えてマニュアル無いなりに理屈つけたんです。
違うサイズのZって可能なのかという疑問は当然頭をよぎりましたが、
まあ、出来ないそうなので、残念です。迷惑に思った方ごめんなさい。


220 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:36
>>219
Zバッファのサイズを減らしたいなら、
解像度を減らすのではなくビット深度を減らすという方向性が
普通だと思うぞ。


221 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:38
>>218
エッジアンチ辛いんですけど・・・
Zソートが必要ですよね。
オブジェ単位のソートではいまいちきれいにならないし。
良い方法あったら教えてください。
#このへんはさすがに知ってても教えてくれないか・・・


222 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:41
>>220
もっと減らす方法は無いかと思って。普通をあんまし知らない物で。


223 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 01:43
>>221
素直にフルシーンアンチで我慢すべし。
まぁ、ライン上書きアンチというやり方もあるらしいが。


224 名前: 221 投稿日: 2001/07/03(火) 01:59
>>223
ライン上書きは私も詳しくないので良くわかんないですが、
VU1とか2回まわしてそう・・・うーん・・・
>>218でエッジアンチが正しい方向性と書いてるので、
もしや、めがうろこがでるか!? と期待したんですけどね・・・
フルシーンアンチもつらいので、ジャギーは気にしないことにします(w


225 名前: 92 投稿日: 2001/07/03(火) 02:00
>>221
素人なりに考えてみました。
エッジアンチの必要があるポリゴンは全ポリゴン中の一部であると
いう性質を生かして、動的にエッジを抽出しZソートして
アンチエイリアスラインとして別描画するというアプローチを考えてみました。

オブジェクト単位でソートされ、かつオブジェクトのポリゴンリストは
ストライプになっている仮定します。

前ポリゴンの法線ベクトルと現ポリゴンの法線ベクトルの内積が
負の時、一つ前の頂点と二つ前の頂点が形成する線分は
オブジェクトの境界となります。
その透視変換済みの2頂点をVUメモリの別エリアにストアします。

全ポリゴンを描画した後、線分リストをZソートし、
アンチエイリアスラインを描画すれば、
無駄な座標変換を省略でき、
かつ必要最小限のソートで済むのではないかと思います。

以上妄想でした。


226 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 02:07
>>225
すごいね。でもストライプじゃなくてストリップだZo


227 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 02:09
>>226
トライアングルストリップ 32件
トライアングルストライプ 5件

まあ、どっちでもいいんじゃないの?


228 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 02:11
>>225
すごいね。でも、その妄想は妄想で終わるYo!

早く、開発環境が手に入るといいね。がんばれ!


229 名前: 初必者 投稿日: 2001/07/03(火) 02:11
>>225
俺が理解しきれていないだけかもしれんが境界となるポリゴン
対は何も鋭角接続部だけではないんではないか?


230 名前: 92 投稿日: 2001/07/03(火) 02:14
>>229
・オブジェクトは閉じていると仮定する。
を追加します。


231 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 02:15
>>227
良くないよ。知らない人が見たら、間違ったことを覚えることに
なるんだよ。


232 名前: 初必者 投稿日: 2001/07/03(火) 02:15
いや、それにしたってカクンといってるところだけが
境界になるとは限らないんじゃないかな?


233 名前: 初必者 投稿日: 2001/07/03(火) 02:18
>>231
同意。俺も最初ストライプって何だろう?って思った。
昔、データベース屋さんだったので、、、ストライピン
グが真っ先に浮かんだ。


234 名前: 92 投稿日: 2001/07/03(火) 02:19
>>233
下のページで初めてストリップのことを知ったので、
ストライプだと覚えてしまったのです。

http://www.win.ne.jp/~m-nagaya/program/strip/strip.html


235 名前: けろ 投稿日: 2001/07/03(火) 02:22
>>230
オブジェクトは凸を追加だね.
non-photorealistic系でエッジ描いてるのとか見てみたら?


236 名前: 初必者 投稿日: 2001/07/03(火) 02:24
>>235
そゆこと。サンクス


237 名前: 初必者 投稿日: 2001/07/03(火) 02:30
>>92
2chで住所を明かすわけにもいかんが、家が近かったら
SoGなディスプレイ一台余ってるので、君に提供したい
くらいだ。


238 名前: 221 投稿日: 2001/07/03(火) 02:32
>>225
>>235
エッジ描くことの応用ですか。なるほど・・・
TriStripに乗っているエッジだけしか抽出できないような気がするけど、
あとは工夫しろ、ってとこですかね。。。

いや、なんか、目、さめちゃいました。
まいったなぁ・・・92にうちの会社入られたら、立場ないな>俺


239 名前: 221 投稿日: 2001/07/03(火) 02:35
あ、sageちゃった。
ageとくよ。。。


240 名前: 初必者 投稿日: 2001/07/03(火) 02:36
と、いいながら下げる人も珍しいな。
代わりにあげとく。


241 名前: 221 投稿日: 2001/07/03(火) 02:36
ageってないって。。。動転してどうするんだ>俺


242 名前: 92 投稿日: 2001/07/03(火) 02:41
>>235
凸でなくてもいけるはずです。
線分を抽出した後に、Zソートかけてますから。
当然Zソートで破状するような形状では完全じゃないですが。


243 名前: 初必者 投稿日: 2001/07/03(火) 02:43
いやしかしね。内積が負になるってことは90度以上でしょう。
そこだけがエッジになるの?


244 名前: 初必者 投稿日: 2001/07/03(火) 02:50
おーい。寝ちゃった?
いや一定値以下にすればよいのだけれどね。
実はポリゴンリダクションエンジンで削除可能ポリゴンを
検出するために似たようなことするんだが。。。


245 名前: 92 投稿日: 2001/07/03(火) 02:56
>>243
内積が負になるという条件は訂正です。
カリングの対象になるを0、カリングの対象にならないを1として、
前ポリゴン xor 現ポリゴンが1のとき、エッジとする。
これならどうでしょうか。

いや、でも谷折りのエッジも抽出してしまうのか・・・。
やはり無理かもしれませんね。


246 名前: 初必者 投稿日: 2001/07/03(火) 02:57
マジで92と友達になりたいYO


247 名前: 初必者 投稿日: 2001/07/03(火) 03:04
>>245
あと、けろの言ってたnon-photorealistic系(catoon-rendering?)
も調べてみては如何でしょう?
texture でやるのもあって面白いよ。

おいらもう寝ます。また遊んでね。


248 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 03:10
まぁ、実際にはアンチライン用のモデルを用意しておいて、VUを2回回した
方が単純で速いだろうな。


249 名前: 221==228 投稿日: 2001/07/03(火) 03:11
>>225
妄想で終わる、と書き捨てるだけなのもなんなので、
とりあえず、マズい点を指摘。

1.ストリップで繋がってない部分が綺麗に出ない
2.結果を格納しておく余裕なんて、VUメモリに存在しない

2の方が致命的。作り方にもよるだろうけど、VUメモリの空き領域なんて、
200〜300クワッドワードがせいぜい。1頂点当たりに必要なデータサイズは
最低でも3クワッドワード。つまり、50本のラインを描画するのがギリギリの
線、ってこと。しかも、最後に描画要求する時に、テクスチャがGS上に
載ってないとマズいから、色々な面で制約を要求することになる。

どう考えても、フルシーンアンチエイリアスの方が現実的、ってことだね。

221さんの発言があったから書き込んだのかもしれないけど、あまり
気にせずネタを披露してちょうだい。面白い議論ができれば、それでOKだから。


250 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 03:12
 この辺のアルゴって大半が573の出願中なんだよな。
シーグラフの論文漁るよりも特許庁のサイト見た方が早かっ
たり。

 あとセガも結構きついね。


251 名前: 92 投稿日: 2001/07/03(火) 03:12
>>247
法線方向に押し出して反転するエッジ抽出手法のことですか?

自分も寝ます、ではまた。


252 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 03:54
PS2のNTSC出力において問題になっているのは、
ジャギーよりもむしろフリッカーであることを考慮すると、
エッジAAをがんばるよりも、単純にFSAA(倍ライン描画→縦縮小)を
やっておいた方が妥当、というのが、最近の私の結論です。

ただ、これだと「フレーム落ちした瞬間に解像度が落ちる」というPS2の
もうひとつの弱点を克服できないため、最近では、フィールド表示モードを
使う(表示も倍ラインにする)、ノンインターレスモードを使う
(インターレス表示自体を諦める)などの方向性を模索しています。

ただ、エッジAAを有効に利用したソフトはまだほとんど無いので
(システム画面ぐらい)、本気で使ったら、すごいことができるかも
しれませんけどね。


253 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 03:54
sage


254 名前: 249 投稿日: 2001/07/03(火) 04:15
>>251
テクスチャ座標の自動生成を使ったものでしょう。


255 名前: 初必者 投稿日: 2001/07/03(火) 08:48
ね、ねむー。
>>254
いやもっと楽ちんで Cubic map 使った奴だったりして。。
基本的に Eye Vec. * Normal Vec. だからさ。


256 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 11:34
>>252
EEの演算処理で落ちてしまう場合は、DMAパケットを送り直す事で
対応できなくは無い。

もちろん描画で落ちてしまう場合は、どうしようも無いが。


257 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 12:21
開発者の方でPS2Linuxキットを買った方のイカシタ使用目的を教えてください。


258 名前: 92 投稿日: 2001/07/03(火) 21:02
>>249
具体的なご指摘ありがとうございます。

少し誤解があるようですが、
全ポリゴンといのは、VUメモリに乗っている全ポリゴンということです。
オブジェクト単位にVUメモリに乗せて、
ポリゴン描画->エッジ抽出->アンチライン描画
というプロセスをオブジェクトの数だけ繰り返すということです。
当然オブジェクトは奥から順にソートしておきます。
オブジェクトが複雑に絡まっていると問題が生じますが、
単純にオブジェクトだけをソートするよりはましかなと思ったのです。
ですので、テクスチャ等の問題はありません。

VUメモリの少なさへの対応ですが、2頂点をストアするのではなく、
1クワッドワードに、線分のZ座標(2頂点の最大値or平均)と
透視変換した頂点のアドレスを、パックしてストアするというのはどうでしょうか。
こうすれば1ラインにつき1クワッドワードに抑えることができ、
またPATH1転送をしている間にインサーションソートをすることも
できるような気がします。

ストリップで繋がってない部分への対応は、
可視ポリゴンは無条件に現頂点と2つ前の頂点が形成する線分も加える
ぐらいしか思いつかないです・・・。

・・・やはり実用性に欠けますね。


259 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 22:02
>>258
オブジェクト単位ってどんな単位ですか?
VUメモリに乗るのは、せいぜい1ストリップぐらいだと思いますけど。


260 名前: 92 投稿日: 2001/07/03(火) 22:08
>>259
マトリクス一つで変換できる程度の単位です。(背景除く)


261 名前: 259 投稿日: 2001/07/03(火) 22:14
>>260
だから、そんなに乗らないんだってば。
1ストリップって書いたっしょ。


262 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 22:18
このスレは PS2Linux 限定でもないみたいなのでカキコ。
ProDG って、どうなんすかね?使えそう?使ってます?
http://www.spice-net.co.jp/snsys/index.html
Windows で完結できるってのは、良い話だと思いました。


263 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 22:26
>>262
ライセンシー向け商品ですね。
今さらソースコードデバッガはいらんです。
VUは次のバージョンみたいですね。
Windowsで完結できるのが、別に良い話だとも思いません。


264 名前: 92 投稿日: 2001/07/03(火) 22:34
>>261
16Kあれば100頂点ぐらい乗りませんか。


265 名前: デフォルトの名無しさん 投稿日: 2001/07/03(火) 22:52
>>264
乗ります。
ただし、実際にはダブルバッファにすることがほとんどでしょうから、50〜60頂点です。
仮に100頂点だとしても、それで1オブジェクトとお考えですか。
うーむ、実際の3Dデータってご存知ですか?
まあ、モノにもよりますがゲームを考えるなら、やはりそれは1ストリップでしょう。

なお、>>92さんの理論を全て否定しているのではなく、
>>258の「オブジェクト単位にVUメモリに乗せて」とか>>260にのみの反応ですから、あしからず。


266 名前: 92 投稿日: 2001/07/03(火) 23:14
>>265
やはり100頂点程度では厳しいですよね・・・。

16ライン分ぐらいバッファをとっておいて、
バッファが埋まるか、テクスチャ変える時点でラインを描画するとか。
・・・あまり意味がなさそう。

64Kぐらいメモリがあればなぁ。


267 名前: デフォルトの名無しさん 投稿日: 2001/07/04(水) 00:45
>64Kぐらいメモリがあればなぁ。
はは、そりゃ禁句ですな。


268 名前: デフォルトの名無しさん 投稿日: 2001/07/04(水) 01:29
8MBくらいVRAMが(以下略)


269 名前: デフォルトの名無しさん 投稿日: 2001/07/04(水) 01:38
VU1が停止しているときにEEから直接VUメモリにアクセスできるみたいですけど、
その時のペナルティはどんなものなんでしょ。


270 名前: デフォルトの名無しさん 投稿日: 2001/07/04(水) 02:59
>>269
VU1の停止を待つ、という点が致命的。速度を要求する場面では
使えないね。気にしないのであれば、別にいいんでない?


271 名前: age 投稿日: 2001/07/05(木) 01:24
1


272 名前: デフォルトの名無しさん 投稿日: 2001/07/05(木) 19:30
質問なのですが、
32bitZバッファを32bitRGBAテクスチャするには
フォーマットをPSMZ32からPSMCT32に変えるだけでは駄目なんですよね?
やはり32×16ピクセル単位に並べ替える必要があるのでしょうか。


273 名前: デフォルトの名無しさん 投稿日: 2001/07/05(木) 19:34
そうぢゃ.腐ってるんだよ.


274 名前: デフォルトの名無しさん 投稿日: 2001/07/05(木) 20:16
>>273
ああ・・やはりそうですか。
メモリ空間がリニアならいろいろできそうなのに・・・。
せめて同じビット深度のメモリマップぐらい統一して欲しかったなぁ。

今日はインクリメンタルなステンシルバッファを実現する方法について
考えていたのですが、いろいろと厳しいですね。

とりあえずベタな方法としては、
・フレームバッファと同じサイズの32bitRGBAステンシルバッファを確保
・赤成分を加算/減算してシャドウボリュームを描画
・32bitZバッファにステンシルを32×16ブロック単位に置換して転送
・フレームバッファのαを0でフィル
・ZテストGREATERで、Z=1,α=1のビルボードをαのみ書きこみで全画面に描画
・αテストEQUAL,AREF=0で半透明のビルボードを全画面に描画

Zバッファとフレームバッファが16bitなら、
5bitのステンシルでいけそうですが、32bitだとVRAM不足しまくり・・・。

他にもフォーマットをPSMCT32からPSMCT16Sに変えて、
AAAAAAAABBBBBBBBGGGGGGGGRRRRRRRR
ABBBBBGGGGGRRRRRABBBBBGGGGGRRRRR
偶数ピクセルの青成分を加算/減算することで、
5bitステンシルが実現できるかなと思ったのですが、
あのトリッキーなメモリ空間ではまず無理ですね・・・。


275 名前: デフォルトの名無しさん 投稿日: 2001/07/05(木) 20:55
訂正です。
・フレームバッファのαを0でフィル
・ZテストGREATERで、Z=1,α=0x80のビルボードをαのみ書きこみで全画面に描画
・転送先αテストDATM=0で半透明のビルボードを全画面に描画


276 名前: デフォルトの名無しさん 投稿日: 2001/07/05(木) 22:36
>>274
勘違いしてるかもしれないけど、それだとDepthBufferが壊れ
ちゃわないですか?
StencilBufferと言うからにはやっぱほかのBufferは
壊さないでやりたいなあ。無い物ねだりかも知れないけど。
DestinationAlphaのテストでStencilは代用出来そうな気は
するけど、インクッリメンタルなのはどうか見てみます。


277 名前: デフォルトの名無しさん 投稿日: 2001/07/05(木) 22:43
>>276
Zバッファは通常用とステンシル用で2枚使用します。
(ですのでVRAMがかなり厳しいです。)
DestinationAlphaテストだけでは凸物体の落とす影しか正しく表現できないので、
やはり汎用的に影を実現しようとすると、
インクリメンタルなステンシルバッファは必須なんです。


278 名前: 276 投稿日: 2001/07/05(木) 23:20
>>277
なるほど。
AlphaBlendでAlpha値をインクリメント出来るような仕様だったら
ひょっとして・・・と思ったんですけど浅はかでした。
しかしZバッファって最低でも16bit/pix取っちゃうんでしょ?
ステンシル用として扱うには贅沢すぎるような気がするんですけど。
特にVRAMの少ないPS2では。
ちょっと、興味がなくなってきたなあ・・・。


279 名前: 274 投稿日: 2001/07/05(木) 23:26
改良案です。
MGS2ライクなVRAM割り当てを考えます。

フレームバッファPSMCT32(512 × 512) × 2
ZバッファPSMZ32(512 × 512)
テクスチャバッファ(512 × 512 × 32bit)

背景とオブジェクトを描画した後、
エフェクトを描画する前に、ステンシル描画パスを加えます。

・テクスチャバッファを、ステンシルバッファ(PSMCT16S)、ステンシルZバッファ(PSMZ16S)に分割する。
・ステンシルバッファに赤成分を加算/減算してシャドウボリュームを描画
・ステンシルバッファを32×16ピクセル単位にステンシル用Zバッファに置換転送する。
・フレームバッファのαを0でフィル
・ステンシルZバッファを用いてZ=1,α=1のビルボードをαのみ書きこみでフレームバッファに描画
・転送先αテストDATM=0で半透明のビルボードをフレームバッファに描画

8bitから5bitに精度は落ちますが、5bitあれば大抵は十分だと思われます。
もしも範囲が不足する場合、通常ステンシルバッファは表面を加算した後、裏面を減算しますが。
ステンシルバッファの初期値を16とし、加算減算を適時行うことで、
5bitでも十分な精度が得られると思われます。
初期値を16にした場合、最後にカラークランプをラップモードにして16を減算します。

これで、すこしは実用的になったのではないでしょうか。


280 名前: デフォルトの名無しさん 投稿日: 2001/07/05(木) 23:35
>>279
一応、プロの人なのかな?

大手の会社だったら、その辺のノウハウはもう蓄積
されてると思うから、中小で最近触り始めたのかな?(適当)

パッと見、実用的でない、というのが正直な感想かな。


281 名前: デフォルトの名無しさん 投稿日: 2001/07/05(木) 23:38
プロジェクションテクスチャーが一番な気がします。


282 名前: 274 投稿日: 2001/07/05(木) 23:42
>>281
プロジェクションテクスチャだと、セルフシャドウができないし、
あまり大量のオブジェクトの影を投影するには効率的でないですよね。
まあその辺はトレードオフなのですが。


283 名前: 274=92 投稿日: 2001/07/05(木) 23:48
>>280
自分は一介の学生ですよ、PS2LinuxでPS2を触り始めたんです。
大手とかでは研究し尽くされているんでしょうが、まあ自己満足なんで。


284 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 01:12
>>274
要するに、RGBは加減算できる。
Aを使って、影の部分だけ何か描画処理をしたい。

RGBの情報をAに持って来たい。と。
えーっと、確か TEXAとかFRAME.FBMSKとか使えば出来たと思うよ。


285 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 01:36
>>280
そうなん? ほとんど役に立ちそうもないことを研究してるのか、大手って。
あ、そうじゃなくって、ステンシルを使う方法じゃなく、ステンシルを使わなくても済む方法の研究か。それなら納得。


286 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 02:20
http://www.cgigame.com/bbs/raiv.html


287 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 09:18
>>284
そうなんです、ようはRをAに持って行きたいのですが
その方法が見つからないので、あんな回りくどい方法をとるしかなかったのです。
FBMSKはただのマスクですし、TEXAはαに定数を設定するだけなので、
できないと思うのですが、もしできるのならその方法を教えて下さい。

>>285
影の重要度が高いなら、役に立たないこともないと思いますよ。
フィルレート食いますが何事もトレードオフですしね。

まあ普通は凸オブジェクト単位に処理して1bitステンシルで済ますか、
プロジェクションシャドウにしますがね。


288 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 10:31
>>287
ひとつ言っとくと、加減算可能なステンシルバッファが無くても、
シャドウボリュームは可能だよ。デステネーションアルファテスト
だけで十分。


289 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 11:12
>>288
だとすれば、転送先αテストで十分なのに、なぜDirectX等では加減算可能なステンシルがサポートされているのでしょうか。
凹物体が落とす影も問題なく1bitステンシルで表現できるのでしょうか。

ところで改良案です

・テクスチャバッファを、ステンシルバッファ(PSMCT16S)、ステンシルZバッファ(PSMZ16S)に分割する。
・ステンシルバッファを31でフィル
・ステンシルバッファに赤成分を減算/加算してシャドウボリュームを描画
・ステンシルバッファを32×16ピクセル単位にステンシル用Zバッファに置換転送する。
・ステンシルZバッファを用いてZ=30のビルボードを半透明でフレームバッファに描画

なんとか使えるレベルにはなってきました。


290 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 12:06
>>288
どうやってやるの?


291 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 12:17
age


292 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 12:41
DXとOGLは転送先αテスト不可能。


293 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 12:48
>>292
そうでしたっけ。
でも、それで加減算可能なステンシルが必要だという理由にはなりませんよ。
転送先αテストがなくとも、1bitステンシルで十分なのですから。


294 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 15:29
OpenGL赤本読んで>>293


295 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 16:01
>>294
読めば凹物体のシャドウボリュームを
転送先αテストのみで描画する方法がわかるんですか?


296 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 17:04
>>288
どうやってやるのか俺も知りたい。
転送先αテスト、しかもMSBが0か1かしか判定できないのに、
穴のあいたトーラスの影を描画できるなら、かなり画期的なことだよ。

でも凸物体に分割するなんて、くだらない落ちはやめてね。


297 名前: age 投稿日: 2001/07/06(金) 18:19
age


298 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 19:14
>>288の解答に期待上げ。


299 名前: 289 投稿日: 2001/07/06(金) 23:16
もしかして、2chでこういう技術的な話題って需要ないです?


・・・逝きます。


300 名前: デフォルトの名無しさん 投稿日: 2001/07/06(金) 23:24
>>299
逝っちゃダメ。
多少妄想気味の方が良いんですけど。
PS2Linux7月組が増えればまた賑わうかと。


301 名前: 7月組の名無しさん 投稿日: 2001/07/06(金) 23:45
『試しにやってみた。このサンプルでどうよ?』
ってなスマートな展開きぼんぬ


302 名前: デフォルトの名無しさん 投稿日: 2001/07/07(土) 00:26
うーん、それにしても
PS2でプログラムを組んでいる奴を全然見かけないね〜。
そろそろ何かVU組んでますみたいな人が出てきてもおかしくないんだけど。
結局、初回のPS2Linuxを買った奴は、
Linuxマニアと夢見がちなゲームヲタだけだったのかな。

7月組みに、つわものが含まれてることに期待。
ってそう簡単にPS2を使いこなされたらプロの立場がないんだけどね。


303 名前: デフォルトの名無しさん 投稿日: 2001/07/07(土) 00:32
>>302
おそらくほとんどがヲタだったと思う。
そしてLinuxの画面を見て、一人で喜んでるだけ・・・


304 名前: デフォルトの名無しさん 投稿日: 2001/07/07(土) 00:39
>>302
国内のアマプログラマのレベル見てる限り、
あまり期待できそうにないな・・・。
プロがアマのふりしてマターリと何かしてくれるのを期待するしかないのか。

>>303
ヲタに小判、ヲタに真珠だね。


305 名前: 284 投稿日: 2001/07/07(土) 00:40
>>287
16bitのステンシルバッファを R,G,B=0x78で初期化。
+8,-8で加減算。
FBMASK R,G,B=0x80 とした状態で R,G,B=0x00で塗りつぶす。
すると、影になる部分はR,G,B=0x80それ以外は R,G,B=0x00となる。
TEXAレジスタでA=0のアルファ値を設定、R,G,B=0x00の場合アルファ=0とするフラグを立てる。


306 名前: 289 投稿日: 2001/07/07(土) 01:07
>>305
目が鱗!!!
TEXAレジスタにそんな機能があったんですね、
すっかり見落としていました。

この機能を使えば、
ずっとエレガントに仮想ステンシルバッファを実現できますね。
ご教授ありがとうございました。


307 名前: デフォルトの名無しさん 投稿日: 2001/07/07(土) 01:10
>>304

お〜い。頼むから三流評論家ゴッコはその辺にしとこうぜ。
首筋が痒くなってくらぁな。


308 名前: 289 投稿日: 2001/07/07(土) 01:38
TEXAレジスタのAEMフラグを使用した改良案です。

・16bit/24bitのステンシルバッファを用意
(16bitの時5bit,24bitのとき8bitをステンシルとして使用可能)
・ステンシルバッファをゼロクリア
・シャドウボリュームを加算/減算してステンシルバッファに描画
・TEXAレジスタAEM=1,TA0=0x40に設定
(TA0の値は黒色と転送先カラーとのブレンドレートになる,0x40は50%)
・ALPHAレジスタ,A=0,B=Cd,D=As,D=Cdに設定
・ステンシルバッファをテクスチャに設定し、フレームバッファに描画

ステンシルバッファの値がR=G=B=0のときαは0となり、
(0-Cd)*0+Cd -> Cd
転送先カラーがそのまま出力される。
ステンシルバッファの値が0でないとき、αは0x40となり
(0-Cd)*0x40>>7 + Cd -> Cd/2
転送先カラーの輝度を半分に落としたRGB値が出力される。

コスト的には一時的にステンシル用のVRAMが必要になるだけで、
転送先αテストを用いたシャドウ描画とほとんど変わらないと思われます。

使えますでしょうか?


309 名前: デフォルトの名無しさん 投稿日: 2001/07/07(土) 01:38
>>302
元スレに出てた方のけろってVU弄ってたっぽくなかったっけ?


310 名前: デフォルトの名無しさん 投稿日: 2001/07/07(土) 01:50
>>308
もしかしてかなり画期的手法かも、大手では常識なの?
鬼武者の影は転送先αテストっぽかったが。


311 名前: 288 投稿日: 2001/07/07(土) 05:36
答えを書くと、守秘義務に違反することになるから
書けない。業務時間中に知りうることが
できた知識だからね。純粋に。

>>296
凸じゃなくても出来たはず。あんまり細かく確認
してないから断言はできないけど。

鉄拳TTなんかも同じようにやってるんじゃ
ないかなぁ。雪のステージでシャドーボリューム
使ってるしね。
鉄拳のキャラが陰を落とせるようなのじゃ、
くだらない、というレベル?

ま、影用のデータは別に用意しないといけない
のは当然だけど。コスト的に。


312 名前: 288 投稿日: 2001/07/07(土) 05:45
ちなみに、αの部分を使うので、16BITカラーモードでは出来ません。
1か0か、ではなく、8BIT部分を使う利用する方向で考えてみてください。


313 名前: デフォルトの名無しさん 投稿日: 2001/07/07(土) 10:31
>>311
どの程度現実的かわかりませんが、

・テクスチャのアドレスとフレームバッファのアドレスを同じにする。
・FBMASKでαのみ書きこみを有効する。
・シャドウボリュームの表面をHIGHLIGHT,Af=1で描画
・シャドウボリュームの裏面をMODULATE,Af=0x7fで描画

この方法でαを加減算できないかなぁ。


314 名前: age 投稿日: 2001/07/07(土) 17:15
age


315 名前: デフォルトの名無しさん 投稿日: 2001/07/07(土) 21:46
3D初心者ですけど、シャドウボリュームはどうやって作り出すんですか?


316 名前: 289 投稿日: 2001/07/07(土) 22:53
>>315
一般的な手法としては以下のようなデータ構造を持つ、
オブジェクトの辺リストを作成して、
struct{
 VECTOR3D n1; //辺を共有する面の法線ベクトル
 VECTOR3D n2; //辺が一つの面しか持たない場合normal2にはnormal1の逆ベクトルを設定
 VECTOR3D v1; //始点
 VECTOR3D v2; //終点
}EDGE;

v1,v2,n1,n2をワールド座標系に座標変換した後、
光線ベクトルをlightとすると、
((n1●light) * (n2●light))が負となる辺が影の境界となる。
そして4点(v1,v2,v2+light*L,v1+light*L)が作る面がシャドウボリュームとなる。

;●はベクトルの内積
;Lはシャドウボリュームの長さ


317 名前: 315 投稿日: 2001/07/07(土) 23:22
>>316
ありがとうございました。よくわかりました。


318 名前: デフォルトの名無しさん 投稿日: 2001/07/07(土) 23:43
>>316
わかりやすかったです.
ビルボードはどうやって作り出せばよいのですか?


319 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 00:53
>>318
http://www.platz.or.jp/~moal/billboard.html


320 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 01:06
ほう、アレの正式名称はビルボードって言うのか・・・
昔から使ってたが名前を知らんかった
つうわけで、>>318
ビルボード用のマトリックスを用意するだけで出来ます


321 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 01:11
>>316
そのような内容(シャドウボリューム等)が解説されているページか書籍があったら
教えてください。


322 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 01:20
>>321
http://www.gamasutra.com/features/19991115/bestimt_freitag_01.htm


323 名前: 289 投稿日: 2001/07/08(日) 01:45
8bitCLUTを利用した加減算ステンシルバッファのアイデアです。

以下のようにインデックスに1を加算したα値をもつCLUTを用意します。
インデックス:012345678...
アルファ値 :123456789...
フレームバッファのアドレスをテクスチャアドレスに設定して、
テクスチャフォーマットを32bitRGBAの上位8bitをインデックスとして使用するフォーマットである
PSMT8Hに設定、先ほど用意したCLUTを設定します。
シャドウボリュームの表側を描画します。
α値が0->1,1->2へと遷移し、インクリメントと同じ効果が得られます。

次にCLUTをインデックスに1を減算したα値を持つように変更し、
インデックス:012345678...
アルファ値 :001234567...
シャドウボリュームの裏側を描画します。
α値が2->1,1->0へと遷移し、デクリメントと同じ効果が得られます。

>>313で述べた手法が駄目だった場合はCLUT分VRAMを余計に食いますが、
こちらの手法が使えるかもしれません。

フレームバッファが16bitの場合は、>>308の手法を使うしかありませんね。


324 名前: 289 投稿日: 2001/07/08(日) 01:52
反響もないので加減算ステンシルバッファの話題はこれにて終わりにします。


325 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 01:58
>>324
7分で反響が無いなんて言わないでよ!
今頭のなかで動きを検証してるから。


326 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 02:25
>>323
えーっと、最終目的が、α値を持つテクスチャーをステンシルマスク
としてフレームバッファに張り付けて、DestinationAlphaのテスト
でフラグメントを無効化しようって話でしたっけ?
そう仮定した場合、CLUTの内容を
インデックス:0 1 2 3 4 5 6 7 8 ...
アルファ値 :0 0 0 0 0 ffffffff...
みたいにして描画の境界を作ればいいんじゃないでしょうか?
GSのDestinationAlphaのテストはクソだからα値が0x80の境界
でしか見てくれないみたいなんで、任意の値でテストする
みたいな本来のステンシル操作でできる事はできないけど。
実は今手元に資料が無いんで確認できないんですが、R値を加減算
出来るならステンシル用にFrameBufferを一つ用意するだけで
インクリメンタルなステンシルバッファが出来ちゃいますよね。

何かすっとぼけた事言ってるのかも知れないけど・・・。


327 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 02:31
うん、すっとぼけてるね。少しは読めよ。


328 名前: 289 投稿日: 2001/07/08(日) 02:46
>>325
いえ、前に>>308とか>>313とか書いたのですが反響がなくって・・・。
せめて使えるか使えないかぐらい言って欲しいよなぁ・・・。
まあ、どちらにせよネタは尽きたので逝きます。


329 名前: 318 投稿日: 2001/07/08(日) 02:52
>>319
ありがとうございました.
よくわかりました.簡単な行列演算だけでできるなんて感動です.
ステンシルバッファ(?)がやりたい(考えたい)のですが,なにぶん知識不足でして...
それらの解説ページとかありませんでしょうか?
#DirectXのヘルプとかって有効でしょうか?


330 名前: 318 投稿日: 2001/07/08(日) 02:59
>>329
追加.判りやすい図があればうれしいのですが.


331 名前: うえーん 投稿日: 2001/07/08(日) 03:47
284さんナイス!
当方一応プロで、別の方法でステンシル実装してたんだけど、
その方法に切り替えてみようかな。

僕はステンシルはDirectXで勉強しました。


332 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 03:57
>>329
そらよ.せいぜい勉強しな.
http://www.ntkr.co.jp/info/course/hobby3.html#jump3


333 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 04:19
>>329
http://www.opengl.org/developers/code/features/StencilTalk/index.htm
後一応スレ違いなんで気をつけて。これ以上ヘタレた質問は
無いようにね。


334 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 04:37
問題はそこまでのマシン資源を使ってまでステンシルを実現する意味が
あるのかって事だな。足元に丸い1枚ポリ影でいーじゃーんとか思ったり。
スマソ


335 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 06:11
>>334
ゲーム中の負荷のバランスを考えたら、そういう選択肢が現実的ですね。


336 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 12:20
良いスレほど下がるよなぁ。age


337 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 13:19
>>333
いいじゃないヘタレ質問もあっても。
1にも、
>*もちろんプログラミング全般、アルゴリズム、
>その他アイデア等の話題もアリです扱います。
って書いてあるんだし。


338 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 13:28
シャドウボリュームで影の境目をなめらかにする高速な方法ないですか?


339 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 15:25
安易にライトの向きをちょろっと変えて重畳するってのはだめ?


340 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 15:26
シャドウボリュームだと無いんじゃないかなあ。
一般的なソフトシャドウの手法で微妙にずらして何回も書く
ってやり方は速度的に全くだめだし。


341 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 15:28
>>340
マップにしてヴォカすのはだめ?


342 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 15:33
だめ.


343 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 16:28
>>338
スーパーサンプリングしろ。

つうか、屋外はステンシル、屋内はシャドウマップでしょ。


344 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 18:01
シャドウボリューム→エッヂクッキリ
シャドウマップ→エッヂデコボコ

見た目では、セルフシャドウできなくても
投影テクスチャをぼかすのが一番良い?


345 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 18:21
さっきおいらが言ったらだめっていわれたのにT_T


346 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 18:24
ドロップシャドウはどうよ?
当たり前だが、シーンによって使い分けるのが吉だよね。


347 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 19:15
バウンサーの影の表現は上手かった。


348 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 21:07
そうか?


349 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 21:55
>>348
影の使い分けがね。


350 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 21:57
>>346
床がまっ平らだとか、ポリ少ないとかだったら簡単なんですがね〜
セルフシャドウとかまで考え始めると、ドロップシャドウはキツイ。
シャドウマップやシャドウボリュームは光源数が増えるといゃ〜ん。
ドロップシャドウは逆にうふふふふ。


351 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 22:22
GT3は路面が比較的平らなのでドロップシャドウとみた。横壁は無視されてるっぽかったし。
どのシャドウ使うにしてもシャドウ用の省ポリゴンバージョンを用意すると思うYo!


352 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 22:49
ロコツに影とキャラのポリ数が違うと萎え〜。


353 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 22:58
>>352
???
気がつかないはずだが、想像で書いてる? それとも実例がある?


354 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 23:06
>>353
んなのチラッと見りゃ分かるでしょ、フツー.


355 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 23:16
技術的な会話に口を挟んでなんだけど、64ゼルダの影は上手いと思った。
ゲームとしてみた場合、ああいう発想の方が重要かなーと。
 あと、まともにステンシルやりだすとPS2でもDC並みにポリ数落ち
ませんか?そうでもない?


356 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 23:40
ピクミンでも64ゼルダと同じ影だね。
ルイージマンションはドロップシャドウとシャドウボリュームの使い分けかなぁ。


357 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 23:44
>>355
憶えてない、どんなんだったっけ。
光源で影がクルクル回って綺麗ってとこだけしか記憶に残ってない。
ゲーム性に組み込んであったっけ?
まあ、あの任天堂のことだからそのくらい仕込んであって自分が
気づいてないだけってのありがちかな。


358 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 23:49
64のゼルダは夕暮れになるとぼわーっとした影が長くなって
夕暮れの雰囲気が出ててイイ。
屋外ではシャドウボリュームみたいに影の形が
はっきりするとかえって不自然かも。


359 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 23:50
いまさら恥ずかしくて聞くかどうか10分ほど悩んだんですが
ドロップシャドウってどんなの指すんですか?


360 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 23:54
ドロップシャドウつーか、Planar Shadowか?


361 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 23:55
>>359
ドロップシャドウ行列ってのを使って、立体のオブジェクトを
平面に貼り付けるの、それでもって色を黒の半透明にすれば出来上がり。
通常同次座標系というのを使います。


362 名前: デフォルトの名無しさん 投稿日: 2001/07/08(日) 23:56
コンシューマー機用のプログラミングに関する掲示板や
ホムペって存在する?


363 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 00:01
ふと思ったんだけど。
PS2の場合力任せにドロップシャドウを何回も使ってふちをぼかすと
例のぜルダの夕暮れ影のような美しい影できるかもね


364 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 01:56
>>363
 それは正に1パス処理に命をかけたXBOXこそ得意とする処理
じゃないかな?

 そいや、ノクターンっていう海外ゲーのシャドーのアルゴって誰か解り
ます?かなり綺麗だと思うんですけど。(クソ重いケド)


365 名前:   投稿日: 2001/07/09(月) 02:00
外側ボケたテクスチャを上手くUV合わせて貼っちゃ駄目かな?>ドロップ


366 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 02:04
そりゃムリだろ.
ライトの位置と物体の位置に応じてあらかじめ計算しときゃできるが、
それだったらもっと簡単にできるし.


367 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 02:20
>>364
違うな.頂点を増やすことになるからバンド幅の広いPS用だな.
XBOXが有利なのはマルチテキスチャとかピクセルシェーダだ.
と思ったが、ドロップシャドウのポリゴンをピクセルシェーダで太らして
やればいいのか.


368 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 02:28
>>367
XBOXは1枚8チャンネルだっけ?それだけあればマルチテクスチャで
ちょっとUVずらしてやるだけでいい感じのボケシャドーが出来るんじゃ
ないかなーと。これなら頂点数は増えないし。
ピクセルシェーダと合わせるともうちょっと面白そうだけど現実的な速度
は出なさそうだね。


369 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 03:03
純粋に趣味でやるなら素直にGEFORCE3買った方がいいと思うが。


370 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 03:08
>>369
唐突に何を言い出すのだキミわ。


371 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 03:11
>>369
それは禁句.


372 名前: とりあえず専用スレ紹介しときます。 投稿日: 2001/07/09(月) 03:17
>>367-368
http://piza.2ch.net/test/read.cgi?bbs=tech&key=993758383&ls=50


373 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 03:42
PS2Linuxの欠点は飼いならすだけで満足しちまう事だろーな。
成果ブツを求めて時間を費やすのならWin+D3Dの方がいいわな。

ま、それは今のところの話で将来的にどうなるかは解んないけどね。


374 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 04:12
>>373
なにが(どのハードが)良い悪いなんていう話は控えましょうよ。
どのスレにも言えることですが、スレッドの意向に従うだけで円滑な進行が期待できると思います。


375 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 05:46
>>374
別に良い、悪いという意味はないんですけど。ちょっと神経質では?

つまり、今のところは研究期間みたいなもんだから、手っ取り早く
モノを作りたいならWin環境の方がいいかもしんないけど、将来的に
PS2Linuxで環境が整えば立場が逆転するかもネ、みたいな意味ですよん。

その為にこのスレが機能するなら嬉しい話じゃないですか。


376 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 06:07
PS2Linuxは今の販売方法ではかなり限界あると思うけど・・・


377 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 06:27
>>375
ハード比較を始めるとゲーハー厨が集まって荒れるからだろ。


378 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 07:07
>>377
369-373まではハード比較って感じじゃないけどぉ。どちらかと言うと
開発環境比較じゃないの?
 PS2ならこうするけど、XBOXならこうするね、みたいな論題まで
ハード比較扱いしてゲハ厨房扱いすんのはどーなんかなー?


379 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 07:36
>>378
今はそうでも、それがエサになってゲハ厨が寄ってくるから
予防の意味でやめとこうって話だろが。
ゲハ厨は日本語も理解できねえのか!ヴォケナス!


380 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 07:59
>>379
お前がゲハ厨房だっつーの。氏ね。


381 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 08:14
・コンシューマ系技術スレが立つ。

・そこそこ有意義な話題で盛り上がる。

・XBOX、DirectXでの実装時の比較をなどの話題が出る。

・ゲハ指定厨房登場。

・スレ崩壊

・残念な参加者がスレを建てる

・最初に戻る


382 名前: ゲームアマグラマ 投稿日: 2001/07/09(月) 13:25
平面投影シャドウ、シャドウボリューム、シャドウマップ
他にどんなシャドウあるのか教えてくれにゃー。


383 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 13:34
>>382
ただの黒くて丸い半透明
バカバカしく基本かつゲームでは以外に重要。


384 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 14:02
バス優先車道


385 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 17:19
それはむしろ車線


386 名前: PS2Linuxkit7月到着組 投稿日: 2001/07/09(月) 19:40
>スレッドの意向に従うだけで円滑な進行が期待できると思います。
この一文が理解できず、批評とその是非を問う事に明け暮れる厨房は逝ってヨシ。

これだけだと漏れも逝かねばならなくなるのでヘタレネタ振り。
VGAから単純に四倍してSXGA?を作り出して、
サンプルを斜めに1/1280ドットずらして戻したVGAはボケ・・るでしょう。
じゃあ色深度を減らしてディザがかったSXGA?からフルカラーのVGAを作り出すと、
やっぱりボケてる?

ペイントソフトでチクチク試してみたんだけど、<ヘタレの極み
一応ジャギーは薄くなったけどインターレースに出すとどうなるのか判らない。

雲の上の方々には実証済みとは思いますがどうなんでしょ。


387 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 19:42
>サンプルを斜めに1/1280ドットずらして戻した
サンプルを斜めに1/1280ドットずらして取って戻した、です。


388 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 22:54
>>386
>この一文が理解できず、批評とその是非を問う事に明け暮れる厨房は逝ってヨシ

 これだけタンカ切ってそのカキコはないよ・・・。


389 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 23:11
んで、>>386は何がしたかったの?
ジャギ消し? NTSCのフリッカー軽減? どっちにもなってないけどね。


390 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 23:13
スキャンラインでの統合シャドウ、レイトレ、ラジオシティ、
シャドウZバッファ、予め作った変換による影。
あとはなんかあったっけ?


391 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 23:25
>>388 >>389
すんませんあれこれ試しているうちに最初に戻ってたみたいです。
結局解像度の不足は補えないという事ですよね。


392 名前: デフォルトの名無しさん 投稿日: 2001/07/09(月) 23:27
>>391
最初の1文がなけりゃ良かったんだけどね。


393 名前: こちらも並行して使いましょう 投稿日: 2001/07/09(月) 23:49
PSLinux(銀杏座β)EE,GSに関するQ&A
http://www.anakureon.com/pslinux/bbs2/

>難解であるハード部分に関する略語、用語や概念などを誰にも恥ずかしがる
>ことなく質問の場を設け広く公開し、後に続いてくれる人または同じ目標を
>目指す仲間の助けにするものである。
>EE、GSに関することであればどんな簡単なことでも結構です。
>気軽に質問してみて下さい


394 名前: デフォルトの名無しさん 投稿日: 2001/07/10(火) 01:18
Projection Texture Mappingによる影。
Drop Shadowとは違う。


395 名前: デフォルトの名無しさん 投稿日: 2001/07/10(火) 02:58
>>394
何を今更


396 名前: デフォルトの名無しさん 投稿日: 2001/07/10(火) 03:00
sage


397 名前: 9月組 投稿日: 2001/07/10(火) 05:10
Xデーが近づいてきました。
楽しみにしています。


398 名前: デフォルトの名無しさん 投稿日: 2001/07/13(金) 00:03
IOPも語ってー


399 名前: デフォルトの名無しさん 投稿日: 2001/07/13(金) 00:07
>>398
いくら2ちゃんねるでもヤバイだろう
よって語れません


400 名前: デフォルトの名無しさん 投稿日: 2001/07/13(金) 01:10
ディスプレイリストに、TEX0等のテクスチャ指定・ポリゴン座標データ等(複数)・テクスチャ指定・・・
とあったとします。
これをVIF1で送るのですが、テクスチャ指定はDIRECT(PATH2)、座標データ等はMSCALFでVU1に演算させ、XGKICK(PATH1)
とさせます。すると2番目のテクスチャ指定が最初のポリゴンデータ群の最後のプリミティブの座標変換中に追い抜いてGSに渡されてしまうようです。
DIRECTの前にFLUSHも指定してタイミングを取っているつもりなのですが、うまくいきません。
FLUSHがないとすれば理由はよくわかるのですが、FLUSHがうまく機能してないのでしょうか?
それとも、他に工夫が必要なのでしょうか?


401 名前: デフォルトの名無しさん 投稿日: 2001/07/13(金) 01:50
EOP使え。


402 名前: 400 投稿日: 2001/07/13(金) 16:38
>>401
Thanksです。そっか、そうだったのか〜。
現在テスト中ですが、別バグ発生のため、またうまくいったら報告します。


403 名前: デフォルトの名無しさん 投稿日: 2001/07/14(土) 17:00
windows2k 上に cigwin を用いてクロスコンパイル環境の構築を,
http://ps2.imou.to/cross.html
を参考にして行ったのですが,
blow をコンパイルする際に
types.h の 46,47行目(下記)でエラーが発生してしまいます.
TIとはどこに定義されているのでしょうか?また,設定が甘い気がしますが,
ご指導お願いいたします.

エラー行:
45: #ifdef CONFIG_CPU_R5900
46: typedef __signed__ int __s128 __attribute__((mode(TI)));
47: typedef unsigned int __u128 __attribute__((mode(TI)));
48: #endif

エラー内容:
gcc -g -DDEBUG -I/usr/local/apps/cross-ps2/mipsEEel-linux/include -I/usr/local/
apps/cross-ps2/include -I/include1 -I/include -I/usr/include -Wall -fno-common
-c -o blow.o blow.c
In file included from /include1/linux/ps2/gs.h:4,
from blow.c:18:
/include1/asm/types.h:46: no data type for mode `TI'
/include1/asm/types.h:47: no data type for mode `TI'
make[1]: *** [blow.o] Error 1
make[1]: Leaving directory `/home/d0912/vu1/blow'
make: *** [all] Error 2

参考:
PATH=/usr/local/apps/cross-ps2:/ps2linux/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/ps2linux/bin:


404 名前: デフォルトの名無しさん 投稿日: 2001/07/14(土) 19:48
パッチが足らんのじゃ?


405 名前: 403 投稿日: 2001/07/14(土) 23:20
確かに,何か足りないはずですが....
追加:ヘッダファイル(ps*.h等)がインストールされなかったので,
マウントしてインクルードディレクトリを追記しています.


406 名前: 400 投稿日: 2001/07/16(月) 18:34
なんでだろ
なんで途中のEOP落とすとバグるんだろう・・・
DMAと何の関係が・・・??


407 名前: 400 投稿日: 2001/07/16(月) 20:04
MSCAL(F)をはさむせいか、EOP立てないと完全にバグるっす・・・。


408 名前: mk 投稿日: 2001/07/17(火) 09:58
ここの書込みをわかりやすくまとめて転記するのはまずい?


409 名前: デフォルトの名無しさん 投稿日: 2001/07/17(火) 11:34
>>408
転記先を公開してくれるならオケ


410 名前: mk 投稿日: 2001/07/17(火) 12:30
転記元って
http://piza.2ch.net/test/read.cgi?bbs=tech&key=993662234&ls=50
ここの掲示板より って感じでよいのかな?


411 名前: mk 投稿日: 2001/07/17(火) 12:31
間違った、転記先でした。

転記先はもちろん公開予定です。
公開しないことには意味ないし。
転記先はジオの無料ページを予定。


412 名前: mk 投稿日: 2001/07/17(火) 15:07
http://www.geocities.co.jp/SiliconValley-Cupertino/8320/

仕事中にさくっと作りました。
これからよろしくお願いします。


413 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 01:09
>>412
タイトル通り、低レベルだな。


414 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 01:34
>>412にとても痛い予感がするのは俺だけか?


415 名前: mk 投稿日: 2001/07/18(水) 01:46
ゲーム開発の経験ないからまとめるのむずいー
わからん単語もあるし、ここで聞いたら怒られる?


416 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 02:30
>>415
そんなレベルじゃないよね。もっと低レベルと思われ。


417 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 02:36
幼稚という意味


418 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 07:10
>>415
ひとまずリンクを掻き集めて、
居着くべき人のレベルを定め、それ向けのネタを一方通行気味に展開する。
今回入門〜下級組がいっぱい居る訳だから、
その人たちに対する多様な底上げ的ページがあれば、
今後有意義・・だと思います。妄想に走るのもまた一興。

それから判らない単語や動作のOverViewに関する質問は>>393
のリンク先へ集約しておいた方が今後の編纂上良いと思います。


419 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 12:10
「■本日の一言」が寒すぎです。
でも、がんばって。


420 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 12:14
>>419
確かに(w


421 名前: mk 投稿日: 2001/07/18(水) 20:17
393 の場所で多数の質問を書き込みました。
果たして答えは得られるか?


422 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 20:21
誰か mk 殺して。


423 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 20:29
夏が嫌いになりそう......


424 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 20:52
>>421
やはり、とんでも電波君だったか・・・。


425 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 21:04
ワラタ


426 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 21:11
流石はお受験世代。
巻末に (解答) のページが無いとやっていけないのだな。


427 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 21:13
他人の掲示板を利用させてもらっているという意識は無いのだろうか?


428 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 21:34
mk逝って良し。


429 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 21:36
まあ人間、一度や二度はバカをやるもんだ。
以後、気をつければそれで良し。
運良く誰かが答えてくれれば、思わぬ収穫って奴だし。

そういえばあそこ、けろもいるようだが2chと同一人物?


430 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 21:54
>>421
google など使ったり専門書漁るなどして自分で調べたようとした?
そもそも教えてもらおうという姿勢の書き方じゃないよな、あれは
あーゆー他人任せなことやっている限り理解できないと思うよ


431 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 21:56
>>421
いや、むしろ一冊しっかりとしたお勉強用のグラフィックの本を買いなさい。
間違ってもハデハデなナンパ本買っちゃ駄目だよ。


432 名前: 431 投稿日: 2001/07/18(水) 22:01
グラフィック → グラフィックス
だな。utudasinou


433 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 22:53
銀杏座βでmk君が壊れました。


434 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 23:07
藁た >mk君
何がしたかったの? 一人FAQ?


435 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 23:10
2chの(このスレの)発言番号ね?あの番号は。

あれじゃあ壊れたようにしか見えんぞー。

このスレ参照させるようにさせれば?

http://piza.2ch.net/test/read.cgi?bbs=tech&key=993662234&st=xxx&to=xxx
'xxx'のところが発言番号ね。


436 名前: 434 投稿日: 2001/07/18(水) 23:18
あれ Q&A BBSの事じゃないの?


437 名前: けろ 投稿日: 2001/07/18(水) 23:21
び、びっくりしました。
い、いったい彼は何者?
どう反応したら良いのやら....


438 名前: デフォルトの名無しさん 投稿日: 2001/07/18(水) 23:57
なぜ自分ところ掲示板ではなく銀杏座β? >mk君
情報が分散して集めるのが大変だよ(w
431が言うように、3D関連の本買って体系的に勉強しないとあの手の技術用語
は理解できないというか使い物にならないと思われ


439 名前: BlueSky 投稿日: 2001/07/19(木) 00:10
ゲロゲーロ、ゲロゲーロ.


440 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 00:55
mk君は久々のビッグウェーブだ。
彼の成長を見守りたい。


441 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 01:04
彼のような人間が将来ウィザードと呼ばれるようなプログラマに
成長したらやっぱり嬉しい。


442 名前: お! 投稿日: 2001/07/19(木) 02:22
mkさんってネットやろうぜにもいなかったか?


443 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 05:28
確かに、度が過ぎてほほえましいな。
ばればれな自作自演とか。


444 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 05:32
今ゲーム系スレ上げてるやつは単独犯クサイな(藁


445 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 06:08
皆様おすすめの「一冊しっかりとしたお勉強用のグラフィックスの本」を
教えてください。できれば、松・竹・梅ぐらいに分けて(藁。


今もっている、図形処理の基礎(by 朝倉書店)で基礎は勉強(復習)する
つもりなのだが、やっぱ古い感じ(^^;。10年以上前の本だしなあ。


446 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 06:26
>>445
「メガデモを作ろう」名著だ。


447 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 06:52
>>446
なぁ、ネタだよな?ネタって言えよ、言ってくれよ…


448 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 07:45
>>447
ネタですъ( ゚ー^)


449 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 08:07
「Surveys in Differntial Geometry, Dedicated to Index Theory」
http://www.amazon.com/exec/obidos/ASIN/1571460691

やさしすぎるかも。
この程度は常識?


450 名前:   投稿日: 2001/07/19(木) 08:20
>>449
d. to Index Theoryうーん、なんだべ?
応用数学の方は、何でもアリだからなぁ。
エッセイ集かな??


451 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 08:32
>>445
私もみんなが読んでる本興味あるので書いときます。
でも、みんなの話を鵜呑みにせずに、是非自分で立ち読みとかし
てみて、本当に納得してから買ってね。

和書だと ASCII の「入門」「実習」「応用」(だっけ?ちと自身
なし)グラフィックシリーズ, OpenGL の赤本,

洋書でよければ
"COMPUTER GRAPHICS C VERSION"(PRENTICE HALL)、
 ほんとに基礎。なんでも載ってるが無駄も多い。最先端のものは
 のってない。
"3D GRAPHICS PROGRAMING GAME AND BEYOND"(SAMS)
 さらに応用として、リアルタイムレンダリングを中心に書かれた
 本。私にはこれが一番読み易かった。

あと結構変な部類として、
"CUTTING EDGE 3D GAME Programming with C++"(CORIOLIS GROUP)
 一歩一歩順を追って3Dエンジンを設計していくタイプ。
 実践派の方にお勧め。

たけえ本多いなあ。
すんません。補充どなたかよろしく。


452 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 08:37
この程度は押さえておかないとグラフィックスの入門にもたどりつけませぬ。
http://www.iwanami.co.jp/.BOOKS/01/1/010651+.html


453 名前: mk 投稿日: 2001/07/19(木) 08:43
すみません、日本語でよい本があればご紹介願います。
いったん地道に勉強しないとだめなようです。

私と同じように、βキットを購入したが3Dプログラムの次の一歩に
踏み出そうにも知識不足の人がいると思います。
この人たちへ向けた、有用なページを目指そうとしています。
引き続き具体的なご指摘や提案などをいただければ幸いです。

将来的には、用語とそれに対応したPS2のサンプルプロをのせれれば
と思っています。

銀杏座を利用したのは、あそこのQA用のBBSがあったためです。


454 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 09:18
PS22LINUX上でミリ秒単位のタイムを得るには何を使ったら
宜しいのでしょうか?


455 名前: デフォルトの名無しさん 投稿日: 2001/07/19(木) 22:00
UNIX(Linux)といえば、gettimeofday()。オーソドックス。

------
#include <sys/time.h>
#include <unistd.h>
int main(void)
{
struct timeval start;
struct timezone tz;

gettimeofday(&start, &tz);

printf("system time:%ld.%ld\n", start.tv_sec, start.tv_usec);

return (0);
}


456 名前: 454 投稿日: 2001/07/19(木) 23:33
>>455
有難うございます。
これでやっとフレームレート調整が出来そうです。。


457 名前: デフォルトの名無しさん 投稿日: 2001/07/20(金) 00:01
>>456
ン?
何やってるの?


458 名前: デフォルトの名無しさん 投稿日: 2001/07/20(金) 02:46
PS22LINUX上でキーボードの状態(あるいはメッセージ?)を得るには何を使ったら
宜しいのでしょうか?


459 名前: デフォルトの名無しさん 投稿日: 2001/07/20(金) 03:56
getchar();


460 名前:   投稿日: 2001/07/20(金) 19:49
>>458
なんかサポートライブラリーなかったっけ?


461 名前: 投稿日: 2001/07/20(金) 20:25
何処ぞで公開されてたソースを元にタイミング計ってみたら
PADの自走に成功した。藁


462 名前:   投稿日: 2001/07/20(金) 21:07
>>461
今度、PAD相撲でもやろう。


463 名前: 投稿日: 2001/07/20(金) 23:02
Basic3D理解出来た人にお願い、
>SampleCubeDataHead:
>SampleCubeDataBlock0:
の値の意味はどの辺りを眺めれば解るんでしょうか・・・


464 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 02:48
>>463
普通に頂点、法線、色、テクスチャ座標、が並んでるだけやんか。
#順番は間違ってるかも。いまFFセットになってるもんで確かめれん。。。
ただしpacketにする段階でばらしてるけどね。

ところで、こーゆーネタってLinux板の方に書いたほうが良くないかい?


465 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 03:00
>>464
なんで?


466 名前: 投稿日: 2001/07/21(土) 03:03
>>463
その手前です・・・GIFtag(?)部分
cube.Sにはコメントに 0x<block num|PRIM>
コメント外に 0x00010014 とありますが、
このblock num は 頂点、法線、テクスチャ、色 の 4 と、
PRIMの 0x0010010 を | して 0x00010014と言う事なのでしょうか?
だとしたら、このPRIMの様な命令はユーザーズマニュアルの
どの辺りに・・・

#ここはアセンブラlかりかり限定なんでしょうか?


467 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 03:10
>>465
少なくとも 463 の情報だけでは PS2Linux を持ってる人以外
には訳わからんと思うので。

>>1
>PS2Linuxに付いての話題はこちら
http://cocoa.2ch.net/test/read.cgi?bbs=linux&key=992958478&ls=50
と書いてあるし。


468 名前: 463 投稿日: 2001/07/21(土) 03:13
そうか・・・本職の人が居るのか^;
向こうはPSLUGと同じくPS2でLINUXなスレ、
こっちはLINUXでPS2なスレと思い込んでました。


469 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 03:20
>>466
あかん、別人かと思って読み飛ばしてた(ついでにターゲットミスってないか?)
PRIM 等は GS のレジスタref.見れ。


470 名前: 463 投稿日: 2001/07/21(土) 03:29
あ・・
.Sでが0x00010014なのに
オブジェクトデータに写す段階で
o->blockNum = *(o->pDataHead + 2) >> 16;
と成ってるから、blockNumは1なんですね・・・で、
o->prim = *(o->pDataHead + 2) & 0x0000ffff;
だから PRIMが0x14なのか・・・もうわけ解らん

S>OBJ>パケットの変換追いかけるの辛い
直接パケットに入れて欲しかったヨ。

>>469
すみません。
おっしゃる通りレス番ミスってる上に日本語めちゃくちゃです。
もう脳が逝ってる様なので失神する事にします。


471 名前: 463 投稿日: 2001/07/21(土) 03:38
はぁ また逝ってる
レジスタ>汎用レジスタ>PRIM見たら
0x14はTriangleStrip/フラット/テクスチャでぴたり一致の模様
今まで見当違いの所見てたり・・・ありがとうございました。


472 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 13:29
>>470
低レベルってのそーゆーことさ.
低レベルってのは厨房のやることじゃないんだよ.


473 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 14:12
>>472
なにが?


474 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 14:45
>>473
Linuxネタは高水準なのでスレ違いと思われ


475 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 14:57
>>474
(゚Д゚)ハァ?


476 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 15:17
>>475
低水準、高水準の違いわかってるか?


477 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 15:31
475じゃないが

472 それが低水準
473 何処が低水準
474 Linuxは高水準なのでスレ違い
475 はぁ?
476 低水準、高水準の違い解る?

素晴らしい


478 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 15:43
subarashi...


479 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 15:48
違う意味で低レベルになってきたな。


480 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 18:32
>>479
いや、もともと同じ意味だよ.


481 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 18:48
低レベル==HW寄り
じゃないの?


482 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 19:01
>>481
いまさら説明しなくてもいいことを書く
その低レベルさが気に入った!


483 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 19:03
>>482
いや、>>472-480を見てたらつい心配になって…


484 名前: デフォルトの名無しさん 投稿日: 2001/07/21(土) 23:52
どこかでも同じような勘違いで荒らしてるっぽいバカが出てたので
次スレはタイトル工夫しましょう。

PS2 ハードウェア プログラミング、くらい?


485 名前: 470 投稿日: 2001/07/22(日) 00:25
えーと、結局自分はこのスレに近寄ってはいけないのでしょうか


486 名前: デフォルトの名無しさん 投稿日: 2001/07/22(日) 00:31
>>470
?? べつにいいんじゃない?
ただしこっちでは、 PRIM とは? とか、GIFTag の構成について、
くらいのPS2Linuxのサンプルなどに依存しない形にまで噛み砕いて
から出す、と。


487 名前: デフォルトの名無しさん 投稿日: 2001/07/22(日) 03:31
>>486
そうそう。GIFTagだのPRIMだのってのはこのスレから見れば
充分「高レベル」な部類なので、リナ板逝け言われるんだなもし。


488 名前: デフォルトの名無しさん 投稿日: 2001/07/22(日) 11:44
支離滅裂


489 名前: デフォルトの名無しさん 投稿日: 2001/07/22(日) 12:55
なぜ追い出すようなことを書くの?
PRIMやGIFTagって、
ハードウェアが扱うフォーマットで
これ以上の低レベルは無いよ?
まぁ、僕はPS2Linuxは持ってないから
それに付属しているサンプルのことは
解らないけど、普通はここに来る人って
PS2Linux持ってることに
なってるんじゃないの?


490 名前: 486 投稿日: 2001/07/22(日) 14:11
>>489
分ってるとは思うケド、俺のレスは PRIM, GIFTag まで噛み砕けばOK、
逆に /usr/doc/PlayStation2/samples.... が云々はNGって意味です。
次の人が勘違いしただけ。
貴方のような人にも意見をもらうためには >>463 じゃまずいでしょ?


491 名前: デフォルトの名無しさん 投稿日: 2001/07/22(日) 14:31
つか、487はLinuxKitすら買えなかった厨


492 名前:   投稿日: 2001/07/23(月) 02:03
>>470
ポインターの足し算、結構微妙だよね。型意識したコーディングした方がいいよ。


493 名前:   投稿日: 2001/07/23(月) 02:07
「低レベルプログラミング」ときたら、
やっぱりライブラリー作成だと思うけどな。

フォーマットの話題は、ここでもいいと思うけど、仕様レベルな話だね。


494 名前: デフォルトの名無しさん 投稿日: 2001/07/23(月) 02:13
>>491
470のどこが微妙だっつーの. 型も全然意味ねーし.


495 名前: デフォルトの名無しさん 投稿日: 2001/07/24(火) 09:51
PRIM の ABE をオンにして ALPHA_1 にも 0x44 を入れたのに
何故かAをいくつにしてもブレンドかかりません。何がたりねー
んでしょーか?


496 名前: デフォルトの名無しさん 投稿日: 2001/07/24(火) 10:03
>>493
ハードウェア(GIF)が受け付けるフォーマットなんだから、寧ろここでやるべき議論です。
ちゃんと理解した上で書こう。