PlayStation Suiteプログラミング part 1

**名前は開発中のものです。** · 2012/02/25(土) 11:36:53.06

PlayStation(R) Suite SDKを使ってゲームを作るためのスレ

SDKは現在クローズドβで公開中です。
申し込みはこちら（個人でも申し込み可能だが選考基準は不明）
http://www.playstation.com/pss/closedbeta/index_j.html

**名前は開発中のものです。** · 2012/04/25(水) 14:24:51.27

/**
* クラス名
* @author あなたのお名前
*/

**名前は開発中のものです。** · 2012/04/25(水) 14:32:28.33

>>776
会話の意味わかってないのか

**名前は開発中のものです。** · 2012/04/25(水) 14:35:32.33

>>775
ignoreCaseな状態でgrepして無きゃないよ
テキストファイルだけならば

**名前は開発中のものです。** · 2012/04/25(水) 14:45:28.17

>>776
ビルドしたバイナリに署名的なものが入れられるかっつーことでは？
jarのmanifestファイルみたいなもの？なのかな?よく分かってないけど

**名前は開発中のものです。** · 2012/04/25(水) 14:59:19.62

>772
動作端末というか、意図しない操作をしてくれるかもしれないテストプレイとかは配布してやってもらいたい。

プロの人はどうやってるか知らないし、PSSじゃないけど
以前カクゲー＋エディタ作った際にヒットストップ中も移動値に重力加算され続けて
ヒットストップが切れた瞬間に蓄積された移動値が反映されてすげぇ吹っ飛び方するっていうアホな事やらかした。
自分でテストした時には空中ダメージは空中コンボからやるからいつも同じくらいの上昇状態からダメージ入るから気付かなかったけど
対戦しまくって初めて気付いた。

シンプルなミニゲーム的なのだったら動きゃなんとかなるけど
攻撃移動値とかパラメータ色々ぶっこんで動作が変わるようなゲームだと
色んな動作テストしないと不安だわ。

**名前は開発中のものです。** · 2012/04/25(水) 15:15:38.58

スト×鉄拳のことかー

**名前は開発中のものです。** · 2012/04/25(水) 15:38:38.79

でもソース渡すのは嫌がる人多そうだよね
なんか配布の仕組みあるといいんだけど

**名前は開発中のものです。** · 2012/04/25(水) 16:22:52.17

配布前はソニーで端末チェックするんじゃないの
ソース公開するならGitリポジトリでやっちゃえば

**名前は開発中のものです。** · 2012/04/25(水) 21:15:38.72

ふと思ったが、これってさ、ビルドした後 bin/Release 下の物を丸ごと渡せば、
PSS環境入ってる所なら実行出来るのかな
何がやりたいかと言うと、PlayStation 実機向けじゃなくて、Win上で単に動作させるって事。
意味があるかどうかは置いといてｗｗ

**名前は開発中のものです。** · 2012/04/25(水) 21:34:20.77

>>784
多分できる。

**名前は開発中のものです。** · 2012/04/25(水) 21:46:03.32

ソリューションを開くときに
サンプル等のあるライブラリのドキュメントだけ何故か何も表示されない
デスクトップやダウンロード等他のフォルダは問題ない
クローズド期間のときは問題なかったしのになんだろうこれ
とりあえずパスを直接入力すれば開けるっぽいけど不気味だ

**名前は開発中のものです。** · 2012/04/25(水) 22:03:28.29

実行だけならIDE起動しなくてプロジェクトファイルがなくてもSCE\PSS\target\win32\pss.exe を実行すると
実行ファイル名と実行ディレクトリを入力しろと出るのでexeのフルパスとexeのあるフォルダを
指定してやればエミュレーターが動く
エミュレーターでの実行はbin\Release\プロジェクト名-unsignedのほうで動く

**名前は開発中のものです。** · 2012/04/25(水) 22:06:20.39

パソコン上だと早いのにVita上だとUI表示されるまですごく時間かかるorz
ローディングとか入れないとだめか…

**名前は開発中のものです。** · 2012/04/25(水) 22:12:02.80

>>786
オープンβから
サンプルの配置場所が変わったからじゃ？

C:\Users\Public\Documents(Win7の場合)
のほうを見てる？

**名前は開発中のものです。** · 2012/04/25(水) 22:29:16.99

>>789
バージョン違いで置き場変わったのは知っているがドキュメントのフォルダを開いても空白になるんだ…
パブリックでもユーザーのDocumentフォルダでも同じ
へんに容量喰ってるわけでもないし、旧バージョンのPSSフォルダ移動してみたりしたが変わらん
そのうちフォーラムに垂れ込んでみるかねえ…

