HSPTV!掲示板

この記事は投稿者により削除されました。
2017/12/17(Sun) 22:37:29

まず、VRAM直接参照というのは、役にたつ局面は限定的です。
「pgetやpsetを何千回、何万回とやるようなコード」だったらVRAM直接参照に
置き換えた方が速いですが、大抵のケースでは、標準命令での描画の方が速いです。
（あとは、あるバッファの内容を、全く同じサイズのバッファに丸ごとコピーする処理とか）
はるさんは「明るさ調整」の処理にVRAM直接参照をやっているようですが、
私がこのスレ↓でVRAMの話題を出したのは、あくまでも「エンボス加工」での話です。
http://hsp.tv/play/pforum.php?mode=all&num=81916
VRAMを使う必要性を感じないのなら、使う必要はありません。


＞透過職が２５５だから染まった途端に消えるという状態になってます
「透過色は透過にしか使わない」と決めて、それ以外の用途には使わないようにすれば済む話では？


＞なぜgmodeは負担をかけず早いとか知りたいです
なぜgmodeの話が何回も出てくるのかよくわかりませんが、先ほどのスレで私が答えた、
「gmode 5や6としたあと、gcopyで矩形を加算コピーや減算コピーして、
明るさ調整をする」というやり方のことを言ってるのでしょうか？
はるさんはそのスレの最初のコードで、12万回以上ループしてpsetをしていましたが、
ただでさえ「遅い」pset命令を12万回もやるのに比べれば、gcopy一発の方が速いのは当然です。


＞http://hp.vector.co.jp/authors/VA015883/hsp/hna/hnafast1.html
＞のdupの部分に書いてある配列参照だとか
＞http://www.hspdx.net/hspyarou/2001.html
＞１０の実験の一時変数に代入後参照とか
＞代入と何が違うのかな、と
なぜそんな話題が唐突に出てくるのかさっぱりわからないのですが……まず上の配列参照から。
こういうコード↓を組んで実験してみたところ、確かに処理時間が倍違いましたが、
それでも私の環境で100万回ループして、やっと50ミリ秒の差が出る程度の違いでした。
実際そのサイトにも「ここで行っている高速化は実際には微々たる物です」って書いてあります。

#uselib "winmm.dll"
#cfunc timeGetTime "timeGetTime"

dim a,6
a=0,1,2,3,4,5

st=timegettime()
repeat 1000000
	b=a(3)
loop
mes timegettime()-st

dup c,a(3)
st=timegettime()
repeat 1000000
	b=c
loop
mes timegettime()-st

で、次の記事ですが、記事と同様の実験をしたところ、私の環境ではカウンター(cnt)直接参照の方が速かったです。
記事自体が16年も前のHSP2時代のもので、PC-9821 Xa13という骨董品クラスのマシンでの実験ですから、
今からだとあまり参考にはならないでしょう。

明るさとかに限定したわけではなく色変えたり、覚えてできることを増やしたいという感じです
画像加工とかの知識がなく、例として命令をあげていますが
どうしてgmode命令が負担なく早いのかがわからないのです
自分の知識ではgmodeとvramでやるしかないのでどうすれば負担なく早くできるかわからないので質問してしまいました

「HSP　参照」等の意味も別の検索がでてほしい情報がでず
昔の知識なのも承知ですがそれも把握できてないので学ぶ対象として知りたかっただけです

＞どうしてgmode命令が負担なく早いのかがわからないのです
私たちがHSPのプログラムを実行した場合、HSPのシステムは命令の内容を
ひとつひとつ逐次解釈して、その解釈に従って処理を実行します。
（解釈しやすいように、中間コードという形に変換はしていますが）
この一連の「解釈→処理」という手順が結構時間のかかるもので、
一度に何十万回も命令文を実行したら、それだけべらぼうな時間を消費してしまうのです。
しかし、私の教えたgmodeを使った処理なら、「何十万回」に比べればだいぶ少ない
命令の数で済みますから、その分速度が上がるわけです。

