HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2022
0620
アキアキノヒロロ[hgimg4] についてのひとりごと35解決


アキアキノヒロロ

リンク

2022/6/20(Mon) 11:19:49|NO.96689

題名を
> [hgimg4] のライトや物理設定について思うこと
として、スレッドをたてましたが、「ライトや物理」に限定したくないと思いはじめたので、
> [hgimg4] についてのひとりごと
に変更して、再録させて頂き、続けていきたいと思います。
勝手な「ひとりごと」として無視してくださって構いません。
すいません。

まずは、以下再録。

[gpfloor] や [gpplate] のノードは、ライトの反映が、[gpbox] のノードと同等には
なっていないことが分かっています。
基本として、ライトの反映は、そのノードの[material]内の設定によるので、
[gpbox] のノードでは、その [gpbox] 命令に、[material]内設定と同じことが
組み込まれているのではないか、と思われます。
一方の[gpfloor] や [gpplate] のノードが、同等の反映にならないのは、これらの
命令には、その組み込みがなされていないのでは、と思われます。

試しに、Blenderで平面を作って、そのまま[gpb]にして[hgimg4]でライトを試してみると、
反映されませんが、その[material]内設定を、[DIRECTIONAL_LIGHT_COUNT 1] とすれば、
[gpbox] のノードと同等の反映になります。
このことは、Blenderで立方体を作った場合でも同様で、その[material]内設定の有無に
よるのです。

このように、ライトに関する基本的な働きの反映は、[gpbox] のノードには組み込まれているが、
他のものには、組み込まれていなかったり、または、他の形で組み込むようになっている、
ということなのです。

[gpbox] のノードにのみ、基本的な働きの反映が組み込まれている、というのは、
ライトだけでなく、物理設定におけるコリジョンについても同様のようです。

なぜそうなっているのかということを考えてみるに、これは、[hgimg4] の物理やライトを
開発していくにあたって、[gpbox] のノードを基本に据えて行われ、それに必要な設定を
[gpbox] のノードに付与したことによるのでしょう。
そのような付与の設定を既定のものとするかしないか、またどういう形の付与の仕方にするか、
この辺りのことを [hgimg4] としてどう構成していくのか。これらのことを、具体的にどう
命令として形作っていくのがいいのか。

それらの足跡が垣間見られるように思えてきます。



この記事に返信する


アキアキノヒロロ

リンク

2022/6/20(Mon) 12:19:27|NO.96690

「opt」が設定できる命令の場合を見てみたいと思います。
その「opt」を見ていくと、
> 付与の設定を既定のものとするかしないか、またどういう形の付与の仕方にするか
という部分がよく分かってきそうな気がします。

例えば、[sample/hgimg4/freemesh.hsp] の [freemesh] の [opt] は、

> GPOBJ_MATOPT_NOLIGHT ライティングを行なわない
> GPOBJ_MATOPT_NOMIPMAP MIPMAPを生成しない
> GPOBJ_MATOPT_NOCULL カリングを無効にする
> GPOBJ_MATOPT_NOZTEST Zテストを無効にする
> GPOBJ_MATOPT_NOZWRITE Zバッファ書き込みを無効にする
> GPOBJ_MATOPT_BLENDADD プレンドモードを加算に設定する
> GPOBJ_MATOPT_SPECULAR 光源計算時にスペキュラーを適用します
> GPOBJ_MATOPT_MIRROR 反転した画像として表示する
> GPOBJ_MATOPT_CUBEMAP キューブマップとして設定する
> GPOBJ_MATOPT_NODISCARD αチャンネルによるピクセル破棄を無効にする

との説明がヘルプに載っています。
「ライティングを行なわない」ために、[opt] で [GPOBJ_MATOPT_NOLIGHT] するとは、
逆に言えば、この [opt] 設定をしなければ、[LIGHT] するということ「ライティングを行なう」、
言い換えれば、既定のものとして、[LIGHT] が付与の設定になっている、ということです。
同様に、[MIPMAP] [CULL] [ZTEST] [ZWRITE] [DISCARD] が既定であって、それぞれ
「MIPMAPを生成する」「カリングを有効にする」「Zテストを有効にする」
「Zバッファ書き込みを有効にする」「αチャンネルによるピクセル破棄を有効にする」
が、付与の既定設定になっているはずです。
その他の [opt] 設定は、簡単には判断できませんが、それに関する何らかの付与の設定が
あるはずです。ですから、[opt] 設定されていない命令の場合の既定設定は、実際に使って
みないと分かりづらいです。

元へ戻って言えば、このように [opt] 設定を設けるというのは、既定のものがあって、
それを変更する方法として、『付与の仕方』を [opt] で行なうという形になっている訳です。
また、ライトのことで言えば、すでに[material]内設定でその有効無効が決められることに
なっているので、 [opt] でそれを行なうわけにいかず、それに従うことが『付与の仕方』に
なる、これが、『どういう形の付与の仕方にするか』にあたることです。

ただ、最も基本的なものとしての [gpbox] のノードには、既定設定としておかないと、
[hgimg4] の開発上、煩雑になってきてしまう基本的な設定がある訳で、それは、もう
[gpbox] という命令に組み込んでしまっている......。


なんか、随分と回りくどい言い方になってしまいました。
読み返すと、当たり前のことしか、言ってないようにも思えますね。
すいません。



アキアキノヒロロ

リンク

2022/6/21(Tue) 18:38:24|NO.96694

ツイッターに載せたまんまです。すいません。


ライトについての頭の整理

〓太陽光は平行光で、環境光。平行光に乗せて広がる光だから、ベクトル関係 [setdir] で設定〓
 ディレクショナルライト(平行光)に対して、[setdir] でアンビエントカラー(環境光)を設定

〓太陽は一つ〓
 設定有効はカレントライト(gpuselightの0番)のみ


[GPOBJ_LIGHT] は、既定では、ディレクショナルライト(平行光)になっている、ヌルノードの一種。
強いて書けば、こんな感じか。

gpnull id_[GPOBJ_LIGHT]
gplight id_[GPOBJ_LIGHT], GPOBJ_LGTOPT_NORMAL


以上、こじつけみたいだけれど、こう考えることで、一応納得で、落ち着きました。



アキアキノヒロロ

リンク

2022/6/22(Wed) 05:50:26|NO.96702

[hgimg4] のスレッドばかりたてて、目障りに思われていそうで、
内心ちょっとビクビクしてます。すいません。