**名前は開発中のものです。** · 2012/04/25(水) 22:47:47.34

>>785 >>787
ありがとう！　自分で試してみれば良かった。
試しに、>>787 のヒントから、

　１．適当な場所にディレクトリ作る
　２．\SCE\Pss\target\win32 下の全てのモジュールを１以下にコピー
　３．＜プロジェクト＞\bin\Release\＜プロジェクト＞-unsigned 下を１以下にコピー

で、全てまとめて、

　４．１のディレクトリに適当なバッチファイル作成。　※例として run.bat
　　　中身はこの１行

　　　pss.exe %~dp0\Application\pssapp.exe

　５．後は run.bat を叩くと、そのまま実行おｋ
　６．１の内容まるごと zip にまとめて誰かに渡せば、そのまま動く、と。

最終的なディレクトリの様子： http://wktk.vip2ch.com/vipper0531.jpg

**名前は開発中のものです。** · 2012/04/25(水) 23:02:12.84

ちなみに、試しにリフレクタで覗いてみた所、案の定、
pss.exe はネイティブアプリケーションだけど、
Application 下の pssapp.exe は、素の .NET なので、ソースコード丸出し状態であった

で、多分 pssapp.exe の方、中身はデフォルトのテンプレだけだけど、ファイルサイズが 4KB しかなかったので、
多分ホストアプリにあたる pss.exe から、Sce.Pss 系パッケージのライブラリ実行が補完されると予測
＝実機に渡された場合、丁度同じ仕組みで、実機側のホストアプリが実行する、みたいな階層か。

なんとなく構造見えた

**名前は開発中のものです。** · 2012/04/25(水) 23:12:23.50

そして .NETバイナリである pssapp.exe 側をバイナリレベルで覗いてみた所、
VC# のデフォルトのような、ローカルディレクトリパスやオーナの情報なんかは含まれて居なかった
※Release版

…ただし、これらの１パッケージを zip でまとめて Web上で配布みたいな行為しようとした場合、
pss.exe だけ除外しなきゃいけないかもしれない。　ライセンス的な意味で。
他の DLL は Sony のプロプライエタリじゃないから OKなはず。

**名前は開発中のものです。** · 2012/04/25(水) 23:33:21.94

ソニーのAndroidウォークマンってこれに対応してるの？

**名前は開発中のものです。** · 2012/04/25(水) 23:44:36.91

>>793
乙乙

**名前は開発中のものです。** · 2012/04/26(木) 00:27:12.17

>>794
Androidウォークマンかどうかは知らないが、
\SCE\Pss\tools 下に、psslauncher.apk はあるな。 apk = Android用のアプリケーションパッケージ

試しに、コピーして拡張子を zip に変え、中身を覗いてみると、
普通に AndroidManifest.xml がいるので、同じ拡張子の別物ではなく、とりあえず Android用のランチャだろうと予測。

その奥を覗いてみると、lib/armeabi の下に、上で書いた win32 版と同様、
monosgen、zplatform なんかのライブラリが鎮座してる。　assets/ 下には、psslauncher.zpak ファイルもある。
ただし、これらは Sony による製作の Androidアプリっていう立ち位置だと思うので、
勝手に使って言いわけは無いと思う。　利用方法については、追いかけ中止。シラネ。

**名前は開発中のものです。** · 2012/04/26(木) 00:33:35.10

あと、上 >>791-793 に書いた内容の追記。注意事項。

今ライセンスを日本語訳しながら確認してるけど、それ以前にとりあえず、
win用に zip でまとめなんて時、pss.exe だけ除外じゃ確実にＮＧと思われ。

何故なら、 \SCE\Pss\source 下に、よく見ると Physics2D や Model、GameEngine2D、UI なんかが
C#ソースの状態で置かれている。　つまりそれらのライブラリは、pss.exe にバイナリで持たれてるんじゃなく、
C# 上でソースレベルライブラリとして位置づけられてる予感。

だとすると、コンパイル後、.NETバイナリである pssapp.exe 側に、これらの　「Sonyが書いた物そのもの」が
自分で書いたコードと同じ高さで含まれちゃうから、配布出来ない。

つまり、実質、配布は、出来ない。　Sony製でない各種DLLだけ配布しても意味無いので、
結局結論として＝出来ない　になると。

重要事項と、状況からの判断、以上。

**名前は開発中のものです。** · 2012/04/26(木) 01:04:18.15

ああら残念
他の人に試してもらおうとしたら
ソースまるごとしかないのかしら

イリーガルなことはやりたくないしなぁ

**名前は開発中のものです。** · 2012/04/26(木) 01:29:21.33