また、処理の内容にもかかる時間の違いがあり、たとえばpsetやpgetは、
VRAMにpeekやpokeするのに比べると、だいぶ遅くなります。
どうして速度に差が出るのかは、HSPのシステム内部の話になりますので、
私たち一般ユーザーには詳しいことはわかりません。
ただ、HSPのシステムはWindows自体の機能も駆使して処理を行っていますから、
処理を行うのに好都合な機能がWindowsに搭載されているのなら、
そういった処理は速やかに行えるのではないか……という想像はつきます。


＞「HSP　参照」等の意味も別の検索がでてほしい情報がでず
そのページで言うところの「参照」というのは、ただ単に、
「変数なり配列変数なりの内容を見る」ということを言っているだけですよ。
（見るというのは、たとえば他の変数に代入したり、計算したり命令に組み込んだり、
表示したりということ）
別に、「参照」なる特別な何かをしているわけじゃありません。

HP見たけど……「おまけ」のつもりとはいえ、VRAM使ったコードなんか投稿するんじゃなかったな。
VRAMに対してここまで異常に拘泥するとは……「今は覚える必要はない」
「役に立つ局面は少ない」「使う必要を感じないなら使わなくていい」って、
何度も釘を刺してる筈なのに。
それに、HSPにはgzoomっていう命令があるのに、いちいち自前でヒーコラヒーコラと
拡大縮小ルーチン作ってる意味もよくわからないし……。

老婆心ながら言いますが、自分のやりたいことを見つけたら、考えるべきことは、
「それをいかに苦労して実現するか」ではなく、「いかに楽をして実現するか」ですよ？
ブログでOpenCV(HSPだったらhspcv)に手を出すことに難色を示していますけれど、
VRAMの使い方なんか覚えるのに比べれば、hspcvを使った方がよっぽど応用が利きますし、
高度な画像加工も簡単にできますよ？

そういうつもりじゃなかったですけど消します

　

もうここ来ないらしいけど、わざわざ時間かけて付き合ってあげて、
長文でレスしたのに無視されるという仕打ちまで受けたのに、
なんで私が初心者をいじめる悪者みたいに言われなきゃいけないんだか。
さすがに腹立つわ。

頭冷やした上で、真面目にレスです。

＞自分なりに考えたものに対してヒーコラヒーコラとか傷つく
これですが、あなたをバカにする意図はありません。
ただ、楽な方法がいっぱいあるのに、あまりにも遠回りで、いたずらに
苦労するようなことばかりしている様を見かねて、つい口走ってしまっただけです。
軽率な言い方で、立腹されたようなら申し訳ありません。

その上で言いますが、プログラミングに関することを、何から何まで、
深い部分に至るまで覚えなくちゃいけないなんて言い出したら、
時間と労力がいくらあっても足りませんよ？
深い部分の知識というのは、必要に迫られた時になって初めて覚えれば良いことであって、
「テンプレのようなの」で事が済むのなら、それで十分なのですよ。

もうここ読んでないと思いますが、読んでいるのなら再考ください。

来ないと書きましたが気になって見に来ました
出来ない人ができないなりの処理をしたり
わからないから学ぶためにしてるだけで
正解を知ってるならわざわざ聞きに来ません
自分も先にそういうつもりじゃないって書いたのに
そのようなつもりないって言ってるじゃないですか
そういうつもりじゃなくてもヒーコラヒーコラって
出来ない人が四苦八苦してできる人と比べてもどうしようもないと思います
言い合いする場所でもないですし明日の夜この投稿けします

まず、落ち着いて聞いてください。
以下、長文になりますし、言い訳がましいことばかりで不快に思うかもしれませんが、
どうかお許しください。


たしかに、質問されたことだけならまだしも、人のホームページにまで踏み込んで
その内容について云々する、というのは、冷静に考えれば私の越権行為でした。
差し出がましいマネをしたことをお詫びします。
ごめんなさい。

＞そういうつもりじゃなくてもヒーコラヒーコラって
本当に、この言葉を見て「バカにされた」と受け止められるとは思いませんでした。
あくまでも「なぜそんな大変なことを……」という感想を素直に書いたまでです。
しかし結果として、これほどまでに激しいお怒りを買ってしまったのなら、
申し開きようがありません。
重ね重ねお詫びいたします。


