タグ

ブックマーク / mirichi.hatenadiary.org (19)

  • ライセンスのお話。 - mirichiの日記

    Twitterでライセンスの話を呟いていたら、zlib/libpngライセンスをお勧めされた。 http://sourceforge.jp/projects/opensource/wiki/licenses/zlib_libpng_license DXRubyがなぜMITライセンスなのかというと、できるだけ緩いライセンスにしておきたかったからだ。 GPLにするとexeに組み込んだときに全体がGPLになるだとか、LGPLにするとどーなのかとか、ライセンス関連はややこしい話が山積みだから、ソースを流用して改変する場合はともかく、DXRubyを使って何か作ってくれているユーザーの人に面倒を押し付けたくない。 なのでそういった面倒ごとがなさそうなMITライセンスにしておいたわけだ。 でも、初めから気にはなっていたことなのだが、MITライセンスの条文に「上記の著作権表示および許諾表示を、ソフトウェ

    ライセンスのお話。 - mirichiの日記
    nobyuki
    nobyuki 2019/08/20
  • Chipmunkのエッセンス - mirichiの日記

    最近いじってわかってきたことを個人的メモ。 ■Chipmunkとは オープンソースで開発されている2D物理演算ライブラリである。物体に重さや形状などの情報を設定すると、衝突した反応などをリアル(2Dだけど)に計算してくれる。この分野で最もメジャーなのはBox2Dで、まあ次点と言ったところか。RubyバインダもあるのでDXRubyと併用すればそれっぽいゲームが作れる。かもしれない。 ChipmunkはCで書かれているが概念としてはオブジェクト単位となっていて、オブジェクト指向言語と相性がよい。 ■基的なところ 最も基となるクラスはSpace、Body、Shapeの3つである。 SpaceはChipmunkが扱う物理世界を表し、このオブジェクトに登録した物体について物理現象を再現してくれる。 Bodyは剛体(力を加えても変形しない物体)を表すが、その言葉のイメージとは少し違って、質量や座標

    Chipmunkのエッセンス - mirichiの日記
  • DLとWin32APIとFiddle - mirichiの日記

    Rubyには外部のライブラリの呼び出しインターフェイスとしてDLというライブラリが添付されているが、Ruby2.0になってそれは廃止予定になってFiddleが追加された。他にWindows用にはWin32APIもある。このへんをまとめる。 ■Ruby1.8時代 Win32APIが独自実装で存在していた。ダイナミックリンクライブラリのインターフェイスとしてDLがあった。標準で添付されていないがDL2があった。 ■Ruby1.9時代 DLが廃止され、DL2がDLという名前で標準添付になる。互換性は無い。Win32APIは新しいDLを使うラッパライブラリとして書き直されたが、廃止予定になり代わりにDLを直接使えという警告が出る。DLの一部機能を実現するために内部的にFiddleが組み込まれる。 ■Ruby2.0時代 DLの機能はFiddleにマージされ、DLが廃止予定となる。DLをrequire

    DLとWin32APIとFiddle - mirichiの日記
  • DXRuby1.5.11devリリース - mirichiの日記

    DXRuby1.5.11devをWikiに置いといた。 http://dxruby.sourceforge.jp/cgi-bin/hiki.cgi?%A5%D5%A5%A1%A5%A4%A5%EB%C3%D6%A4%AD%BE%EC Input::IMEの機能追加で、変換中の文字列や候補の一覧、数などを取得できるようにした。 通常、IMEの変換中文字列の描画はIMEがやってくれるのだが、ゲームなどの場合はIMEによる描画の上にDirectXで描画しちゃったりすることになるので、基的に自前で描画してやる必要がある。 DXRubyの場合、ライブラリが勝手に描画するのもなんだかなーということで、描画に必要な情報一式をCompInfo構造体で返すようにしてみた。それを使って頑張って描画してくれたまえ。諸君の手腕に期待する。一応、ime_test.rbとしてサンプルにクッソ手抜きなものを入れてある

    DXRuby1.5.11devリリース - mirichiの日記
  • Spriteの実装と設計判断 - mirichiの日記

    高尾さん(@takaokouji)から「Spriteはなぜインスタンス変数に値を持たないのか」という質問を受けた。その回答はシンプルに「遅いから」であった。 Spriteの描画時など、参照するパラメータは10を軽く超える。これらをすべてCのAPIでインスタンス変数から取得すると、特にSpriteの描画数が多い場合にハッシュアクセスが膨大な数になる。衝突判定も同様で、これらの重い処理をできるだけ軽くするためにSpriteのパラメータはC構造体に持って、内部的には直接、Rubyからはメソッドでアクセスするようにしているのである。 CRubyのインラインキャッシュ RubyのVMはいくつかのインラインキャッシュ機構を持っている。メジャーどころはインラインメソッドキャッシュだが、同様に定数もキャッシュしている。これらは ・探索空間が広いので検索に時間がかかる場合がある。 ・コードの同じ場所からのア

    Spriteの実装と設計判断 - mirichiの日記
  • 松江Ruby会議05に参加してきた(3) - mirichiの日記

    昨日の最初に書いた「普段置かれている環境への疑問」てのは職場のことであって、Twitterとかで関わってる人たちのことではない。ここを誤解されると致命傷になりかねんので一応念のため。 さて、今回は松江Ruby会議05ちょー個人的感想の最終回で、DXRubyに関することあれこれをまとめて。 DXRubyとは 松江Ruby会議05はその後に懇親会もあって、たくさんの人と色々話してきた。そこで感じたのは、DXRubyを既に知っている人は講演で話したようなこととは少し違うことを知りたかったのかな、ということ。なので、ちょっと違った切り口で。 何度も繰り返すが、DXRubyは複雑なゲームを簡単に作れる、というタイプのライブラリではない。簡単なものを簡単に作れる。提供している機能は ・ゲームを作るのに最低限必須なもの ・表現力を拡張するもの ・こまごまとした面倒な処理をサポートするもの という程度であ

    松江Ruby会議05に参加してきた(3) - mirichiの日記
  • 松江Ruby会議05に参加してきた(2) - mirichiの日記

    前回は講演の超主観的な感想であった。全体的にレベルが高いのは松江だからなのか、それともどこに行ってもこんな感じなのか。 自分が普段置かれている環境に若干の疑問を持ちつつ。次いってみよー。 松江、島根の取り組み Ruby合宿、中学生Ruby教室、Ruby.Jrなど、Rubyの勉強会的なものを自治体が主体でやっている。いずれもDXRubyを使ったり、使わなかったりしていて、また、よくわからないのだが、NaClが関係していたり、していなかったりするようだ。 Matsue.rbのTシャツを着ている人がMatsue.rbのメンバーなんだろうという気がする。県とか市の人も着ていた。このあたり、特定個人が組織やコミュニティにかぶって所属していると思うので実態がいまいち把握できていない。 結局のところ、誰(どこ)が具体的に何をしているのかというのは妙にややこしくて、というか理解が足りてなくて、うまく説明で

    松江Ruby会議05に参加してきた(2) - mirichiの日記
  • 松江Ruby会議05に参加してきた - mirichiの日記

    2014/3/15(土)、島根県松江市にてMatsue.rb主催の松江Ruby会議05が行われた。それのゲスト講演をしてきた。 島根県がやっているRuby合宿でDXRubyが使われているという繋がりでDXRubyに関する講演の依頼が来たので、ちょっと喋りに行ったという経緯である。 懇親会含めていろんな人と話したし、こっちで細々とライブラリ作ってるだけではわからない松江の現場の話を色々と聞けて、非常に楽しかった。まとめるにもどうまとめたらいいのかよくわからない感じになっているので、何回かに分けて感想などを書いていくことにする。 まずは講演の感想から。 Matzの基調講演「Prepend Your Class」 Ruby2.0とRuby2.1での新機能について、及び、Ruby2.0で追加されたModule#prependの話。 Module#prependはこのブログでも過去記事で軽く紹介して

    松江Ruby会議05に参加してきた - mirichiの日記
  • Window.draw_morphを使う - mirichiの日記

    この記事はDXRuby Advent Calendar 2013の2日目です。 1日目の記事はあおいたくさんのIntroduction to DXRubyでした。 なんか初っ端から気合の入った紹介記事だったが、2日目は急展開でマイナーな機能の活用ネタとして、Window.draw_morphを使ってみる。 draw_morphはxとyを4つずつ指定する制限付き自由変形(?)可能な描画メソッドである。 Window.draw_morph(x1, y1, x2, y2, x3, y3, x4, y4, image, hash={} ) 他の人がこれを使っているところはいまだに見たことが無いし、使っているサンプルも1つしかない。biyo.rbだ。 サンプルにこれだけが入っているということは、まさに「あ」を「びよーん」ってのがやりたくてこんなメソッドを作ったと考えられるわけだが、実はそうではない。

    Window.draw_morphを使う - mirichiの日記
  • DXRubyのポリシーなど - mirichiの日記

    最近、mrubyのSDLライブラリや、Rubyでも他のゲームライブラリなどが出てきている。前からRubyゲームライブラリは比較的たくさんあったわけだが、他のものを眺めていて、ようやくいまごろDXRubyの特徴的な設計方針がわかったような気がした。 もともと作り始めたのはRubyを触り始めた頃で、オブジェクト指向もよくわかっておらず、Rubyの難しい機能もさっぱりという状態だった。ようするに自分という具体的な初心者をターゲットに置いて、DXRubyの開発はスタートしたのである。 一般的にゲームライブラリは「何ができるか」に注目する。ここではあえて、「何が無いか」を取り上げてみよう。DXRubyにはざっくりと以下のものが存在しない。 (a) includeして使うモジュールが存在しない。 (b) クラスを継承して使う必要がある抽象クラスが存在しない。 (c) ブロックを受け取り保存して後で呼

    DXRubyのポリシーなど - mirichiの日記
  • Spriteにまつわるあれこれ - mirichiの日記

    この記事はDXRuby Advent Calendar 2013の8日目です。 7日目の記事はしのかろさんのDXRubyのSpriteを継承して拡張する方法についてでした。あおたくさんとハイドさんがMarkdownで綺麗にしてくれました。https://gist.github.com/RPGP1/7833833 Spriteの挙動を詳細に調べて、Rubyの言語仕様とうまいこと融合させた、Sprite拡張の手法である。両方について高い理解度がないとこういうことはできない。すごい。8日目はしのかろさんに続いてSpriteの記事で行こうと考えていたのだが、直球勝負では分が悪いので変化球で逃げることにして、作者ならではのSpriteの裏話あれこれを。 Spriteの歴史的な話 DXRubyのSpriteは古くて、うちのブログで検索すると2009年7月あたりが初出となる。当時は外部ライブラリとして実

    Spriteにまつわるあれこれ - mirichiの日記
  • RGenGCに対応する方法 - mirichiの日記

    Ruby2.1.0-preview1は出たがREADME.EXT.jaを見ても書いてないので調べたことをここに書いておく。正式なマニュアルじゃないし検証してるわけでもないから豪快に間違っているかもしれん。 ■はじめに RGenGCは今までの拡張ライブラリのコードそのままで動作するように作られていて、何も考えずにコンパイルすれば普通に動く。2.1用に拡張ライブラリをコンパイルして動かない場合、よっぽど特殊なことをしていない限りはRGenGC以外のところに原因があると考えてよい。そのぐらい互換性に気を使われている。 なので特別に対応する必要は無いのだが、対応すればGCのパフォーマンスが上がるし、Shady化の処理を省く効果もあったりしてさらに速くなるかもしれない。速度を売りにした拡張ライブラリは対応しておいて損は無いだろう。 RGenGCの対応には大きくわけて以下の2つのパターンがある。両方や

    RGenGCに対応する方法 - mirichiの日記
    nobyuki
    nobyuki 2013/10/15
  • アリーナのかいしんのいちげき - mirichiの日記

    mrubyにはmrb_gc_arena_save()/mrb_gc_arena_restore()という関数があって、これを使わずにCでオブジェクトを作りまくるとエラーでコケる。この件について作者のMatzが直々に日記を書いておられる。(http://www.rubyist.net/~matz/20130731.html#p01) mrubyとC言語とGCの問題点とその解決策を説明してくれているのだが、これを読んでもなんとなく微妙にわからない。という人は多いのではないかと思う。mrubyのGCを読んだことある人ならわかるんだろうけども。 で、俺も何か書いてみようと思ったわけだ。余計わからなくなるかもしれないが。しかしmrubyのarenaまわりのAPIはかなり内臓が飛び出したような設計だと思うので、使う人がGCとかオブジェクト管理を少し知らないといけないんじゃないかと。 ■さわり まず前提

    アリーナのかいしんのいちげき - mirichiの日記
  • RubyとGCについて - mirichiの日記

    思ったことをつらつらと支離滅裂な個人的メモ。 1.シンプルマルチスレッドGC このあいだからいじってるやつだが、とりあえず世代別GCがあるのとないので3倍も違うというのはおかしいのでまだどこかバグっているんじゃないかと思う。効率面での話なのでヒープスロットの取得・解放戦略のへんが怪しい。 単純な再帰型マーク関数を2つのスレッドで同時に動かすというのは、まあそれなりに短時間で終わるのだろうが、それはあくまでも遊んでるCPUがあるという前提であって、システム全体のスループットとしてはたぶんあまり嬉しい話ではないだろう。作るのは楽だが無駄が多い。 このシンプルな手法が通用するのは関数を再帰呼び出しするというマシンスタックを使った探索の場合のみであり、たとえばmrubyrubyのようにリストを繋いだりたどったりする方法ではリストのアクセスに排他制御が必要になって思ったような性能は出ないと思われる

    RubyとGCについて - mirichiの日記
  • GCCの勉強とmruby - mirichiの日記

    最近ちょとmrubyのコードを見たりしていた。ついでにGCCの使い方を勉強しつつ、吐き出すアセンブラを眺めてみたり、そんな感じ。 勉強がてらVMまわりを少しいじってみたので自分用メモを残しておく。 眺めてたのはVMのコードで、mrubyのVMはGCCではダイレクトスレッデッドコードになるので、ラベルの配列を作ってgotoすることで命令を実行していく。 gotoするときはNEXTというマクロを使う。 #define NEXT mrb->arena_idx = ai; i=*++pc; goto *optable[GET_OPCODE(i)]ここで疑問なのはmrb->arena_idxで、こいつは何に使うのかというと、ここに説明が書いてある。 http://www.dzeta.jp/~junjis/code_reading/index.php?mruby%2FGC%BD%E8%CD%FD%A4

    GCCの勉強とmruby - mirichiの日記
  • Rubyのクロージャとforとeachと1.8と1.9 - mirichiの日記

    Rubyにはクロージャと言うものがある。 ようするに手続きオブジェクトで、Proc.newなどで作ることができる。 こいつのポイントは、それが作られた環境(ローカル変数とか)のスコープと値を保持するところだ。環境を閉じ込めるからクロージャという。らしい。 array = [] (0..2).each do |i| array.push(Proc.new {i}) end p array[0].call # => 0 p array[1].call # => 1 p array[2].call # => 2 array = [] for i in 0..2 array.push(Proc.new {i}) end p array[0].call # => 2 p array[1].call # => 2 p array[2].call # => 2 上のコードでは(0..2).eachしてい

    Rubyのクロージャとforとeachと1.8と1.9 - mirichiの日記
  • mingw版のRuby1.9.1 - mirichiの日記

    いやはや、参りました。 約50%の負荷で約1000オブジェクト、Rubyのコードだけで動くようになってしまった。 何をしたかと言うと、いままでmswin32版のRuby1.9.1を使っていたのを、mingw32版に換えただけ。 正確には ruby 1.9.1p376 (2009-12-07 revision 26041) [i386-mswin32] を ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-mingw32] にした。 別の言い方をすると、こちらからダウンロードさせていただいていたものを http://www.artonx.org/data/asr/ こちらにかえた。 http://rubyforge.org/projects/rubyinstaller/ どうなったのかというと、 http://d.hatena.ne.jp/mi

    mingw版のRuby1.9.1 - mirichiの日記
  • DXRuby1.4.0リリース - mirichiの日記

    DXRuby1.3devを作り始めたのが3月だったので、5ヶ月ほどかかった計算になる。そんだけの時間でShaderと衝突判定を再実装したと考えると頑張ったほうかもしれない。 ブログには前からちょこちょこ書いてるから改めて言うことでもないが、DXRuby1.4.0の目玉はSpriteの描画と連動した衝突判定と、HLSLでプログラマブルシェーダを扱うShaderクラスだ。Spriteは何か作るときの労力を格段に減らしてくれるし、Shaderは表現力を飛躍的に向上させてくれる。 パッチをもらって対応したアナログパッドの入力もなにげに大きい。アイデア次第で面白いものが作れそうだ。 今後1.4系としてはこれをベースに速度まわりのチューニングや積み残しの機能の追加などを行う。かもしれない。 あとは近いうちに1.5devをスタートしよう。想定している機能としては ・3D描画機能の再チャレンジ。頂点バッフ

    DXRuby1.4.0リリース - mirichiの日記
  • mrubyのContextThreading化 その5 最終回 - mirichiの日記

    こまごまとした修正と若干のパフォーマンスチューニングを入れて、O3コンパイルでmake testを通過できるようにしておいた。 https://github.com/mirichi/mruby/tree/ct この時点でAOベンチ(O3コンパイル)比較は 元のmruby:6分8秒(368秒) ContextThreading:6分9秒(369秒) となり、俺程度の技術力ではContextThreadingの効果は見込めないという状態である。 ディスパッチ関連で無駄があるとすれば間接分岐になってしまっているあたりだが、これをcall-retに再修正するためには例外の機構をごっそり入れ替える必要がある。具体的にはスタックの操作が発生するからsetjmpをメソッド呼び出しごとに入れるか、例外をインラインアセンブラで処理するか、という感じになるだろう。前者は恐らく大変遅いが、後者は大変手間である。

    mrubyのContextThreading化 その5 最終回 - mirichiの日記
    nobyuki
    nobyuki 2012/08/14
  • 1