あ、思い出した。乗算だ。やりなおし。 def「incがやられたようだな…」 配列「ククク…奴は四天王の中でも最弱…」 *「加算ごときに負けるとは激遅族の面汚しよ…」

激遅四天王かと思った。 def「incがやられたようだな…」 配列「ククク…奴は四天王の中でも最弱…」 dec「加算ごときに負けるとは激遅族の面汚しよ…」

思います。 文字タイプが面倒だから、試行錯誤のコストが高いのよね。

画面のプログラムで、 inc x[0] 一回の実行時間は 1.31μ秒 x[0]=x[0]+1 一回の実行時間は 2.24μ秒 になりました。(当社調べ)

【衝撃】incの方が速い?【新事実】 INCは駄目な子じゃなかった！ベンチマークが語る衝撃の真実！？ INC最速説浮上……カ？ x=x+1 より遅い inc x ですが、配列が相手なら inc の方が速くなります。(3.2.0) 配列があまりに遅いため、2回評価する前者よりも、1回しか評価しない後者が最後には勝利するという… 加算のヤツ油断したな！！

厳密な定義は存在しませんが、 おおまかには width 16 とした時の編集画面一画面に収まるプログラムのことでしょう。

button(2) であっても、値が更新されるのは「一画面書き終わった時」なので、それまでは同じ値を返します。 while 1 ? button(2),button(2) wend を実行してみてちょ。

実践してます!!

ok これプチコンにコピペすればいいのね???

ハンカチ3枚分泣いた。

スタックじゃないならレジスタか。 でんぺんさん Godot さんアイデアありがとうございます。

拡大の場合は、画素の補間という工程が必要になります。左はバイリニア補間、右は座標の切り捨て(ニアレストネイバーとほぼ同じ)。 プチコンの補間アルゴリズムは、右側に近いようですね。 ちなみに右側の方が簡単で速いです。

ソフトな感じだからわかりにくいかもだけど、 nobu さんはツッコミ入れたんです。 「遊べる」じゃ! ボケェ! くらいだとわかりやすいけど、nobu さんのお人柄でしょうね。

お久しぶりです!! みずさわ先生の作品が読めるのはプチコンだけ! 今度は超高速スクロールか～～ なんか出てくるし。

たらい回し関数を侮ってはいけません。 10 5 0: 343,073小節=5.3日 12 6 0: 12,604,861小節=194.5日 14 7 0: 588,802,013小節=9086日=24.9年 16 8 0: 33,635,863,081小節=1421.1年 ドヤァ!! (再帰レベルは240)

スイカでしょ? クォーターメロン。 つまらん。

どんなセンセーショナルなタイトルにしようかと思って。 【衝撃】inc の方が速い!?【新事実】 とか? これから出かけるので後ほど。 うえこうさんは臨界ゲームよろ。

よくあることだから問題ありませんね。 興味のあることをどんどんやってみるといいと思います。

昨日あたりからはやってるみたいですよ。 キュウリ、スイカ、プリン スプライト番号でいうと 2066,2054,2059 かな?