この「セガサターン」には下記のような選考・審査があります。有用なアイデアが残されているかもしれません。この記事を編集される方は一度ご参照下さい。

	日付	選考・審査	結果
1.	2006年1月31日	査読依頼

この記事中の「湯川専務」のＣＭはドリームキャストのときではありませんでしたか？U.S.S.Momotaro 06:42 2003年10月4日 (UTC)

確かに湯川専務が出演していたのはドリームキャストのCMでしたね。この部分はドリームキャストの方に移した方がいいかも知れません。イトトン 01:24 2003年10月5日 (UTC)

どうも技術的な知見を持っていない方が、曖昧な記述で技術的劣勢を無かったことにしてしまった（苦笑）ようなので、そのあたりの詳細を大幅に加筆しておきました。

冷静を失って公平な記述ができない方は、記述を諦めた方がよろしいでしょう。 Wikipediaも、そのような人材は望んでいないようですし。 210.149.190.143 2005年7月7日 (木) 22:34 (UTC)[返信]

Wikipedia:個人攻撃はしない Nonenone 2005年7月8日 (金) 02:49 (UTC)

公平な視点からの訂正と批判を、単に個人攻撃と受け取られるとは心外です。訂正を要求します。 またそのような論理は、私の批判が正しかったこと(Nonenone氏の視野が主観に凝り固まっていること)の何よりの証拠であることを確信しました。

いずれにせよ、客観性・公平性に努められない方は、Wikipediaには不要であると思われます。210.149.190.143 2005年7月8日 (金) 20:40 (UTC)[返信]

今ちょっとN氏の投稿履歴を拝見して来ましたが、酷いですね。ここで批判されたストレスをスーパーファミコンやMSXを貶して発散ですか。機会があればそちらも再修正したいところですが、自らの心境次第でネガティブにものを卑しめるような方は、投稿ブロックを申請した方が良いかもしれませんね。 210.149.190.143 2005年7月8日 (金) 20:52 (UTC)[返信]

下記点、追加しました。 セガ純正 　・通信拡張端子(COMMUNICATION CONNECTOR)に接続 他社発売 　・プリンタインターフェイス(光栄「サターン用ワープロセット」に同梱)　2005年11月6日 (日)(bx)

多少不明点があるので確認できればと思います。

• "複数のCPUを効率よく協調動作させる際に必要となる割り込みやバスの調停機能などを整備しておらず"

  SCUという専用コントローラにより割り込みやバス調停は完備していたと思いますが、どの部分を指していますか？　確かにコンシステンシの制御はないようですが。

• "パースペクティブの指定はできない等、他機種との大幅な差は見出しにくく、技術力の低い会社には不利なアーキテクチャであった"

  パースペクティブ指定（補間？）はPSもなかったですが、位置指定のマッピングができないこと（テクスチャードポリゴン）を指している？

• "一般市場で調達可能な部品のみで構成された製品では海賊版の登場が不可避であるなど、その構造にまつわるリスクも少なくない"

  VDP1/2など基幹部品は専用（ただし他社製）が多かったのでは。

• "ネイキッドポリゴン描画のみ対応"

  ネイキッドポリゴンはあまり聞かない名称ですが、一般的でない名称の時はある程度の説明がほしいです。

• "もっとも、格闘ゲームに特化したライブラリであったため一般的には扱いにくいという意見があった"

  客観的な資料はありますでしょうか？

取り敢えず以上です。--ちぇす 2005年12月4日 (日) 12:51 (UTC)[返信]

仕様書類を読み漁ってみましたが、キャッシュコンシステンシを監視する機構がユーザブレークコントローラにありましたね。ですのでマルチプロセッサシステムとして不利なのは１にも２にもキャッシュ容量の不足と言えましょうか。あとはNUMA構成でなかったからとか。2CPUが使われなかったのは機構的に不可能だったからでは決してなく、環境のサポートが一切なかったからでしょうかね。それも当時のゲームシステムであることやキャッシュ容量制限を勘案すればガチなプログラミングとならざるを得ず、致し方ないと言えますかね。--ちぇす 2005年12月17日 (土) 21:40 (UTC)[返信]

相変わらず仕様書を読んでいますが、SGLのマニュアルなどを見ると別に格闘ゲームに特化したライブラリではなかったようです。通常使いそうなGL的関数や構造体、ペリフェラル系関数が揃っているだけのようです。

また修正を入れましたがVDP1について変形スプライトがテクスチャポリゴンの代用である（もしくはテクスチャマップ機能を持っていない）という文があちこちにありましたが、VDP1マニュアルを見てもPS的（もしくはOpenGL的）ポリゴンでないというだけで、れっきとしたテクスチャマップドポリゴンととれます（しかしこのテクスチャマップは制限きついですね。パターンの方を一所懸命最適化する必要がありそう・・・）。ポリゴンと変形スプライト間の違いはpartsと呼ばれるデータフォーマットの違いであり、処理パイプラインは当然同じ（制御が異なるのみ）でしょう。まったく別のユニットがあるわけではない。ですのでことさら両者を明確に分ける必要はなさそうです。

またVDP1が機能面でPSに劣勢なのはわかるとしても、ピクセルフィルレートが大幅に劣っているという表現が妥当であるという資料は見当たりませんでした。SSがSDRAMであり、PSがEDORAMであることや、SSがテクスチャとフレームバッファでバスが分かれていることなどを勘案すると、バス幅や周波数の差を補うでしょう。

ということで、だいぶ修正してしまいました。--ちぇす 2005年12月18日 (日) 06:23 (UTC)[返信]

修正後また上記と同様の記述が書き加えられましたが、再度質問というか確認できればと思います。あと新規の確認もあります。