>>798
うーん、その話で言うと、揚げ足取りみたいな事したらいけるか？とも思ったけど、
そもそも無理かもしれない。

揚げ足取りみたいな方法ってのは、例えば SCE コンフィデンシャルなソース部分を静的に利用せず、
例えば \SCE\Pss\source 以下にある内容を、各自の環境で一旦　「.NET DLL になるように丸ごとビルドしてもらって」
自分の環境でも同様に .NET DLL としてビルドして、それを、参照する形で自分のコードを書き、実行するようにしたとすると、
（もしもそれが可能ならば） pssapp.exe 側には Sony のプロプライエタリが含まれない格好になるので、

コンフィデンシャルなライブラリのDLL、pss.exe の２つを含まないならば、配布しても問題無いかもしれないが…
しかしそれ以前に、

FAQ
http://www.playstation.com/pss/developer/openbeta/faq_j.html
＞無料のゲーム/アプリを開発しても良いでしょうか？
＞有料（フリーミアム含む）の開発に限定させて頂きます。

と、あるので、「試してもらう」は、この話に該当するから、ＮＧかな。同じ意味で、ソースレベルだったら？は、
もうフォーラムなりSCEに直接なり、聞くしかないと思う。あと同様に、上の「外出しDLL化」で、それを配布しない場合、とかも。

**名前は開発中のものです。** · 2012/04/26(木) 03:07:03.31

駄目だ、どう頑張っても2Dスプライト200個程度で処理落ち始まるもう寝る

**名前は開発中のものです。** · 2012/04/26(木) 03:08:15.84

SDKだけは自前で公式から落として入れてもらえばいいでしょ

**名前は開発中のものです。** · 2012/04/26(木) 08:38:12.90

>>801
むしろそれじゃ足りなくてって話
>>797 >>799

**名前は開発中のものです。** · 2012/04/26(木) 08:45:14.90

足りなくてっていうか
SDKだけ落としてもらって、友人にはソース渡せばあとは相手の環境でビルドするだけじゃないの？

**名前は開発中のものです。** · 2012/04/26(木) 09:04:29.89

>>799
それはPSStoreの話でSDKとは関係ないと思われ
俺はソース丸ごとMITライセンスで公開する予定

**名前は開発中のものです。** · 2012/04/26(木) 09:21:28.33

>>803ｰ804
ソースだけなら正直いけそうとは俺も思うけど、一応、本当にいいよね？と聞いた方がすっきりするかな？程度の話で、
上の話はバイナリの話。

>>801 のレスは、SDK落としてもらえばいいだけでしょ、としか書いて無かったから、
例えばランタイムだけ自分で調達してもらって、ビルドした.NETバイナリは渡す、みたいなケースを考えてたらマズいので、
足りないって話。その事を上で書いてるから、安価してるってこと

**名前は開発中のものです。** · 2012/04/26(木) 09:56:27.37

PSSuiteSDKの参照ページで検索かけるときに「Search」が消えないのが地味にｲﾗｯとする

**名前は開発中のものです。** · 2012/04/26(木) 10:02:59.86

あぁ、あと、ソースレベルなら大丈夫だろうと思うけど、一応聞いた方がって慎重になってる理由は、今のとこ2つある。

ひとつは、開発環境インストールすると付いてくるAPIドキュメントについて、
フッタやそこらにコンフィデンシャルと記述があること。
これが、例えばドキュメントそのものをパブリックな場所で公開はダメってのは当然として、
その意味する所はどこまでか、って話が見えないから。

普通、こんな社内ドキュメントに書くような強い言葉は使わないので、気になる。ってのと、

もうひとつはライセンス条項にある限定性の前提と知的財産権の行使を会わせた時の解釈。

まだ全部訳してないけど、なんか公式フォーラム以外で色々した場合、怒られるのかどうなのかが微妙。

だから、おkじゃないの？とは思うけど、一応聞いた方がと思った次第
Oracle社やHP社の製品扱う時みたいなイメージで、一応念入りに見てる俺

**名前は開発中のものです。** · 2012/04/26(木) 10:09:37.14

>>807
乙過ぎです！

フォーラムでソース配布しないで
他の人に試してもらう仕組み的なものを用意しないのか聞いてみようかな

**名前は開発中のものです。** · 2012/04/26(木) 10:16:54.44

Confidencial指定はクローズドβの時の名残だと思われ
（クローズドβの時はソースも含めてSCEIが許可した場合を除き配布できなかった）
今はソースもバイナリも勝手に配布してOKなはず

**名前は開発中のものです。** · 2012/04/26(木) 10:41:55.42

>>809
それマジかい。どこかでその旨アナウンスされてた？
バイナリまでっての、例えば上の方に書いたzipに1パケでまとめて、ってのもおk？