話題によっては、思いの外、多くの方からレスを頂くこともあって、
[hgimg4] のこれまでとの違いを感じられる段階になってきたようで、
『万年一人相撲』だったと言っていい私としては、嬉しくなってきます。

ただ、やはり一人相撲になるのかな、と考えてしまう、スレッドも......。

> [GPPBIND_MESH] での [gppbind] について、表示形状と接触判定用コリジョンの関係
http://hsp.tv/play/pforum.php?mode=all&num=96678

以前、[high_school_girl.fbx] [high_school_girlSD.fbx] のコンバートが
上手くいかず、あれこれ考えられるだけの組み合せを色々やってみた時の
ことを思い出してしまいました。
最近は、以前のような体力も気力も続かなくなってきました。

本当に、誰かやってくれないかな。



ギバロウ

リンク

2022/6/22(Wed) 21:15:22|NO.96705

書き込むべきかかなり悩んだのですが、独り言としてスレッド立ててらっしゃるので、書き込んでも良いのかな(?)と思いましたので書き込みさせていただきます。

何度もコリジョンのスレを読んだんですが、私の読解力では、何がわからないのかがわからないです、すみません。
コリジョンについては公式の説明まんまだと思うのですが、当たってるのに判定されない、とか、当ってないのに当たってるとかが起こるという事でしょうか?



アキアキノヒロロ

リンク

2022/6/23(Thu) 02:41:05|NO.96708

ギバロウ さんへ
 『独り言』としたのは、今まで『一人相撲』ばかり味わってきた思いが抜け切れていないので、
『一人言』ということで、『ひとりごと』にしました。詰まらない親父ギャグのダジャレのつもり
ですので、あまり気になさらないで、書き込んで行ってかまわないです。
zrs90(5さい) さんが立てられたスレッド『○hgimg4、3DCG関係の情報等についてのスレッド』に
載せてもいいかな、とも思いましたが、「情報」などでなく、愚痴めいたことになりそうなので、
個人的な意味合いも兼ねての、『ひとりごと』です。


> 当たってるのに判定されない、とか、当ってないのに当たってるとかが起こる
はい、その通りです。

基本の基本は、[gpbox] で作った箱ですね。これ、「コリジョンについては公式の説明まんま」
その通りです。
> 箱ノード、床ノード、板ノードはそれぞれの形状をコリジョンとして扱います。
以下のヘルプの解説にある通りなのですが、
> optionに、GPPBIND_NOSCALEを指定した場合は、スケールが反映されていないもともとの
> 形状がコリジョンとなります。
この意味は、
箱ノード、床ノード、板ノードは、[setscale] でサイズ変更しても、[option] 指定なしならば、
その変更したサイズ(表示される大きさ、形状)がコリジョンになるが、GPPBIND_NOSCALEを指定
すると、サイズ変更前のもともとの大きさ、形状がコリジョンに使われるから、拡大表示されて
いれば、表示上、ノードの中にめり込んで、もともとの大きさ、形状の位置まで進まないと、衝突
判定されないし、逆に、縮小表示されていれば、表示されているノードに衝突する前に、もともと
の大きさ、形状の位置に当たるので、衝突の判定となります。
これは、この解説の通りで、知っておいてわきまえていれば、おかしいとはならず、そういう仕様
なのだ、というだけです。でも、この仕様の有効な利用方法が思い浮かびませんよね。
何かあるかな。

また、これとは反対に、3Dモデルノードは、[setscale] でサイズ変更してもしなくても、[option]
指定なしならば、その表示されている大きさ、形状のモデル全体を覆うスフィア(球体)がコリジョン
になるので、モデルに当たっていなくとも、スフィアに当たれば、衝突と判定されます。しかし、
GPPBIND_MESHを指定すると、コリジョンとしてのスフィアはなくなり、モデルの形状そのものが
コリジョンになり、即ち、表示されているモデルに当たれば、衝突の判定です。ただしGPPBIND_
MESHの指定でも、凹型の部分は正しく判定されません。GPPBIND_MESH指定の凹型衝突判定
については、私のツイッターでの実験を見て下さい。
1月9日
https://twitter.com/akiakinohiroro/status/1480143010914770950
1月10日
https://twitter.com/akiakinohiroro/status/1480351379495743491

以上、なんのことはない、ヘルプの解説にある通りで、問題はありません。
ここのヘルプは、「作成日 2022/05/04」となっています。

一体、何が問題なのかと言うと、実のところ、この先が問題なのです。

掲示板での私のスレッド 『[GPPBIND_MESH / NOSCALE] とコリジョン / 画面表示との関係』
http://hsp.tv/play/pforum.php?mode=all&num=94873

このスレッドは、今年の1月時点でのもので、この後にヘルプの解説が新しく書き換えられて
いたりしますので、突き合わせると、話が合わない部分があったりします。
今、自分で読み返しても、頭が混乱しそうなので、それ以上は上手く説明できそうにありません。
御足労をおかけしますが、このスレッドを一読して頂けないでしょうか。
何回となく、具体的にテストしたスクリプトが数あるはずですが、お恥ずかしい話、今、ちょっと
見つかりません。見つかったら、提示しようと思いますが、あらたに作ってみようかとも思います。

答えになっていないようで、申し訳ありません。



アキアキノヒロロ

リンク

2022/6/23(Thu) 03:10:20|NO.96709

箱ノード、床ノード、板ノードや3Dモデルノードとは、ちょっと性質が違いますが、
GENKI さんが、「HSP3.7に向けたβテストについてのお願い」
http://hsp.tv/play/pforum.php?mode=all&num=94865#96654
でも、GPPBIND_MESH 指定が正常でない例を上げておられます。



アキアキノヒロロ

リンク

2022/6/23(Thu) 07:15:44|NO.96710

もう一つ、私のツイッターの
https://twitter.com/akiakinohiroro/status/1507642615902400512
は、
1月10日
https://twitter.com/akiakinohiroro/status/1480351379495743491
のこれを、別の形で利用したものと言えると思います。



ギバロウ

リンク

2022/6/23(Thu) 19:06:43|NO.96711

私は、公式のライトや物理は使うことはなく、もしやるなら自前で実装するので、そちらのほうは弄ることはないので、お力にはなれないかなと思います。
ただ、当たり判定は使おうかなと思っていたので、現状の問題点や実験を見せていただけて有難いと思っています。

ちょっと余裕がない日々が続いてるので実験できてなくて申し訳ないんですが・・・。