• 「VDP1から見てパターン（テクスチャ）バッファは読み出し専用、フレームバッファは書き込み専用となっていたため、フレームバッファ上の色情報をパターンに適用して色演算する必要のある半透明処理にも著しい制約がつく」は間違いでしょう。フレームバッファはRMWであるので正確には書込み専用ではなく、また半透明に制約があるのはフレームバッファからくる制限ではなく、ラスタライズの方式からくるものです。
• 「二基のVDPは16bit幅のデータバスによって接続されており、このバスの帯域によって実質的にVDP1側のフィルレートが律速され、カタログスペック上の理論値を達成させることができないボトルネックとなっていた。」これがVDP2の項にありますが、VDP1とVDP2とを接続するバスはVDP2への片道バスであり、VDP1で生成した描画データを次のフレームでVDP2で合成するためのものです。従ってVDP1が最終的に生成するフレーム分あればよく、フィルレートネックにはなりません。また、SCUから来るバスがVDP1とVDP2に跨っていますが、これのネックはポリゴン投入のネックにはなってもやはりフィルレートネックにはなりません。あくまでもVDP1のフィルレートネックはVDP1が持つメモリとのアクセスネックでしょう。もちろんVDP2の項にくるものではありません。
• これは表現の問題でしょうが、VDP1の「3D表現の自由度は競合機、とくにプレイステーションのGPUには遠く及ばなかった」という表現は誤解を招く可能性があると思います。私も「今ひとつ」という表現を用いたのは、3D表現をする上で両者の機能を比較し片方が致命的かどうかと見た場合、どれもworkarroundがあり致命的ではないためです。
• 「格闘ゲームを念頭に開発されたライブラリであるため広範な適用には不向きであり」ですが、SGLに格闘ゲーム用の関数、もしくは構造体はありましたか？私も斜め読みであり見落としがあったら教えていただきたいのですが、それでもそれら関数の殆どはかなりプリミティブな3Dライブラリや周辺機器や音のライブラリだと思われますが。

以上です。ちぇす 2006年1月4日 (水) 12:26 (UTC)[返信]

一日早いですが一週間の返答期間を待ち、修正しました。--ちぇす 2006年1月9日 (月) 22:09 (UTC)[返信]

セガのハードウェアのシュリンク失敗による赤字計上について3度書かれているので修正します。210.194.223.25 2006年1月8日 (日) 17:28 (UTC)[返信]

そのうちのひとつは概要なので復活させました。概要の位置付けとして、各論にあっても重要な点は記載する必要があると考えたためです。この場合、早期に縮小する原因である赤字要因は重要と考えられます。疑問点はノートまで。--ちぇす 2006年1月9日 (月) 22:07 (UTC)[返信]

情報開示の批判が2箇所あるので1箇所にまとめました210.194.223.25 2006年1月8日 (日) 18:46 (UTC)[返信]

>フレームバッファ上の色情報をパターンに適用して色演算する必要のある半透明処理にも著しい制約がつく」は間違いでしょう。

>半透明に制約があるのはフレームバッファからくる制限ではなく、ラスタライズの方式からくるものです。

VDP1がフレームバッファを読み出すことができないため、ポリゴンやスプライトをラスタライズする際に制約がつく（半透明で描画できない）のですよ。

フレームバッファを読み出せないとラスタライズに影響するのですか？フレームバッファは今のGPUで言うレンダーバックエンドに繋がっているわけで、ラスタライズとは関係がないんじゃないでしょうか。もしくはここではレンダリングパイプの処理全般をラスタライズと表現されているのでしょうか。どちらにしてもフレームバッファがライトオンリーなら半透明は全く使用できない（機能がない）でしょうが、実際はコマンドテーブルには半透明bitがあるわけで。もしくは全く別の制限があるのでしょうか？

>「二基のVDPは16bit幅のデータバスによって接続されており、このバスの帯域によって実質的にVDP1側のフィルレートが律速され、カタログスペック上の理論値を達成させることができないボトルネックとなっていた。」これがVDP2の項にありますが、

自分が記述したものは字下げをせず、段落を分けておいたはずです。また記述の内容も、VDP2の項目に書いたのではなく、二つのVDPの概観として記述したつもりです。 位置が不適切であると感じられたのであれば、（何か特別な意図があるのでない限り）削除するのではなく適切な位置に移動していただければと思うのですが。

段落に関しては差分を見ていたため見落としていました。申し訳ない。しかし言いたいのは段落ではなく、VDP1とVDP2を接続するラインがボトルネックでピクセルフィルレートが制限されるわけではない、という所です。そこはVDP1からVDP2へスキャンアウトするだけのラインなので、帯域的には単純に言えば704×240×1Byte×60Hz(もしくは352×240×2Byte×60Hz)=10MB/s分あればよく、充分満たしているわけです。つまりボトルネックはそこにはない。もしくは実際はそれ以外の帯域を食う処理をしているということでしょうか？

>これは表現の問題でしょうが、VDP1の「3D表現の自由度は競合機、とくにプレイステーションのGPUには遠く及ばなかった」という表現は誤解を招く可能性があると思います。

私には、まったくそのようには思えません。ポリゴン数やフレームレートで明らかにプレイステーションの後塵を拝していたのが実情です。 それが一律にゲーム性やゲームそのものの価値を下げるとまでは考えてはいませんが、表現力や自由度についての制約は残念と言わざるを得ないものでしたよ。 そして（いわゆる素人の方の言う）2D系の画面造り・表現力では、同時代の最高峰に位置していた。そのトレードオフとしては良い落としどころであったと思うと同時に、やはり3Dの表現力は残念であったと。

然るに、一方的に記事を削除されてしまう（非常に削除がお好きな）点については、憂慮と遺憾を表明せざるを得ませんね。また返答待ちの一週間という区切りも、相当勝手な事を言っているな、という印象です。

一週間に関しては編集のガイドラインに「ノートに提示したあと、しばらく待ってください。1週間程度、待っても反応がなければ、その編集を実行してください。」とありましたのでそれに従っています。まぁ私もその後忙しいことが判明していたのでちょっと早かったことは申し訳なく思います。他の方による編集で内容が動きそうだったこともありますし（もちろんそれが悪いことではないですが）。

>SGLに格闘ゲーム用の関数、もしくは構造体はありましたか？

そういう話ではないのですよ。 例えばパースやポリゴンのソート、クリッピング等のロジックが、いわゆる格闘ゲーム向けの空間を前提に設計されている。例えばレースやRPGのように、地形に（空間的に大きな）ポリゴンを貼って、その上にキャラクターオブジェクトを配置することで広大な空間を表現するような処理にはおよそ向かない。 添付のサンプルも（本来VF2から派生したものなので当然ですが）同様で、他ジャンルのソフトウェアへの応用はそのままでは難しい、つまり貧弱で不向きなものでした。 そもそもSGL以前は、ポリゴンの画面端のクリッピングすらまともにできていない作品がSEGA内制の作品でさえ散見されたほど、サターンのライブラリ環境はお粗末な代物でしたが、ようやく出てきたSGLでもこの程度では…というのが、当時の製作現場の率直な感想でした。

210.149.190.139 2006年1月16日 (月) 19:44 (UTC)[返信]

見た限りSGLはプリミティブに過ぎる感じですが（この程度が途中で出たことが3Dに対する当初のセガの体制を表している言えますが）、逆に言えばハードウエアに密着した最低限のライブラリとの印象を受けます。あの当時の速度、メモリ量、演算精度からOpenGLのような汎用多機能ライブラリを作成するのは逆にパフォーマンスを損なう可能性が大きいのではないでしょうか？タイトルごとに様々なスケーリングや最適化があるわけで、それはタイトル側の領域にすべき問題ではないでしょうか。逆にそこまで勝手にやられたらパフォーマンス管理上迷惑では（3Dクリッピングも勝手にやるのは迷惑な気がしますが）。

SGLは格闘ゲームに特化したというよりは、SH2やVDPなどハードの演算精度やメモリ量に合わせた最低限の3Dインタフェースを提供している感があります。固定少数である限り演算精度管理が場面依存なのはしょうがないですよね。--ちぇす 2006年1月17日 (火) 15:57 (UTC)[返信]

ですから「格闘ゲームの開発から派生した、格闘ゲームに特化した（他の広範なジャンルへの応用を当初から考慮せずに設計された）お粗末なライブラリであった」と何度も書いて（そしてその度にあなたが根拠も提示せずに消して）いるのですが、一体何が不満だと主張されたいのでしょうか？210.149.190.140 2006年1月20日 (金) 20:13 (UTC)[返信]

本文のコメントで、 「数値計算というと通常は浮動小数点演算を指しますが、SHにはFPUは搭載していません。またCPUによってジオメトリからラスタライズまで一切の処理を行うワークステーションやPCでもジオメトリ演算は可能であり、SHの能力として強調する必然性はありません。乗除算も32ビットプロセッサには当たり前で、強調する必要はありません。」

とありますが、数値計算イコール通常はfloatであるということはありません。固定小数のDSPも普通にあります。3DCGだけが数値計算の用途ではないので。 またマイクロコントローラであるSHでは乗除算器がありジオメトリ計算もなんとかできるのは（その当時では）結構トピックです。WSやPC以外の世界もあるということです。 なので「制御用マイコンではあるが」とくるのです。本来は制御用の安いマイコンなのにDSP的機能も入っている（のでジオメトリをSHでやっている）。何で制御用マイコンでジオメトリ？という疑問に対する答えを書いてもいいのではないかと。--ちぇす 2006年1月17日 (火) 16:57 (UTC)[返信]

…というよりも、FPUが無ければ整数演算で近似するより他に方法が無いのですよ。そんなことはパソコンでもゲーム機でも、乗算命令すら持たない8bit機や16bit機ですら当たり前にやってきている。当時のプレイステーションでさえもGTEでは固定小数点を用いていたくらいですし、R3000が持つのもSHと同様に整数演算命令のみです。双方ともFPUもMMUも持たない、素朴な32bitプロセッサでしかありません。

構造体ごとGPUに丸投げして当たり前に32bit floatで処理してもらえる現在の感覚では、にわかに想像することは困難かもしれませんが、同時代にSHの整数演算能力が他の32bitプロセッサの水準と比較して殊更強調すべき機能や特性を持っていたかのような書き方は、到底了解することはできません。

それと蛇足ですが、SH2に整数同士の乗算はありましたが、除算はどうでしたかね。現在手元に詳細な資料が無いため断言は避けますが。また制御用「マイコン」という、時代感を読み誤っているかのような単語の選び方も、自分には気になります。210.149.190.140 2006年1月20日 (金) 20:13 (UTC)[返信]

>フレームバッファを読み出せないとラスタライズに影響するのですか？フレームバッファは今のGPUで言うレンダーバックエンドに繋がっているわけで、ラスタライズとは関係がないんじゃないでしょうか。もしくはここではレンダリングパイプの処理全般をラスタライズと表現されているのでしょうか。どちらにしてもフレームバッファがライトオンリーなら半透明は全く使用できない（機能がない）でしょうが、実際はコマンドテーブルには半透明bitがあるわけで。もしくは全く別の制限があるのでしょうか？

自分の記述の後ろに追記されているとは思わず、見落としていました。申し訳ありません。ただ、次からは文中にそれもわかりにくい形で署名すらせずにツッコミを入れることは避けていただければと思います。面倒でも引用して文末に追加してゆく形などでお願いします。

さて、フレームバッファを読み出すことができない場合に受ける機能の制限ですが、これが何を意味するか、まだ理解できませんか？

ラスタライズの際、ピクセル単位で書き込みをする際、通常のピクセルであれば上書きしてしまって構いませんね。フレームバッファを読み出す必要はありません。 では透過処理をする場合は、どうなるでしょう。

上から書き込まれるピクセルの色はパターンテーブルから引いてくれば良いので、透過無しのレンダリング処理と変わりません。しかし透過処理の場合は、その下のピクセル色を読み出す必要があります。 そしてここで色演算のために読み出すべき色情報は、VDP1が読み出すことのできないフレームバッファに描かかれている、というわけです。