記憶だけの話なら、Sonyに一応聞いてみけど

**名前は開発中のものです。** · 2012/04/26(木) 12:34:54.74

うーむsamplerを配列にして一回のドローコールで完了だぜヒャッハーは無理なのか
ifで判定するのはペナルティが無いんだろうか

**名前は開発中のものです。** · 2012/04/26(木) 12:37:02.11

>>811
それはエスパーすると、>>767 の話か

**名前は開発中のものです。** · 2012/04/26(木) 12:46:27.14

>>812
TEXUNIT0:プレイヤーのテクスチャ
TEXUNIT1:背景のテクスチャ
TEXUNIT2:弾のテクスチャ
TEXUNIT3:敵のテクスチャ
TEXUNIT4:ボスのテクスチャ
TEXUNIT5:エフェクトのテクスチャ
を割り当ててtex2D(tex[index],uv.x,uv.y)をやりたい。
これなら違うテクスチャ使う場合でも同じ頂点バッファにできるから
はやいかなーと

**名前は開発中のものです。** · 2012/04/26(木) 17:26:13.51

>>813
ん？シェーダの考え方的になんか変じゃねそれ。

それら複数のテクスチャって、ひとつのメッシュで全部に同時に必要なの？
あるひとまとまりのメッシュ＝VertexBufferに並ぶ一連のプリミティブ（トライアングルとか）を描画するのに必要な情報を渡して描画する、その
パイプラインに置くのがシェーダだけど、

もしもその例にあるテクスチャが個別なら、配列に持たすんじゃなくて、ひとかたまりのメッシュ描画するごとに、テクスチャ生成時のID、
OpenGL的にはnameなんて言い方するが、IDをコンパイル済みシェーダプログラムに、渡す格好になると思う

シェーダ使ったプログラム、今回が初めてか？PSSに限らず

**名前は開発中のものです。** · 2012/04/26(木) 17:32:06.71

あ、もしかして
＞これなら違うテクスチャ使う場合でも同じ頂点バッファにできるから
＞はやいかなーと

複数のモデルを一つのVertexBuffer一本に全部つめてまとめて描画したいってことか？
つめてもいいけど、オフセットしながら、シェーダに値渡しながらDrawじゃなくて、
一回だけの呼び出しでって
それメリット薄い気がするが、もしかして描画時に毎回バッファ作成してGPUに送り込んでるとかしてないよな？

**名前は開発中のものです。** · 2012/04/26(木) 17:42:35.03

何をやりたいのかよく分からんな
Cgはまったく知らないけどただのマルチテクスチャーなら普通に出来るでしょ

**名前は開発中のものです。** · 2012/04/26(木) 18:02:16.86

>>816
マルチテクスチャ自体はいいんだけど、俺も考え方的に違和感
あとちなみに、PSSはGL"ES"ベースのCgのようだぜ。制限範囲把握してないけど

**名前は開発中のものです。** · 2012/04/26(木) 18:13:14.85

スプライトの描画おそいから一つの頂点バッファに全部いれて
一回のDrawArraysにすればはやいかなと。メッシュとか数千ポリでも余裕じゃん。
でもテクスチャ足りないからマルチテクスチャ使えないかなーって思ったの。
VRAMバンクみたいなの感じ？

**名前は開発中のものです。** · 2012/04/26(木) 19:26:22.06

>>818
で、個別の板ポリそれぞれについて、n組の変換行列渡すか、またはn組の頂点オフセット値を配列uniform 使って渡して、attributeでインデクス渡して特定して描画って格好か
VertexBufferは予め最大幅確保して。

いやパンクは無いだろうけど、テクスチャって言うより、そもそも
uniformに渡せる配列の最大幅には、ハードウェア依存の制限あるけと思うけど
＝その方法で一度に個別な板ポリ描画しようとすると、同時に扱える仮数に制限あると思うけど

その辺収まるの？やりたい内容的に
それとも座標は固定なの？

**名前は開発中のものです。** · 2012/04/26(木) 19:27:58.35

スマホtypo炸裂した
×仮数
○個数

**名前は開発中のものです。** · 2012/04/26(木) 19:40:00.25

DrawArraysの回数を数百回から数回に減らしてみた
速度変わらなかったｗ

**名前は開発中のものです。** · 2012/04/26(木) 19:42:07.92

別にそのタイミングで転送がある訳じゃないからな

**名前は開発中のものです。** · 2012/04/26(木) 19:47:01.38

GraphicsContextのスプライトの登録数って4096が最大か？
4096個以上だとプログラムが落ちるんだが……

