Discuss Scratch
- Discussion Forums
- » 日本語
- » 意外と知られていないテクニック集
- kinnniku_pi-mann
-
100+ posts
意外と知られていないテクニック集
#3995
正常に動作しましたが、見えにくいので
正常に動作しましたが、見えにくいので
ずっとのほうがよさそうですね。
[カウント v] を (1) ずつ変える
end
ずっと
(1) 秒待つ
[FPS v] を (カウント) にする
[カウント v] を [0] にする
end
Last edited by kinnniku_pi-mann (Jan. 7, 2024 01:37:23)
- inoking
-
1000+ posts
意外と知られていないテクニック集
(一時的な答えの正確さは別として)定義 FPS(2000年からの日数保存)
[色 v] の効果を (0) にする
[FPS v] を ((1) / (((2000年からの日数) - (2000年からの日数保存::custom)) * (86400))) にする
FPS(2000年からの日数)
上のような例は無限に再帰呼び出しされているため、原理的にはスタックオーバーフローなどでいつか破綻します。
再帰呼び出しには帰還条件が必要です。
- scratch-takayama
-
1 post
意外と知られていないテクニック集
クラウド変数付きのプロジェクトで、作品内で登録すると自動でメッセージじがくる仕組みを作っていました。どうやるのでしょう。ちなみに、@takechi-scratchさんの、https://scratch.mit.edu/projects/870204802/です。知ってる方ぜひお願いします。
- kouryou118103
-
1000+ posts
意外と知られていないテクニック集
[順番確認 v] を受け取ったときこれでできると思います。
[順番 v] を [0] にする
(([順番 v] の長さ :: list)の長さ) 回繰り返す
< ([list v] の(順番)番目 :: list)キーが押された> まで待つ
<< ([list v] の(順番)番目 :: list)キーが押された>ではない>まで待つ
[順番 v] を (1) ずつ変える
end
…
[どれかの v] キーが押されたとき
もし < < ([list v] の(順番)番目 :: list)キーが押された>ではない > なら
[このスプライトの他のスクリプト v] を止める:: stack
[順番確認 v] を送る
end
追記
2つ目のスクリプトで、ハットブロックから1つ目のスタックブロックに移行するのに時間がかかるのでそこでバグが発生するかもしれません。
Last edited by kouryou118103 (Jan. 28, 2024 11:42:47)
- kouryou118103
-
1000+ posts
意外と知られていないテクニック集
Last edited by kouryou118103 (Jan. 28, 2024 12:49:54)
- -_make_game_-
-
11 posts
意外と知られていないテクニック集
既出だったらごめんなさい
定義 FPS算出
[FPS v] を ((1) / ((タイマー) - (FPS計算用))) にする
[FPS計算用 v] を (タイマー) にする
定義 main
ゲームの処理
FPS算出
[ゲームスタート v] を受け取ったときでFPS算出機能付きのゲームを作成できます。定義「main」は「画面を再描画せずに実行する」を入れないと正しく動作しないので注意してください。また、
ずっと
main
end
<マウスが押された>などのブロックは True か False のどちらかを返しますが、
(() + <マウスが押された>)にするとTrueなら1を、Falseなら0を返すようになります。実用性はあまり無いかもしれませんが…(苦笑)
- _inosisisamaaonly
-
8 posts
意外と知られていないテクニック集
[return v] を ([e^ v] \( (([in v] \( (A) \))) * (B)) \)) にする
これはA(A=>0)を底数とするB乗の値を返す式です。例えばA=10 B=1.5とでもすると≒32の値が返ってきます。これはscratchが上手くなればなるほど使う場面が増えてくるので覚えておきましょう。
Last edited by _inosisisamaaonly (Jan. 31, 2024 04:09:56)
- kouryou118103
-
1000+ posts
意外と知られていないテクニック集
(((B) * ((A) の [ln v]::operators)) の [e ^ v]::operators)これで
((A)^(B)::operators)が作れますが、A>=0の時しか動作しません。
- HexaHorn6530
-
4 posts
意外と知られていないテクニック集
スクラッチは30fps(1秒間に30回描画される)なので、描画に関係するブロックを挟むことで比較的正確に時間を測り、かつ他の条件も並列することができます。
また、
条件分岐などが大量に含まれる大きなループでは、1Fの遅延を挟むだけで処理が必要以上に頻繁には行われなくなり、軽くなります。タイマーのスクリプト以外にも
⚑ がクリックされたとき上のサンプルコードでは、300フレーム、すなわち10秒を正確に測るだけでなく、この間にスペースキーが押されればループから抜ける事ができる。他の条件をいくらでも並列できるのは意外と便利です。タイマーでfpsを計測するコードも含まれています。「1秒あたりのループ回数」は30に近くなるはずです。これは分かりやすくするためのものなので、抜いて良いです。
[フレーム数_30fps v] を [0] にする
[1秒あたりのループ回数 v] を [0] にする
[実際に測った時間(秒) v] を [0] にする
タイマーをリセット
< < (フレーム数_30fps) = [300] >または <[スペース v] キーが押された>> まで繰り返す
表示する
隠す
[フレーム数_30fps v] を (1) ずつ変える
[1秒あたりのループ回数 v] を ((フレーム数_30fps) / (タイマー)) にする
end
[実際に測った時間(秒) v] を ((フレーム数_30fps)/(30)) にする
また、
隠すでは1フレームの遅延が発生しないことに注意。おそらく「描画しないブロック」に該当するからであろう。
条件分岐などが大量に含まれる大きなループでは、1Fの遅延を挟むだけで処理が必要以上に頻繁には行われなくなり、軽くなります。タイマーのスクリプト以外にも
表示するや
表示するを挟むのは大いに意義があると思います。
隠す
Last edited by HexaHorn6530 (Feb. 8, 2024 07:26:34)
- HexaHorn6530
-
4 posts
意外と知られていないテクニック集
[return v] を ([e^ v] \( (([in v] \( (A) \))) * (B)) \)) にする
これはA(A=>0)を底数とするB乗の値を返す式です。例えばA=10 B=1.5とでもすると≒32の値が返ってきます。これはscratchが上手くなればなるほど使う場面が増えてくるので覚えておきましょう。
上の2つを(自分の解釈で)解説します。AのB乗を考える。(((B) * ((A) の [ln v]::operators)) の [e ^ v]::operators)これで((A)^(B)::operators)が作れますが、A>=0の時しか動作しません。
((A)の(In ))はネイピア数eを何乗すれば( )の数になるか?という値を返す。(wikiより。)
((A)の(e^ ))はネイピア数e = 2.71828…を何乗かしたときの結果を返す。(wikiより。) つまり、
((A) の [ln v]::operators)はネイピア数eを何乗すればAになるか?という値を返す。これよりe^((A)の(In )) = A
つまり
(((A) の [ln v]::operators) の [e ^ v]::operators)= A
両辺をB乗すると{e^((A)の(In )))}^B = A^B
指数は(a^2)^2 = a^4のように計算できるから、A^B = e^{((A)の(In ))*B}
これをスクラッチのブロックで表すと、A^Bは、
(((B) * ((A) の [ln v]::operators)) の [e ^ v]::operators)となる。
- AKYARA
-
36 posts
意外と知られていないテクニック集
絶対もう書かれていますが、移動のプログラムを手っ取り早く組む時、私は
ずっとと書いています、早く組めて斜め移動にも対応してるのでオススメです
x座標を (<[右向き矢印 v] キーが押された> - <[左向き矢印 v] キーが押された>) ずつ変える
y座標を (<[上向き矢印 v] キーが押された> - <[下向き矢印 v] キーが押された>) ずつ変える
end
Last edited by AKYARA (Feb. 7, 2024 07:12:52)
- inoking
-
1000+ posts
意外と知られていないテクニック集
#4006:
フレーム回数で時間が計れるのは一定の条件を満たしたときだけです。
時間を計るのなら
素直に「2000年からの日数」や「タイマー」で経過時間を計ったほうがよいでしょう。
また、「タイマーは重たい」はどこから来たのでしょう?
「重い」とは実行が遅くなるという意味ですか?
(「比較的正確に」とはありますが) スクラッチは30fps(1秒間に30回描画される)なので、描画に関係するブロックを挟むことで比較的正確に時間を測り、かつ他の条件も並列することができます。
~略~
上のサンプルコードでは、300フレーム、すなわち10秒を正確に測るだけでなく、この間にスペースキーが押されればループから抜ける事ができる。他の条件をいくらでも並列できるのは意外と便利です。「(10) 秒待つ」とは違うのだよ、「(10) 秒待つ」とは。
なお、タイマーでfpsを計測するコードも含まれています。「1秒あたりのループ回数」は30に近くなるはずです。これは分かりやすくするためのものなので、抜いて良いです。タイマーは重たいですし。
フレーム回数で時間が計れるのは一定の条件を満たしたときだけです。
時間を計るのなら
素直に「2000年からの日数」や「タイマー」で経過時間を計ったほうがよいでしょう。
また、「タイマーは重たい」はどこから来たのでしょう?
「重い」とは実行が遅くなるという意味ですか?
- HexaHorn6530
-
4 posts
意外と知られていないテクニック集
#4006:「重い」とは実行が遅くなるという意味です。なぜかというと、以前私がゲームを作っていた時に、タイムアタックの記録用にタイマーを使ったらいきなり実行速度が遅くなり、それ以来あまり使うのを極力避けるようになったからです。タイマーは常に動作しているというのを初めて知りました。あの時実行速度が遅くなったのはタイマーを変数のようにステージに表示していたことが原因かもしれません。私の知識不足と思い込みでした。すみません。私はフレーム単位での時間の計測を「◯◯フレーム以上ボタンが押されていればプログラムAを実行し、◯◯フレーム以内にボタンが離されていればプログラムBを実行する」のような使い方をしています。タイマーほどではないですが、短時間であれば比較的正確に時間を測れますし、同じタイマーを共有することによって生じる条件分岐、計算などを気にしなくて良いので手軽に使っています。
(「比較的正確に」とはありますが)
フレーム回数で時間が計れるのは一定の条件を満たしたときだけです。
時間を計るのなら
素直に「2000年からの日数」や「タイマー」で経過時間を計ったほうがよいでしょう。
また、「タイマーは重たい」はどこから来たのでしょう?
「重い」とは実行が遅くなるという意味ですか?
例えばこんな感じ。↓
⚑ がクリックされたときしかし、長い時間を測ったり、精度を重視したりするのならタイマーで時間を計ったほうが良いのではないかと思います。
[フレーム v] を [0] にする
ずっと
表示する
もし <[右矢印キー v] キーが押された> なら
x座標を (5) ずつ変える
<<<[右矢印キー v] キーが押された> ではない> または <(フレーム) = [30]>> まで繰り返す
表示する
[フレーム v] を [1] ずつ変える
end
もし <(フレーム) = [30]> なら
<<[右矢印キー v] キーが押された> ではない> まで繰り返す
x座標を (10) ずつ変える
end
end
[フレーム v] を [0] にする
end
end
※「ずっと」の中の最初の「表示する」は処理を軽くするためのものです。
2024/03/14 追記 : 「0秒待つ」でも約1Fの遅延が発生するとのことです。「表示する」などよりも扱いやすいと思いました。
Last edited by HexaHorn6530 (March 14, 2024 02:36:29)
- inoking
-
1000+ posts
意外と知られていないテクニック集
はい、特性を理解したうえで使うぶんには何の問題もありません。 私はフレーム単位での時間の計測を「◯◯フレーム以上ボタンが押されていればプログラムAを実行し、◯◯フレーム以内にボタンが離されていればプログラムBを実行する」のような使い方をしています。タイマーほどではないですが、短時間であれば比較的正確に時間を測れますし、同じタイマーを共有することによって生じる条件分岐、計算などを気にしなくて良いので手軽に使っています。
「単にフレーム回数で時間が計測できる」ではないということが言いたかったので。
なお、タイマーの使い方についてはこちらも読んでみてください。
Last edited by inoking (Feb. 8, 2024 03:08:32)
- -_make_game_-
-
11 posts
意外と知られていないテクニック集
気になったため検証してみました。
全く関係無いけどいちいち @greenflag がクリックされたとき と入力しないと一番上のこのブロックを出せないのがちょっと面倒。
(以下、「フレーム」は「F」と略します)
また、このプログラム内で使用されているFPSの算出方法は実は「開始から今までの平均FPS」になってしまっており、最初の数Fの間は実際とはかなり離れた値が出てしまいます。毎FリストにFPSを記録するようにして調べた所、開始して1Fの時の値はInfinity、2Fの時は60前後、100F時点で約30.6、1000Fで約30.3、と少しずつ実際の値に近づくものの、実際のFPSとは違う値となっています。
正確なFPSを求めたい場合は、
全く関係無いけどいちいち @greenflag がクリックされたとき と入力しないと一番上のこのブロックを出せないのがちょっと面倒。
@greenflag がクリックされたとき#4006を参考に上のようなコードを作り、実行してみました。何度か実行した結果、「かかった時間」の値はおおよそ9.9前後になりました。300の部分を6倍の1800に変えた時、「かかった時間」の値が59.4になった事から、恐らくscratchのFPSは30ぴったりでは無いのでしょう。(重いプログラムでなければ大体30.3くらいになるはず…)
[経過フレーム v] を [0] にする
タイマーをリセット::sensing
<(経過フレーム) = [300]> まで繰り返す
表示する
隠す
[経過フレーム v] を (1) ずつ変える
[FPS v] を ((経過フレーム) / (タイマー::sensing)) にする
end
[かかった時間 v] を (タイマー::sensing) にする
(以下、「フレーム」は「F」と略します)
また、このプログラム内で使用されているFPSの算出方法は実は「開始から今までの平均FPS」になってしまっており、最初の数Fの間は実際とはかなり離れた値が出てしまいます。毎FリストにFPSを記録するようにして調べた所、開始して1Fの時の値はInfinity、2Fの時は60前後、100F時点で約30.6、1000Fで約30.3、と少しずつ実際の値に近づくものの、実際のFPSとは違う値となっています。
正確なFPSを求めたい場合は、
定義 FPS算出 (何Fの平均か)のようなコードを組んで毎F呼び出せば直近数FのFPSの正確な値が算出可能かと思います。
もし <([平均FPS算出用 v] の長さ :: list) = (何Fの平均か::custom-arg)> なら
[平均FPS算出用 v]の(1)番目を削除する::list//古く不要なデータは削除する
end
(((((1) / ((タイマー) - (FPS算出用))) * (10)) を四捨五入) / (10)) を [平均FPS算出用 v] に追加する//このFのFPSを小数第一位まで求めています
もし <((経過フレーム) を (何Fの平均か::custom-arg) で割った余り) = [0]> なら//毎FごとにFPSを変えると見ずらいため
[FPS v] を (平均の算出プログラムを書くと長くなるので割愛::undefined) にする//こちらも小数第一位程度までの四捨五入を推奨
end
[FPS算出用 v] を (タイマー) にする
- yucca42
-
100+ posts
意外と知られていないテクニック集
苦戦しがちなサロゲートペアの判定
追記: scratchblocksバグった…
追記: scratchblocksバグった…
定義 サロゲートペアかどうか (1文字目) (2文字目)
[\\uD7FF v] を [] にする
[\\uDC00 v] を ([
Last edited by yucca42 (Feb. 12, 2024 05:38:23)