結果的にVDP1では、スプライトやポリゴン同士の半透明処理は、その構造上できません。そのためにメッシュ処理が代用されたのです。 作品によっては、偶数メッシュと奇数メッシュを1フレーム毎に切り替えることで、プレイヤーの視覚（残像）を利用した、擬似半透明とも言える泥縄的な処理まで行っているものもありました。

嘘をつくな、一部の作品では実際に半透明ポリゴンを描いているじゃないか、という突っ込みも想定内です。これは該当する領域をVDP1側で背景ヌキとして描画した上で、半透明ポリゴンのみをVDP2側に描画して処理しています。 VDP2側では、VDP1のフレームバッファを読み出して色情報を適用することで、VDP1の出力に対して色演算を行うことが可能です。ひらたく言えば、スプライトとBGの間では透過処理が可能ということです。これを応用した力技ですね。

サターンでは、そこまでやらなければ半透明処理ができなかったのですよ。

210.149.190.140 2006年1月20日 (金) 21:00 (UTC)[返信]

わかりにくい形での記述申し訳ない。私は常に差分を用いて読んでいたため、途中の書き込みも把握できたため他の方もそうだとばかり思っていました。しかし差分は便利ですよ。お勧めです。

私は昨年にネットに落ちているVDP1, VDP2のユーザーズマニュアル, SGLの両マニュアル, その他様々な資料を落として精読しているところです。かなりの分量ですが、様々なことがわかってきています。

まず、VDP1の半透明についてですが、half-transparencyやshadow, half-luminanceなどの処理に使うColor Calcuration Bitsについて各所で説明されています。その中でもVDP1マニュアルのP.95にはわかりやすく各ファンクションのback ground (pixel data already drawn in the frame buffer)との演算が表化されています。当然すでに書いたピクセルとの演算をするためにはframe bufferからのリードが必要になりますしそう書かれています。そもそもVDP2側での演算だけならColor Calcuration BitsなどいらずにColorのMSBだけ使えばいいのでは？

ではなぜ半透明が実質使えないかというと、いきなりP.8にありますが、変形スプライトやポリゴンなど四角から形が変形したものは、穴が開かないようにするためVDP1内部で多重化して描画するようです。そのためポリゴン内の一部が複数回描画される。つまり半透明を変形したポリゴンやスプライトに用いたらあるピクセルに意図せずに複数回書いてしまい、その部分だけ透明度が下がってしまう。そのためポリゴンの表面にひび割れのようなスジが入ってしまうんでしょう。当然見苦しいので実質使用不可になるということです。つまり半透明処理自体は可能と。 ここまではマニュアルに書かれていることですが、なぜ穴が開くラスタライズなのか、なぜそれを埋める処理が（ハード内に）必要なのかは、P.10のFigure 1.7から類推できます。すなわちVDP1のラスタライズはスキャンラインコンバージョンではなく、ラインルーチンを用いてポリゴン内部を埋めているようです。そのためラインとラインの間の隙間ができ、それを埋めるようにAnti-aliasing（通常言うアンチエリアシングではなく、このマニュアルではピクセルの穴埋め処理を指している）という処理を行っています。これが半透明が限定的である元凶です。

ここまでしっかり書かれていて、実はframe bufferのリードがないなどとなったら上述のような現象は全てありえず、それらマニュアルに記載された説明は全てうそということになってしまうんですが。workaroundはメッシュやVDP2使用でいいのでしょうが、なぜ理由がframe bufferのリードができないという認識になっているのかが不思議です。逆にそのような記述はどこにもないわけで。ひょっとしてbackgroundという用語がVDP2にあるBG面と勘違いさせましたか？しかしちゃんと色々な所にbackground is written to the frame bufferとかBackground:pixel data already drawn in the frame bufferなどと書かれていますよ。--ちぇす 2006年1月21日 (土) 05:19 (UTC)[返信]

差分で追うのも結構ですが、ノートとして参照できなくなる（意味が通らなくなる）形での編集には同意できません。

また流出した資料の出所や信憑性についても何ともコメントできませんが、自分が当時参照した資料は、その殆どが日本語のものでしたけどねえ…。

直線補完の誤差によってポリゴンやテクスチャに穴が空いたり筋ができるという問題も、開発初期のターゲットボックスがまだ巨大な箱だった頃の話ですね。実際に仕様が確定し製品の開発が始まってからは、VDP1が出力したフレームバッファ出力に対してVDP2側で処理をする(VDP1側のフレームバッファの出力をVDP2側でBGプレーンの間の自由な位置に設定し、VDP2側の1プレーンとの間で色演算が可能)というものでした。 210.149.190.140 2006年1月21日 (土) 23:02 (UTC)[返信]

取得した資料がUSからのものなので、あちら向けに翻訳したものと思われます。またこのUsers Manualは修正履歴が1994年になっているのでいくらなんでも最終仕様でしょう。上述のVDP1出力のフレームバッファデータをVDP2でマージする機能も当然VDP2のマニュアルに記載されています。上述の穴が開くバグを解決するためにAnti-aliasing（この資料では穴埋め処理を指す）を導入したことは自明でしょう。ちなみにあなたも認めているスジになる現象は、不透明だと原理上スジはできないので必然的に半透明のVDP1内部演算を指すため、frame bufferを読めなければならないのですが、この因果関係はどういたしましょう。そもそも上述のVDP2云々は単なるソフト上のworkaroundの説明であって、結局ターゲットボックスからマスプロへの移行の際の仕様変更（があったとして）を説明していないのですが。

半透明が使えないのが、スジによるものなのかLookup Tableモードだからなのか、frame bufferリードができないからなのか、その他の理由によるものなのか、どの理由でもVDP2使って半透明しようとするでしょう。いくらVDP2での方法を説明してもframe bufferリードができないことの説明にはならないのです。例えばColor Calcuration Bitsの使い方などどうなったのでしょうか。--ちぇす 2006年1月22日 (日) 01:43 (UTC)[返信]

とりあえず次はSH-2でのジオメトリ演算についてです。