**名前は開発中のものです。** · 2012/04/26(木) 20:02:52.18

>>819
uniform配列は使わないで毎フレーム頂点バッファに書き込もうかと
配列使えないから意味ないんですがね

// fcg
void main(
float4 out color : COLOR,
float2 in uv:TEXCOORD0,
int in index:TEXCOORD1,
uniform sampler2D tex[] : TEXUNIT // これを配列にしたい
)
{
color = tex2D( tex[index], uv);
}

**名前は開発中のものです。** · 2012/04/26(木) 20:03:30.54

// C#側

struct Vertex
{
float x,y,z,w;
float u,v;
int index;
};
struct Sprite
{
Vertex v[4];
};

// スプライトバッファ
Sprite sprite[1024];
sprite[0].v[xxx].index = 0; // playerTexを使用する
sprite[1].v[xxx].index = 1; // bgTexを使用する
sprite[2].v[xxx].index = 0; // playerTexを使用する

// 登録したスプライトを元にして頂点バッファを作成
vtx = CreateVertexBuffer(sprite);

SetVertexBuffer(vtx);
SetTexture(0,playerTex);
SetTexture(1,bgTex);
DrawArrays(sprite,n);

**名前は開発中のものです。** · 2012/04/26(木) 20:18:21.13

>>824
それ、CPUｰGPU間の転送動作とか、その辺わかってて書いてるかい？
あと、上の方でも書いたけど、PSS環境以外で書いたことはあるかい
普通、そういう猛烈なコスト無視なコード書かないと思うけど

**824** · 2012/04/26(木) 20:56:09.52

>>826
DirectX9あたりまでなら作ったことがあります。
弾の座標なんて毎フレーム変わっちゃうんで
システムメモリにVertexBufferつくってLockして毎回設定してたんですが
今はやり方ちがうんですかね

**名前は開発中のものです。** · 2012/04/26(木) 21:09:27.18

>>827
いやいやDirectX9でもプログラマブルシェーダ使う前提だとか、VertexBuffer使うって話であれば変わらないよ
要はCPUｰGPU間の転送って言う基本的で物理的な事情に由来する話だから、

例えば「早くしたい」って事情なら、真っ先にそこ回避したいところ

もっと昔だと、Cライクな構文のシェーダ言語はなかったので、GPU側の機械語で計算処理書いて、予め転送した頂点計算したりしてた

その辺、そこまで要件がタイトじゃないとしても、毎フレーム生成は真っ先に避けたくなる所だよ
それは昔から変わらない

なので、昔の本でもいいから、基礎から勉強しなおしした方がいいと思う。
処理効率的な意味で。別にいじわるで言ってるわけでなく、マジで。

**名前は開発中のものです。** · 2012/04/26(木) 21:11:36.56

>>827
あと、その毎フレーム座標変わっちゃうんで、だろうと思ったから、
先に >>819 のレスを書いてるのだ
意味がわかんなかったら、聞くか調べておくれ

**名前は開発中のものです。** · 2012/04/26(木) 21:12:58.20

うーんムズカシイのう

**名前は開発中のものです。** · 2012/04/26(木) 21:27:12.64

ParticleSystemは毎フレーム座標の設定をしてるみたいだけど
毎フレーム変更するならImmediateModeを使えばいいんだろうか？

**名前は開発中のものです。** · 2012/04/26(木) 21:40:11.96

>>830
とりあえず、週末になったら
Sprite2D使った場合と、
毎フレーム頂点の生成廃棄と転送繰り返す場合と、
シェーダ使った意味的に普通のコードの場合

で、速度検証のコード俺も書くよ

**名前は開発中のものです。** · 2012/04/26(木) 21:56:28.50

>>831
パーティクルだと実装手段180度違うような方法色々あって、一概に言いづらい
ってのは、例えばポイントスプライト（新しいDirectXだと消えたらしいが）だとか、普通にポリゴンだとか、色々方法あるから。

ただ、いずれも描画のための頂点座標計算はCPUでやらないで、シェーダ側で計算するのが普通だけど、
その元になる係数なんかについてはCPU側で計算して、それを、
uniformやattributeで渡して、みたいな格好。

あとバッファをLockやUnlock、map／unmapしてCPU側管理下のメモリに内容展開して計算して詰め直し、GPU側に再転送みたいなアプローチは、初期処理は当たり前として、
それ以外だと例えば、場面替えの時とか、あるいはゲームじゃなく
3Dモデリングソフトを作るだとか、そういう「やってもいい時にだけ」する感じ

**名前は開発中のものです。** · 2012/04/26(木) 22:48:58.96