色々見させて(読ませて)頂いて、思うに、箱・板・床とオリジナル形状のGPBは別物(似て非なるもの)として認識されたほうが良いかと思われます。
また、推測ではありますが、「GPPBIND_NOSCALE」は過去バージョンとの互換性のためのもののような気がします。

「GPPBIND_MESH」にバグ(?)がありそうだということはわかりました。
しかしながら、内部処理がどうなってるかはわかりませんが、現実的に考えて、全くの形状そのものの面すべてに対して当たり判定を計算し続けるのは相当厳しいと思うので、近似形状で判定するようになってるのかな(?)と推測します。

結構、どのライブラリでもそうなんですが、当たり判定は、大まかに2段階や3段階で判定していく形でないと、各オブジェクトの全部の面について計算していては、いくら昨今のCPUやGPUの処理速度が上がったとはいえ、実用の処理速度はだせないです。
ですので、実質的にはスフィアで大まかな当たり判定をして、当たってるっぽかったら、もっと詳しく判定していく、、、という処理を自前で書くことになるのかな、と思います。

今回、いろいろ勉強になったので、当たり判定もライブラリに頼らず、自前で実装しようと思います。
お力になれず申し訳ないですが、有難うございました。



アキアキノヒロロ

リンク

2022/6/23(Thu) 23:48:21|NO.96712

> 箱・板・床とオリジナル形状のGPBは別物
はい、表示される形は同じでも、その成り立ちは違い、性質も違ってくること、
そのことを確認するために、テストをした訳です。

> 「GPPBIND_NOSCALE」は過去バージョンとの互換性のためのもの
この意味がよく分かりません。[hgimg4] の過去バージョンと互換を取るという、
そのことが具体的にどういうことを意味しているのか分かりません。

「GPPBIND_MESH」は、動かないもの(mass=0)として、地面等に利用するには、
とても有効です。あまり複雑なものは避けたほうが無難だと言いますが、
今までのところ(プロコン作品等で)不都合なことは感じていません。厳しい
ことをさせているような感覚もありません。
しかし、動くもの(mass≠0)としてのオブジェクトに「GPPBIND_MESH」を使おうと
すると、俄然クセが出て、使いづらくなります。


ギバロウ さんも、当たり判定には色々あって、用途にあったものを使うのがいい
と、考えてらっしゃいますが、私もその通りだと思います。
そして、一つのもの(作品、ゲーム)の中でも、場合々々で使い分けるといいですね。
単に座標間の距離で当たり判定してもいいし、スフィアにやらせる方がふさわしい
ものもあります。スフィア代りを箱ノードにやらせてもいい。凸凹地面は、[mass=0]
[GPPBIND_MESH]設定でいく。建物は、それを覆う箱ノードで、同じく[mass=0]の
[GPPBIND_MESH]で出来る。樹木は、ツイッターでやったように、その幹だけを
当たり判定の対象にもできる。
このように、一つのもの(作品、ゲーム)だからと言って、全て同じ方式だけに
する必要も理由もなく、場合々々にあった、相応しい、応用できるものをそれぞれで
使い分けるように、プログラムするのが一番でしょう。

そのために、これら色々な組合せ条件で、どのような命令をどのような形で使う
のがいいのか、このことを探って知ることが重要だと思ったのです。

GPPBIND_MESH指定の凸型と凹型の衝突判定のテストを繰返しツイッターでやったのは、
モノレール状の軌道を作りたかったからで、結果としては、物理設定利用による
軌道は、無理だと断念しましたが、これも、もとを正せば、場合々々にあった、
相応しい、応用できるものを探すテストでした。

> 当たり判定もライブラリに頼らず、自前で実装
そうですね、相応しい、応用できるものがなければ、自作することになりますよね。
その時は、お教え頂けると、嬉しいです。



Drip

リンク

2022/6/25(Sat) 14:31:46|NO.96719

こんにちは。Dripです。

アキアキノヒロロさん>

>> 「GPPBIND_NOSCALE」は過去バージョンとの互換性のためのもの
>この意味がよく分かりません。[hgimg4] の過去バージョンと互換を取るという、
>そのことが具体的にどういうことを意味しているのか分かりません。

HSP3.51までは物理動作がscaleを考慮せずに判定していた時代があります。
Hgimg4付属サンプルの test11.hsp の37行目あたりに setscale i,2,2,2 を一行追加して実行してみますとHSP3.6と3.51での動作の違いがわかるかと思います。
この不具合の修正とともにかつてバグの存在したバージョンと互換性を取るために設けられたパラメータがGPPBIND_NOSCALEです。
使いようによっては任意で少し壁にめり込んで見える物理動作モデルの生成等にも使うことができますよ。


フリーメッシュに関して>

個人的な見解ですが、現状のHgimg4のメッシュの物理動作は仕様通りに動作しておらず、殆ど使う事ができない気がしています。
まず頂点の登録順序やUVの座標説明がマニュアル通りになっていないことは誰もが混乱する部分かと思います(少なくとも四角ポリゴンを生成しようとした場合、頂点を時計回り(或いは反時計回り)に登録することは絶対にできないはずです)が、
当たり判定も滅茶苦茶で空中に浮いたり地面にめり込んだりと、まともに動作していないように見えます。
別のスレッドでGENKIさんも気づかれていらっしゃいますが、HSP付属のフリーメッシュのサンプルも誤記によってメッシュの物理が正常に設定できておらず、
そもそも動作の見た目がgpboxと何ら変わり無い形状でテストしているため、フリーメッシュとの違いが全くわからないのも問題に思います。