>…というよりも、FPUが無ければ整数演算で近似するより他に方法が無いのですよ。そんなことはパソコンでもゲーム機でも、乗算命令すら持たない8bit機や16bit機ですら当たり前にやってきている。当時のプレイステーションでさえもGTEでは固定小数点を用いていたくらいですし、R3000が持つのもSHと同様に整数演算命令のみです。双方ともFPUもMMUも持たない、素朴な32bitプロセッサでしかありません。

>構造体ごとGPUに丸投げして当たり前に32bit floatで処理してもらえる現在の感覚では、にわかに想像することは困難かもしれませんが、同時代にSHの整数演算能力が他の32bitプロセッサの水準と比較して殊更強調すべき機能や特性を持っていたかのような書き方は、到底了解することはできません。

確かに乗算器や除算器（SH-2に除算器は搭載されています）は安価なマイコンと言えども特別のものではなくなりつつある時期でしたね。ただ「SH-2は制御用マイコンではあるが乗算器や除算器を備え、高度な数値計算にも対応可能であるため、ポリゴンのジオメトリ計算などに用いることができる。」が元文ですが、他の32bit CPUと比較してるわけでなし、少なくとも実際セガサターンでジオメトリ計算をSH-2で行っているならそのことを掲載しても問題はないのでは。「高度な」が問題ならそれを外して掲載するのはどうでしょう。

>それと蛇足ですが、SH2に整数同士の乗算はありましたが、除算はどうでしたかね。現在手元に詳細な資料が無いため断言は避けますが。また制御用「マイコン」という、時代感を読み誤っているかのような単語の選び方も、自分には気になります。

これは、いにしえのマイコン（３）を想像されていますか？通常組み込みの世界でのマイコン（２）はマイクロコントローラの略であり、現在でも使われている結構メジャーな用語です。wikipediaを見たり「東芝　マイコン」とか「日立　マイコン」でググってみたりするとわかると思いますが、マイコンの特徴は汎用CPUと比較し、非常に安価で周辺ユニットが充実しているなどがあり、汎用向けCPUとはまた違った世界を構築しています。そもそもCPUコアはマイコンの（メインではあるが）一部のユニットの位置付けです。そしてSH-2は本来その世界の範疇にいます。本当は１個数万円のWSやPCの石と１個千円程度のマイコンチップを比べてはほしくないんですけどねぇ。--ちぇす 2006年1月23日 (月) 16:53 (UTC)[返信]

苦しくなるとその度に話題を変えてくるというのも、何とかしてもらいたいところですねえ。

「マイコンという単語」が現在もニッチで使われているという事情は理解できましたが、一般的な文脈としては32bitマイクロプロセッサとして記述すべきだと思いますよ。

それと、同時代の水準で専用のベクトルエンジンやジオメトリエンジンを搭載しないアーキテクチャでCPUがそれらの演算を(場合によっては整数で)行うことを、強調するほど特殊な状態だとは到底思えないのですが、殊更に強調しなければならないほどの事情が何かありますか？

例えばSuper32XもSH2を2基搭載しており、32XではジオメトリのみならずポリゴンのラスタライズまでCPUが全て行っているわけですが（というか32XはSH2とフレームバッファ、音源が乗っているだけで、基本的に全ての処理をCPUが行うというシンプルなアーキテクチャです）、これは同時代のPCやローエンドのワークステーション等でも当たり前の構造です。 210.149.190.140 2006年1月26日 (木) 20:36 (UTC)[返信]

私ちぇすは2006年1月27日に編集時の容量制限緩和のため、このノートに節分けを行いましたが、その際に他の方の文章を分断したり、わかりにくい構成とするなど問題となる編集を行ってしまいました。深くお詫びをし、また各人の議論がスムーズにできるようにその構成を元に戻したいと思います。

この整理方法（差戻しと整理前の文章の掲載方法）はWikipedia:査読依頼/セガサターン 20060131で議論し、取り敢えずの方法として実行しますが、問題があると思われる方はこの節の終わりにご意見を追加してください。

次の議論を行う方は是非とも別の節を作成してから続けて下さい。

整理に際し、問題の節分けから整理前の間に記述した文章の辻褄が合わなくなりますが、ご容赦ください。ただし節分け後はセガサターン本文に関する記述はなく、主に節分けの編集方法に関する意見ですので、その編集方法を整理する今回の変更にはご了承いただけると思います。節分けから整理前の間の文章は下記に段を下げて掲載しますが、整理前のノートを閲覧されたい方は、2006年2月17日 (金) 00:35 の版をご参照下さい。--ちぇす 2006年2月19日 (日) 08:54 (UTC)[返信]

節付けから整理前の間の記述

ちぇす氏にまた返答を頂いているようですが、何処にどのように追加されたのかが極めて把握し辛く、このような編集は勘弁してもらいたいところです。以前にも指摘しましたが、少なくともノートとして頭から何の先入観もなく読んで行ったとき、議論や意見交換の流れが把握できなくなる形での編集には同意できません。またそのように読んだとき、相手の文章に介入する形で署名もなにもない文章を追加する編集にも強く反対します。ノートは意見の調整や交換に使用すべき場であって、他者の文章を改変してよい（一連の文章として意見や提示を述べ終わる前に介入してよい）場所ではないと考えるからです。意見の調整としての対話を試みる以上は、両者の意思の疎通が可能な形で行われる必要があるし、またその様子を第三者が見て把握できなければならない。ちぇす氏の編集スタイルでは、そのどちらの点にも大きな問題がある。

それらを踏まえた上で申し訳ない事ですが、このような独創的な形式で意見や質問を追加されても、既に書かれた文章の中から改変された個所を見つけだし、整理して返答する労力を割くことに意味を見出せない。はっきりと言わせてもらえば、あなたの身勝手なスタイルに私がここまで付き合わされ、振り回されなければならない合理的な理由を見出すことができない、ということです。

ちぇす氏には、この混沌としてしまったノートの正常化と整理を要求します。またノート、本ページを問わず、私の記述した文章の中に勝手な節を書き加えたり、位置を編集することも即刻止めて頂きたい。