これSpriteList->SpriteRenderer->ImmediateModeQuad
でSprite描画はDrawごとにVertexBufferにsetVerticesやってるっぽいな…

**名前は開発中のものです。** · 2012/04/26(木) 22:59:39.10

標準ライブラリだからはやいと思ったがそうでもないみたいだな
弾幕シューティングは無理か

**名前は開発中のものです。** · 2012/04/26(木) 23:31:56.51

32x32なら500近く行けそうな感じになってきた・・・
けど小さすぎるわ・・・

**名前は開発中のものです。** · 2012/04/27(金) 00:34:32.51

>>835
あきらめない！！

**名前は開発中のものです。** · 2012/04/27(金) 01:16:38.22

>>835
お前人の話読んでないだろ
別に無理じゃないって

**名前は開発中のものです。** · 2012/04/27(金) 03:17:22.68

99BASICでスプライト500個！60fps！
http://www.geocities.jp/arc_bureau/sample/SAMPLE2012_04_27_FRI.jpg
http://www.geocities.jp/arc_bureau/sample/SAMPLE2012_04_27_FRI.zip

フォルダをクリックして展開。
キーボードの+-*/で2Dスプライトの個数を増減できる。
プロテクト付き。

**名前は開発中のものです。** · 2012/04/27(金) 08:07:48.29

出来るならぜひご教授を・・・

**名前は開発中のものです。** · 2012/04/27(金) 08:25:15.63

99BASICのスレ
http://ikura.2ch.net/test/read.cgi/i4004/1252332146/l50

**名前は開発中のものです。** · 2012/04/27(金) 08:28:07.42

>>840

float x,y;
float u,v;
float cx,cy;
float scalex,scaley;
float rx,ry;
float rot;
float r,g,b,a;

のパラメータをsetUniformで渡す方法じゃないのか？
でもuniform vectorは128までだから、一回の描画で8個ぐらいしか描画できないか。

**名前は開発中のものです。** · 2012/04/27(金) 08:33:06.28

スピード係数

８ビット（MSX）　　　　　１
X68000　　　　　　　　　１０
MSXturboR　　　　　　５０
FM-TOWNS　　　　　　１００
PSP/DS（Vita/3DS）　５００
Wii　　　　　　　　　　　　７５０
AT機/PS3/XB360　　１０００
- - - - - - -

開発費係数

1万　　　　８ビット（MSX）
1万10円　 MSXturboR
10万　　　 X68000
100万　　　FM-TOWNS
1000万　　Android/AT機/モバゲー
1億　　　　PSP/DS（Vita/3DS）
10億　　　Wii/PS3/XB360

**名前は開発中のものです。** · 2012/04/27(金) 08:33:26.24

スプライト係数

１　　　　８ビット（MSX）　16×16ドット　32枚　単色～16色　パレット512色　ラインバッファ方式
　　　　　（turboR同じ）　　横方向表示8枚まで

１０　　　X68000　　　　　16×16ドット　128枚　16色　パレット65,536色　ラインバッファ方式
　　　　　　　　　　　　　　　横方向表示32枚まで

２５　　　FM-TOWNS　　16×16ドット　1,024枚　16色～32,768色　パレット32,768色　フレームバッファ方式
　　　　　　　　　　　　　　　フレームレート224枚　横方向表示制限なし

１００　　AT機（99BASIC）　16×16～64×64ドット　32枚　256色　パレット16,777,216色
　　　　　　　　　　　　　　　　フレームバッファ方式　フレームレート32枚　横方向表示制限なし

１０００　AT機（DarkBASIC）　スプライトサイズ制限なし（ビデオカードとメモリ搭載量に依存）
　　　　　　　　　　　　　　　　　 65,536枚
　　　　　　　　　　　　　　　　　 16,777,216色中16,777,216色（完全フルカラー）
　　　　　　　　　　　　　　　　　パレットなし
　　　　　　　　　　　　　　　　　フレームバッファ方式（ポリゴン転用）
　　　　　　　　　　　　　　　　　標準フレームレート1,024枚（ビデオカードとスプライトサイズに依存）
　　　　　　　　　　　　　　　　　横方向表示制限なし
　　　　　　　　　　　　　　　　　回転・拡大・縮小あり
　　　　　　　　　　　　　　　　　各種SFX（カラーフィルター、アルファetc.）あり

**名前は開発中のものです。** · 2012/04/27(金) 08:35:10.44

誰かC#で書かれたゲームエンジン作らないか？
さしあたってPSSをターゲットにするが
PSSに依存せずあらゆるプラットフォームで動くマルチプラットフォームなやつ

**名前は開発中のものです。** · 2012/04/27(金) 08:37:38.87