//フリーメッシュの物理動作がおかしいサンプル(コピペで実行できます) // ・物体が適当な大きさの箱型に判定されてるっぽくないですか? // ・マウスを動かすとカメラが回転します // (HSP3.6〜HSP3.7b2にて動作・テスト済) #include "hgimg4.as" //hgimg4読み込み chdir dir_exe+"\\sample\\hgimg4" //hgimg4のフォルダで実行 gpfloor id,100,100,$8899FF:setpos id,0,-10,0 //床生成 gppbind id,0,0.5 //床に物理設定 repeat 2 //2種類の図形を生成 //なんか適当な物体を生成する処理 gpmeshclear:idMax=0 //ポリゴンリセット type=3+cnt\2 //三角ポリゴンか四角ポリゴンか指定 height=8.0 //ろくろの形状ごとの高さを指定 ddim size,1 //ろくろの形状(幅) if cnt=0:size=1.5,8.0:ccc=$99FFAA //ろくろの形状と色を登録(1回目) if cnt=1:size=1.5,8.0,4.0:ccc=$FFAA99 //ろくろの形状と色を登録(2回目) repeat length(size):y=cnt //形状情報数でループ repeat type //ポリゴン分の頂点を生成 fv=sin(m_pi/type*2*cnt)*size(y),height*y-2,cos(m_pi/type*2*cnt)*size(y) gpmeshadd IDs(idMax),fv,fv(1),fv(2),fv,fv(1),fv(2),0,0:idMax++ loop loop if idMax<4:end //ろくろが生成されていない if type=4:{ //四角ポリゴンで作るろくろ gpmeshpolygon IDs(3),IDs(2),IDs(0),IDs(1) //蓋 gpmeshpolygon IDs(idMax-4),IDs(idMax-3),IDs(idMax-1),IDs(idMax-2) //底 }else:if type=3:{ //三角ポリゴンで作るろくろ gpmeshpolygon IDs(2),IDs(1),IDs(0) //蓋 gpmeshpolygon IDs(idMax-3),IDs(idMax-2),IDs(idMax-1) //底 }else{ end //それ以外のポリゴンは認めない } repeat type*(idMax/type-1) //ろくろの側面を生成 id=cnt\type+cnt/type*type,(cnt+1)\type+cnt/type*type gpmeshpolygon IDs(id),IDs(id(1)),IDs(id+type),IDs(id(1)+type) loop repeat 5 //5個のろくろをランダム配置 gpmesh id,ccc:setang id,0.01*rnd(628),0.01*rnd(628) setpos id,rnd(60)-30,10+cnt*height,rnd(60)-30 gppbind id,1,0.5,GPPBIND_MESH //ろくろはメッシュで物理形状判定 gppset id,GPPSET_GRAVITY,0.0,-20.0,0.0 loop loop repeat //メインループ fv=sin(0.01*(ginfo_winx/2-mousex))*80 // マウスで fv(1)=0.1*(ginfo_winy/2-mousey) // カメラ fv(2)=cos(0.01*(ginfo_winx/2-mousex))*80 // 操作 setpos GPOBJ_CAMERA,fv,fv(1),fv(2) gplookat GPOBJ_CAMERA,0,0,0 redraw 0 //描画開始 color:boxf gpdraw color 255,255,255:pos 30,30:mes "フリーダムすぎる^^;" redraw 1 await 16 loop

この状態で作品制作にフリーメッシュを(特に物理で)利用されている方は今のところ存在するのかもかなり怪しい気がしています。
個人的には…ですが、もう現時点までのフリーメッシュの仕様や互換性は正直どうでもいいので、
実際の作品制作を想定した仕様に刷新した方が良いような気がしています。
ここまでおかしな動作ですと、旧バージョンとの互換性を取るフラグもかえって混乱の元なのでこの際要らないと思っています。


P.S:
上記のサンプルで物体の見た目がヌルッとしているのは頂点を使いまわしている結果なんですが、
頂点は使いまわしつつ面ごとにUVや法線を設定することはできないのでしょうか?
(内部的に意味のある事かはわかりませんが)現状のHgimg4で面ごとに法線やUVを設定しようとした場合、
同じ座標の頂点を使う面が複数あっても面の数だけ同じ座標の頂点を再登録する必要があり、メモリを相当無駄遣いするような気がしています。


↑このような4つの四角面を持つメッシュを生成しようとした場合、頂点が使いまわせれば頂点情報は9個で済みますが、
面ごとに法線やUVを設定しようとした場合頂点は使いまわせず、16個の頂点を登録する必要があり、
特に中央の頂点は4つの面に利用されてますから、4回も同じ座標を再登録するハメになりますよね。
なんだか凄くメモリの無駄遣いをしている気がするのですが^^;;;
(三角ポリゴンで形成しようとした場合は更に増えて24個の頂点が必要に。9個 → 24個… うぅ…ん)



アキアキノヒロロ

リンク

2022/6/25(Sat) 18:10:44|NO.96720

Drip さん、このようなスレッドに、ご反応頂き、ありがとうございます。

「互換性」について、
> HSP3.51までは物理動作がscaleを考慮せずに判定していた時代があります。
よく調べもせずにいたこと、反省いたします。
バグとして存在していたものを残すために互換を取る、ということがあり得るのか、
などとの決めつけに邪魔されて、テストを怠ってしまいました。
> 使いようによっては任意で少し壁にめり込んで見える
> 物理動作モデルの生成等に使うことができますよ。
例えば、壁に当たって跳ね返るボール、とかかな。他にどんなのがあるかな?

フリーメッシュに関して
物理でフリーメッシュを利用のサンプル、ありがたいです。
ここまでになると、この命令、物理での設定はエラーになるようにするとか、
したほうがいいかもですね。
ただ、私は、[E3D] の起伏地面作成と同等の機能を、[gpmeshpolygon] を使って、
[hgimg4] でも出来ないか、とテスト中ですので、[gpmeshpolygon] 自体は残して
おいてほしいな。
> 実際の作品制作を想定した仕様に刷新した方が良い
そうおっしゃるDrip さんも、この命令いらない、とまでは思ってらっしゃらない
ですよね。



アキアキノヒロロ

リンク

2022/6/25(Sat) 18:16:04|NO.96721

ギバロウ さん、すいませんでした。

> 「GPPBIND_NOSCALE」は過去バージョンとの互換性のためのもの

勝手に、バグだと決めつけて、確認を怠りました。



Drip

リンク

2022/6/25(Sat) 18:51:32|NO.96724

アキアキノヒロロさん

>[gpmeshpolygon] 自体は残しておいてほしいな。
>> 実際の作品制作を想定した仕様に刷新した方が良い
>そうおっしゃるDrip さんも、この命令いらない、とまでは思ってらっしゃらないですよね。

もちろんでございます^^;命令は廃止になっても機能まで廃止してほしいとは考えておりません。
メッシュの現行の仕様では非常に扱いにくく動作もおかしいため、扱いやすく正しく動くように整備し直していただければ有り難い…ということです。
その整備に際して現在のおかしな動作を残して互換性を取る必要性はあまり感じられない…という意味です。
まだ実装間もない段階かつ正しく動作していない今ならば、アップデートに際してGPPBIND_OLDMESH等のフラグを用意して旧バージョンの変なメッシュ動作を残したり、旧バージョンの動作を意識するあまり新しい使い易い仕様の導入をためらう必要はないのではという意味です。

