aclib #3

  • (by K, 2020.09.09)

(1) メモ

  • [2020.09.09 #1]
    • osdev-jpのkagura1050さんにとてもいいことを教えてもらいました。古い環境とかだと、SDL2用のドライバはないけど、SDL1用のドライバがある、というケースはまあまああるそうです。だから、aclibもSDL2だけではなくSDL1用も作れば、それらも全部サポートできることになりそうです。
    • ぜひやりたいです。
  • [2020.09.09 #2]
    • aclibはKにとって全く新しいことをしているというわけではなく、以前に使っていたblaライブラリを手直しして、SDL用のドライバを書いて、hrb_esb02bの時に作ったドライバも使って、それで整理した程度です。
  • [2020.09.09 #3]
    • aclibみたいなライブラリってどうやって作っていくのが賢いのかな。まずSDL版かWin版か、まあどちらでもいいけど、とにかくどちらかに絞って必要な機能をそろえて、それからほかの環境向けに移植していくのがいいのかな。
  • [2020.09.11 #1]
    • よしわかった。SDL2.0版を先に作ればいいんだ。最初にWindows版を作ろうと最初思ったけど、それだどSDL2.0版ができるまでblaライブラリと同じことを繰り返すだけになってしまう。
  • [2020.09.11 #2]
    • いろんなビット数のCPUで問題なく動くようにすることを考えると、気軽にintとかを使うべきじゃないなと思いました。intの幅はCPU依存なので(C言語の規定では16bit以上にせよとしか書かれていない)、それだと期待通りにならないケースもありそうだなと思いました。
    • ということでAInt16とかAInt32を積極的に使うことにします。
  • [2020.09.14 #1]
    • デバッグモードが全くできていないですが、グラフィックのほうはそこそこできるようになってきたので、そろそろ一度uploadしようかなと思っています。
  • [2020.09.18 #1]
    • 昨日totoさんにmandel.cでの不具合を教えてもらえて、原因を考えて、今日になってひらめいたのですが、やっぱりこういうのって、ライブラリとして言語本体よりも先に公開したからだよなあと思いました。ライブラリはまだ規模が小さいので、問題の切り分けが簡単なのです。言語の一部として組み込まれて公開していたら、きっと切り分けられなくて直せなかっただろうなあ、と。
  • [2020.09.18 #2]
    • 大雑把に言って、どういう順番で開発を続けようかなと迷っています。現状、aclライブラリはただのSDL2.0のラッパーライブラリでしかありません。これがSDL以上のものであるためには、SDLにできないことができなければいけないです。そうすると「はりぼてOS」向けのaclライブラリを作ることを優先するべきでしょうか。しかしなあ、きっと作ってもほとんどだれも使わないような気はします。そうすると、それは「aclライブラリはSDLライブラリよりも移植しやすい」という証明をするためだけの存在で、なんだかなーという気はします。
    • それよりもデバッグ支援機能を先に作るべきでしょうか。そうするとSecHack365との整合性はかなり良くなります。ライブラリに何ができて何ができないか(=言語からやらなければ実現できないことは何か)を明確に示すことができるでしょう。それはそれで有意義なことです。
    • 一方で、aclライブラリを利用したアプリをもっとたくさん書くとか、チュートリアルを書き足すとか、そっちの方向性もあり得ます。
    • さらに、aclライブラリはこのあたりで一区切りということにして、言語本体の開発に注力する道もあります。
    • ということで、選択肢がたくさんあって、忙しいなあという感じです。
    • (まあでも、「はりぼてOS」向けのaclライブラリの移植は大した手間ではないので、悩んでいないでさっさとやってしまえばいいような気はします。)
  • [2020.09.2 #1]
    • SDL2.0って適当に使っているとうまくいかない場合があるのがわかってきたので、それも吸収できるライブラリになれたらいいなあ。

こめんと欄


コメントお名前NameLink

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2020-09-20 (日) 10:33:00 (1d)