>>845
質問だけど、プロで食ってる人たち？
そうでなければ99BASIC/DarkBASICが近道。

**名前は開発中のものです。** · 2012/04/27(金) 08:40:42.07

VITA上のPSSエミュが遅いんすかねぇ
画面いっぱいに拡大した2Dスプライトが20個程度で処理落ち始めるし

**名前は開発中のものです。** · 2012/04/27(金) 08:44:07.09

>>847
アルファ使ってるとしたらカットするしかないね。

切っても処理落ちしたらVitaはちょっと…

**名前は開発中のものです。** · 2012/04/27(金) 09:01:05.41

>>847
画面いっぱいって960x544のスプライトを20個描画してるのか？
960x544x4B = 2MBx20 = 40MBぐらいのフィルレートか

**名前は開発中のものです。** · 2012/04/27(金) 09:04:19.22

いや、64x64をいっぱいに拡大

**名前は開発中のものです。** · 2012/04/27(金) 09:33:21.86

>>845
なんて言っていいか、どういうイメージでどんな内容想定して言ってる？

PSS自体がゲームエンジンで、さらに固有処理は、プラットホームの限定がない仮想マシン（,NET）なのに

相当でたらめな想像してるか、または作れるものを限定して、固有処理のレイヤまで予め作るつもりか？

>>846
多分彼は違うと思う

**名前は開発中のものです。** · 2012/04/27(金) 09:45:41.10

>>845
どんな場面を想定してるの？

>>851
なるほど、” 仮想コンソール環境 ” ね…。
使ったコトないけどあんまり高望みはできそうにないね。

**名前は開発中のものです。** · 2012/04/27(金) 09:53:24.43

あ、間違えた。

どんな場面を想定してるの？と言うのは>>850へ。

**名前は開発中のものです。** · 2012/04/27(金) 09:56:24.33

>>840 >>842
処理のアプローチとしてはそう言うことで、>>819 に書いてるのがそれだが、

普通はどんな内容描画したいが先にあって、それで実装だから、
それらのパラメータが全部いるとは限らないので、上限鑑みて必要なものだけにして、一度の描画の個数を増やすアプローチ
普通の考え方の順序で言うと、そう。

よーく要件考えれば手段なんていくらでもあるがな

例えば平面二軸方向だけ変化して、実行時にスケーリングの計算がいらないもの、いるもの、だとか
マテリアル、テクスチャの単位毎にまとめて描画とか、
固有要件で普通分ける話なので、そのへん自分でちゃんと考えて

**名前は開発中のものです。** · 2012/04/27(金) 10:00:58.76

口だけは達者だなｗ

**名前は開発中のものです。** · 2012/04/27(金) 10:06:42.14

>>852
ん？お前もお前でなんか多分勘違いしてないか。
仮想コンソール環境ってなんだよww
わざわざダブルクォートまでつけてるが、そんな言葉無いぞ。具体的に説明してもらえるか？

そして上で書いた仮想マシンってのはVMの事だ。VMってのは仮想的なCPU、というアイデアで作られたひとつのアプリケーションの事だ
JavaやC＃でお馴染みのものだ。

**名前は開発中のものです。** · 2012/04/27(金) 10:07:36.17

>>855
おまえ最低だな

**名前は開発中のものです。** · 2012/04/27(金) 10:13:15.99

>>856
あのさあ、そこはアツくなるところじゃないからね…。

” 仮想コンソール環境 ”ってのは、MSIL（CIL）の考え方だよ。

分からなかったら検索するといい。

**名前は開発中のものです。** · 2012/04/27(金) 10:14:53.19

ごめんなさい。速度全然でなくてイライラしてた。もう少し頑張ってみます

**名前は開発中のものです。** · 2012/04/27(金) 10:26:27.71

>>858
いやいやそうじゃなくて、MSｰILはそのとおりだが、
それの例えとしても仮想コンソール環境なんて言わないぞ

もしもおまえも職業プログラマだったら、その辺の席の人間捕まえてそれ話してみな。

普通、その言葉が出るのはこの文脈じゃなくて、*nixのXコンソールだとか、そこにターミナルから接続する構成だとか、それに類する仕組みの時だ

**名前は開発中のものです。** · 2012/04/27(金) 10:29:28.95

>>860
いやぁ、趣味でやってる暇人だからね…。

だからどこでどんな話をしてどんな反応が返ってきても何とも思わないよ。

ゲーム業界ってこんなのばっかりかな…ｗ”

**名前は開発中のものです。** · 2012/04/27(金) 10:30:28.94

もしかしてバーチャルコンソール

**名前は開発中のものです。** · 2012/04/27(金) 10:34:46.25