フリーメッシュ機能自体は私も待ち望んでいる機能ですので是非とも使えるようにしていただきたい気持ちです。
例えばgpmeshadd命令はパラメータが9個もあり、座標・法線・UVを一度に指定していますが、これが最適な仕様なのか少し疑問に感じた部分は前投稿でP.Sに具体示しています。
別の命令で極端に例えるならば、例えばmes命令が 「mes 使用フォント,サイズ,描画座標X,描画座標Y,描画文字列」 みたいに書く仕様だったらかなり使いづらいですよね;覚える命令は1つで済みますが…

>> 使いようによっては任意で少し壁にめり込んで見える物理動作モデルの生成等に使うことができますよ。
>例えば、壁に当たって跳ね返るボール、とかかな。他にどんなのがあるかな?

例えば重い鉄球が土の上に正確に接地してたらおかしいですよね;
鉄球は少し地面にめり込んで見えるほうが自然かもしれません。
逆にアイテムオブジェクトなんかはscaleを小さくすることで壁や地面から少し離れてぶつかるようにすると浮いて見えるため、視認性に一役買ったりするかもしれません。



アキアキノヒロロ

リンク

2022/6/25(Sat) 20:17:21|NO.96727

ここの『ひとりごと』でなく、
『HSP3.7に向けたβテストについてのお願い』の方に、レスされた方が相応しい内容に
なってきましたね。
ここのスレッドを、おにたま さんが要望として読まれることは、
私としては、想定しておりません。
Drip さん、お願いします。



アキアキノヒロロ

リンク

2022/6/27(Mon) 10:38:22|NO.96738

逆引きサンプル集について。
以前、どこかに似たようなこと書いたけど。

使えるサンプルを見つけたり、自分で作った時、それを保存しておくのは当然だけど、
数多くなってくると、いざ使おうとした際に、
「あのやつはどこやったっけ。どれだっけ」となることがよくある。

そのため、一つのフォルダにまとめてあるんだけど、
そうしていても、これまた溜まってくると、その中から探すのも厄介。
サンプル集フォルダにはしたものの、逆引きに都合がいいようなファイル名になってない。

この間、それがしやすいような名前に変えたんだけど、
日本語名にすると、HSPの『日本語ファイル名嫌い』(フォルダ名も)にひっかかりそうで、
英数字名にしてる。
でもそうすると、やはり逆引きで探しづらい。
分類別フォルダ分けもしたいけど、自作素材使ってたりすると、
[res]があっちにもこっちにも状態でイヤになる。

ここは、やはり日本語名が一番だ。
『日本語名嫌い』の対策として、カッコ付けで英数字名もプラスした形にしようかな。
『日本語名(英数字名).hsp』な感じ。
『日本語名嫌い』にひっかかるなと思った場合は『英数字名.hsp』で使うように、だな。



アキアキノヒロロ

リンク

2022/7/7(Thu) 08:09:11|NO.96757

ダイアログについて感じたことと同じことを、画像についても感じてしまいます。
何かというと、[hgimg4] は、その方向性がゲーム向けになっていて、
ツール開発向けは、もっぱら、[basic] にお任せといった感じで、
[hgimg4] そのもので、[hgimg4] ツール開発をするようにはなっていないんだ、ということです。
何も、[hsp3] のツール開発などといった大げさなものでなく、ちょっとしたことを
しようとすると、[hgimg4] では使えない命令であったり、データであったりするということです。

[hgimg4] では、ダイアログも、ファイルOPEN等以降のものは、標準や警告の [dialog] と同等には
実装になっておらず、一手間もふた手間も要ります。
画像について言えば、[hgimg4] で扱う画像は、[png] が主で、それ以外のものは、
マテリアルでの画像指定での [tga] くらいしか思い浮かびません。
[png] を画像保存したくとも、画像保存の命令は、[bmpsave] しかなく、保存後の処理として、
これまた、プラグインとかモジュールの手を借りることになります。

[hgimg4] では、[button]等、ツール用のオブジェクトが使いづらかったり、
サポートされてなかったり。
こちらの方面も、バージョンアップに入れてもらえると、いいんですけど、
[hsp3dish]のスマホ関係もあって、一概に何でもとはいかないんでしょうが、
それ用のパラメーターかなにかの設定で、[hgimg4] でも使えるようになるとか。

一貫して [hgimg4] で行くことは出来ず、[hgimg4] に入る前とか出た後とかに
そういった処理をするとか済ませておくとか、になってしまう。
ツール開発向けとは言わずとも、出はいりしたり、手間が要ったりすることなく、
もう少し、直接的にこれらのことが、[hgimg4] で出来るといいのだけれど、と思ってしまう。



アキアキノヒロロ

リンク

2022/7/19(Tue) 16:48:16|NO.96825

zrs90(5さい) さんが立てられた「○hgimg4、3DCG関係の情報等についてのスレッド」に
以前、次のように書きました。

> blender用の『複数アクション一本化FBX出力』アドオン。
> 誰か、作ってくれないかな。

確かに、これあると便利だな、とは思うけれど、需要は少ないようにも思える。
フリー等、手にはいる3Dブレンダーファイル等は、複数アクションが別ラインで
収められていることが殆どだから、それを [HSP3] で利用しようとすれば、
一本化しないといけない。
でも、[HSP3] でゲームを作るために3Dキャラクタを用意する人の多くは、
最初から自分でblender等でキャラクタを作るように思える。
だとすれば、一本のラインに必要な複数アクションを組んでいけばいいだけの話だ。
あるいは、別ラインで作った後、一本にしたものも作ればいい訳だ。自分でそうする分には、
それ程苦にならないし。

という訳で、もうこの話は無しにしてもいいか。
ただ、[HSP3] サンプルに付属の
[high_school_girl.fbx] [high_school_girlSD.fbx]
これの改変再録にあたっては、「複数アクション一本化FBX」も同梱してほしいな。



アキアキノヒロロ

リンク

2022/7/19(Tue) 21:02:46|NO.96828

感じ方の違いでしょうか。

モーションの一部を変更するのは、
複数アクションを組んでいるそのラインのその変更部分を変えればいいだけ、
後は、そのアクションの指定範囲の変更を登録し直せばいい訳で、
それ程手間が多すぎるとまでは感じないですが。
アクションの指定範囲が元のものより長くて、元の位置に収まらない時は、
ラインの最終にあらたに付け加えればいいだけだし。

やり慣れれば、考えようによっては、かえって確認作業になっていいようにも。


