目次
01日 あけましておめでとうございます
08日 新年早々
14日 カセットポン
23日 100倍規模
26日 ノートパソコン修理
29日 微分積分いい気分
今年のおせち料理は大幅に手抜き。
親戚の集まりもやらないことにしたので、家族で食べられればいいだけだし。
昨年のうちに、業務スーパーで手頃な値段で売っている豚の角煮が、僕が作るのとあまり変わらないことを確認していた。
なので豚の角煮は買ってきたもの。
鶏ハムは作るつもりでいたら、2日前から仕込みをしないといけないのを忘れてた。
時短レシピを調べたら、最近は仕込み無しで作るレシピのほうが普通のようだ。
いつもと若干味わいは異なるが、別に構わない。
伊達巻。失敗して、一枚目を味付け無しで焼いてしまった。しかし、見た目は悪くない。
今日は、ちゃんと焼いた二枚目を食べたので、いつもどおり。
金団は、大成功。
ここ数年は長女次女が裏漉しをやってくれる。しかも、2度越しするので非常に舌触りなめらか。
そこに、今年はちゃんとクチナシも入れたし、甘さは控えめで栗と芋の甘さを活かした、非常に美味しいものとなった。
これは、市販品以上の出来だと自負する。
いくら。
毎年秋のうちに筋子から作るのだが、昨秋はコロナで外出を控えているうちに、買い逃してしまった。
ネットで冷凍物を買ったが、自分で作るより高いのに、自分で作るより味が落ちる。
味付け玉子。
大量にゆで卵をつくり、だし醤油ににんにくを入れたものにつけただけ。
だし醤油を濃縮のまま使ったら、少し塩辛かった。
松前漬け。毎年使う、市販キット。一応調理はするのだか、袋を開けて混ぜるだけ。
そこに、クリスマス前の安いうちに買っておいた冷凍数の子を混ぜた。
あとは市販品そのまま。
黒豆、膾、ままかり、昆布巻き、紅白かまぼこ、ワカサギの甘露煮、さくらんぼの練切り。
昨年末は、12月に入ってから少しづつ大掃除をすすめ、上に書いたように おせち も手抜きしたので、大晦日の夜にゆっくりできる余裕があった。
子供が小さい頃は、子育て優先で余裕がなく、深夜0時を過ぎてもおせち作ったりしてた。
ここ数年でも、紅白見ながらせわしなく掃除をしていて、ゆく年くる年が始まると､「タイムリミット」で打ち切っていた。
年越しのときくらいは、心穏やかでありたい。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
政治的なことはあまり書かないことにしているが、歴史的転換点だと感じるのでメモ程度に。
昨夕、東京・神奈川・埼玉・千葉に対して、コロナウィルスの感染拡大に対する緊急事態宣言が出された。
昨年末から早く出すべきだと言われ続けていたものを、ゆっくりと調整しつつやっと「緊急に」出されたもの。
まぁ、経済のことなども考えるとすぐに出せなかったのは理解できるが、遅すぎた、かつ宣言に対する規制などが弱すぎる気がする。
吉と出るか凶と出るか。
昨日、アメリカでクーデーターまがいの事件があった。
昨年末の大統領選挙で、負けたトランプ大統領は負けを認めなかった。
その後も各所に圧力をかけ、今からでも再集計をすべきだ、そしてその時には自分が勝つだけの票が新たに見つかって当然だ、と言い続けていた。
（暗に不正を行うように示唆していた）
そして昨日、ついに最終結果が出される段になって、支持者に対して議会に向かって抗議を行うよう示唆。
暴徒となって議会が襲撃され、死者も出る結果になった。
クーデターというのは権力者に対して行うものなので、今回は「権力者が」指示したためにクーデターとは言わない。
しかし、権力を失いつつあるものが、権力を維持するために、次の権力者に対して武力行使に出たのだから、クーデターと考えてよいように思う。
トランプ大統領に対して弾劾裁判を起こしてすぐに罷免すべきだ、という声が、仲間である共和党からも出ているそうだ。
しかし、任期はあと１２日。弾劾裁判は３週間かけて行うように法で定められているそうなので、間に合わない。
しかしこの暴挙に対して政府要人が次々辞職してしまったため、もはや政権は機能しない。
任期満了までの１２日間、アメリカでは権力の空白が生まれることになる。
昨日、香港で民主派の政治家などが５０人逮捕された。
「民主主義思想を持っている」という罪だ。何かをやったわけではない。
現在の中国では、考えただけで罪になる。
新年早々の中国本土のニュースとしては、アリババ（中国の大手ネットショップサイト）の創業者である、ジャック・マー氏が音信不通と明らかになった。
毎年欠かさず出席していた新年会に行かなかったことから疑念がもたれ、調べると昨年１０月ごろから、行方不明だそうだ。
マー氏は、民主派で共産党を表立って批判していた。
年末ニュースとしては、2020年末をもって、イギリスはついに EU を離脱した。
４年前から離脱は決まっていたことだが、離脱後の処理などで合意できず、やっと合意に至ったのは12月25日だった。
（前日まで交渉は全くまとまってなかったので、クリスマス休暇に入る前に無理やりまとめた感じだった）
そのヨーロッパでは依然としてコロナウィルスが猛威を振るっている。
ワクチンの接種もやっと始まりつつあるが、効果のほどはまだ不明。
（治験は行っているが、期間がなくて十分では無い感じ）
感染性が高くなった変異株も現れた、と騒ぎになっているが、これもどの程度のものかよくわからない。
世界情勢が、安っぽいディストピア小説のようだ。
特に昨日は一日でいろいろなことが起こりすぎたので、メモ程度に記録しておくものである。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
割とどうでもよい話なのだけど。
今朝、NHK ニュースを見ていたら、タイのサトウキビ栽培の話をしていた。
サトウキビは収穫時に尖った葉がかなり邪魔で、茎の部分は十分水分を含んでいるため、火をつけてしまうと葉だけが燃えて、収穫が楽になるのだそうだ。
でも、これで出る煙が公害で、社会問題化しているらしい。
そこで日本の大手砂糖メーカーが技術提携して、社会貢献している…という話。
このニュースで気になったのは、内容ではなくて出てきた会社。
インタビューに答えた会社員の所属が「砂糖メーカー カセットポン社」となっていたのだ。
カセットポン…PC-6001 を思い出す。
ジャンケンポン、カセットポン
というキャッチコピーで売り出した 8bit PC だ。
当時は家庭用にパソコンを売り出した黎明期。
第一陣となった PC-8001 / MZ-80 あたりは、カセットテープからプログラムを読み込む必要があり、非常に遅かった。
ちょっと使うのにいちいち待たされるのでは家庭用に向かない、というので、プログラムを ROM カートリッジに収めて、挿せばすぐ使える、というのが、家庭用への普及には必要だと考えられていた。
PC-6001 は、その最初期のものだが、のちには IBM Jr. や MSX など、カートリッジを搭載して家庭向けの普及を狙った機種は多い。
（もっとも、ATARI 社が出したゲーム機が ROM カートリッジのアイディアの先駆だろう。それを PC にも取り入れよう、という動きは世界的なものだった）
ちなみに、今では「カートリッジ」と呼ばれるが、当時は「カセット」と呼ばれた。
カセットテープはメディアとして普及していたので、簡単に交換できるものを「カセット」と呼んだのだ。
（今でも、カセット式ガスコンロとかある）
話を戻す。
ニュースに出てきた「カセットポン社」の名前を見て、僕は上のように交換式の何かを連想したのだ。
何で砂糖メーカーでカセットポン？
元は名前にふさわしい別の事業をやっていたが、仕事の幅を広げて砂糖も作っている？
気になったので調べたら、カセットポン社は三井物産と、子会社の三井製糖が共同出資するタイの現地法人だった。
三井製糖、と書いてもよくわからないかもしれないが「スプーン印」と書いたら誰もが知っているだろう。
で、答えは三井製糖の CSR 報告書に書いてあった。
（CSR 報告書とは、企業として社会的にどのような貢献を行っているかの情報をまとめたもの）
タイの言葉で、カセット (เกษตร:Kaset) は農地、ポン (ผล:phol) は実り、利益、収穫を意味するそうだ。
（CSR報告書７ページ右下）
そんなわけで、「なぜ砂糖の会社でカセットポン？」と疑問に思っていたのだが、農業法人らしい非常に良い名前だった。
しかし、日本語的にも非常に面白かったので、ここに記しておく次第。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
お仕事の話。ほぼ愚痴。
100名程度の使用を想定して作ったシステムがあり、開発をお手伝いしている。
ありがたいことに人気が出て、人気が出ると想定外の使われ方をし始める。
特に、多人数で使いたいという要望が多く、1000人規模でも使えるように1年ほど前に大規模改修を行っている。
僕はこの改修の途中から参加させていただいた形だが、システムのスループットは上がり、1000名でも使えるようにはなった。
この際に、さらに人数を増やすこともできるような設計にはしていたが、それは「設計」だけで、実際には対応できていなかった。
それが、今回1万人で使いたいという依頼が来て…
いや、依頼はしばらく前から来ていたのだ。というか、依頼は1万人とも限定していなかった。
最大5万人くらいということだったが、それはさすがに難しそうなので、1万人に制限してもらったのだ。
システムはいくつかのパーツに分かれているが、サーバー部分は改修の際に、node.js で作り替えられていた。
node.js はサーバー側で動作する javascript 環境だ。
細かな話を書くと長くなるが、もともと javascript はブラウザ向けの技術だった。
そのため、非常に癖の強い特徴を持つ。
一番重要なのが「ノンブロッキング」であるということだ。
ブラウザはユーザーが操作するものなので、その操作を阻害…「ブロック」してはならない。
これがノンブロッキングという思想。
言語が動いているときは、ユーザーの操作を受け付けられない。
そう仮定すると、ユーザーの操作を阻害しないため、言語は無駄な実行時間をかけてはならない。
とはいえ、普通のプログラム言語にはたいてい「何かを待つ」処理が入るものだ。
ファイルを読んだり、ネットで通信をすると、CPU よりもはるかに遅いディスク装置やネットワークのデータを待つ。
プログラムをしていると、ごく当たり前のことだ。
javascript では、これらのことは「行えない」。
待たせてはならない、という設計思想だからだ。
とはいえ、ディスクを読んだり通信をしたり、というのは当たり前のことで、もちろんできる。
どうやるかというと、待つのではなく、いったん終了してしまうのだ。
「通信してね」って頼んだら、終了する。
そして、通信が終わると、「通信終わったよ」ともう一度処理を起動してもらう。
javascript では、一事が万事この調子。プログラムを組んでいると、非常に組みづらい。
まぁ、最近では昔より環境が整えられ、かなりマシになったのだけど。
そして、あえてこの使いにくい環境をサーバーで使うと、「待ち時間のない」プログラム環境を実現できる。
待ち時間がないということは、常にプログラムが動いているし、リクエストに応えられるということだ。
従来…というとちょっと古いのだが、Wordpress などに使われる PHP では、1秒間にせいぜい 10リクエスト
くらいしか答えられない。
でも、同じことを node.js で実装すると、1000リクエストくらいは答えられるのだ。
＃PHP はインタプリタだが、node.js は即時コンパイルだ、とか、PHP はプロセスフォークで動く Apache 上で動作するが、node.js はシングルプロセスなのでタスクスイッチのオーバーヘッドがないとか、他の要因も多分にあるのだけど。
それでも期待できるのは 1000人レベルだ。
大規模改修で node.js を使って 1000人規模に対応した、というのがこの段階。
今回1万人規模のリクエストなので、node.js をクラスタ化して対応することにした。
node.js は、シングルプロセスで動作する。
たった一つのプログラムで、1000以上の接続に対応するのだ。
しかし、これは CPU がマルチコアだったとしても、１コアしか使わないという意味でもある。
CPU のコアの数だけプロセスを増やせば、理論上はもっと多くの接続を処理できる。
もちろん、そのための制約はいろいろとあるのだが、最初から「マルチプロセスで動かすことができるように」という設計をしていた。
そして、pm2 という node.js 対応のプロセス管理ツールを使うと、プログラムは無改造のまま、マルチプロセス化できる。
（通常、プロセスが増えると、それぞれが別の通信ポートなどを用意しないといけなくなる。
通信ポートが増えれば、アクセスするクライアント側もそれに対応しなくてはならなくなる。
しかし、pm2 は代表して１つの通信ポートを作り、配下のプロセスのポートに適切にデータを流してくれるので、外部から見るとそれまでのプログラムと何ら変わらないように見える）
というわけで、処理性能は何倍かに跳ね上がった。
…でももちろん、話はそんなに単純ではなかった。
接続が増えたら、当たり前だがそれらの接続ごとに、データを収めた DB へのアクセスが発生する。
１プロセスで 1000 人程度をさばいているときには問題にならなかったが、１万人規模になると接続ができなくなった。
DB の接続数の上限設定があるのだ。これは、 DB の設定を書き換えて解消する。
これに伴い、適切なワークメモリの割り当てなども変える必要があるが、とにかく設定した。
DB が接続を受け付けられるようになっても、その接続のための通信ポートが十分作れない。
OS 側に、通信ポートをいくつ作れるか、という設定があるのだ。
それらも設定する必要がある。
UNIX では、すべてのリソースがファイルとして扱われる。
通信ポートも１種のファイルだ。そして、UNIX には、プロセスごとに開けるファイル数の制限がある。
この制限も増やす必要がある。
100 人程度なら問題なし、1000人でも大丈夫だったとしても、１万人規模になるとそれまで気にしていなかった設定が問題になるので、問題発生のたびに何が悪いのか調べ、設定をチューニングする必要が出る。
それまでは問題にならなかった DB の Query が、突如として slow query になる、というのもあった。
DB へのアクセスが激しすぎると、特に問題がなかった部分がボトルネックになりだすのだ。
…これらは、上に書いたような順序で、理路整然と起こったわけではない。
とにかく不具合が続出し、原因を切り分け、考えられる要素をひとつづつ潰していく必要があった。
上に書いたのは、「結果としてそういうことだった」というだけで、原因がわからないので見当違いの設定に手を出して、何も変わらないので元に戻す、というようなこともやっている。
問題はサーバー側だけではなかった。
１万人規模、と書いたが、その規模の人たちがサーバーに接続し、操作した結果を集計して表示する画面がある。
普通の WEB ページとして作られているので、PC さえあればインストール作業などなしで表示できる。
この画面自体は、サーバーと接続しているだけだ。接続が増えるようなことは無い。
だから特に問題は出ないだろうと思っていたら、１万人分…１人についてのデータが複数あるため、数万件のデータになると通信に支障が出た。
特に、何らかの不具合が起こって画面のリロード…と考えたとき、数万件のデータ再送信はそれだけで１分程度の時間がかかる。
通信したデータを、ローカルにキャッシュして持つように改良した。
再起動が行われた際は、まずキャッシュからデータを読み込み、続きのデータの送信をサーバーに依頼する。
５秒程度で表示が行えるようになった。
この表示も１万件あると遅くなった。
全部を表示したいのだが、ただ１万行の HTML というだけで、重くてスクロールもままならないのだ。
これはプログラムテクニックで乗り切った。
どこかに詳細なテクニック紹介をしたいのだけど、忙しくて概要説明だけ行ったままだ。
100人を想定して作ったものを、１万人向けに提供する…となると、思わぬことがいろいろと発生する。
同じテーマの日記(最近の一覧)
別年同日の日記
16年 iOSでtextのコピー・ペーストができないバグの回避
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
昨年８月に購入したノートパソコンが壊れた。
壊れたといっても、起動はできるし普通に使える。
ペンコンピューティング可能なマシンだが、ペンも使える。
でも、指で直接ディスプレイにタッチした際の操作が効かなくなった。
それ以外の症状はない。
最初は、ペンは使えるがタッチは使えない、というので、タッチパネル自体は壊れてないんだよね？
と思ってドライバ不具合などを疑った。
調べると、Windows アップデートなどでドライバが不具合を起こすことがある、という情報があったし、うまく動かなくなった直前に Windows のアップデートを行っていた。
じゃぁこれかな、と思って、メーカーのページに書かれていたトラブルシューティングの方法に従ってドライバを入れなおす。でも治らず。
さらにネットの情報を探す。
我が家の機種とは違うが、同じシリーズの以前の機種で、同様の問題を発見。
タッチディスプレイのケーブルが内部基板から外れやすくて、ペンは使えるのにタッチのみ使えなくなりやすい、という。
後継機で前の機種のトラブルが対応されていないことは無いと思うのだけど、症状的に似通っている。
ケーブルが外れているだけなら自分で治せるかもしれないけど、保証期間内だったので素直に修理に出すことにした。
まず、メーカーのページで修理申込する。
不具合のある機種を使って申し込みをすると、自動的に機種を判別し、保証期間内であることが示される。
そして、自己診断プログラムのダウンロードを促される。
このプログラムを入れると、自動的に自己診断が始まり、その情報とともに修理申込ができる。
その際、マシンのシリアルナンバーなども自動判別される。
我が家の機械の場合、故障個所はない、という診断だったが、申し込みはできた。
自己診断の限界もあるのだろう。
住所氏名や電話番号などの連絡情報を入れたのち、不具合について記入。
タッチパネルが反応しないがペンは動くこと、公式の方法でドライバの入れ直しも試みたことなど書く。
で、翌日にはメールで返事が来た。ハードウェア故障の可能性が高いので引き取り修理をするという。
引き取り日の希望などを返信するが、最短で翌日。で、翌日には佐川急便が引き取りに来たので本体を渡す。
梱包などは佐川の方でやってくれる。
当日のうちに到着連絡が来たが、この日が金曜日だったため、週末の間は修理は進まなかった。
そして、昨日月曜日に修理完了の連絡があり、今日には手元に戻ってきた。
一応、メーカーのページには「到着から１週間から１０日で修理完了します」とあったし、さらに「コロナ禍で修理依頼が増えており、少し時間がかかるかもしれません」とお詫びがあった。
しかし、メーカー到着の次の営業日には修理を行い、翌日こちらに届くというスピード修理。
まぁ、本当にハードウェア的な故障で、部品交換で済んだからすぐ終わったのだろうけど。
ソフトウェアのコンフリクトなどを「不具合」として修理に出す人もいるみたいだし、そういう問題はすぐには解決できない。
同じテーマの日記(最近の一覧)
別年同日の日記
14年 iOS の position:fixed バグ回避方法
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
このタイトル、すでに分からない人の方が多そうだな。
急に思い出話。
まだ僕が大学１年生だったころのこと。
PCルームがあって、放課後は入り浸っていた。
その場にいる人の多くは、僕も所属していたコンピューターサークルのメンバー。
でも、そうではない常連の人もいて、学科もサークルも違うのに知人、という人もいた。
そのうちの一人…同じく１年生で、簡単なプログラムは組めるが本格的なゲームなどは作れない、というくらいの知人が、ゲームによくある、ジャンプの動きを作ろうと頑張っていた。
その知人は「ジャンプは放物線なのだから」と、何かの二乗を使って書こうとしてたんだ。
（二乗のグラフとして描かれる線を、放物線と呼ぶ）
でも、そうじゃない。ゲームならジャンプは次のように書く。
（当時は BASIC を使っていたので、BASIC 風に）
10 X=X+1
20 IF INKEY$=" " THEN JUMP=1:Y1=-5
30 IF JUMP=1 THEN Y=Y+Y1:Y1=Y1+1
40 IF Y1>5 THEN JUMP=0
50 PUT SPRITE 0,(X,Y),8,0
60 GOTO 10
このプログラムはサンプルなので、初期設定を省いているので、雰囲気で読んで欲しい。
ともかく、こんな感じのプログラムを作って、こうやるんだよ、と見せてあげた。
そうしたら、返ってきた反応は、「なんかずるい」だったんだ。
動きを見ると放物線っぽく見えるけど、プログラム中には二乗どころか、掛け算もない。
それは放物線ではない、というのだ。
いや、別にずるくないよ、と言い返したが、その時の自分には「ずる」ではないという明確な根拠を示せなかった。
今なら明確に示せる。
これは、放物線の式に対し、一階微分した導関数を導き出し、その導関数を再び積分することで放物線を再構築しているんだ。
なぜ微分するかというと、ゲームは時間によって微分された世界で動いているから。
テレビ画面は、連続した「時間」を、1/60 秒ごとに区切って表示する。
このわずかな時間の動きは、時間で微分されている、ということになる。
そして、その微分したものを積み重ねていく。
テレビで言えば、一連の「コマ」を連続させて動かすことが、積分にあたる。
…厳密にいえば、微分ではなく差分だし、積分ではなく積算なのだけど。
これを言い出すと離散数学というややこしい数学の話になるので、今は微分積分という呼び名で話を進める。
僕のプログラムを見た知人は、「プログラム中に二乗がないので、放物線ではない」と言った。
しかし、プログラム上は微分したことで二乗が消えている。
そして、プログラムを動かすと時間変化によって積分され、正しい放物線が描かれる。
これを「ずる」だというのは、微分積分を理解していない残念な人間だというのを、自ら明かしたに過ぎない。
（もっとも、すぐに言い返せなかった自分も、その時には十分理解できていなかったわけだけど）
本当に足し算だけで二乗になるのか、まだ疑う人がいるかもしれないので、わかりやすい例を挙げよう。
まずは、単純なルールで作りだせる、次の数値の表を示そう。
| 0 | 1 | 4 | 9 | 16 | 25 | 36 | 49 | 64 | 81 |
| 1 | 3 | 5 | 7 | 9 | 11 | 13 | 15 | 17 | 19 |
この表のルールはこうだ。
・上に書かれた数値は、その左側の列の上下の数値を足したもの。
・下に書かれた数値は、その左側の列の下の数値に、2を足したもの。
足し算しか使っていない、非常に単純なルールだ。
おかしいところがないか検算してもらってもよい。
ここで、上の数値は、もう一つの意味を持つ。
0,1,2…と続く数値の「二乗」になっているのだ。
日本人なら 9*9=81 まではわかるだろうから、上の表は 81 で止めてある。
でも、もっと長く続けても大丈夫。これも試してもらってよい。
「ずる」と言われたのが悔しくて、根拠を考えていたら、数日後にはこの答えに行きついた。
でも、サークルも違うし学科も違ったので会う機会はそれほどなく、言い返すタイミングは永久に失われた。
それを思い出して急にここに書いたのは、ネットで「微分積分なんて実生活でどう役に立つのか」なんていう…まぁ、よくありがちな学生の愚痴を見たから。
微分積分、生活で超役立つ。
上に書いたように、テレビゲームは微分積分の世界の中にある。
そもそもテレビが微分積分の世界だし、デジタルテレビなんかフーリエ変換（微分積分の親玉みたいなやつ）を駆使して作られている。
ただし、役立てられるかどうかは、自分次第。
ゲームやテレビの中に微分積分が駆使されている、なんていうのは知らない人は全く気付かない世界だ。
それでも生活はできるのだから、知らずに生活している限りは、高校で習った微分積分は「役立てられていない」。
役に立たないのではなく、役立てられないのだ。
なんでかといえば、勉強が浅かったから。「どうせ役立たない」なんて思ってるから。
世界最初のコンピューター、と呼ばれる ENIAC は、実のところ「ひたすら足し算する機械」にすぎない。
それでも、数学的に正しい…どころか、空気抵抗なども考慮した「弾道計算」ができた。
先に書いたように、足し算だけで数学的に正しい放物線は求まる。
しかし、それは空気抵抗や風などがない理想状態での弾道にすぎない。
ENIAC では時間で「微分」した方程式を使い、繰り返し計算して「積分」することで、弾の速度の関数となる空気抵抗や、風の影響なども考慮に入れ、物理現象としての「弾道」を描き出すことができた。
空気抵抗が弾の速度の関数になる、なんていうのは、瞬間ごとの速度を見ながら抵抗を導き、それによって速度を調整する、というのを繰り返しながら積分する方法でないと計算できない。
そうした計算が複雑すぎて人の手に負えないから、ENIAC を建造したわけだけど。
ともかく、ここで重要なのは、どんなに複雑な数式であっても、微分を繰り返せばただの足し算になるということだ。
そして、足し算をひたすら繰り返せば、元の複雑な数式の答えを導き出せる。
（ここでいう答えとは数値演算であり、式の変形ではない）
ENIAC は弾道計算よりももっと複雑な、水爆の内部圧力の計算なども行っている。
使われた計算は全部足し算のみだ。それが微分積分の威力だ。
今回、この話を書こうと思ってネットを調べていたら、以下のようなことを書いている人がいた。
（一連のツイートだが、特定人物を批判したいわけではないため、検索されないよう文面は変えている。）
・ファミコンで三角関数を使うと遅くなるので、スーパーマリオのジャンプは掛け算だけで作られている。
・掛け算だけなので本当は放物線ではないのだが、ゲームを作るうえでのうまいごまかし方だと言える
…まぁ、プログラマーでない人がうろ覚えの知識を披露しただけだと思う。
しかし、どこから突っ込んでよいかわからないほど違っている。
まず、ジャンプを表現する放物線に、三角関数は必要ない。掛け算だけでよい。
そして、ファミコンは掛け算すら遅いので、足し算だけで作られている。
さらにいえば、先に書いたように足し算だけで書いてもごまかしではなく、数学的に正しい放物線が描ける。
ただ、スーパーマリオのジャンプは、放物線ですらない。
放物線にすると、操作が難しくてゲームにならないから。
それでも放物線っぽく感じられるようにしている。
これが「うまいごまかし方」だというのは同意だが、計算できなかったからではなく、ゲームを面白くするためだ。
背景が全く違う。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |