サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
colorful-pico.hatenablog.jp
ゲームの通路など、同じオブジェクトのパターンを複数用意する必要がある場合、 ステージのルートのパスを最初に作成してから、パスに沿って複製することで、 手間がかからずに通路を作成することができる。 Blenderでは、以下のようにしてパスに沿ってオブジェクトを複製することが可能である。 ※動作確認を行った、Blenderのバージョン:2.69 [操作手順] 複製するオブジェクト(obj1)を作成 「Ctrl+A」-「Curve」-(目的に沿ったパス)を選択し、パスの原型(path1)を作成 必要に応じて2.で作成したパスを編集 obj1を選択し、モディファイア「Array」を追加 「Fit Type」を「Fixed Count」にし、適宜「Count」の値を変更 obj1を選択し、モディファイア「Curve」を追加 「Object」にpath1を指定し、適宜「Deformation Axis
ほとんどのレーシングゲームでは、逆走した時に逆走したことを示すメッセージが表示される。 逆走したことのメッセージが存在しないと、 プレイヤーが逆走に気がつかないまま逆走を続けてしまう可能性があり、非常に不親切である。 現在作成しているアプリでも同じ機能をつける必要があり、 逆走判定を行う必要が出てきたため、逆走判定のアルゴリズムをまとめてみた。 候補となるアルゴリズムは、以下の3つである。 1. 進行方向を示すマップを作成し、現在地の進行方向と自身の進行方向を比較 [アルゴリズム] 2Dまたは、3Dで高さ成分をあまり考慮する必要がない場合は、 2次元配列等を利用して、各場所における進行方向を持つマップを作成すればよい。 3Dで高さが大きく変更される場合(フライトレーシング等)は、 3次元配列を用いて3D空間上を表現すればよい。 [利点] それぞれの場所で進むべき進行方向の判定が行えるため、
Qiitaと呼ばれるサービスが登場してからそれなりに時間が経ちましたね。 それなりに時間の経っているサービスですが、私がQiitaで本格的に投稿を始めたのは去年の11月でした。 Qiitaに投稿されるものはブログレベルの長文からメモ書きレベルの短文まで様々です。 基本的に私は前者のようにQiitaを使っているため、ブログとどのように使い分けたらよいか悩んでしまいました。 ついこの前までは、Qiitaに投稿した記事をブログにも移植して投稿することにしていたのですが、ある意味マルチポストになるわけで、気分が悪かったです。 そこでそれぞれの使い道を考え、私なりに答えが出たため、Qiitaとブログの使い道をまとめてみることにしました。 同じような問題で悩んでいる方にとってこの記事が参考になれば幸いです。 Qiita - プログラマのための技術情報共有サービス 最初にQiitaとは何か分からない人が
Linuxカーネルのソースコードを読み始めて、2週間弱経過したのでちょくちょくまとめていこうと思う。 記念すべき第1回は、Linuxがどのように起動されるかを簡単な流れとしてみてみることにする。 詳細な部分の解析をきちんと行っていないため、不満点もあるかもしれないが、参考になれば幸いである。 Linuxのバージョンは2.6.15とし、アーキテクチャはx86_64とする。 簡単な流れとしては以下のようになっている。 linux/arch/x86_64/boot/bootsect.Sは最初に実行されるプログラム linux/arch/x86_64/boot/setup.SでGDTとIDTの設定、プロテクトモードへの移行を行う linux/arch/x86_64/kernel/head.Sは64bitモードへの移行、GDTとIDTの再設定を行う linux/init/main.cでLinuxの各
最近、技術書を読んでいても頭に入ってこなく、読むのに時間がかかるので、読み方が問題なのか気になっていた。 そこで、読み方を変えてみようということで、技術書の良い読み方を検索してみた。 検索の結果わかったことは以下の4つ。 目的があまりなく読んだ本に関しては、ほとんど記憶に残らない 既に知っている内容の部分を読むのは、時間の無駄 積読の消化を意識すると、理解度(集中力)が下がる 理解していないのに、理解した気になっていた そしてこれらの解決法は、以下の2つである。 アウトプットを意識して読む 内容が重要でない、または理解している内容は、流し読みする 特に重要なのは、1のように目的を持って読むことであると思う。 今までの自分は、何となく技術書を読んで、理解した気になっていた。 これでは、せっかく技術書を読んでも時間の無駄になるだけだし、アウトプットもないので達成感も得られなく、また何となく技術
そろそろ本格的にLinuxのソースコードを解読していこうと思う。 Linuxのバージョンは日に日に上がっていき、現在は3.3が最新のバージョン(mainline)である。 最新の技術を知りたいのであれば、最新バージョンを読むほうが良いのだが、ざっくりとLinuxのソースコードを知りたいだけなので、資料が整っている2.6.xあたりを読もうと思う。 さらに、Linuxカーネル2.6解読室との対応を考えて、2.6.15を対象とする。 通常、Linuxカーネルのソースコードは通常、http://kernel.org/から入手できるが、tar.bz2で固められていて、いちいちダウンロード・解凍しなくちゃいけない。 これはちょっと面倒なので、別の環境でもすぐに見られる方法はないかと探していたところ、LXRという、LinuxカーネルのソースコードをWeb上で見られるサービスを発見。 http://lxr
2016年に入ってから記事を書いていませんでしたね・・・ ちょっとした報告や宣伝はTwitterでもできることを知ってからは、なかなかブログを書くこと自体少なくなりつつあります。 去年と変わらず作曲/DTMの勉強やBlenderを中心に活動しているというのが近況報告です・・・が、ここにきて大きな出来事がありました。 なんと、今年夏に開催されるコミケ(C90)に私のサークル『COLORFUL PICO』が当選してしまったのです!当選確率が半分以下と言われている中で、初申し込みで当選できたのは運が良かったとしか思えません。 ちなみにC90では、昨年の9月くらいから執筆しているBlenderのアドオン開発入門本『はじめてのBlenderアドオン開発』を頒布する予定です。 本来であれば、同人ソフトを頒布するためにコミケに出ることを夢見て活動していたので、少し畑違いな分野で参加することになりましたが
30日本とか、はじめて読む486とかで紹介されているコンテキストスイッチ(タスクスイッチ)は、TSS(タスク状態セグメント)を利用した方法である。 しかしここ2週間、TSSを用いたコンテキストスイッチがどうもうまく行かないので、別の方法を試みた・・・というよりは、迷っている間に自前で用意できそうな気がした。 ちなみに、LinuxもTSSを用いたコンテキストスイッチを行っていないことから(アーキテクチャへの依存性などを考慮しているため)、TSSを使わないコンテキストスイッチで実装することは、よい勉強になるのではないと思う。 で、実装できたのでここで書いてみる。 TSSを用いないコンテキストスイッチを行う方法は、以下のようになる。 前タスクのレジスタ(汎用レジスタ、EFLAGS)の退避 前タスクのスタックポインタ(ESP)の退避 前タスクのプログラムカウンタ(EIP)の退避 次タスクのスタック
このページを最初にブックマークしてみませんか?
『趣味プログラマによるOSS開発日誌』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く