少なくともこれらの異常な事態が正常化がなされるまでは、本論においてちぇす氏に返答する意思はなく、またちぇす氏によるセガサターン本ページへの改変や加筆にも反対します。210.149.190.138 2006年1月31日 (火) 00:00 (UTC)[返信]

• このまま、論争の解決の目途が立たないと、本文の編集合戦にも陥りかねないと判断して、勝手ながらWikipedia:査読依頼をして、第三者のご意見を仰ぐことにしました。--210.196.189.19 2006年1月31日 (火) 00:25 (UTC)[返信]

今回、混乱をきたしてしまって申し訳ありませんが、理由は上述に書き、なおかつ最終段にその場所へのリンクも張りました。再度その理由を書けば、編集時に32kBを超えたため節分けをせよとのメッセージが出たため、それに従い節分けをしただけです。またその際それに問題があればrevertして欲しい旨も書き添えました。

何度も編集を繰り返したように見えるのは、節分けの際、投稿した時にエラーが出て（エラーメッセージまでは記録していませんでしたが）投稿がダメになったように見え、再投稿を繰り返してしまったこと。それが実は全て有効だったことが後で判明したことから、複数投稿のような形になってしまいました。もしそれが混乱の原因になったのであれば申し訳なく思います。

査読依頼をされたとのことで、その結果を待とうと思いますが、私も今回はメッセージに従っただけで、別に編集形態にはこだわりませんので、上述したようにrevertすることで解決するのではないかと思います。--ちぇす 2006年1月31日 (火) 00:58 (UTC)[返信]

と思ったら査読依頼は、節分けに関してではなく、意見対立に関するものだったのですね。一応両者ともノートでの議論が継続している間は本文の編集は控えているものと認識していましたが。本文を充実させるため事実を浮き彫りにするためには、時にはある程度の掘り下げた議論も必要な場合があると思われますが、それを失うことなく議論として完結させることを望みます。また査読依頼の目的が批評の項目への反映であることから、これを待つということはせず、とりあえず節分けに関しては上述でも述べたrevertでの事態収拾でよいかの意見を待ち、反対意見がなければ2006年1月27日 (金) 05:36の版に差し戻し、そこから意見を継続していこうかと思います。また32kB制限についてはまだ編集が可能なようなので、編集が本格的にできなくなったら考えましょうか。--ちぇす 2006年1月31日 (火) 01:58 (UTC)[返信]

セガサターン本項に対する編集、削除のため、議論が中座して結論が出ていないものも含めて疑問点を整理しようと思います。

VDP1で半透明は不可能か否か、またその理由が疑問点として現在「VDP1から見てパターン（テクスチャ）バッファは読み出し専用、フレームバッファは書き込み専用となっていたため、フレームバッファ上の色情報をパターンに適用して色演算する必要のある半透明処理にも著しい制約がつく」という文をを削除した状態です。これに対し210.149.190.1??氏から異議が出ています。また上述の著しい制約とは、VDP1には半透明機能は存在せず、VDP2を用いた回避策により対応したとのことです。私の方ではネットに流出しているVDP1のマニュアルを入手し、VDP1の半透明機能の存在と別理由（半透明描画時におけるアルゴリズム）による制約を理解しました。特にこのマニュアルは流出資料であり出所が明確ではないため、セガサターン本項にこの理由を記述することは控え、上述の文を削除することに留めました。--ちぇす 2006年3月5日 (日) 16:50 (UTC)[返信]

GAME BASIC for SEGASATURN(以下GBSS)で半透明について確認ができるとの情報を得ましたので試したところ、やはりVDP1のポリゴンにおける半透明はできること、また上述の推測のような歪んだポリゴンによるスジ現象を確認しました。GBSSのリファレンスマニュアルにもありますが、SETATR命令のMODE項bit0,1がVDP1マニュアルのcolor calculation bitsに対応しており、VDP1の半透明機能をオンにします。ちなみにこれら命令の内部フォーマットはプロアクションリプレイとPCインタフェースによる内部データの確認により、VDP1のマニュアル通りである事も確認しました。従ってGBSSがVDP2を用いた複雑な手順による半透明代替処理を行っていないことを確認済みです。

以上より従来の「フレームバッファは書き込み専用」の削除は正しかったことと、より正確な記述に関しては再検討ということになります。--ちぇす 2006年4月2日 (日) 06:21 (UTC)[返信]

今回の経験により、当事者もしくは制作現場に関わったと称する人物からの情報だからといって、検証不可能な情報を掲載することは危険であるとの教訓が得られたと思います（今回は幸いにも検証できましたが）。やはりちゃんと裏を取る努力、疑問点を提示していく姿勢をとるべきでしょう。--ちぇす 2006年4月2日 (日) 06:21 (UTC)[返信]

「二基のVDPは16bit幅のデータバスによって接続されており、このバスの帯域によって実質的にVDP1側のフィルレートが律速され」も現在は削除状態にあります。VDP1とVDP2、SCUを結ぶ16bitのバスはありますが、VDP1とVDP2でやり取りするデータはフレームバッファ１枚分であり、またSCUから送られるデータもディスプレイリストやテクスチャデータであって正確にはフィルレートとは異なります。フィルレートに関連するのはVDP1に接続されたフレームバッファのみと取ることができます（前述の資料とサターン実基板の解析による）。従ってこの文の前提に疑問が持たれ、削除しています。--ちぇす 2006年3月5日 (日) 16:50 (UTC)[返信]

「サターンに採用された当時はその実績も特に知名度の点では劣ること、競合機のCPUは押し並べてワークステーションなどに搭載されていたCPUアーキテクチャを採用していた事などから、性能にも疑問の声が少なくなかった」の文ですが、この疑問の声が誰（どういった集団）を指しているのかがわかりません。制作の人たちであれば、ターゲットボックスがあるため性能の検証は可能であり、疑問は出にくいと考えられます。そう言う方々は定量的データを持っているため、WSに載っているからといったような定性的な判断をする必要がないためです。また一般ユーザであればSHどころかARMやMIPSも知らない人が殆どと思われ、それも対象から外れると思います。となると残りは次世代機競争に興味があり（もしくは職務とし）、WSや組込み系CPUをよく知っていて、尚かつ開発環境がない人もしくは期間となり、非常に限定された集団と思えてきます。もしそのような特定母集団だとすればその声が少なくなかったという判断基準や、またどうやってその声を吸い上げたのかにも疑問が残りますが、いかがでしょうか。--ちぇす 2006年3月31日 (金) 22:35 (UTC)[返信]