パソコン使ってるからWindowsAPIとかDirectXとかMSILの部分を指してるつもりだよ…。

もっとも、↑のは直接使わないけどねｗ”

DarkBASIC使ってると少しは意識するけど…99BASICだと考えるだけムダだからね。

**名前は開発中のものです。** · 2012/04/27(金) 10:49:22.44

>>851
PSSに依存しない移植性に優れた軽量ゲームエンジン
機能としては、
・シーングラフ
・アニメーション
・スキニング
・モーフィング
・テクスチャー
・シェーダー
・モデルデータの入出力
・マルチパスレンダリング
を全てPSSに依存しない形で実装する
レンダリングやIOなどのハードウェア依存処理は無理なものも多いので
１箇所に集約して下位レイヤー(PSS)に全てお任せ
どうよ？

**名前は開発中のものです。** · 2012/04/27(金) 10:56:08.59

>>859
週末になったら俺もテストしてみるから
なんとかなるさ

**名前は開発中のものです。** · 2012/04/27(金) 10:59:33.02

>>864
それ作って公開してくれるっつーこと？

**名前は開発中のものです。** · 2012/04/27(金) 11:08:53.89

>864
言いだしっぺの法則だな。

元々何か作ってた人は自分用に使いやすいフレームをPSS上で再構築するだろうし。
そうじゃない人はライブラリできるまで待つのもアレだから先に自分で思い描くもの作り出すだろうし。

**名前は開発中のものです。** · 2012/04/27(金) 11:15:20.16

>>864
気持ちはわかる。そしてその要件レベルの話はいいとして、
なんて言うか、もっと具体的な実装イメージの話だよ

例えば、PSSの標準にない部分について共通仕様を決めて、その部分を拡充したい、なら現実としてわかるが、
いったいどういう実装イメージで、「環境に依存しないもの」と言ってるのかってこと

実行時に差異吸収だと、それこそVM挟む格好で、その意味で例えばJavaやC＃を土台にして、とかインタプリタになるし、
ソースレベル互換ならC/C++でも構わないが、いずれにしても要件はAPIレベルで揃えたいって話か？
例えばOpenGL周辺のような

共通項洗いだしと動作揃える作業量、半端じゃないぞ？

**名前は開発中のものです。** · 2012/04/27(金) 11:18:07.81

>>867
言い出しっぺの人間が多分理想の上っ面イメージで話してるから現実味は無いとして、
他はその通りだと思う

**名前は開発中のものです。** · 2012/04/27(金) 11:21:05.67

ではこれにて…。

シンプル・ブレイク・アウト、ファーストインベーダーの最新版（V2R1）。
http://www.geocities.jp/arc_bureau/main_street/

**名前は開発中のものです。** · 2012/04/27(金) 11:25:48.86

>>870
とりあえず君ももっと勉強した方がいい
DarkBasicその他環境は好きでいいとして、
あんまりとんちんかんで適当に曖昧な事言ってると、意味伝わらなくて話にならないから

あと俺はゲーム業界じゃなくてシステム開発業界の人間だよ

**名前は開発中のものです。** · 2012/04/27(金) 11:34:33.31

おまけ♪

99BASICでスプライト500個！60fps！
http://www.geocities.jp/arc_bureau/sample/SAMPLE2012_04_27_FRI.jpg
http://www.geocities.jp/arc_bureau/sample/SAMPLE2012_04_27_FRI.zip

フォルダをクリックして展開。
キーボードの+-*/で2Dスプライトの個数を増減できる。
プロテクト付き。

ではでは…。

**864** · 2012/04/27(金) 11:42:09.44

>>868
現状ではPSS向けにがっつりゲームエンジンを作るという判断はどこの会社でも難しいと思う
ただし.Net環境(C#)自体は非常に有望でこれに投資するのは悪くない
ゆえにPSSに依存しない.Net環境で動くゲームエンジンが今もっとも必要とされている
（原則.NetのSystem.***以外は使用禁止）
例えばテクスチャーならPSSのTextur2Dクラスではなく自前のTexture2Dを
.NetのBitmapイメージから作る事になる。
同様にMeshクラスも自前で作ってSceneも作ってRendererクラスも作って
（このクラスだけPSSのGraphicsContextに依存していい）描画する
こうすればWindowsでもXNAでも移植するのは簡単
PSSに用意されている仕組みをほぼ全部実装し直しになるけどやる価値はあると思う

**名前は開発中のものです。** · 2012/04/27(金) 12:00:43.53

>>873
理想は分かった。
頑張って実装してくれ

**名前は開発中のものです。** · 2012/04/27(金) 13:16:47.50

まぁ効率狙う以上、適当では済まないだろうよ