そもそも、アニメーションは、[gameplay3d] に負っているものです。
別々に [hgimg4] に読み込んだものを、[hgimg4] 上で繋げることが出来たとしても、
[gameplay3d] は、一つのモデルとして、一つのgpbファイルを読込むことで、
そのアニメーションを再生しているのでしょうから、読み込む時点で、一対一に
なっていないと無理のように思えるのですが、これは、[gameplay3d] に負っている
以上、仕方ないことでしょう。



アキアキノヒロロ

リンク

2022/7/20(Wed) 12:52:48|NO.96833

NO.96828 の内容が何故か浮いてしまいました。


ある方がこの直前に、NO.96825 の私のひとりごとに対して、

blenderのアドオンではなく、別々に読込んだものを[hgimg4]上で繋げられるようにして欲しい。
モーションの一部を変更した場合、また一つにまとめなければならず、手間が増えて厄介。

という意味のことをおっしゃられた( NO.96827 ? 何故か、現在、削除されています)ので、
それに対して思ったことを書いたのが、上の NO.96828 です。


お含みおき下さい。



アキアキノヒロロ

リンク

2022/7/28(Thu) 18:06:52|NO.96871

[hgimg4] の ライトについて、あれこれ試しています。

ライト効果の表現は、結局、どのように色を変化させて表示するか、
ということだと思うのだけれど、
具体的には、何んらかの色合成をしているのだろう、と想像。
それを確かめるため、検証プログラムを作ってみています。
https://twitter.com/akiakinohiroro/status/1551650898429952000

上記に続くツイッターであれこれ四苦八苦してやってみたところ、
どうも、ライトは、乗算の色合成で表現されているように思えてきました。
これって、合っているんでしょうか。
もし、そうなら、この、乗算の色合成、使って、ライト様のことが
自前でなんとかできそう、なんて希望を持ってしまう。



youdai

リンク

2022/7/28(Thu) 20:49:20|NO.96872

>ライト効果の表現は、結局、どのように色を変化させて表示するか、
HGIMG4の標準のシェーダーのColoredとTexturedのいわゆる「光源(ライト)」は、乗算系だと思います。
例えば、RGBのカラーでモデルの表面色の1.0,1.0,1.0に対し、光源色1.0,0.0,0.0とすると、式としては1.0*1.0,1.0*0.0,1.0*0.0となります。
これは現実の光源の仕組みとは異なることに注意してください。(現実の光源は上記のようなシンプルな乗算系ではなく、もっと複雑な過程の式になる)



アキアキノヒロロ

リンク

2022/7/29(Fri) 06:49:39|NO.96873

> 現実の光源の仕組みとは異なる

私の拙い検証プログラムで見てみても、乗算の色合成そのままではないにしても、
ほぼそれと言っていいものになっていることは、確かめられていますが、
だからと言って、実際、現実の光源の仕組みが、これで忠実に再現されているとは
もちろん思っていません。
ただ、[hgimg4] のライトの仕組みに興味があって、試してみたのです。


また、私のツイッターの方に、zakki さんが返信を寄せてくださいました。
https://twitter.com/k_matsuzaki/status/1552599783474601991

OpenHSPは、私の実力を超えたところにあるので、御紹介のもの、理解に甚だ時間を
要しそうです。
ただ、[shaders/lighting.frag]が、ライトの働きを担っていることは、分かりました。
そして、Wikipediaがとても参考になりました。
https://ja.wikipedia.org/wiki/Phong%E3%81%AE%E5%8F%8D%E5%B0%84%E3%83%A2%E3%83%87%E3%83%AB



アキアキノヒロロ

リンク

2022/7/29(Fri) 07:07:07|NO.96874

ライトが当たるものの、もともとの色(RGB値)が基本になっていて、
それに鏡面反射や拡散反射、環境反射といった係数を掛けて、算出しているんですね。

もちろん、乗算の色合成そのままはあり得ないですが、
もともとの色(RGB値)に掛け算してる訳だから、似たような感じになるんですね。
そして、RGB値に色成分(0)があれば、掛け算しても、その色成分は、(0) だよね。
共通する色要素がないと、機能しないのは、こういうことかな。



アキアキノヒロロ

リンク

2022/7/29(Fri) 07:52:03|NO.96875

GENKI さんの「GHP(仮)/hgimg4/シェーダー」で紹介されている
『wgld.org WebGL contents』の次の項も、とても参考になりますね。

平行光源によるライティング
環境光によるライティング
反射光によるライティング



youdai

リンク

2022/7/29(Fri) 12:12:01|NO.96878

>だからと言って、実際、現実の光源の仕組みが、これで忠実に再現されているとはもちろん思っていません。
現実の光源の仕組みに比較的近いものとして物理ベースシェーディングがありますが、HGIMG4の標準シェーダーはその物理ベースシェーディング系ではないという意味で噛み砕いて「現実のそれとは違う」と書きました。
HGIMG4は物理ベースシェーディング系でこそないのですが、その代わりパラメータの設定が単純なので初心者にはむしろシンプルな現状の非物理系の方がいいかもしれません。
例えば物理ベース系の比較的有名なものとしてはBlenderのブリンシブルBSDFがありますが、あのパラメータを初心者が理解するのはかなり難しいかもしれません。
また、物理ベース系のシェーダーは比較的に非常に動作パフォーマンスの悪い重いシェーダーになりやすいので、ゲームに適しているかどうかはかなり判断の難しいところです。(といっても、最近の商業ゲームのほとんどが物理ベース系のものなのだとは思うのですが)

>それに鏡面反射や拡散反射、環境反射といった係数を掛けて、算出しているんですね。
いや、HGIMG4の標準シェーダーには鏡面反射の概念はないと思います。実際に.materialのパラメーターとしてもありませんよね。
あるのは古典的なスペキュラーの強度を操作するだけのu_specularExponentがあるだけのはずです。
マテリアル表面への鏡面反射を実装するには、シェーダーを自作する必要があります。



アキアキノヒロロ

リンク

2022/7/31(Sun) 12:22:54|NO.96891

youdai さん、いつもレスして頂き、感謝しています。
ただ、これ以上の話は、ひとりごとの域をこえてしまいますし、
私の能力も体力気力も続きそうにありませんので、潔く引き下がります。

共通する色要素がないと、ライトが機能しないようなのは、
どうも仕様上、そうなるものなんですかね。
ライトを当てても、照らされている様子が見えない、なんてことが起こっては困るので、
プログラムを組む時、このことに留意して、色設定には気を付けようと思うばかりです。



アキアキノヒロロ

リンク