06/04/09に修正しました。--ちぇす 2006年4月14日 (金) 15:31 (UTC)[返信]

「一方、SDRAMは当時まだ高価であり、サターン発売後もしばらく価格が高止まりを続けたため、製造コストを押し上げ、後の本体の値下げ競争においてコストダウンを困難とする要素の一つとなった。」の文ですが、確かに発売当初 (1995年など) は通常のDRAMに比べ値段も高かったと記憶していますが、1996年頃になるとEDRAMからSDRAMへの移行期で、大口顧客に対してはEDRAMなどとも遜色ない値付けをしていたと思いましたが。DRAMベンダがセガにどのような値段の提示をしていたかはわかりませんが、値下げ競争の真っ只中を96～97年とするとこの文の正確性に疑問が持たれます。従ってこの文を継続するためには、相応の出典、資料が必要でしょう。--ちぇす 2006年4月14日 (金) 15:31 (UTC)[返信]

Mein Name ist Hase und ich weiss von nichts.

全てのリンクがページ下部の「外部リンク」の節にある「セガハード大百科 セガサターン」のリンク先の下位URLばかりです。たしか、本来あまり記事本文内には外部リンクを設けるべきではないはずです、外部リンクとしてルートへのリンクがちゃんとあるのですから一々全部をリンクさせる必要は無いでしょう。--61.201.116.253 2007年1月11日 (木) 18:41 (UTC)[返信]

「あまり記事本文内には外部リンクを設けるべきではない」という規約は知りませんでした。よろしければWikipediaの指針やルール、もしくは他所での議論等があるのでしたらお教えいただければと思います。

個人的にはルートへのリンクより目的のページへ直接リンクされた方が便利と思いますがいかがでしょうか。

あとこの節とは関係がありませんが、セガサターン互換機の節で箇条書きの書式が他の節と異なっており、いつも一緒にリバートされているようですが、なにか意図がおありでしょうか。--ちぇす 2007年1月12日 (金) 00:09 (UTC)[返信]

単なる箇条書きではなく、名前と説明とが交互に来るようなものをウィキペディアでは「定義の箇条書き」と呼びまして、それには推奨される記述法があるのです。Wikipedia:編集の仕方#箇条書きやWikipedia:箇条書きのマークアップ#定義の箇条書きなどに詳しいので、それらを参照してください。
また外部リンクを本文内に多く設けない事については、どこで見たかは忘れました。たしか記事のメンテの手間かなにかのためだったと思われます、外部のサイトは例え公式サイトであってもアドレスが変更になったり、消滅したりという事がいくらでもありますので。たいていの項目で外部リンクという節をわざわざ作って一箇所にまとめているのはそう言う理由からでしょう。Wikipedia:外部リンクの選び方#基本的な考え方なども見てみてください、「5. 外部リンクは最小限度にとどめること。」となっていますから。--61.201.159.66 2007年1月12日 (金) 14:43 (UTC)[返信]

ご説明ありがとうございます。定義の箇条書きに関してはよくわかりました。逆に他を（例えばCPUやVDPなど）変更しなければならなそうですね。

外部リンクの件に関してはまだちょっと納得できかねる部分もあります。例えば「5. 外部リンクは最小限度にとどめること。」の意味は冗長性を排除する、つまり同じような情報を掲載しているリンクを複数記述するなという意味とも取れますし、こういった場合に適用できるのか不明です。これらリンクは記事の内容を補完していますし、Wikipediaでは載せづらい版権系の写真も多用できます。アーカイブ扱いのページなので将来の継続性も満足できると言えます。他の外部リンクと異なり条件的には結構都合がよく、他項目が消極的だからこれらも削除というのはちょっともったいなく、またユーザビリティが低いかなと。

問題点が「5. 外部リンクは最小限度にとどめること。」の解釈のみであるなら、Wikipedia‐ノート:外部リンクの選び方で聞いてみることで解決するかなと思いますがいかがでしょう。--ちぇす 2007年1月13日 (土) 09:06 (UTC)[返信]

私は、「最小限」というのは文字通り最も小さい状態を指すわけですから、何か一つだけの視点ではなく、解釈しうるあらゆる角度から、なるべくリンクが少なくすむようにするべきなのだと思ってます。別にユーザビリティのために何でもすべきというわけではありませんし、そもそも有用と思しき情報があるならば（著作権に反しない形で）ウィキペディアの記事内にその情報を持ってくるように努力するのが本分じゃないでしょうか、いかに近年ディープリンクが許容されがちになってきたとはいえ、いささか度をこし過ぎにも見えますし。と言っても、もちろんそんな質問なんかおよしなさいと言うわけではありませんけども。--61.201.159.66 2007年1月15日 (月) 08:37 (UTC)[返信]

ref name文を使うことでリンクだらけになる問題を解決しました。--126.141.217.225 2019年5月16日 (木) 05:17 (UTC)[返信]

ノート:ネオジオポケットでも同様の事を話題にしましたし、ここの記事の要約欄にも以前書いたのですが、「セガサターンのゲームタイトル一覧」と「Category:セガサターン用ソフト」とは代表的作品の節からTemplate:Mainを使ってリンクさせる必要は無いでしょう、関連項目の節からのリンクで充分なはずです。それを何度もテンプレート使用の形式に戻すなら、ちゃんと要約欄やノートでそうする事の理由や必要性を説明してからにしてもらいたいのですが。--61.201.116.253 2007年1月11日 (木) 18:41 (UTC)[返信]

