一部分消す もしくは 書き換える方法
一部分消す もしくは 書き換える方法
ずっと疑問に思っていたのですが、DXライブラリで
ゲームの画面の全体を裏画面で全て描写してそれを表に反転させて画像や文字列を描写する方法があるのは知ってはいるのですが、反転させても全く変わらない部分の画像や文字列のほうが多いのに一部を書き換えるために全部を消すのは無駄なことをしていないか?
っと思ったのです。
そのため、画面の一部分消す もしくは 書き換える方法はないものでしょうか?
参考サイトなどがあれば教えていただけるとうれしいです。
ゲームの画面の全体を裏画面で全て描写してそれを表に反転させて画像や文字列を描写する方法があるのは知ってはいるのですが、反転させても全く変わらない部分の画像や文字列のほうが多いのに一部を書き換えるために全部を消すのは無駄なことをしていないか?
っと思ったのです。
そのため、画面の一部分消す もしくは 書き換える方法はないものでしょうか?
参考サイトなどがあれば教えていただけるとうれしいです。
Re: 一部分消す もしくは 書き換える方法
裏画面に描写して表に出すのは、
ダブルバッファリングを行っているためで、
これは画面のちらつきを無くして描写を行いますよね。
おそらくですが、手元にある技術書などを参考にする限り
DXライブラリ特有ということではなく、PCゲームを作成する際に
必然的にそうしなければならないルールになっているのだと思います。
ダブルバッファリングは、
自然に画面全体が更新されているということになるため
そう言った意味では一部分だけというのは難しいというか、
やはり無理なのではないかと考えられます。
ダブルバッファリングを行っているためで、
これは画面のちらつきを無くして描写を行いますよね。
おそらくですが、手元にある技術書などを参考にする限り
DXライブラリ特有ということではなく、PCゲームを作成する際に
必然的にそうしなければならないルールになっているのだと思います。
ダブルバッファリングは、
自然に画面全体が更新されているということになるため
そう言った意味では一部分だけというのは難しいというか、
やはり無理なのではないかと考えられます。
Re: 一部分消す もしくは 書き換える方法
反転ではなく反映ですかね?反転処理と言うと、一般的には鏡に映したような画像処理を指すと思います。よって「反転の基準とする直線」を基準とした左右対称に近い絵で無い限りは、反転前後で描写は必須だと思いますので・・・
部分描写はSetDrawArea関数が近いと思いますがどうでしょう。もしくはこのような関数を利用して、「表示が変わるものだけを描写しなおす」という処理の関数を自分で作ることになるでしょう。
しかし基本的には描写しなおす可能性のある領域は再最描写するのがベターで、描写領域を何度も変動させるべきではないと思います。 なにより楽ですし、基本的にコストが増大するのではないでしょうか。
部分描写はSetDrawArea関数が近いと思いますがどうでしょう。もしくはこのような関数を利用して、「表示が変わるものだけを描写しなおす」という処理の関数を自分で作ることになるでしょう。
しかし基本的には描写しなおす可能性のある領域は再最描写するのがベターで、描写領域を何度も変動させるべきではないと思います。 なにより楽ですし、基本的にコストが増大するのではないでしょうか。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: 一部分消す もしくは 書き換える方法
DOS時代など昔は画面クリアや再描画を出来るだけせずに済ませていた時代もありますが、これには大きな問題があります。
1.前回の画面との差分を自分で把握して局所的にクリア or 上書きしなければいけない。 → 当然ながら管理が複雑になりますのでバグの温床になります。
2.ダブルバッファで描画しているため2フレーム前との差分を把握しなくてはいけない。
ちなみにダブルバッファをやめると極端に描画に避ける時間は短くなります。
3.細かく消していると一括クリアや再描画よりも遅くなる可能性があります。
>そのため、画面の一部分消す もしくは 書き換える方法はないものでしょうか?
クリアをやめるのは簡単でClearDrawScreen()を止めるだけです。
部分的に消すのはDrawBox()、書き換えるのはDrawGraph()するだけです。
それよりも問題なのは、書き換える部分を把握することで大変面倒です。
>参考サイトなどがあれば教えていただけるとうれしいです。
自分で構築できない人はやらないほうが良いですね。必ずバグを産みます。
と言うことでデメリットのほうが多いので、やらないことが多いと言うことです。
1.前回の画面との差分を自分で把握して局所的にクリア or 上書きしなければいけない。 → 当然ながら管理が複雑になりますのでバグの温床になります。
2.ダブルバッファで描画しているため2フレーム前との差分を把握しなくてはいけない。
ちなみにダブルバッファをやめると極端に描画に避ける時間は短くなります。
3.細かく消していると一括クリアや再描画よりも遅くなる可能性があります。
>そのため、画面の一部分消す もしくは 書き換える方法はないものでしょうか?
クリアをやめるのは簡単でClearDrawScreen()を止めるだけです。
部分的に消すのはDrawBox()、書き換えるのはDrawGraph()するだけです。
それよりも問題なのは、書き換える部分を把握することで大変面倒です。
>参考サイトなどがあれば教えていただけるとうれしいです。
自分で構築できない人はやらないほうが良いですね。必ずバグを産みます。
と言うことでデメリットのほうが多いので、やらないことが多いと言うことです。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: 一部分消す もしくは 書き換える方法
変化しない部分は、オフスクリーンに描画して、オフスクリーンから転送する、という方法を使います。
現代ハードでは、ふつうに描画したら、その内容が次のフレームまで残っている保証がないので、部分描き換えにはオフスクリーンが必須です。
たいていふつうに描画するよりオフスクリーンに描画するほうが処理速度が落ちるので、描き換える部分が極端に少なく且つ描画処理速度がべらぼうに遅い環境でなければ意味がありません。
PCではプログラムが複雑になるだけなのでやらないほうが良いです。
ちなみに、ドコモのiアプリでオフスクリーンを使っていたゲームを、auのEZアプリ(BREW)に移植するとき全部描き換えるようにしたほうが速かったです。
余談ですが、わたしもずっと疑問に思っていることがあります。
プログラムで画面に『描写』するという表現なんですけど、どこ由来なんでしょう。
現代ハードでは、ふつうに描画したら、その内容が次のフレームまで残っている保証がないので、部分描き換えにはオフスクリーンが必須です。
たいていふつうに描画するよりオフスクリーンに描画するほうが処理速度が落ちるので、描き換える部分が極端に少なく且つ描画処理速度がべらぼうに遅い環境でなければ意味がありません。
PCではプログラムが複雑になるだけなのでやらないほうが良いです。
ちなみに、ドコモのiアプリでオフスクリーンを使っていたゲームを、auのEZアプリ(BREW)に移植するとき全部描き換えるようにしたほうが速かったです。
余談ですが、わたしもずっと疑問に思っていることがあります。
プログラムで画面に『描写』するという表現なんですけど、どこ由来なんでしょう。
Re: 一部分消す もしくは 書き換える方法
皆さんの意見を総合すると
・方法はあるけれどかえって処理速度に時間がかかる、もしくは手間になる
・<<プログラムで画面に『描写』するという表現なんですけど、どこ由来なんでしょう。
プログラムを作り出した博士さんがそう言ったのかな?
・<<自分で構築できない人はやらないほうが良いですね。必ずバグを産みます。
あれから思いついたのですがSetDrawAreaを使って変えたい一部を真っ黒(初期化)にしてから、最描写でいけるのではないかと思いつきました。
質問したときは単純に関数を全て把握してるわけではないので「今は」構築できなくてもヒントがあれば構築することは可能ですよ
・<<反転ではなく反映ですかね?反転処理と言うと、一般的には鏡に映したような画像処理を指すと思います。よって「反転の基準とする直線」を基準とした左右対称に近い絵で無い限りは、反転前後で描写は必須だと思いますので・・・
言い回しについては勘弁してください。
表現方法としてそう思いついたので、そういいましたが皆さんの知識との誤差があったのであればわかりづらくてすみませんね
皆さんの意見を参考にして作るべき関数をどのようにすべきか方針がきまりました。
教えていただきありがとうございました
・方法はあるけれどかえって処理速度に時間がかかる、もしくは手間になる
・<<プログラムで画面に『描写』するという表現なんですけど、どこ由来なんでしょう。
プログラムを作り出した博士さんがそう言ったのかな?
・<<自分で構築できない人はやらないほうが良いですね。必ずバグを産みます。
あれから思いついたのですがSetDrawAreaを使って変えたい一部を真っ黒(初期化)にしてから、最描写でいけるのではないかと思いつきました。
質問したときは単純に関数を全て把握してるわけではないので「今は」構築できなくてもヒントがあれば構築することは可能ですよ
・<<反転ではなく反映ですかね?反転処理と言うと、一般的には鏡に映したような画像処理を指すと思います。よって「反転の基準とする直線」を基準とした左右対称に近い絵で無い限りは、反転前後で描写は必須だと思いますので・・・
言い回しについては勘弁してください。
表現方法としてそう思いついたので、そういいましたが皆さんの知識との誤差があったのであればわかりづらくてすみませんね
皆さんの意見を参考にして作るべき関数をどのようにすべきか方針がきまりました。
教えていただきありがとうございました
Re: 一部分消す もしくは 書き換える方法
オフスクリーンは他にも用途があるので、覚えておいて悪くはないと思います。
それはそれとして、せっかくなのでわたしが経験から分かったことを書いておきます。
オフスクリーンに描画すると透過情報は失われるので、適用できるのは背景だけになります。
複数の画像が重なる部分を描き換えるのは、プログラム的には『描画範囲を絞って』すべて描き直すことなので、『』の分の手間が増えるだけになります。
部分描き換えが有効な手段となるのは、例えば640x480の画面サイズに32x32のタイルマップを描画するとして、ループを回して300個のタイルを描画するとコマ落ちが発生するが、オフスクリーンの転送一回+部分描き換えであればコマ落ちしない、というような場合です。
つまり300回のループを回すだけで数ミリ秒掛かるような実行環境ということになります。
わたしは30年ほどゲームプログラミングやってますが、『描写』という表現はここ1年くらいの間にこの掲示板ではじめて見ました。
描写というのは、既存の風景をそのまま、あるいはそれが持つ雰囲気を描き出すことなので、「プログラム作ってて楽しい」とか気持ちを込めた画面にしたいのだろうかなどとついつい考えてしまいます。
正直言ってとても違和感があります。
それはそれとして、せっかくなのでわたしが経験から分かったことを書いておきます。
オフスクリーンに描画すると透過情報は失われるので、適用できるのは背景だけになります。
複数の画像が重なる部分を描き換えるのは、プログラム的には『描画範囲を絞って』すべて描き直すことなので、『』の分の手間が増えるだけになります。
部分描き換えが有効な手段となるのは、例えば640x480の画面サイズに32x32のタイルマップを描画するとして、ループを回して300個のタイルを描画するとコマ落ちが発生するが、オフスクリーンの転送一回+部分描き換えであればコマ落ちしない、というような場合です。
つまり300回のループを回すだけで数ミリ秒掛かるような実行環境ということになります。
わたしは30年ほどゲームプログラミングやってますが、『描写』という表現はここ1年くらいの間にこの掲示板ではじめて見ました。
描写というのは、既存の風景をそのまま、あるいはそれが持つ雰囲気を描き出すことなので、「プログラム作ってて楽しい」とか気持ちを込めた画面にしたいのだろうかなどとついつい考えてしまいます。
正直言ってとても違和感があります。
最後に編集したユーザー ISLe on 2013年2月25日(月) 22:01 [ 編集 1 回目 ]
Re: 一部分消す もしくは 書き換える方法
そうですね。ISLe さんが書きました:オフスクリーンは他にも用途があるので、覚えておいて悪くはないと思います。
いつ何時どういう方法をとれば意外なことで問題解決できることもありますからね
その程度の速度の誤差なら大丈夫かな?ISLe さんが書きました:それはそれとして、せっかくなのでわたしが経験から分かったことを書いておきます。
オフスクリーンに描画すると透過情報は失われるので、適用できるのは背景だけになります。
複数の画像が重なる部分を描き換えるのは、プログラム的には『描画範囲を絞って』すべて描き直すことなので、『』の分の手間が増えるだけになります。
オフスクリーンが有効な手段となるのは、例えば640x480の画面サイズに32x32のタイルマップを描画するとして、ループを回して300個のタイルを描画するとコマ落ちが発生するが、オフスクリーンの転送一回+部分描き換えであればコマ落ちしない、というような場合です。
つまり300回のループを回すだけで数ミリ秒掛かるような実行環境ということになります。
とは思えなくもないですがゲームを遊んでくれる人の環境とかを考えたらもっと遅くなる人っているんじゃあ?
とも思えるのでちょっと躊躇しますね
ちなみに画面サイズはオリジナルに近い936*702でやろうと思ってましてそれがどういう影響になるや
ら
それならば魚を食べられることを知らない地方にいけば魚を食べる人を見たらお互いびっくりするようにここの風習なんじゃないですか?ISLe さんが書きました:わたしは30年ほどゲームプログラミングやってますが、『描写』という表現はここ1年くらいの間にこの掲示板ではじめて見ました。
描写というのは、既存の風景をそのまま、あるいはそれが持つ雰囲気を描き出すことなので、つい「プログラム作ってて楽しい」とか気持ちを込めた画面にしたいのだろうかなどと考えてしまいます。
正直言ってとても違和感があります。
違和感なんてその土地(掲示板)にいけばしばらくすればなれるかと
住めば都ですね
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: 一部分消す もしくは 書き換える方法
はっ! 今まで『描写』と表現が多発していたことにまったく気づいていなかった。
検索してみてびっくり! こんなにあるとは。 『描写』は、この掲示板だけの特異現象ですかね?
ただ、一般に通用しない用法なので注意してくださいね。
そういえば、部分書き換えの必然性がよく分からないのですが、どこかの環境で処理落ちが発生していると言う状況でしょうか?
場合によっては、そのほかの方法が効果的な場合もありますので、現状の問題点を書いてもらったほうが良いのかもしれません。
検索してみてびっくり! こんなにあるとは。 『描写』は、この掲示板だけの特異現象ですかね?
ただ、一般に通用しない用法なので注意してくださいね。
そういえば、部分書き換えの必然性がよく分からないのですが、どこかの環境で処理落ちが発生していると言う状況でしょうか?
場合によっては、そのほかの方法が効果的な場合もありますので、現状の問題点を書いてもらったほうが良いのかもしれません。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: 一部分消す もしくは 書き換える方法
誤差?フィア さんが書きました:その程度の速度の誤差なら大丈夫かな?
とは思えなくもないですがゲームを遊んでくれる人の環境とかを考えたらもっと遅くなる人っているんじゃあ?
とも思えるのでちょっと躊躇しますね
前のコメントにも書きましたが、300MHzとかのCPUでJITコンパイラのないJavaVMで実行するゲームアプリでは必要でした。
同じようなCPUでもネイティブなバイナリを実行する環境では逆に遅くなりました。
実際にPCではCPUのクロックがMHzで2桁から3桁になった頃に部分描き換えより全描き換えのほうが速くなった覚えがあります。
マルチメディア向け命令セットとかグラフィックアクセラレータが出てきたのもこのくらいの頃ですし。
いまはGHzです。MHz単位で言ったら4桁です。
わたしがこの掲示板に来て3年くらいですが、以前は無かったんですけどね。フィア さんが書きました:それならば魚を食べられることを知らない地方にいけば魚を食べる人を見たらお互いびっくりするようにここの風習なんじゃないですか?
違和感なんてその土地(掲示板)にいけばしばらくすればなれるかと
住めば都ですね
(追記)
この掲示板でも前から言われていることですけど、更新と描画の処理をきっちり分けてコードを書いていれば、部分描き換えに変更すること自体は難しいことではないです。
Re: 一部分消す もしくは 書き換える方法
その場合、正式な言い方はどういえばいいのでしょうか?softya(ソフト屋) さんが書きました:はっ! 今まで『描写』と表現が多発していたことにまったく気づいていなかった。
検索してみてびっくり! こんなにあるとは。 『描写』は、この掲示板だけの特異現象ですかね?
ただ、一般に通用しない用法なので注意してくださいね。
別段処理落ちはしていませんよsoftya(ソフト屋) さんが書きました:そういえば、部分書き換えの必然性がよく分からないのですが、どこかの環境で処理落ちが発生していると言う状況でしょうか?
場合によっては、そのほかの方法が効果的な場合もありますので、現状の問題点を書いてもらったほうが良いのかもしれません。
今回聞いたのは
例えばこんな感じのゲーム画面を作ったとします。
■■■■□
■■■■□
■■■■□
■■■■□
○○○○□
○○○○□
■ ゲームの描写がころころ変わる
□ メニュー部分のため表示は変わらない
○ サブメニュー部分のため表示は変わらない
こういうのだと■の部分だけ変えればいいのに他のとこまで全部変える必要あるのかな?
と思ったからです。
ですので問題になったわけではないのですよ
ご心配させてもうしわけありません。
多分、今なら速度差はそんなに影響はないと思うんですよISLe さんが書きました:誤差?
前のコメントにも書きましたが、300MHzとかのCPUでJITコンパイラのないJavaVMで実行するゲームアプリでは必要でした。
同じようなCPUでもネイティブなバイナリを実行する環境では逆に遅くなりました。
実際にPCではCPUのクロックがMHzで2桁から3桁になった頃に部分描き換えより全描き換えのほうが速くなった覚えがあります。
マルチメディア向け命令セットとかグラフィックアクセラレータが出てきたのもこのくらいの頃ですし。
いまはGHzです。MHz単位で言ったら4桁です。
ですが、体感できないのであれば作ったところでちゃんとできてるのか不安ってことなのです
それならば時代が変化したのでしょうねISLe さんが書きました:わたしがこの掲示板に来て3年くらいですが、以前は無かったんですけどね。
流行語が流行って自然化した感じじゃないですか?
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: 一部分消す もしくは 書き換える方法
>その場合、正式な言い方はどういえばいいのでしょうか?
書籍や解説で書かれている表現は『描画』です。
英語でDrawやPaintと表現しますので、日本語で描くと言う意味になりますから描画なのです。
『描写』は英語だとdescriptionで表現と言う意味で使われます。
心理描写とか情景描写とか、そういう使い方です。
ゲームだと暴力描写とか残酷描写とかの使われ方がされていますね。
ただ、その書き換えを抑止する手間や書き換えを抑止のために発生するバグの発生率や処理速度が毎回描画するより上回る事が多いので現代ではデメリットのほうが大きいと言うことです。少なくとも現代のPCでは私やISLeさんが書いたようにデメリットの方が上回ります。
ぜひ、実測したりして実感してみたほうが良いと思います。
少なくともコードを書く手間が増えるのは予想できると思いますので。
書籍や解説で書かれている表現は『描画』です。
英語でDrawやPaintと表現しますので、日本語で描くと言う意味になりますから描画なのです。
『描写』は英語だとdescriptionで表現と言う意味で使われます。
心理描写とか情景描写とか、そういう使い方です。
ゲームだと暴力描写とか残酷描写とかの使われ方がされていますね。
凄くもっともな疑問ですね。疑問としては非常に良いと思います。■ ゲームの描写がころころ変わる
□ メニュー部分のため表示は変わらない
○ サブメニュー部分のため表示は変わらない
こういうのだと■の部分だけ変えればいいのに他のとこまで全部変える必要あるのかな?
と思ったからです。
ただ、その書き換えを抑止する手間や書き換えを抑止のために発生するバグの発生率や処理速度が毎回描画するより上回る事が多いので現代ではデメリットのほうが大きいと言うことです。少なくとも現代のPCでは私やISLeさんが書いたようにデメリットの方が上回ります。
ぜひ、実測したりして実感してみたほうが良いと思います。
少なくともコードを書く手間が増えるのは予想できると思いますので。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: 一部分消す もしくは 書き換える方法
わたしはこのスレでもずっと『描画』と書いてますけどね。
わたしが経験したこともフィアさんにとっては何の役にも立たないことでしょう。
若いひとのやる気を邪魔してしまうので、これからは『描写』と書かれている投稿には一切関わらないようにします。
否定的な意見に負けることなくぜひいろんなことを経験してください。
なるほど。すると『描写』を受け入れられないわたしは時代遅れということですね。フィア さんが書きました:それならば時代が変化したのでしょうねISLe さんが書きました:わたしがこの掲示板に来て3年くらいですが、以前は無かったんですけどね。
流行語が流行って自然化した感じじゃないですか?
わたしが経験したこともフィアさんにとっては何の役にも立たないことでしょう。
若いひとのやる気を邪魔してしまうので、これからは『描写』と書かれている投稿には一切関わらないようにします。
否定的な意見に負けることなくぜひいろんなことを経験してください。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: 一部分消す もしくは 書き換える方法
ちなみにエフェクトに関しては描写という言葉を使う場合もあります。
ただ一般的には描写が出てくる率は少なくて、半分ぐらいに見えますが実際はもっと少ないです。
表現力という意味での描写も沢山出てきます。
でも、その他の掲示板などでも描画の代わりに描写を使っている人がいるのも事実です。
「プログラム グラフィック "描写" - Google 検索」 約 387,000 件 (0.27 秒)
https://www.google.co.jp/search?num=100 ... ZQzC6xhqbM
「プログラム グラフィック "描画" - Google 検索」 約 668,000 件 (0.36 秒
https://www.google.co.jp/search?num=100 ... P16coWdncU
例えばゲーム開発の現場だと描写と描画をうまく使い分けないと混乱すると思います。
「この描写は、ちょっとダメかなぁ」
エフェクトのことを言っているのか、表示に問題が有ると言っているのか、演出やシナリオに問題が有ると言っているのか分からないです。
ただ一般的には描写が出てくる率は少なくて、半分ぐらいに見えますが実際はもっと少ないです。
表現力という意味での描写も沢山出てきます。
でも、その他の掲示板などでも描画の代わりに描写を使っている人がいるのも事実です。
「プログラム グラフィック "描写" - Google 検索」 約 387,000 件 (0.27 秒)
https://www.google.co.jp/search?num=100 ... ZQzC6xhqbM
「プログラム グラフィック "描画" - Google 検索」 約 668,000 件 (0.36 秒
https://www.google.co.jp/search?num=100 ... P16coWdncU
例えばゲーム開発の現場だと描写と描画をうまく使い分けないと混乱すると思います。
「この描写は、ちょっとダメかなぁ」
エフェクトのことを言っているのか、表示に問題が有ると言っているのか、演出やシナリオに問題が有ると言っているのか分からないです。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: 一部分消す もしくは 書き換える方法
3D描画が進化して、自然界にある風景を再現する手法がたくさん研究されるようになって混同が進んだのかもしれませんね。
わたしは
炎の揺らめきによって得られる落ち着いた雰囲気を描写するというのは目的
揺らめく炎やそれに照らされる周囲をリアルに描画するというのが手段
だと考えます。
なので実装に関しての『描写』は違和感があります。
完全に独断と偏見ですが、どっちでもかまわないというプログラマは、いいかげんな設計でいいかげんな実装をするひとだと思います。
わたしは
炎の揺らめきによって得られる落ち着いた雰囲気を描写するというのは目的
揺らめく炎やそれに照らされる周囲をリアルに描画するというのが手段
だと考えます。
なので実装に関しての『描写』は違和感があります。
完全に独断と偏見ですが、どっちでもかまわないというプログラマは、いいかげんな設計でいいかげんな実装をするひとだと思います。
Re: 一部分消す もしくは 書き換える方法
先ほど、「『描写』と書かれている投稿に一切関わらない」と書きましたが、「実装に関して『描写』と書かれている投稿」と訂正します。
例えば、主人公の怒りを描写するのにどんなエフェクトを描画するのが相応しいか、といった表現であればまったく違和感がないので。
例えば、主人公の怒りを描写するのにどんなエフェクトを描画するのが相応しいか、といった表現であればまったく違和感がないので。
Re: 一部分消す もしくは 書き換える方法
描画ですかなかなかなじみにくい表現ですねsoftya(ソフト屋) さんが書きました:書籍や解説で書かれている表現は『描画』です。
英語でDrawやPaintと表現しますので、日本語で描くと言う意味になりますから描画なのです。
『描写』は英語だとdescriptionで表現と言う意味で使われます。
心理描写とか情景描写とか、そういう使い方です。
ゲームだと暴力描写とか残酷描写とかの使われ方がされていますね。
ん~本当に感覚としては一部変えれば済む気がする とは思うのですがsoftya(ソフト屋) さんが書きました: 凄くもっともな疑問ですね。疑問としては非常に良いと思います。
ただ、その書き換えを抑止する手間や書き換えを抑止のために発生するバグの発生率や処理速度が毎回描画するより上回る事が多いので現代ではデメリットのほうが大きいと言うことです。少なくとも現代のPCでは私やISLeさんが書いたようにデメリットの方が上回ります。
ぜひ、実測したりして実感してみたほうが良いと思います。
少なくともコードを書く手間が増えるのは予想できると思いますので。
説明だと全部変えないとデメリットがありまくりなのですよね
確かに試してみればどれだけバグがあるのか実体験としてはわかると思います。
が、お勧めできないものなら時間があるときにでも作ってみようかなと思いました。
別段、時代遅れとまでは思っていないのですが、そう捉えてしまって気に障ったらすみません。ISLe さんが書きました:なるほど。すると『描写』を受け入れられないわたしは時代遅れということですね。
わたしが経験したこともフィアさんにとっては何の役にも立たないことでしょう。
流行語とは違って最近の流行に服のすそを出すのが最近では普通らしいですけど、
昔はすそは出さないことのほうが普通。
そしてどちらの立場からみても、逆の立場の人は「普通ではない」=「違和感を感じる」人はいるかと
この先「服のすそは切り込む」のが普通の時代が訪れようが「へそだし」が普通の時代が訪れてもそれならそれで、違和感を感じるのならしかたがないのではないですか?
ISLeさんが職場で経験した事であるのなら、私もISLeさんと同様の職場につけば、ISLeさんの経験は生かせると思います
ですので、役に立たないかどうかはわからないではないですか。
私がISLeさんの気に触ったのであれば、私に対して一切かかわらなければいいかと思いますが。ISLe さんが書きました:若いひとのやる気を邪魔してしまうので、これからは『描写』と書かれている投稿には一切関わらないようにします。
否定的な意見に負けることなくぜひいろんなことを経験してください。
ISLeさんの言い分の若い人は私以外にもいるはずで、ISLeさんの意見を求めている方も大勢いらっしゃると思います。
私もオフスクリーンがどんなものなのか参考になりました。
意見ありがとうございます。
そのため、どうか関わり会おうとしないのをやめるのを考え直していただけませんか?
ただ、勉強の仕方や立場、経験といったものが違うだけなのだと思いますしね
否定的なことはどれをさすのかはわかりません。
Re: 一部分消す もしくは 書き換える方法
『描画』という言葉に馴染みがあるかどうかは別として、『描画』も『描写』もずっと昔からある言葉で、それぞれに意味があります。
服のすそを出すのが普通になっても、出さないことができなくなるわけではありませんし、出さないという表現がなくなるわけでもありません。
むかしはすそは出さないことのほうが普通で、いまはすそを出すことのほうが普通だからと言って、「すそを出さない」がすそを出すことを表現するように変わったりもしません。
どちらも存在し、どちらが主流かというだけの話です。
しかし『描画』と同じ意味で『描画』ではなく『描写』を使うというのは、『描画』そのものを否定し無くしてしまうということです。
服のすそで例えるなら、すそを出すのが普通の世界では、すそを出さないという現実が存在しなくなるということです。
それは流行りすたりではなく、『描画』を使う派は滅んでしまえという主張に他なりません。
服のすそを出すのが普通になっても、出さないことができなくなるわけではありませんし、出さないという表現がなくなるわけでもありません。
むかしはすそは出さないことのほうが普通で、いまはすそを出すことのほうが普通だからと言って、「すそを出さない」がすそを出すことを表現するように変わったりもしません。
どちらも存在し、どちらが主流かというだけの話です。
しかし『描画』と同じ意味で『描画』ではなく『描写』を使うというのは、『描画』そのものを否定し無くしてしまうということです。
服のすそで例えるなら、すそを出すのが普通の世界では、すそを出さないという現実が存在しなくなるということです。
それは流行りすたりではなく、『描画』を使う派は滅んでしまえという主張に他なりません。
Re: 一部分消す もしくは 書き換える方法
否定的というのは、部分描き換えはメリットがないのでやらないほうが良いという意見のことです。
部分描き換えでプログラムが複雑になると書いたのは、こちらが勝手にメリットがある状況を先読みしてしまったためです。
背景の他と重ならない領域をオフスクリーンに保存するように変更するだけなら簡単ですので、実際にやってみてください。
先にも書きましたが、描画処理をきちんとまとめてさえいれば、MakeScreen関数とSetDrawScreen関数を組み合わせて使いほんの数行の変更で対応できます。
そんな簡単に対応できるはずがないと思われるのであれば、それは現段階で無駄が多いということです。
仮に部分描き換えにメリットがあったとしても、現段階の無駄を省くほうがはるかに大きなメリットがあるはずです。
部分描き換えでプログラムが複雑になると書いたのは、こちらが勝手にメリットがある状況を先読みしてしまったためです。
背景の他と重ならない領域をオフスクリーンに保存するように変更するだけなら簡単ですので、実際にやってみてください。
先にも書きましたが、描画処理をきちんとまとめてさえいれば、MakeScreen関数とSetDrawScreen関数を組み合わせて使いほんの数行の変更で対応できます。
そんな簡単に対応できるはずがないと思われるのであれば、それは現段階で無駄が多いということです。
仮に部分描き換えにメリットがあったとしても、現段階の無駄を省くほうがはるかに大きなメリットがあるはずです。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: 一部分消す もしくは 書き換える方法
>描画ですかなかなかなじみにくい表現ですね
一般のネット上でのみなさんの描写・描画の使い分けをみてみると曖昧に使い分けている感じを受けます。
ただ、心理描写とか情景描写とかの場合は間違って心理描画と使っていることはありません。
なので無意識には描画と描写を使い分けているようです。
●描写
文学における描写は、その情景・心情を言葉で描くことです。
音楽においても同様にその情景・心情を音楽で表現することですね。
絵画・映画などに置いても描写は、その情景・心情を絵や映像で表現することですね。
●描画
これは絵を描くこと。表現することを含まない機械的な作業を踏めての描くことです。
この掲示板においては、質問者の方が描写と表現されることは多々あるようですが、回答者側を見ると若い世代でも描画の方を使っている様ですのでプログラミング書籍などを読んでいる間に描画と言葉に馴染んでいるものと思われます。慣れの問題では無いでしょうか?
一般のネット上でのみなさんの描写・描画の使い分けをみてみると曖昧に使い分けている感じを受けます。
ただ、心理描写とか情景描写とかの場合は間違って心理描画と使っていることはありません。
なので無意識には描画と描写を使い分けているようです。
●描写
文学における描写は、その情景・心情を言葉で描くことです。
音楽においても同様にその情景・心情を音楽で表現することですね。
絵画・映画などに置いても描写は、その情景・心情を絵や映像で表現することですね。
●描画
これは絵を描くこと。表現することを含まない機械的な作業を踏めての描くことです。
この掲示板においては、質問者の方が描写と表現されることは多々あるようですが、回答者側を見ると若い世代でも描画の方を使っている様ですのでプログラミング書籍などを読んでいる間に描画と言葉に馴染んでいるものと思われます。慣れの問題では無いでしょうか?
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: 一部分消す もしくは 書き換える方法
例えばこのスレに関して、もはや回答者の『描画』派と『描写』派の割合は半々です。softya(ソフト屋) さんが書きました:この掲示板においては、質問者の方が描写と表現されることは多々あるようですが、回答者側を見ると若い世代でも描画の方を使っている様ですのでプログラミング書籍などを読んでいる間に描画と言葉に馴染んでいるものと思われます。慣れの問題では無いでしょうか?
質問者を含めると『描写』派が上回ります。
この掲示板で『描写』が一気に増えてきたのはここ最近です。
他のサイトでもけっこう使われているのは知りませんでした。
なのでどこで『描写』を使っているのを見たのだろうと思って尋ねたわけです。
Re: 一部分消す もしくは 書き換える方法
描画の意味がいいものだからその意味を残しておきたいISLeさんの思いは最もだとは思いますが、結局使う人がいなければ、滅ぶかと。ISLe さんが書きました: しかし『描画』と同じ意味で『描画』ではなく『描写』を使うというのは、『描画』そのものを否定し無くしてしまうということです。
服のすそで例えるなら、すそを出すのが普通の世界では、すそを出さないという現実が存在しなくなるということです。
それは流行りすたりではなく、『描画』を使う派は滅んでしまえという主張に他なりません。
ただ、ISLeさんのように使う人が一人でもいる限りそれは小数になっただけであり、滅びはしませんよ。
だから安心してください。
少数になるのが嫌なので不安を感じてるのですか?
それなら、描画を使うように推奨するしかありませんね
参考意見としてありがたい意見だと思ってましたがそれが否定的といえばそうかもしれませんね。ISLe さんが書きました:否定的というのは、部分描き換えはメリットがないのでやらないほうが良いという意見のことです。
ごめんなさいね。否定的だとは全く気づきませんでした。
作ってみました。ISLe さんが書きました:先にも書きましたが、描画処理をきちんとまとめてさえいれば、MakeScreen関数とSetDrawScreen関数を組み合わせて使いほんの数行の変更で対応できます。
#include "DxLib.h"
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ){
//ウィンドウタイトルの設定
SetMainWindowText("部分書き換えの練習");
//ログを出力しない
SetOutApplicationLogValidFlag( FALSE );
ChangeWindowMode(true);
if( DxLib_Init() == -1 ) // DXライブラリ初期化処理
{
return -1; // エラーが起きたら直ちに終了
}
int white = GetColor(255,255,255);
int red = GetColor(255,0,0);
int blue = GetColor(0,0,255);
int green = GetColor(0,255,0);
int kaki = MakeScreen( 310, 70, FALSE ) ;
int kaki2 = MakeScreen( 310, 50, FALSE ) ;
DrawBox(10,10,320,100,red,TRUE);
DrawString(12,12,"何かを押すと一部分だけ書き換わるよ",white);
DrawString(12,32,"ここら辺が特に",white);
WaitKey() ;
SetDrawScreen( kaki );
DrawBox(0,0,320,100,blue,TRUE);
DrawString( 2, 2, "変わった?", white ) ;
SetDrawScreen( DX_SCREEN_FRONT ) ;
DrawExtendGraph( 10, 30, 320, 100, kaki, FALSE ) ;
WaitKey();
SetDrawScreen( kaki2 );
DrawBox(0,0,320,100,green,TRUE);
DrawString( 2, 2, "更なる変化", white ) ;
SetDrawScreen( DX_SCREEN_FRONT );
DrawExtendGraph( 10, 50, 320, 100, kaki2, FALSE ) ;
WaitKey();
DxLib_End() ; // DXライブラリ使用の終了処理
return 0 ; // ソフトの終了
}
理解していないうちは文字が崩れたりバグに遭遇しましたが、理解できたらバグを出さなくできました。
ええと、まずどこで見たかとかは覚えていません。ISLe さんが書きました:なのでどこで『描写』を使っているのを見たのだろうと思って尋ねたわけです。
そして私が描写と描画を今回指摘していただいて意識してみると確かに違いがありました。
つまり私の場合よく見ないと描写と描画どちらを使ってるのか認識できないのです。
おそらく大体の意味は同じで見た感じが似てるから特に意識していないのかと思います。
それで私が描写を使う理由としては
例えば果物のオレンジを知らなくてみかんは知っていたとします。
オレンジをぱっと見た感じは「みかん」。
ですがよくよく見ると色とか形とか違うわけです。
ここでこれはオレンジなんだと知ればオレンジという名称で言うでしょうが、言い方を変えてもせいぜい「みかんっぽい何か」でしょう。
そんな変な言い方なら、みかんと言ってしまえっという認識になるのです。
そのため、私が描写という言葉を使うのは言い方だとかイメージだとかが見た時にしっくりきたからです。
これは物の覚え方が人は全員同じというわけではないからくるのでしょうね。
Re: 一部分消す もしくは 書き換える方法
ごめんなさいねsoftya(ソフト屋) さんが書きました:一般のネット上でのみなさんの描写・描画の使い分けをみてみると曖昧に使い分けている感じを受けます。
ただ、心理描写とか情景描写とかの場合は間違って心理描画と使っていることはありません。
なので無意識には描画と描写を使い分けているようです。
私の場合、意識しないと使い分けてるかどうか認識できませんでした。
こう分類を説明されるとわかりやすいですね。softya(ソフト屋) さんが書きました: ●描写
文学における描写は、その情景・心情を言葉で描くことです。
音楽においても同様にその情景・心情を音楽で表現することですね。
絵画・映画などに置いても描写は、その情景・心情を絵や映像で表現することですね。
●描画
これは絵を描くこと。表現することを含まない機械的な作業を踏めての描くことです。
教えていただきありがとうございます。
Re: 一部分消す もしくは 書き換える方法
(実装に関しての)『描写』と書いてある投稿に関わりたくないのはそもそも日本語で話が通じないだろうと予感するからです。
まさにいまの状況です。
以前から言葉遣いに違和感を感じる投稿にはなるべく関わらないようにしています。
今回は質問者から回答者まで立て続けに『描写』が続いたのでつい反応してしまいました。
天下のマイクロソフトの翻訳ガイドラインにあるのですから滅ぶはずがありませんよ。
用語検索 - マイクロソフト ランゲージ ポータル
↑のページで日本語を対象にして『描画』と『描写』を検索してみてください。
『描写』を使うひとの将来を勝手に憂慮したりはしますが、わたしと直接には関係ないことです。
わたしの興味を満たすために「どこ由来なのか」と質問をしただけなのですが。
関数名しか見えてないのですね。
どうして前提条件を無視するのでしょうか。
これだけでけっこうです。
ありがとうございました。
フィアさんが『描写』に固執しようがそれによってフィアさんがどうなろうが知ったこっちゃないのですよ。
わたしはわたしのために投稿しているのです。
わたしの感じる違和感が本物であることが今回も証明されたわけですし、得るものはありました。
まさにいまの状況です。
以前から言葉遣いに違和感を感じる投稿にはなるべく関わらないようにしています。
今回は質問者から回答者まで立て続けに『描写』が続いたのでつい反応してしまいました。
『描画』が少数派のような物言いですね。フィア さんが書きました:描画の意味がいいものだからその意味を残しておきたいISLeさんの思いは最もだとは思いますが、結局使う人がいなければ、滅ぶかと。
ただ、ISLeさんのように使う人が一人でもいる限りそれは小数になっただけであり、滅びはしませんよ。
だから安心してください。
少数になるのが嫌なので不安を感じてるのですか?
それなら、描画を使うように推奨するしかありませんね
天下のマイクロソフトの翻訳ガイドラインにあるのですから滅ぶはずがありませんよ。
用語検索 - マイクロソフト ランゲージ ポータル
↑のページで日本語を対象にして『描画』と『描写』を検索してみてください。
『描写』を使うひとの将来を勝手に憂慮したりはしますが、わたしと直接には関係ないことです。
わたしの興味を満たすために「どこ由来なのか」と質問をしただけなのですが。
わたしの言った簡単というのはそういうことではありません。フィア さんが書きました:作ってみました。ISLe さんが書きました:先にも書きましたが、描画処理をきちんとまとめてさえいれば、MakeScreen関数とSetDrawScreen関数を組み合わせて使いほんの数行の変更で対応できます。
(略)
簡単といえば簡単ですね
関数名しか見えてないのですね。
どうして前提条件を無視するのでしょうか。
わたしが聞きたかったのはこれです。フィア さんが書きました:ええと、まずどこで見たかとかは覚えていません。
これだけでけっこうです。
ありがとうございました。
フィアさんが『描写』に固執しようがそれによってフィアさんがどうなろうが知ったこっちゃないのですよ。
わたしはわたしのために投稿しているのです。
わたしの感じる違和感が本物であることが今回も証明されたわけですし、得るものはありました。
Re: 一部分消す もしくは 書き換える方法
私はここ数年間数社の現場を回っていますが描画の事を描写と言う人間には会ったことはないですし
そのような表記を見た事もないです。そう書いてある書籍も知らない。
正直、ネットで横行していると知って驚いています。
どう考えても draw() 関数に「描写処理」というコメントは付かないでしょう。
描写というのが新しいという事ですが
では本来の意味の「描写」はどうのように呼んで区別しているのか?という事には全く触れられないですよね。
ネットではこれだけ使われている!と言ってもその中に第一線で活躍しているプロが何人いるのでしょうか。
これは揚げ足取りでも笑い事ではなく新卒採用する人間の表現に問題がないか確認をするための重要な情報です。
デバッグ票に「~の描写がおかしい」と書いてあっても管理者は混乱も何も迷わずエフェクト班なり企画班に票を回すでしょう。
その先で混乱が生じるか本来の不具合の解決が遅れるか、いずれにせよ実害発生です。
明らかに現場を知らない、ネットでプログラムを覚えた人間が間違って使用したものが広まっているだけですよね。
問題を起こした人間は「今はこれが普通ですよ、え?あなた達は描画と言ってるんですか?珍しいですね」と悪びれないどころか直そうともしない。
それどころか自分が正しい事にしようとムキになって多用し始める。
描写に限らず現場ではよく見られる光景です。
彼らは自分が管理する立場になれば嫌でも「意識統一」や「区別」をしなくてはならないんだという事は学ぶので
今「こうしろ」とか「こうだ」という事は不毛ですし必要のない事です。
むしろ我々が今後こういう人間が入ってくる可能性があるので対策を練っておかねばならないという事だと思います。
そのような表記を見た事もないです。そう書いてある書籍も知らない。
正直、ネットで横行していると知って驚いています。
どう考えても draw() 関数に「描写処理」というコメントは付かないでしょう。
描写というのが新しいという事ですが
では本来の意味の「描写」はどうのように呼んで区別しているのか?という事には全く触れられないですよね。
ネットではこれだけ使われている!と言ってもその中に第一線で活躍しているプロが何人いるのでしょうか。
これは揚げ足取りでも笑い事ではなく新卒採用する人間の表現に問題がないか確認をするための重要な情報です。
デバッグ票に「~の描写がおかしい」と書いてあっても管理者は混乱も何も迷わずエフェクト班なり企画班に票を回すでしょう。
その先で混乱が生じるか本来の不具合の解決が遅れるか、いずれにせよ実害発生です。
明らかに現場を知らない、ネットでプログラムを覚えた人間が間違って使用したものが広まっているだけですよね。
問題を起こした人間は「今はこれが普通ですよ、え?あなた達は描画と言ってるんですか?珍しいですね」と悪びれないどころか直そうともしない。
それどころか自分が正しい事にしようとムキになって多用し始める。
描写に限らず現場ではよく見られる光景です。
彼らは自分が管理する立場になれば嫌でも「意識統一」や「区別」をしなくてはならないんだという事は学ぶので
今「こうしろ」とか「こうだ」という事は不毛ですし必要のない事です。
むしろ我々が今後こういう人間が入ってくる可能性があるので対策を練っておかねばならないという事だと思います。
Re: 一部分消す もしくは 書き換える方法
ここで言う「描画」は技術用語としての「描画」であって,一般用語としての「描画」ではないですよね。
ということは,たとえ日本語として同じ意味であっても別の言葉に置き換えることができないことになります。
技術用語は一つの動作・操作・概念等に対してある技術の範囲において同一の言葉を用いることで,意思疎通をしやすくするためのものだからです。
# まぁ,用語に派閥があったりすることはありますが……。
日本語の意味がどうであれ,DXライブラリはマニュアルにおいてDraw~という関数の説明で「描画」という用語を使っています。
ref) DXライブラリ置き場 リファレンスページ
そうである以上,Drawは「描画」であり,相手を納得させるだけの理由無しにDrawに対して「描写」という言葉を使うのは,混乱を招くだけです。
ということは,たとえ日本語として同じ意味であっても別の言葉に置き換えることができないことになります。
技術用語は一つの動作・操作・概念等に対してある技術の範囲において同一の言葉を用いることで,意思疎通をしやすくするためのものだからです。
# まぁ,用語に派閥があったりすることはありますが……。
日本語の意味がどうであれ,DXライブラリはマニュアルにおいてDraw~という関数の説明で「描画」という用語を使っています。
ref) DXライブラリ置き場 リファレンスページ
そうである以上,Drawは「描画」であり,相手を納得させるだけの理由無しにDrawに対して「描写」という言葉を使うのは,混乱を招くだけです。
Re: 一部分消す もしくは 書き換える方法
申し訳ないですけど、少なくともわたしは、定規を使って折れ線グラフを描くような行為と同じ意味で、『描画』を使っています。YuO さんが書きました:ここで言う「描画」は技術用語としての「描画」であって,一般用語としての「描画」ではないですよね。
ということは,たとえ日本語として同じ意味であっても別の言葉に置き換えることができないことになります。
自分でピクセルを打つプログラムを書いて動かすことを、自分で描くことだと思っています。
コンピュータがプログラマの意図を勝手に汲み取って感情込めて絵を描いてくれるわけではないですから。
歴史的には、コンピュータが文字しか出力できなかったころは「描画」ではなく単に「表示」と言われてました。
好きな色のピクセルを打って自由な図形を描けるようになって「描画」という単語があてがわれました。
『描画』は専門用語が一般化したものではなく、一般的な用語を専門用語に転用したものです。
ですから専門用語であろうとなかろうと同様に通じるはずです。
(追記)
余談ですが、わたしがコードを書くときの描画処理の関数名ですが、いまはrenderがお気に入りです。
Re: 一部分消す もしくは 書き換える方法
そう言えば…M.R さんが書きました:明らかに現場を知らない、ネットでプログラムを覚えた人間が間違って使用したものが広まっているだけですよね。
「描写」は「描画」と紛らわしいので、「描写」は使用禁止にして「表現」で統一
と、ある現場で決められていたのを思い出しました。
言葉の問題
自分は、「ご教示ください」を「ご教授ください」と書かれるのには、抵抗がある。ただ、「ご教授...」と書き込まれる
たびに、「ご教示の間違い」と書き込むのは、さすがにウザがられると思った。なので、プログラムに関するアドバイスが
出来るときだけ、プログラムに関するアドバイスとともに、「ご教授」を注意することにしている。
「表画面と裏画面をひっくりかえす」のを「反転」と表現するのは、別におかしくないのでは ? flip には、「裏返す」
「ひっくりかえす」という意味がある。
「描画」「描写」は気にならなかった。「ご教授ください」が気にならないのに、「描写」が気になるというのは、
自分には、奇妙なことに思えるが、ここに来ている人にとっては、そうでもないのか ?
C言語交流フォーラム~mixC++~ の方でも、話題になっているようですが。
たびに、「ご教示の間違い」と書き込むのは、さすがにウザがられると思った。なので、プログラムに関するアドバイスが
出来るときだけ、プログラムに関するアドバイスとともに、「ご教授」を注意することにしている。
「表画面と裏画面をひっくりかえす」のを「反転」と表現するのは、別におかしくないのでは ? flip には、「裏返す」
「ひっくりかえす」という意味がある。
「描画」「描写」は気にならなかった。「ご教授ください」が気にならないのに、「描写」が気になるというのは、
自分には、奇妙なことに思えるが、ここに来ている人にとっては、そうでもないのか ?
C言語交流フォーラム~mixC++~ の方でも、話題になっているようですが。
VTuber:
東上☆海美☆(とうじょう・うみみ)
http://atassyu.php.xdomain.jp/vtuber/index.html
レスがついていないものを優先して、レスするみみ。時々、見当外れなレスしみみ。
中の人:
手提鞄あたッしュ、[MrAtassyu] 手提鞄屋魚有店
http://ameblo.jp/mratassyu/
Pixiv: 666303
Windows, Mac, Linux, Haiku, Raspbery Pi, Jetson Nano, 電子ブロック 持ち。
東上☆海美☆(とうじょう・うみみ)
http://atassyu.php.xdomain.jp/vtuber/index.html
レスがついていないものを優先して、レスするみみ。時々、見当外れなレスしみみ。
中の人:
手提鞄あたッしュ、[MrAtassyu] 手提鞄屋魚有店
http://ameblo.jp/mratassyu/
Pixiv: 666303
Windows, Mac, Linux, Haiku, Raspbery Pi, Jetson Nano, 電子ブロック 持ち。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: 一部分消す もしくは 書き換える方法
私は「描写」は脳内自動変換で「描画」に見えてました。まさか、「描写」を使っている人がいるとは思いもよらなかったからだと思います。
なので、気づいて驚いたって所です。
「ご教授ください」は「ご教示ください」の間違いであることを分かっていても、あまりに多いのでスルー状態です。
なので、気づいて驚いたって所です。
「ご教授ください」は「ご教示ください」の間違いであることを分かっていても、あまりに多いのでスルー状態です。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: 一部分消す もしくは 書き換える方法
Dixqさんが旧ゲームプログラミングの館で1つの講座だけ描写と書いてますね。
「13a. 裏画面処理をして画像を動かす。」
http://dixq.net/g/13.html
ここで広まったのは、これが原因でしょうか?
他の部分は全部描画なのですが。
「13a. 裏画面処理をして画像を動かす。」
http://dixq.net/g/13.html
ここで広まったのは、これが原因でしょうか?
他の部分は全部描画なのですが。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: 一部分消す もしくは 書き換える方法
さまざまな意見があるようですが、今まであまり意識せずに「描写」という表現をしていた自分としては、少なくとも他者と情報のやり取りをする上では自分と他者が、同一の物を指すと認識するような単語を使うべきなのかな、と思いました。つまりは掲示板やチャットでは「描画」を使うべきなんでしょう。 「描写」を使っていた理由を挙げるなら「描画」という言葉を「描画」と認識していなかったのと、「絵を描いて写す」だから「描写」でいいか、と思っていたからです。個人の設計のメモで、誤解しないなら使う程度に利用は控えるべきなのでしょう。
screenflip関数で反転というのは、直訳では正しいのかもしれませんが、反映や更新という、ネガポジ反転や自分が間違って挙げた様な鏡に映したような処理、と受け取るのが難しいような表現をすべき、だと勝手ながら思うのです。しかしながら、「反転処理といえば、画面の更新をさす」という暗黙のルールがあるなら別です。それなら既に述べたように郷に従うべきです。個人的には「二回裏返したら表になる」という考えがとても強いので、この関数に対しては避けたい表現でもあります。
screenflip関数で反転というのは、直訳では正しいのかもしれませんが、反映や更新という、ネガポジ反転や自分が間違って挙げた様な鏡に映したような処理、と受け取るのが難しいような表現をすべき、だと勝手ながら思うのです。しかしながら、「反転処理といえば、画面の更新をさす」という暗黙のルールがあるなら別です。それなら既に述べたように郷に従うべきです。個人的には「二回裏返したら表になる」という考えがとても強いので、この関数に対しては避けたい表現でもあります。
Re: 一部分消す もしくは 書き換える方法
「映す」の間違いではないのですか?zxc さんが書きました:「絵を描いて写す」だから「描写」でいいか、と思っていたからです。
Re: 言葉の問題
vertical flipやhorizontal flipのflipと、page flipやscreen flipのflipは同じ意味だとおっしゃるのですね。あたっしゅ さんが書きました: 「表画面と裏画面をひっくりかえす」のを「反転」と表現するのは、別におかしくないのでは ? flip には、「裏返す」
「ひっくりかえす」という意味がある。
「ご教授」と書いてあったら「手取り足取り教えて欲しいんだな」と捉えて対応してます。あたっしゅ さんが書きました: 「描画」「描写」は気にならなかった。「ご教授ください」が気にならないのに、「描写」が気になるというのは、
自分には、奇妙なことに思えるが、ここに来ている人にとっては、そうでもないのか ?
こちらもたいてい関わらないようにしてますが、この掲示板では「ご教授」が間違いではない場合も多々あると思います。
Re: 一部分消す もしくは 書き換える方法
横槍を入れるのは好きではないのですが、最近何やらこの掲示板が殺伐としてきたような気がしたので・・・。
自分は書籍でプログラムを勉強したからだと思いますが、昔から描画という表現に馴染み、描写と呼ぶという事に関して確かに違和感を覚えます。
もしかしたらネットでプログラムを勉強してらっしゃる方だと参考サイトで描写という表現が用いられてしまっていたため、そちらで覚えてしまったのかもしれません。
この表現に関しては明らかな間違いですので間違いに気付いたらやんわりと表現を訂正して、その事に関しては終わりで良いのではないでしょうか・・・?
勿論回答するかしないかは回答者様の自由で御座いますし、間違いに気付いても訂正する義務はありません。
気が向いたら正しい表現を伝えて貰えたら有難いです。
自分は自分の表現が正しいという自信は一切無いため、質問する側として表現の間違いがあれば訂正して頂けるととても助かります。
(経験豊かな方やプロの方のご意見や表現の仕方はとても貴重ですので。)
自分はほとんど質問する側ですしこうした議論に首を突っ込むべきではないような気もしますが、何だかんだ結構長い事お世話になっている掲示板が最近不穏ですので首を突っ込ませて頂きました。
すみませんm(_ _)m
自分は書籍でプログラムを勉強したからだと思いますが、昔から描画という表現に馴染み、描写と呼ぶという事に関して確かに違和感を覚えます。
もしかしたらネットでプログラムを勉強してらっしゃる方だと参考サイトで描写という表現が用いられてしまっていたため、そちらで覚えてしまったのかもしれません。
この表現に関しては明らかな間違いですので間違いに気付いたらやんわりと表現を訂正して、その事に関しては終わりで良いのではないでしょうか・・・?
勿論回答するかしないかは回答者様の自由で御座いますし、間違いに気付いても訂正する義務はありません。
気が向いたら正しい表現を伝えて貰えたら有難いです。
自分は自分の表現が正しいという自信は一切無いため、質問する側として表現の間違いがあれば訂正して頂けるととても助かります。
(経験豊かな方やプロの方のご意見や表現の仕方はとても貴重ですので。)
自分はほとんど質問する側ですしこうした議論に首を突っ込むべきではないような気もしますが、何だかんだ結構長い事お世話になっている掲示板が最近不穏ですので首を突っ込ませて頂きました。
すみませんm(_ _)m
Re: 一部分消す もしくは 書き換える方法
私も描写には前々から少し首を傾げていました。
教授と教示についても数度このフォーラムの日記やらで話題に出たことが有りましたが、
そのときにISLeさんは確か『教授』と書かれた質問には回答をしていない、ということをおっしゃっていたかと思います。
実際自分も時々教授と書かれた質問に対し指摘をすることはあるのですが、
むしろ教示という言葉が使われている事のほうが少ないくらいの現状でして、
もうほとんどスルーしている状態です。
反転、ですが、他の方が仰っている通り、
見ている方は左右の反転、などの意味にとられることが多いのではと考えます。
つまり、あながち間違ってはいないのですが、ややこしい、紛らわしい表現であることは確かです。
DXライブラリのリファレンスを見たところ、
ScreenFlipの説明には『反映』という言葉が使われていました。
教授と教示についても数度このフォーラムの日記やらで話題に出たことが有りましたが、
そのときにISLeさんは確か『教授』と書かれた質問には回答をしていない、ということをおっしゃっていたかと思います。
実際自分も時々教授と書かれた質問に対し指摘をすることはあるのですが、
むしろ教示という言葉が使われている事のほうが少ないくらいの現状でして、
もうほとんどスルーしている状態です。
反転、ですが、他の方が仰っている通り、
見ている方は左右の反転、などの意味にとられることが多いのではと考えます。
つまり、あながち間違ってはいないのですが、ややこしい、紛らわしい表現であることは確かです。
DXライブラリのリファレンスを見たところ、
ScreenFlipの説明には『反映』という言葉が使われていました。
Re: 一部分消す もしくは 書き換える方法
賛成です。コレジャナイ さんが書きました: この表現に関しては明らかな間違いですので間違いに気付いたらやんわりと表現を訂正して、その事に関しては終わりで良いのではないでしょうか・・・?
いろいろ溜め込んでいる方(私もそうですが)もいると思いますが、
このトピの主旨とも外れてますし、終わりにしませんか?
Re: 一部分消す もしくは 書き換える方法
『描写』が主流だと言うからそれを否定するということの応酬になってしまいましたが…コレジャナイ さんが書きました:この表現に関しては明らかな間違いですので間違いに気付いたらやんわりと表現を訂正して、その事に関しては終わりで良いのではないでしょうか・・・?
そもそも『描写』を否定するつもりはありませんでした。
『描写』を使うひとから『描写』を使うようになった由来を聞きたかっただけです。
具体的にここの対応をこうしていれば荒れなかったというアイデアがあれば教えてください。
Re: 一部分消す もしくは 書き換える方法
その「映す」も言われてみると良いですね。スクリーンに「映す」わけですから。ISLe さんが書きました:「映す」の間違いではないのですか?zxc さんが書きました:「絵を描いて写す」だから「描写」でいいか、と思っていたからです。
自分が言っていたのはあくまでコピーや写真といった「正確に複製する、写し取る」というような意味合いの「写す」です。用意された画像を画面なり裏画面なりにコピーしている(ように少なくとも私には思える)ので「写す」です。そして少なくとも、自分にとっては分かりやすいです。正直な話、「描いて写す」という意味がないらしいことは知りませんでした。自分にとっては、そのコピーするという意味が結構無視できないものなので、指摘されない限りはきっと気づきませんし、直しませんね。
「描いて映す」であれば、絵を描いてそれをプロジェクターで離れたスクリーンに映すようなイメージです。一般的に見て、私のイメージが正しいかどうかは知りませんので、素っ頓狂なものかもしれませんが。
プログラミングするという視点から言えば矯正すべき、最低でも一般ではどんな言い回しをするのかは知っておく必要があるんでしょうね。そうでないと話が噛み合わないかもしれませんし、紛らわしいですし、何より検索しても参考になるものが、あまり見つからないでしょうから。
Re: 一部分消す もしくは 書き換える方法
他のスレでさんざん『描写』を見てても特に指摘しませんでしたが、理由は想像してました。zxc さんが書きました:自分が言っていたのはあくまでコピーや写真といった「正確に複製する、写し取る」というような意味合いの「写す」です。用意された画像を画面なり裏画面なりにコピーしている(ように少なくとも私には思える)ので「写す」です。
いまのひとはDXライブラリで言えばDrawGraphだけでゲームを作れますからね。
そういうイメージを持っているだろうとは思ってました。
とは言え、どうして『描写』という単語に結び付くのかは謎ですが。
わたしの世代だと、画像は「転送」するものです。
いまでも現役バリバリで使われてますけど。
オフスクリーンに描画したものは映らないので「映す」も適当じゃないです。
「描いて〇〇」なら描くことと〇〇は別のことではないかと思ったわけなので。
Re: 一部分消す もしくは 書き換える方法
なにやら私がいない間に盛り上がってるみたいですね
全部の人に返信をするのはさすがにしんどいのでまとめますと
・私としては描写や描画どちらが主流でもどうでもいいと思っています。
ただ、私が描写と言って質問するのであれば混乱を招く事がわかりましたので、もし質問する際は描画を使うことにします。
(すっごく意識して書かないと難しいですが)
回答する場合はどちらかで書くとは思いますが
・それ以外の言い方の違いについてはノータッチで
結局、日本語に多少の言い方が違う意味やら表現があるやらで当然の事なのでは?っとおもってますから私としては何でそこまで突き詰めて意味を統一する必要があるんだろう?
っと思っています。
私としてはどちらがかかれていようとも勝手に脳内変換されてある程度意味が伝わるので私としてはどちらでもいいことなんです。
皆さんは現場ではこうだから等の理由でどちらを使うかはこうしなければならないというルールがあるみたいなのでそれに関しては何も言いません。
しかし、他の人の言い方が自分とは違うからこう変えろというのは意見の押し付けにしかならないと思うのです。
そして何やら私の言ったことで混乱を生むみたいなので今後はこのスレッドにレスしません。
私としては混乱を作る気なんぞは全くないのですけれどね。
全部の人に返信をするのはさすがにしんどいのでまとめますと
・私としては描写や描画どちらが主流でもどうでもいいと思っています。
ただ、私が描写と言って質問するのであれば混乱を招く事がわかりましたので、もし質問する際は描画を使うことにします。
(すっごく意識して書かないと難しいですが)
回答する場合はどちらかで書くとは思いますが
・それ以外の言い方の違いについてはノータッチで
結局、日本語に多少の言い方が違う意味やら表現があるやらで当然の事なのでは?っとおもってますから私としては何でそこまで突き詰めて意味を統一する必要があるんだろう?
っと思っています。
私としてはどちらがかかれていようとも勝手に脳内変換されてある程度意味が伝わるので私としてはどちらでもいいことなんです。
皆さんは現場ではこうだから等の理由でどちらを使うかはこうしなければならないというルールがあるみたいなのでそれに関しては何も言いません。
しかし、他の人の言い方が自分とは違うからこう変えろというのは意見の押し付けにしかならないと思うのです。
そして何やら私の言ったことで混乱を生むみたいなので今後はこのスレッドにレスしません。
私としては混乱を作る気なんぞは全くないのですけれどね。
Re: 一部分消す もしくは 書き換える方法
そもそも何が原因だったのでしょうか。フィア さんが書きました:しかし、他の人の言い方が自分とは違うからこう変えろというのは意見の押し付けにしかならないと思うのです。
まとめてみました。
わたしもフィアさんも変えろとはひとことも言っていませんね。ISLe さんが書きました:余談ですが、わたしもずっと疑問に思っていることがあります。
プログラムで画面に『描写』するという表現なんですけど、どこ由来なんでしょう。フィア さんが書きました: プログラムを作り出した博士さんがそう言ったのかな?ISLe さんが書きました:わたしは30年ほどゲームプログラミングやってますが、『描写』という表現はここ1年くらいの間にこの掲示板ではじめて見ました。
描写というのは、既存の風景をそのまま、あるいはそれが持つ雰囲気を描き出すことなので、「プログラム作ってて楽しい」とか気持ちを込めた画面にしたいのだろうかなどとついつい考えてしまいます。
正直言ってとても違和感があります。フィア さんが書きました:それならば魚を食べられることを知らない地方にいけば魚を食べる人を見たらお互いびっくりするようにここの風習なんじゃないですか?
違和感なんてその土地(掲示板)にいけばしばらくすればなれるかと
住めば都ですねISLe さんが書きました:わたしがこの掲示板に来て3年くらいですが、以前は無かったんですけどね。フィア さんが書きました:それならば時代が変化したのでしょうね
流行語が流行って自然化した感じじゃないですか?ISLe さんが書きました:なるほど。すると『描写』を受け入れられないわたしは時代遅れということですね。
わたしが経験したこともフィアさんにとっては何の役にも立たないことでしょう。
ただ、わたしは、わたしがこの掲示板を利用することについて、ひどく疎外感を受けました。
とは言え最後の文章はおとなげなかったと思いますが。
そして、これを期にフィアさんの発言はさらに上から目線に調子を上げます。
『描写』に対して『描画』を持ち出すようになるのはこれ以降のことです。
そのあたりは長くなるのでスレを追ってください。
わたしは、知らないことを自分の知っていることに勝手に当てはめて話を進めることは、意見の押し付け以上に問題があると思います。
それはもはやコミュニケーションの放棄ですから。
意味や意図が分からなければ問い返して確認するのは当たり前のことではないでしょうか。