オブジェクト指向を教えてくれ！
レス数が950を超えています。1000を超えると書き込みができなくなります。
オブジェクト指向について、調べれば調べるほど疑問が募ります。低レベルで粗末な疑問かも知れませんが、ご教授願いたいです。
・データと振る舞いをまとめる？
まとめると何か良いことあるの？
ファイルあるいはモジュールにはまとまってるよね？
丁度いい単位があるのに、何故わざわざオブジェクトという概念を導入するの？
(Javaには1ファイル1クラスという文化あるらしいけど)
・カプセル化？
モジュールのimport, exportでも実現出来るよね？
(構造体などへのアクセスを制限できれば)
・ポリモーフィズム？
別にデータと振る舞いをまとめなくても実現出来るよね？
・モノのように扱いたい？
モノとして扱いたいときに扱えば良くない？ なんでわざわざ全てをオブジェクトにするの？ なら何もID変えるほどビビることもないだろ？
自信があるならどうぞ続けてください おっとIDの話にすり替えようとしても、お前の反論がないというこの状況に変化はないぞｗ いいよ、今は反論がないということで
だから続けなよ >>844
なるほど、自分でイベントを発生させたことがないんだね
それでイベントドリブンを語るのはStateパターンすら知らずにオブジェクト指向語るのと同レベルだわ
ゲーム脳に比べると君のほうが常識人に感じてたが
視野狭窄という意味でやっぱりゲーム脳とどんぐりだな
レスバする理由がよくわかった > なるほど、自分でイベントを発生させたことがないんだね
なぜゲームではイベントを使わずに
ポーリングでボタンの状態を検出するというだけの話から
そんな発想が出てくるんだろうか？
意味わからんよねｗ 印刷中は電源オフ要求があったら下の領域でラッチして覚えておき、印刷が終わったところでラッチを調べ、
電源オフ要求があったならば、電源オフ処理を始める。
このように、何かをやっている最中に、何かが起きることを覚えておきたい、というときに、直交合成状態を使うことができる。
この形のことを Latch State (ラッチステート)パターンと言う。リアルタイムUMLワークショップという本の中で、ブルースダグラスさんが命名している。
https://qiita.com/saltheads/items/abd039ec2df18bdd7995
839 デフォルトの名無しさん sage 2021/04/13(火) 11:03:47.18 ID:3qmwHhLR
業務用システムでもいろんなわけわからん条件に応じて
いろんなコントロールが友好になったり無効になったりするときに
Stateパターンでスッキリするときはあるぞ
Stateパターン使うというより
ステートマシンが必要なら作るという
それだけの話だが >>857
視野搾取と言うけど俺は別にそう言った作り方をしていないものを否定はしていないよ
常に追加に対しては開いていて変更に対しては閉じているのだ >>859
正直リンク先見たとき英語で記載されてて
俺じじいだし英語読めないし
DEEPLE先生で翻訳しても訳分からないし
Stateパターンって名前がついているのは知らなかったけど、
クラス図見たとき「ああ、あのアレか」と思うほど結構使われてるやつだったよ
ま、そう言うとまたゲーム脳って言われるんだろうけど データベースとオブジェクト指向の間には溝があります。インピーダンスミスマッチと呼ばれていますが、
ゲームを構築する際にも、インピーダンスミスマッチが生じています。
ゲーム世界をプログラムコードに落とす上で、継承という仕組みは貧弱すぎるのです。
https://qiita.com/tshinsay/items/739ad875cc3925d51f12
一般的なゲームプログラミングで使われるオブジェクト指向は、サブクラスではなくインナークラスのほう。
オブジェクト指向は要らないという意見もあるが、サブクラスについては人工知能に活用したいところ。
例えばクリントン大統領はチンポ【が】シコシコしてしまったのが『不適切な関係』だったとか。
1 インナークラス(オシッコをするときのチンポ)
ネットワーク、メッセージング、イベントドリブン、同期処理・・・
2 サブクラス(勃起・射精するときのチンポ)
自然言語処理、人工知能・・・ こういう場合は、サブクラスとして『ひげそり機を使っている状態のFred』を再定義するしかないかも。
829 デフォルトの名無しさん 2018/11/11(日) 09:52:59.70 ID:y84pWKv0
（第1章 はじめに 2頁）
たとえば、CycはFredという名前の男が朝にひげをそるという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には電気の部品がないことは知っているが、
Fredが電気カミソリを持っていたので、エンティティ「Fredがひげそり中(FredWhileShaving)」
には電気の部品が含まれていると考えた。したがって、CycはFredがひげをそっている間、
Fredはそれでも人間なのかと尋ねた。
『深層学習』
著者:
Ian Goodfellow, イアングッドフェロー,
Yoshua Bengio, ヨシュアベンジオ,
Aaron Courville, アーロンカービル
一般的なアプリやゲームやプリンターにおいては『状態』そのものをオブジェクトには出来ないが、
>>626
> 乗っ取られるという状態変化を起こしたクリントンがシコっていることに変わりはない
人工知能とか自然言語処理なら、シコシコしたチンポにクリントンがシコられたと解釈したいところ。
250 デフォルトの名無しさん sage 2021/03/21(日) 16:00:54.94 ID:rWfpUSZ4
状態をオブジェクトにするな
は昔からよく言われている
「ボタンを押している状態」
をクラスにしてしまうと
プログラムが無茶無茶になる
「モノ」をオブジェクトにする
これがオブジェクト指向の本質 このスレでゲーム脳って言われてる人って
アーケードか家庭用ゲーム機で作ってたりするん？
老舗あるいは有名メーカーだったりするん？ メッセージループでメッセージを受け取る->処理する
送り側はメッセージキューに送る
すべてそれで理解できる
何年も何にも変わってない >>864
それは答えられないなぁ
なんで答えられないのかも答えられない >>865
Windows 3.1や95の初期あたりの頃とかはそうだった
プログラマがウインドウメッセージを直接処理していた
今はそういったものはライブラリが処理し
アプリケーションプログラマから見るとウインドウメッセージは
イベントとして受け取る形でプログラミングできるようになってる
時代は変わってるんだよ >>868
95の初期とか、、、MFCなんて使わないしWindowsXPくらいまでは普通にメッセージ処理してたわいw さて、仕事も終わったことだし
昼頃に言い淀んだことの説明をするか
実はカタワ指向君に反論ではなく>>842に
苦情をいいたかったんだ
カタワ指向君の後にレスしたからカタワ指向が自分のことと思って俺にレスしてきたから
悪いとは思ったけどちょっと面白くなって濁らしたんだ。すまんな、俺は人格破綻者なんだ。
さて
>>842
＞>>679のゲーム脳の例でも
＞〜の場合はボタン押しっぱなし、〜場合はボタン立ち上がり、〜場合はボタン立ち下がり
＞というイベントに変換してるじゃん
いつ俺がイベントに変換しているなんて言ったよ
変に曲解して俺が変なことを言ったように風潮するのは止めて頂きたい
そっちがイベント作成して飛ばすのは勝手だがな。 >>869
> 95の初期とか、、、MFCなんて使わないしWindowsXPくらいまでは普通にメッセージ処理してたわいw
それはお前が選択したものの話であって、Delphi、C++Builder、VB、Javaなんでもありました。
その頃になればC#も登場してますね >>871
それはお前にも言えることだぞ
身近な環境だけがすべてではないことを学ぼう >>225
開発あるあるだなw
そうか、確かにVBAだと後ろが伸びるだけになるかも知れないね。
他のある程度大きいシステムになると
・客先から上がって来ない要件定義
・客先だから強く言えないチームのリーダー
・差し迫る納期
・焦りが出てきてイラつく俺ら。それを宥めるリーダー
この辺からが違うところかな
・システム間の連携や他システムとの連携のため伸ばせない納期
・更に焦る俺ら。宥めきれなくなるリーダー
・上がって来る要件定義、血眼で設計書を作る俺ら
・時間がなくて客先との対面レビューのはずが回覧レビューになる設計書
・PGしながら単体テストケース作りながら単位テストしながらエビデンス取る俺ら
・超える納期、無くなる休日、伸びまくる勤務時間、倒れる仲間
・覆る要件定義、設計種ミス発覚、他の嶋から助っ人入るも焼石に水、発狂する助っ人
・何とかSTまで終了。飛ばされるリーダー、バグだらけの成果物、昇天する俺ら
最悪こんな感じかな。 >>872
だからゲームでボタンを状態にする例をだしたのち
それは例外だって話をしてるだろ
こっちは知った上で話しをしてるんだよ 訂正
だからゲームでボタンの状態をクラスにする例をだしたのち 話を戻すが、「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ にしても
>>250
＞状態をオブジェクトにするな
＞は昔からよく言われている
＞「ボタンを押している状態」
＞をクラスにしてしまうと
＞プログラムが無茶無茶になる
＞「モノ」をオブジェクトにする
＞これがオブジェクト指向の本質
これが未だに釈然としない
もうゲーム脳認定されてるから遠慮なくそっちの話で書くけど
正直、ボタンの状態をイベントで取ろうが
ポーリングで取ろうがCやC++で直接I/Oポートアドレスの値読みに行こうがそんなことはどうでもいい。
キチンと処理に同期してボタン状態が取得出来れば手段はこの話の本質とは関係ない。
以前、イベントでボタンの立ち上がりやキーの立ち下がりは取得出来るから必要ないとの意見もあったけど、
格闘ゲームなどではコマンド入力の判断を行うため、ある程度の期間ボタンの状態をどこぞに格納するのはザラ。
それがエンティティのクラスだからって何故プログラムが滅茶苦茶になるのか理解出来ない。
一般業務になるとどのような制限を受けるのか分からんけど、
処理は無駄になるかも知れないけど、無茶苦茶になるとは思えない。
Object指向的な制約があって、そういうこともあるのかググってみたけど、どれも釈然としない。
終いには昨日聞いたStateパターンの話が出てくる始末。
で、知りたいのは「何故ボタンの状態をクラスにすると無茶苦茶になる」のか、どういう原理で無茶苦茶になるのかと言うところ。
ちなみにカタワ指向君と昨日Stateパターンの話をした人はこの件について別にレスする必要はないと思ってる。
カタワ指向君は既に一般業務以外のものは対象外とバッサリ切り捨てているし、
Stateパターンの話をした人は状態をクラスに持つことを許容していると分かっているからね。 なんだか分からねえが熱いバトルが続いてることは伝わったぜ…! ＞「ボタンを押している状態」
＞をクラスにしてしまうと
「ボタンの状態をクラスにするな」と言われてるのに
> 正直、ボタンの状態をイベントで取ろうが
とボタンの状態を取る方法の話だと思ってしまう人は
オブジェクト指向の設計を全く理解してない
根本的に理解していない 何かしらの状態をクラスにすることはありえるが
「ボタンの状態」をクラスにするなと言われてることが
まだわかってない >>883
うむ、だとしたら解っていないんだろうな。
見解を説明して貰ってもいいかな？ > 状態をオブジェクトにするな
> は昔からよく言われている
ちなみにこれどこ界隈で言われてたんす？
よく言われてるとのことだが聞き覚えは無いんで >>884
お前が「ボタンの状態をクラス」にしたものに
なんて名前のクラスにするかを答えれば
お前の勘違いがはっきりする >>885
俺はStateパターンを知ってるから状態をクラスにするなとは言ってない
だがボタンの状態はクラスにするな >>883
正直、「何かしら」の状態は良くて
ボタンと限定されると駄目なのかが分からん。 >>888
ボタンの状態で振る舞いが変わるのはボタン自身ではないから >>886
以前、
724 名前：デフォルトの名無しさん[sage] 投稿日：2021/04/11(日) 08:28:12.36 ID:CjAFb9gH [17/24]
> 「ボタンを押している状態」をクラス
ButtonPressedClass
> 「ボタンの状況」を把握するクラスを作ること
ButtonStateScannerClass
と言うのは聞いたが実際には
「ButtonStates」になるのではないか？ >>887
>>250に書いてある
> 状態をオブジェクトにするな
> は昔からよく言われている
↑これが言いたいことは
「ボタンの状態はクラスにするな」
が
「昔からよく言われている」
ってこと？ ButtonStatesというのは
どういう状態なのか言え
Stateパターンで「ButtonStatesという"状態"の時」なんて
言い方はしねーよ
結局Stateパターンもわかってない
ググってこい。Stateパターンにおける状態のクラス名を >>892
ボタンと限定されると駄目なのかが分からん。
とお前が言ったから、
だめな理由を答えたんだが？
で？とお前が言うなら、こう答えるだけだぞ
ボタンの状態で振る舞いが変わるのはボタン自身ではないから
ボタンに限定すると駄目 >>893
いや別にここではStateパターンの話をしている訳ではないんだがな。 >>891
どうみても、そういう日本語じゃないよな？ｗ >>895
最初の質問を無視するのはなぜ？
ButtonStatesというのは
どういう状態なのか言え >>896
じゃあどういう日本語なんよ・・・
草生やしてないで「昔からよく言われている」のが何なのか教えてよ
そして、どこでいつよく言われてたのかを最終的には知りたいんよ ButtonStatesとう名前のどこに
「ボタンを"押している"」という状態が含まれてるというのか
「ボタンを押している状態」をクラスにするのがダメという
日本語が理解できていない >>897
ああそうか
例えば上、下、右、左、A、Bというボタンが合ったとして、
それらがいつ押されたとか、いつ離されたとか、どのくらいの期間押されていたかの情報を抱えるクラスだな >>898
「状態をオブジェクトにするなは昔からよく言われている」
に対して俺はそんなこと聞いたことがないと言ってる
この話に「昔からよく言われている」ことが何なのかは
一切書かれていない >>901
「ボタンを押している状態」をクラスにするというのは
「ボタンの上を押している状態」をクラスにする
「ボタンの下を押している状態」をクラスにする
「ボタンの右を押している状態」をクラスにする
「ボタンの左を押している状態」をクラスにする
「ボタンのAを押している状態」をクラスにする
「ボタンのBを押している状態」をクラスにする
ということなわけだ
ありえないだろ >>902
> 俺はそんなこと聞いたことがないと言ってる
それはどこで？ >>903
なるほどそう言うことか
ありがとうカタワ指向君
なんか言いたいことがわかったよ >>904
>>887で言ってる
>>905
今なら最初の頃に指摘したこれも理解できるだろ
711 名前：デフォルトの名無しさん[sage] 投稿日：2021/04/11(日) 07:34:09.10 ID:CjAFb9gH [9/24]
答えに詰まったようだねｗ
ゲームのボタンっていうのはキャラクターの一種なんだわ
例えばマリオだとPスイッチは、押したら潰れて消える
持って投げられる。ベルトコンベアやバネの上で動く。
壁として障害物になる。
そういうのとUIのボタンを一緒にするのは抽象化能力が低い
ボタンという名前だから同じものだと考えてしまっている
ゲームのボタン（キャラクター）を持ち出して
UIまでキャラクターにするのはアホ >>906
そもそもクラスに当てはめるものの見解が違ってたってことだね ゲーム脳が、ゲームキャラクタとしてのボタンのことを
言っていたのか今となっては不明だが
ゲームキャラクタとしてのボタンであれば
ボタンの状態によってボタン自身の振る舞いが変わるから
これはあり得るんだよ
だが物理的なボタンの状態をクラスにするとかありえない んで、ゲームキャラクタとしてのボタンの話かと思ってりゃ
今度はボタンの状態をスキャンする話を始めたからな
こりゃ完全にゲーム脳（ゲームの設計しか知らない）だとｗ >>906
失礼
>> 状態をオブジェクトにするな
>> は昔からよく言われている
>
> ちなみにこれどこ界隈で言われてたんす？
> よく言われてるとのことだが聞き覚えは無いんで
これにレスくれたからってっきり>>250さん本人が
俺の疑問に回答くれてるのかと思ってたが別人だったのね
>>250
> 状態をオブジェクトにするなは昔からよく言われている
>>887
> 俺は(略)状態をクラスにするなとは言ってない >>910
そうそう。俺の主張だと勘違いされるのを防ぐためだ。 >>909
というか最初にボタンの状態をと聞いて
>>903
＞>>901
＞「ボタンを押している状態」をクラスにするというのは
＞「ボタンの上を押している状態」をクラスにする
＞「ボタンの下を押している状態」をクラスにする
＞「ボタンの右を押している状態」をクラスにする
＞「ボタンの左を押している状態」をクラスにする
＞「ボタンのAを押している状態」をクラスにする
＞「ボタンのBを押している状態」をクラスにする
＞
＞ということなわけだ
＞ありえないだろ
これは思いつかないよ
もっとも俺の頭が堅いのかも知れんけど >>912
たぶん単に経験が乏しいんかもね
怒らないでね >>913
怒りはしないけど
アセンブラ時代からやってたところに
そう言われると凹むわー >>912
俺にとってはstateパターンを知ってるから状態をクラスにすることはあり得る
ありえるが「ボタン」の状態をクラスにすることはありえない
あるとしたらゲームのキャラクターであるボタンのことを言ってるのかと推測したが
ボタンの状態をスキャンするとかいい出したから
ゲームのメインループの話をしてるのか？と推測したわけだ
ちなみにMS-DOS時代だがアセンブラも使ってたぞ
割り込みベクタを直接書き換えてた人間に、割り込みの話をされてもなーって感じだし
ゲームは本業ではないが、昔はでべろで遊んでた
今は普通にRubyやらJavaScriptやらオブジェクト指向言語も使ってる B型プログラマ同士が卑語を交えつつマウンティングし合う大会の会場はここかな？ はいそーです
マウントされたくなければ、うかつに手を出さないことだｗ >>916
でべろってあのPCエンジンのか
あれやってるなら
処理単体を1/60と言っていたのも頷けるわ >>918
ちなみに俺はAB型だ
だから人格破綻者だと言ったろ？ アマチュアでもよく使ってたタスクシステムってやつはオブジェクト指向とは違うの？ >>922
オブジェクト指向だと思うよ
最近はコンポーネント思考が主流？ >>920
60fpsは単なるよく使われる割り込み単位の一つだろ？
もとはVSYNC割り込み間隔で、アナログテレビの
垂直周波数（インターフェース）が大元じゃなかったか？
その間隔でなければならない理由はないが
名残で今でもその間隔（またはその倍数）が使われてるんだと思うが >>924
今は1/120とか速いものだと1/240になっている
vsync割り込みは今でもそうだけど
でべろで言うならNMI割り込みかな >>924
PALだと50fpsになるんだよなー
海外版と通信対戦するときはフレームレートの差を気を付けないといけなかったのはいい思い出 >>925
それはディスプレイの話だよね？
映像の表示だけなら高速でもいいが
ボタンのスキャンは低い方に合わせないと
プレイが不公平になると思うが
まあ1秒間に60回以上入力できるやつなんていないから
120回読み取りにしちゃっても差はないというかもしれんがｗ >>927
いんや作りによりけり
例えば1Pと2Pの格闘ゲームを作ってたとして
同じフレームの処理の場合、1Pの処理を
先にするとしたら当然1Pの方が先に
攻撃を当てることが出来るけど
1Pでも2Pでもその際に逆側の攻撃が
当たってないか判定を入れるだけ。
投げる処理とかも同じ処理では違いの
位置の同期をとって行うよ そのことは実は結構大事なことで
これをしないと同時にダメージを
受けるという事象がなくなってしまう
場合があるんだよ >>929
いや、対戦じゃなくて一人プレイの場合よ
仮に連射するだけのゲームが有ったとしたら、1秒間に60回スキャンするよりも
1秒間に120回スキャンする方がが取りこぼしがないだろうけど
そもそも1/60 = 16.7ミリ秒を超えて反応出来る人はまずいないから
気にしてないのかなーって話
でも個人的感覚では人間は瞬間的な速度であれば10ms程度で
反応することは出来ると思うんだよね
昔イライラ棒（物理）を作った時の接触判定を10msのポーリングに決めた経験からｗ
Cバスは単純だから線つなげるだけで割り込みが使えたと思うんだけど
そこいらに転がってたLSIを再利用して適当に作ったから面倒だった。 >>930
> これをしないと同時にダメージを
> 受けるという事象がなくなってしまう
そうそう。そうなるよね。
上の方でゲームではイベントを使わない理由の一つがそれだと思ってる。
イベントで処理してしまうと、どちらかが先に反応してしまうから
だからフレームレート等の一定間隔で1Pと2Pの両方の入力が済んで
両者の計算が終わってから判定処理をするべき
ということを自分で思いついて、小学生か中学生の頃に
MSXのBASICで作った連打するだけのレースゲームで実装してたｗ
当時は記憶媒体がなくて電源消したら全部消える。
紙にソースコード書いてたよｗ >>931
それはその通りで論理的に言えば
60fpsだと1秒に30回、120fpsだと60回の
立ち上がりを検出することが出来るのかも
知れないけど、余り現実的ではないね。
映画で連打でスイカ割ってた高橋名人が
一秒間に18回って言ってたから
打てたとしてもボタンや
キーボードクラッシャーになると思うよ
そこは冗談だけど >>932
ちなみにだけど、
昔の業務用のゲームはたまーにRAMにプログラム載せてて
電池が切れると全部無くなるというのが存在するよ >>898
もともとのオブジェクト指向の意味が「“こうしろ”ってメッセージで自律行動できる単位でプログラムを区切る」だから
単なるフラグ管理レベルをオブジェクト化するのは無駄だからやめろって話だわな。
フラグ管理スペシャリストクラスが必要とかなら別だが、それはそれで設計からおかしいだろうし。
そもそもオブジェクト指向はオブジェクト指向なんか要らないローレベル処理と
オブジェクト指向設計が必要な高レベル処理を自覚して使うものだから
正直な話、処理速度重視とかならそんなとこでオブジェクト指向なんて使う必要ないのよ
それをC++とかローレベルでのパーツ使い回しにオブジェクト指向使ったから
いらんとこまで『オーブージェークーートーー！…指向！」ってなって
低レベルプログラマが発狂していまに至る。 するとチンポは自律行動できる単位なのか？？？
>>935
>もともとのオブジェクト指向の意味が「“こうしろ”ってメッセージで自律行動できる単位でプログラムを区切る」だから
なら話を戻すが、「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ メッセージングはインナークラスとしてのオブジェクト指向でオシッコするときのチンポ、
>>935
>“こうしろ”ってメッセージで自律行動できる単位
『自律行動できる単位』は、サブクラスとしてのオブジェクト指向で勃起・射精するときのチンポ！
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く 割込み（インタラプト）は、OSのほうで隠蔽してくれないと
オプジェクト志向とは相性が悪い。ウィンドウシステムでも、
そこはイベント駆動（イベントドリブン）ということで
なんとか押さえこんでいるわけだし。
ボタンとかキーボードとかだと、チャタリングの処理があるので、
そこは別プロセスで割込みを受けとってキューイングしてくれないと、
メインで動いていているプロセスは対処に困る。
まぁ、入力にも出力にも関わらないプロセスを立てておいて、
出力側がタイマーでそのステートを提示の割込みで見にゆくとか、
そんな実装になるんだと思うが。 577 その名前は774人います (ｽｯﾌﾟ Sd22-ObUD) sage 2021/04/14(水) 00:52:35.71 ID:/qa39Aihd
https://i.imgur.com/u2RSU8j.jpg
https://i.imgur.com/kLtQspe.jpg まぁそうね、考え方は人それぞれ
俺は使い分けだと思うけど。
別にCやC++だって自分で趣味的にやるなら
一切必要ないし、ゲームの仕事してても
多数の言語選べる環境もあるし。
ただ詳しくは言えないけど
CSでゲーム作るなら「今は」C、C++は
やっておいた方がいいと思うよ。
ま、これはObject指向には余り関係ない
から気にしなくていいよ。聞き流して。 コールバック関数というのがあって
常にデバイスをみてるOSやデバイスドライバに
コールバック関数を登録すると
データを渡してくれる
自分で作ったコールバック関数が実行される >>941
詳しそうだね。その登録するときに使う
関数名は言えるかい？ 同時判定って本当に同時だったっけ？
投げは絶対に同時発生しないんだから、どっちか優先だよね？（オブジェクト指向関係ない）
ボタン入力を1ビットづつ読み出し中に分岐して処理したりはしないけど、大体2P側不利にならない？（オブジェクト指向関係ない） 割込みベクタ書き換えて、自前の処理の最後に元の飛び先への分岐も入れとく感じかな？
IOCSに自分でパッチあてたりとか（なんの機種の話だ） >>943
ベストをつくしたいのかもしれないけど
遅延とか普通なのに同時を
判定するのは意味ないような なんかスレ伸び速杉（笑）
昔は CPU が遅かったので、30 FPS としたら
33ms の奪いあいだったわけだが、
現在はプロセッサは速いわ I/O 周りのチップ
（出力側のグラフィックも含めて）は
充実してるわで、 60 FPS でも
16.7 ms の分配ということになる。
しかも最近は CRT じゃなくてディジタル表示なので、
リフレッシュタイムとかは表示側のプロセッサに
丸投げできる（とにかくグラフィック・メモリに描いてあれば
表示してくれるわけだから）。
>>940
> CSでゲーム作るなら「今は」C、C++は
>やっておいた方がいいと思うよ。
同意見ではあるのだが、
アセンブラ →〔マクロプリプロセッサ〕→ マクロアセンブラ →
〔C コンパイラ〕→ C 言語 →〔プリプロセッサ？コンパイラ？〕→
C++
という構造を踏まえたうえで、OS とか 制禦とかについて、理解して
もらいたいと思う。
とはいえ、ぶっちゃけこのあたりの話は「オブジェクト志向」では
隠蔽するのがお約束なので、もはやオカルトになってしまう。
C++を「オブジェクト志向」と呼ぶのは、正直いかがなものか、
と思う。 >>943
それも作りによりけり
1P側有利になっているものもあれば
はじき合うように作られてるものもあれば
投げを奪い合うように作られてるのもあるよ
投げを奪い合うものというのは
ちょっと説明しにくいけど組み合う形になって
その後、操作のタイミングとか、連打回数とか
そういう本来の投げの動作と違う動作になって
投げ勝ち負けの判定をするタイプのもの。
でも実際は通信対戦とかすると
僅かにラグが発生したりするので
その辺は多少は許容するという
暗黙の了解があるみたい。
最近「ラグい」って言葉を聞くことない？
あれはそのラグが酷くて文句を垂れてる
ときの言葉なんだ。 レス数が950を超えています。1000を超えると書き込みができなくなります。
