差分

このページの2つのバージョン間の差分を表示します。

--- ハイハイスクールアドベンチャー_android版 [2025/10/02 23:53] – [オープニング・エンディング] araki
+++ ハイハイスクールアドベンチャー_android版 [2025/10/02 23:59] (現在) – [独自の設定要素] araki
@@ 行 68: / 行 68: @@
 もう、SDLと同じでビットマップ作ってそれスクロールさせればいいんじゃない？
-と、GeminiとCopilotにそれぞれ聞いてみたら、Geminiは「いや、ビットマップは素材の用意が大変だしメモリも食うから RecyclerViewを活用するのが正しいやり方だ」といって、新しい方法を提案してきたが、SCrollViewと大差なかった。
+と、GeminiとCopilotにそれぞれ聞いてみたら、Geminiは「いや、ビットマップは素材の用意が大変だしメモリも食うから RecyclerViewを活用するのが正しいやり方だ」といって、新しい方法を提案してきたが、ScrollViewと大差なかった ー つまり期待してない動作しかしなかった。
 Copilotはビットマップを使う方法を速攻で提案してきて、ほぼ完ぺきだった。
@@ 行 76: / 行 76: @@
 それ以外は、およそ文句の付け所はなかったので、速攻で採用した。
-AIは便利だし、開発の大きな助けになってくれるが、時に頑固で時に忘れっぽくて、しかもGeminiのように効く相手を間違えると、いつまでも盛会にたどり着けなかったりもするので、うまく付き合わないといけない。
+AIは便利だし、開発の大きな助けになってくれるが、時に頑固で時に忘れっぽくて、しかもGeminiのように効く相手を間違えると、いつまでも正解にたどり着けなかったりもするので、うまく付き合わないといけない。
 ((今回はGeminiが駄目だったが、Copilotが駄目なこともあるだろう。))
@@ 行 131: / 行 131: @@
 Kotlinの Byte型は**符号付8ビット整数**なのだ。
-C頭なわたしは、byte_tみたいなやつはすべからく符号なし8ビット整数だと思い込んでいたのだ。
+C頭なわたしは、byte_tみたいなやつはすべからく**符号なし8ビット整数**だと思い込んでいたのだ。
 地図や、先生などの画像データは、バイト配列で座標や色コードを格納している。
@@ 行 148: / 行 148: @@
 のように、いったん、UByte型((符号なし8ビット整数))に変換してから、整数に拡張すれば問題は起きない。
-肩の定義は言語ごとに類似性はあっても独自のものであるので、先入観はすててちゃんと調べないとダメ。
+型の定義は言語ごとに類似性はあっても独自のものであるので、先入観はすててちゃんと調べないとダメ。
 なお、バッファ自体を UByteArray にすれば、余計な toUByte()がいらなくなり、間違いも減りそうだが、UByteArrayを使おうとすると「それはExperimentalだから」といわれていろいろめんどくさいので、今回は採用していない。
@@ 行 287: / 行 287: @@
 結論から言うと、PreferenceCategory側でした。
-app:allwDividerAboveとapp:allowDividerBelowというパラメータがあって、これが線を引くかどうかの制御をしていました。
+app:allowDividerAboveとapp:allowDividerBelowというパラメータがあって、これが線を引くかどうかの制御をしていました。
 しかし、ほかの要素ではこれ特に指定してないのだから、allowDividerAboveが trueで、allowDividerBelowがfalseがデフォルト値じゃないのかって思うんですが、やや解せぬ思いは残りましたが、線は消せました。