2022/8/14(Sun) 07:27:34|NO.96954

youdai さんの、
> HGIMG4のフレームレートに関係するawaitの適切な値について報告します
を読んでいて、リフレッシュレートが64 Hzのディスプレイなんてあるんだ、と初めて知りました。
で、自分のを調べてみると、なんと、60.003Hz、となっていました。なんなんだ?

120とか、240なんて高速なのもあるのは、知っていたけど、60の倍数。
[await]が、1000/60 のままでも、120 のリフレッシュレートの2回のタイミングで、
HGIMG4 は、1回、書換えが行われる訳で、ズレはないからいいんだ。そう思ってました。
でも、64 Hz じゃあズレがでるから、画面がちらつく。
GENKI さんのおっしゃる垂直同期、かつ「await 0か、1」で対応できるとのこと。

でも、Hgimg4の場合、アニメーションと、物理の2つを組み込んでいるとなると、
アニメーションを作るために使っている単位時間と、物理を扱っている[Bullet]が使っている
単位時間もあって、ややこしくなる。アニメーションの方は、
> setreq SYSREQ_FIXEDFRAME,____
で、フレームレートに応じたアニメーションの更新を行なうことができるからいいとして、
[Bullet]が使っている単位時間は、60 Hz で、これは変えられない。
物理データの更新タイミングをディスプレイのリフレッシュレートに合せることは出来ないから、
物理挙動がなめらかさに欠けることがあるかも知れない。
まあでも、物理挙動は、所詮、擬似的なもので、普通には細かいことを求めないし、
ズレがあったとしても、それそのままを物理挙動として受け入れれば済むことだし。

結局のところ最終的には、ディスプレイ(モニタ)が映し出すのだから、アプリケーションの
フレームレートを、ディスプレイのリフレッシュレートに合わせるのが当然か。


自分としては、それより、もともと3D描画で負荷が大きいHgimg4では、同じ[await]でも、
設定選択等によって、速度の違いが極端なことの方が気がかり。
バッファを使った処理をすることになるプログラムは、PCに掛かる負荷がより大きくなる。
バッファ処理をしない設定選択をすると、めちゃくちゃ速くなって困ってしまう。
これを上手く調整したとしても、PCの性能次第ということで、公開するとなると、その人の
PC性能に左右される。困った、困った。



アキアキノヒロロ

リンク

2022/8/14(Sun) 07:35:32|NO.96955

> PC:フレームレート・垂直同期・リフレッシュレート
https://tkent.blog.jp/archives/27872387.html

ここが一番参考になったけど。



アキアキノヒロロ

リンク

2022/8/18(Thu) 11:57:25|NO.96971

波間にプカプカ浮かぶアヒル。
アヒル自身が動かなくても、水面の動きでプカプカ。
これを何とか出来ないか、考え中。

https://twitter.com/akiakinohiroro/status/1560058226053632000

水面の動きは、次のを利用かな。
https://twitter.com/genki_hsp/status/1559898569855086592



zrs90(5さい)

リンク

2022/8/20(Sat) 22:39:00|NO.96987

接続ケーブル等について
書いてる方がいなかったので
ここに残しておきます。

インチキ仕様ケーブルとか
モニター側の接続端子の接続位置
(※モニター側の仕様)によっては
グラボ本来の性能が出ない場合が
あります。

ちなみにWikipediaのリンクを載せたのは
今後規格が追記/修正される可能性があり
調べる際、都合が良さそうだからです。


●DisplayPort
https://ja.m.wikipedia.org/wiki/DisplayPort

●DisplayPort2.0
https://gigazine.net/news/20220301-certify-label-display-port-2-0/

●HDMI
https://ja.m.wikipedia.org/wiki/HDMI

●接続ケーブルの話
https://chimolog.co/bto-gaming-monitor-hdmi/

※HDMI 2.1a と言う
2.1 のブラッシュアップ版の
モニター端子規格が進行中ですが
まだ対応モニターは出ていないようです。
DisplayPort 2.0 についても同様の様です。


● 可変リフレッシュレート
https://ja.m.wikipedia.org/wiki/可変リフレッシュレート

2022年7月?の時点でリフレッシュレート360hzに対応したモニターが市場に。下記の記事によると近々500hzも投入予定。

https://pc.watch.impress.co.jp/docs/news/1411/515/amp.index.html


眉唾モノ?のネット記事があり、
ここではリンク先を省略しましたが
各モニターメーカーの目標はリフレッシュレート
1000hz(!!)との事。


●追記とか色々。

●私がここに書いた理由の1つはウチの4kモニターを
数年間、59hzで何の疑いもなく動かしてました(笑)
ふとos設定見たら60hzになってない。ぇ...
60hz設定出来るじゃん。何故???
NO.96954の記事見て直しました。
ありがとうございました。

↓後で気が付きましたがウチのはコレが原因かも?

https://support.microsoft.com/ja-jp/topic/windows-の画面のリフレッシュ-レートは-特定のテレビ互換のタイミングを報告する-モニターとテレビでユーザーが選択した設定を適用しません-0a7a6a38-6c6a-2aec-debc-5183a76b9e1d
  

●60.003Hzの件

細かい数値をどうやって出力させているか
存じませんが計算誤差範囲?ではないかなと。
cpuとかも2.4Ghzと言いながら
わずかに遅かったりするので。


●超高精度カウンターの件

QueryPerformanceCounterについて。

ここまで極端に精度が違うと
普通のタイマー系命令の意味って...
他の命令も何とか出来るんじゃないの?
MSさん。ただ処理が重そうですが。

3.7βスレッドのNO.96228で
窓月らら さんがおにたまさん
へ要望として出してました。
今後のhsp3に採用されるかは分かりません。


●blender3.2xの動作が重い件

メモリは出来れば16G以上。
blenderのGPU設定が
off状態になってませんか?
Yahoo知恵袋にも似たような
対処方法が載ってました。
調べる価値はあるかも。


●番外編(その1)
ファイルが見つからない!!(※Windows7版)

Twitter読ませて頂きました。
ファイルを削除していない事、
別の日にリネームツールの使用や上書きをしていない事が
前提になります。1日に10個以上
hspファイルを作っているとちょっと面倒かも。

エクスプローラーを使えばほぼ解決します。

ソースを保存しているドライブ、フォルダを指定

*.hsp を指定

アキアキノヒロロ さんの場合
ムービーをTwitterに上げた日が分かっているので
その日から、1日ずつ指定して遡れば
ファイルが見つかるはずです。