えー・・・、それらはuser:影武者のソックスパペットの仕業だと思います。相手をするのも流石に疲れてきました・・・。--NORN 2007年1月12日 (金) 01:10 (UTC)[返信]

疲れるのもそうですが、編集合戦になってしまいますしね…それに相手は3rrを全く恐れていないので、同じ調子でリバートするとこちらもそれに触れてしまいそうでどうしたものか。相手が明確な荒らしの場合はこのルールに抵触しないはずではありますが…（それに触れる触れないに関わらず、編集合戦はリソースの無駄ですしねぇ～…）。--61.201.159.66 2007年1月12日 (金) 21:05 (UTC)[返信]

だいぶ前からここやドリームキャストなどで編集合戦が続いているようですが、この行為自体に問題があるし、このようなことで保護になるのは避けたいので止めてください。
スタイルに関して言えば双方とも間違ってはいないようです。Wikipedia:表記ガイド#括弧類では「括弧類は、原則としていわゆる全角のものを用いる。括弧内がアルファベット・数字だけの場合は、いわゆる半角の () {} [] "" 等をつかってもよい。その際には括弧の外側に半角空白をいれる。」となっており、またWikipedia:日本語環境#全角と半角の使い分けでは一応今回のような場合は半角とありますが、一応議論の結果まとまりつつあるルール扱いであり、まだ議論途上です。編集合戦になる理由に乏しい。また改行を入れないことともありますが、「段落の途中で」と限定されており、また段落の前後の改行が不利益となる理由は書かれていません。つまりどちらでもいいということになります。節名の周りにスペースを入れる／入れないなど瑣末すぎです。
それよりも内容が変わっている部分（ファイターズメガミックスの削除、2度あることはサンドア～ルの削除など）が気になります。現状ではスタイルが理由によるリバートのついでになくなっているのか、削除理由があるのかわかりません。内容を削除するのであればできれば削除前にノートでの議論が欲しいところですし、せめて要約欄に理由を明記すべきです。でなければなぜ削除されているのかわかりません。--ちぇす 2007年2月12日 (月) 23:18 (UTC)[返信]

またぞろWikipedia:編集合戦が盛んになっていますが、主たる内容も

• 箇条書きや節名の前後などにスペースを入れる/入れない
• 画像名にアンダーバーを入れる/入れない
• 英字の前後の括弧が全角/半角
• 段落の最後に改行を入れる/入れない

など非常に瑣末です。これ以上続くようですとWikipedia:編集合戦に則りWikipedia:保護依頼もしくはWikipedia:投稿ブロックの必要が生じてきます。ドリームキャストやXBOX 360など他の項目も同様です。各自ご自重ください。--ちぇす 2007年2月20日 (火) 16:47 (UTC)[返信]

外部リンクの節に個人サイトが存在します。特に現在掲載されているサイトは独自の実験に基づいたノウハウを記述しているサイトで、WP:NOR特にWP:NOR#信頼できる資料に反します。WP:Vの観点からも明らかにWikipediaに掲載するに相応しくないサイトであるため、この記事の存続には相応の理由が求められます。それが記入されない限りWP:NOR、WP:Vに則り削除せざるを得ません。--ちぇす 2007年6月10日 (日) 20:51 (UTC)[返信]

テンプレート「未検証」「出典の明記」「独自研究」の使い分けについて意見のすりあわせを行い、ある程度の統一見解を作りたいと思います。

ご意見をお持ちの方はTemplate‐ノート:Unreferenced/テンプレート「未検証」「出典の明記」「独自研究」の使い分けまで。 Penpen 2007年6月22日 (金) 23:45 (UTC)[返信]

最近出典のない記載が大幅に削除されていますので皆さんにご連絡しておきます[1]。出典がないと言っても、要出典タグが付けられてわずか1週間しかありません。編集合戦は避けたいところですので、もし皆さんが出典を明記した上で復活させていただけるのでしたら大変助かります。ご協力よろしくお願いします。--Uiweo 2010年7月22日 (木) 08:31 (UTC)[返信]

1週間で除去は早すぎでしょう。確かに出典を明示することは重要ですが、((要出典))は記述を除去する口実にするためのものではないと考えます。このような編集を望むのであれば、まずノートに意見表明をしたり、意見が集まらなければWikipedia:コメント依頼に呼びかるなどの手を尽くした上で、それでも出典が提示されないのであれば、最終手段として除去を考えるべきではないでしょうか。--けいちゃ 2010年7月23日 (金) 14:03 (UTC)[返信]

削除したのは私ではありませんので削除した人に言ってもらえますでしょうか？　私は今回の件について非常に遺憾に思っております。--Uiweo 2010年7月23日 (金) 21:09 (UTC)[返信]

えーとですね、ですからその除去したことについて意見を述べているんですが・・・。--けいちゃ 2010年7月24日 (土) 01:56 (UTC)[返信]

はじめまして。私は主に他機種の関連記事を執筆しておりますが、その記事に妙な編集傾向（他機種を揶揄するような不自然な内容）があり、他社の記事に痕跡が無いかチェックしています。この記事では既に要出典タグが張られていますが、該当すると思われる内容を見つけましたのでご報告します。

• この編集と同時期に匿名掲示板で投稿された未検証の内容に酷似している問題の投稿

ただしこれはPC-FXに関連する話題であり、匿名掲示板上でも情報源が特定できていない内容です。投稿時期がほぼ一緒で、なぜサターンのものとして書かれているのか分かりませんが、内容については検証が必要でしょう。--Kaonohito（会話） 2016年1月17日 (日) 06:18 (UTC)[返信]

「セガサターンに搭載するに当たり、オリジナルのSH-2からいくつかの機能強化が行われている」という記述に続いて動作周波数の向上や除算器の搭載・・・などの説明があり、それらの特徴がないオリジナルのSH2が存在しているかのような記述になっています。このテキストを継続するためにはこれら機能強化がないオリジナルのSH2が存在するという出典が必要です。--240D:1A:F7:5600:E8B8:2D3A:A75F:31D3 2021年4月22日 (木) 01:13 (UTC)[返信]