ここから先は、本当にあなたのためを思って言います。
物を学ぶのには、順序というものがあります。
もちろんあなたは、それをわかっていて、

「画面に一点一点ずつ描くという、基本的な描画処理から始めよう」
「gzoomやhspcvのような『楽なやり方』にいきなり手を染めるのは、
　基礎をすっ飛ばして応用に行っているようなものだから、よくない」

と考えているのだと思います。

しかし、少なくともHSPの世界では、そういう順序で学ぶのは間違っていると思います。
HSPという環境には、「楽なやり方」がふんだんに用意されていて、
それを組み合わせることで、初心者であっても、そこそこに高度なものを
簡単に作ることができます。
（たとえば、HSPのヘルプをザッと読むだけでも、楽なやり方というのはどんどん見つかります）
そうしてまずは、「自分でもこんなに良いものが作れるんだ」という喜びを
感じてほしいのです。

「画面に一点一点ずつ描く」といった「難しくて面倒なやり方」というのは、
「楽なやり方」だけではどうにもならなくなった時になって、はじめて考えれば良いことであって、
「難しいやり方」ばかりを考えていては、そのうち疲れてしまい、
プログラミングをすること自体が嫌になってしまうかもしれません。

先の問題の書き込みは、軽い気持ちでいきなり「難しいやり方」を教えてしまった、
私なりの後悔の気持ちです。
「今はまだ理解できなくてもいい」「役に立つ局面は少ない」「もっといいやり方が」というのは
そういった気持ちで書いたものですが、それにも怒りを感じられたのなら申し訳ありません。

重ね重ね、お詫びいたします。


最後になりますが、この件でHSPや、ひいてはプログラミングが嫌いになる、
などというのは、全く私の本意ではありません。
お気を悪くされてしまったのなら、どうかお怒りを鎮めてください。
このたびは、本当に申し訳ありませんでした。

横から失礼します。

＞沢渡さん

スレッドの文面を読む限りは、はるさんはアルゴリズムの研究をHSPで
やっているのだと思いました。だからあえて標準命令で描画ではなく、
自由度の高いVRAMを直接いじられているのではないかと。
のちのちは、その知識を生かして何かアプリを作るのでしょうが、
いまはアプリ制作が目的ではなく、アルゴリズムの理解、もしくは独自のアルゴリズムを
作り出すことに集中しているのだと思いました。

＞はるさん

沢渡さんがNO.82012で回答されている内容と似た話になりますが。
VRAMをHSPから触る場合、HSPそのものの動作速度があります。
例えば、点を打つPGET命令を実行しても、C++などのコンパイル言語とHSPの中間言語は
翻訳というワンクッションある分、遅くなります。
その代わりにとVRAMを直接いじれば少しは高速になるのでしょうが、体感的には(?)昔ほどではないかもです。
その遅さを少しでも補うためにHSP内部で一括高速処理してくれる命令があるわけです。


横から失礼しますた m(＿ ＿)m

「ヒーコラヒーコラ」って昔はよく使われてた表現だったですね。
頑張ってプログラムを書く様、そしてそのプログラムが動いてる様。
どんなに頑張っても波打つスクロールを見て、お〜ヒーコラヒーコラ動いとるねぇ。みたいな。
沢渡さんもおっしゃってますが慣用句的によく使われていた言葉なので、そこまでキツい意味は無かったと思います。
そう言えば最近はあまり聞かなくなったなぁ…

VRAMいじり、楽しいですね。私も好きです。
グラフィック周りの便利な命令はビデオカード自身に処理をおまかせしちゃうので速くてお得だと思います。

完全に私、「いたいけな初心者を頭ごなしにいびる、意地悪な悪役」扱いなんだな。
いつ私が頭ごなしに自分の見解押しつけたっていうんだか。

まあいいや。親切にする相手を選ばなかった私が悪いんだ。いい勉強になったわ。