●番外編(その2)
hgimg4ファイル名日本語嫌いの対処

ファイル名は日本語ダメでも
ソース内に日本語コメントは入れられるので
ファイル先頭に複数行コメント
使って、日付、実験内容、次の課題とか
自由に記述してセーブ。

(※↑をサボる私の様な者には逆効果で
ファイルが混在して、整理出来ません。)


hsp3のsample\misc内のsampleview.hsp
の様なファイルセレクターを作って
内容を見れば良いです。
ソースの実行機能はなくて構いません。
ただしソースが、64KBを超えると
mesbox ではそのまま表示出来ません。
工夫が必要になります。



アキアキノヒロロ

リンク

2022/8/21(Sun) 13:51:27|NO.96992

zrs90(5さい) さん、いつも有益な情報等有難うございます。

大型テレビに、HDMI 接続して、安上がりに楽しもう、
なんてケチくさい考えを起こしたことありました。
何年も前のことですが、上手くいかなかった覚えがあります。
今回のことでも、HDMI ってどうなんだろう、と疑問に思いましたが、
テレビとパソコンの規格の違いもあるだろうと思い、今は興味ありません。

blender は、高機能すぎる面があり、どのバージョンもフリーで使えるのだから、
自分にあったバージョンでやっていければいいや、というクチです。
正直な話、私のパソコン、それほど高機能じゃありません。
買った当初は、3Dなど考えてもみなかったので、グラボはありません。
よって、GPUはなし。メモリも8Gですし、これでよく3Dやってるな、
と自分でも思います。
でも、自分が「HSP」で作るゲームは、3Dと言ってもタカが知れていて、
これでもまあ動いてくれますので、パソコンの買い替えを考える時期がきたら、
その時に検討しようと、そういったところです。

ファイルが見つからない件まで、ご心配いただき、恐縮です。
恐らく、手違いか、操作ミスで削除されてしまったようです。
デスクトップに作ったフォルダに収めていたのですが、
ある日、デスクトップ上のフォルダやファイルが全てなくなっていたのです。
何故なのか、その原因は分かりませんが、どうにか以前の構成に近い形にまで
再現できていますが、今回のゲームファイルはダメでした。
エクスプローラーの検索機能を一日稼働させてみたこともありましたが。
ある程度できたファイルで、重要だと思うものは、外付けディスクにコピーしていて
多くは、それで助かったのですが、件のものはまだコピーしていなかったのです。

これに懲りて、外付けディスクにコピーは、こまめにやってます。
一時期、「1日に10個以上、hspファイルを作っている」ことがありましたっけ。



アキアキノヒロロ

リンク

2022/8/24(Wed) 01:12:55|NO.97015

やっと、ブロコン、出品できる。
「迷路の島」をいじくっていて、思った。
これの面白味って、「ゾロゾロ関数」のお陰だな。

zrs90(5さい) さん、
いつか、「ゾロゾロ関数」のプログラムが見られない、って言ってましたね。
掲示板の次にところに載せてたのを発見。
自分で書いておきながら、忘れてました。

お恥ずかしい話、年とると、失くしたり、忘れたり......。

http://hsp.tv/play/pforum.php?mode=pastwch&num=94165#94165



アキアキノヒロロ

リンク

2022/8/27(Sat) 06:35:34|NO.97031

youdai さんの、
> HGIMG4で等速移動のeventを実装したい
を読んでいて、「あっ」と思った。

[E3D] の機能で [hgimg4] に取り入れたいものとして、
ナビライン作成ソフト[gviewer] を考えていたからです。

https://twitter.com/akiakinohiroro/status/1500816012358619144
https://twitter.com/akiakinohiroro/status/1510824304589807616
https://twitter.com/akiakinohiroro/status/1502944567859216387
https://twitter.com/akiakinohiroro/status/1504373564497342466

作りかけの [gviewer_もどき]、ナビポイント間隔を等分化して、
なめらかなナビラインに近付けなければ、と思いつつ、ほったらかしでした。
youdai さんのこれを組み込めば、出来る気がしてきましたが、
[event_pos]、使ったことなくて、要領のみこむのに時間かかりそうだし、
[event_pos] の補間オプションも、上手く働いてくれないことがあるようですね。

どうしようか、やるだけやってみるかな。
実際、やってみなければ、何も始まらないし......。


『ANIMAL_ISLAND + (ショートカット機能付)版』ブロコン出品できたのに欲かいてます。

この [gviewer_もどき]も、そしてついでに、
進路(移動可能領域)設定(by_画像)も、

https://twitter.com/akiakinohiroro/status/1541360655563104256

仮完成でもいいから、出せる形に持っていこうか......。



アキアキノヒロロ

リンク

2022/8/28(Sun) 12:01:04|NO.97034

「HSP3.7に向けたβテストについてのお願い」に載せた
エディタのバージョン表記の件ですが、
zezenana さんの"hsedver view"

http://hsp.tv/play/pforum.php?mode=all&num=94865#97000

使わせてもらっています。とても便利で重宝してます。
有難うございます。



アキアキノヒロロ

リンク

2022/8/29(Mon) 07:08:33|NO.97036

『ひとりごと』のスレッド、30以上に伸びてる状態。

個人の『ひとりごと』が掲示板の一部を占拠しているようで、

「これって、許されるのかな」
「不快に思ってる人いるんじゃないかな」
「そもそも、こんなに続ける『ひとりごと』は想定外か」
「単発程度のものが "ひとりごと" だろうが」
「ホームページか、ツイッターでやれよ」

あれこれ、感じてきていますので、このスレッド、
ここで打ち止めにします。



記事削除

記事NO.パスワード
(質問が解決したスレッドは他の利用者に活用してもらうため、削除しないようお願いします)

NO.96689への返信

マスコット

好きなマスコットを選んでください。

名前

e-mail
HOME
  1. 初めて利用する方は、HSP3掲示板の使い方をお読みください。
  2. 不要部分の多い長いスクリプトの投稿は ご遠慮ください。
  3. 書き込みは自動改行されません。適度に改行を入れてください。
  4. スクリプトは小文字の<pre>〜</pre>で囲むと見やすく表示できます。

削除用パスワード

エラー発生時、再送信すると二重送信になることがあります。
回答が得られたら、お礼書き込み時に[解決]チェックしてください。
SPAM防止のためURLから始まる文章は投稿できません。
SPAM防止のため英文字のみの本文を投稿することはできません。

ONION software Copyright 1997-2021(c) All rights reserved.