2010/03/01(Mon)続・言語の壁

はてブ数 2010/03/01 23:06 計算機な日記::ソフト作り つーさ

3月です。

体調不良気味でえsサボってDirect3D周りの記事読んでたら、10時間経ってました。やばい。

C++使おうと思ったら、C++にはGCがないから、
自分でGCを作った方がいいのか、それともSmartなポインタを駆使すべきなのか。
まぁ、自分でGC作ろうと思ったら研究が足りないので、おかしなGC作ってメモリリークさせるよりは、
Smartなポインタクラスを作った方がきっと成功しそうな気はしますよね。

パフォーマンス

以下gdgd

続きを読む

2010/02/16(Tue)言語の壁(C#とC++の狭間で揺れる)

はてブ数 2010/02/16 5:21 計算機な日記::ボクと計算機 つーさ

プログラム書くのに言語はそんなに問題じゃない。だってやることは一緒さ。
それはある意味正しいけど、ある意味間違いでもある。
だって、高級言語には構文だけじゃなくて「機能」が備わってる。

就活してる。会社説明会とか行く。
どこに行っても「C/C++プログラミング経験のある方」と言われる。
僕の普段使いの言語はC#なんだよなぁ。

僕はゲーム作りに、ずっとC#を使ってきた。
でも、高確率でこれからはC++を使うことになると思う。あるいはJavaかもしれない。
僕はC++も書けるけど、「STLをある程度使える」ぐらいのレベルでしかなくて、マスターしてるとは言い難いし、
Javaなんか、大学の課題でブロック崩しAppletを作っただけ。ほとんど書いたことがない。

たとえば、C#で僕が作ったゲームアプリケーションと同じコトをC++でやろうと思うとどうなるのか。
C#にはC#の流儀があって、C++にはC++の流儀があるから、1対1でトランスコードするのが必ずしも美しいわけではないけど、
C#からC++へ環境を移そうと思ったときに、今まで書いてきたコードはどうすればいいのかというのを考えてみる。
C++を日常的な言語として使うにあたって、僕が今から勉強しないといけないことは何なのか明確にする意味を込めて。

続きを読む

2010/01/27(Wed)ゆびったー - twitter botを作ってみた

はてブ数 2010/01/28 0:36 計算機な日記::ソフト作り つーさ

前から1度ぼっとを作ってみたかった。
別に、そんな難しくなかった。

@jubeatter
自己紹介: @ttsuki (TU-SA) の jubeatニュースを報告するbotです。フレコ: 14400002896462

今回もC#で書いた。

似たようなこと誰かやってないかと思ったけど、誰もやってなかった。
まぁ、誰得?って感じではある。

1回の更新に関するつぶやきを1つにまとめたら、自分の本アカウントでも使えそうではある。
ごく身内向けに、あー、つーさ今ゲーセンにいるのね、みたいな。
試しにWebサービスにしてみるとか?

OAuth に関しての参考メモ
http://code.google.com/p/oauth/
http://watcher.moe-nifty.com/memo/2009/04/c-oauth-c097.html

2009/10/08(Thr)めも

はてブ数 2009/10/08 8:52 計算機な日記::ソフト作り つーさ
  • XNA の検索結果 約 3,420,000 件中 1 - 10 件目 (0.22 秒)
  • Managed DirectX の検索結果 約 297,000 件中 1 - 10 件目 (0.24 秒)
  • SlimDX の検索結果 約 14,800 件中 1 - 10 件目 (0.15 秒)
  • SlimDX に一致する日本語のページ 約 5,590 件中 1 - 10 件目 (0.23 秒)

うーん……

GSDKをSlimDX上に移植してます。
ちょこちょことブラッシュアップしつつ、だいたいはコピペっていう。
MDX1.1に比べて微妙に不親切だったりしてますが、書き換えること自体はあんまり難しくないみたいです。
ただ、これ何だろう? と思ったときに調べると↑なので、移植が終わってからが難航しそうだなぁ。

なんつーか、ライブラリばっか作ってないでゲーム作れって話なんですが。

2009/05/27(Wed)StaticResourceLoader.cs

はてブ数 2009/05/27 2:48 計算機な日記::ソフト作り つーさ

GSDK on C# で。

これで

namespace Tsukikage.GameSDK.Base
{
  public interface IDXResourceLoader<ResourceType>
  {
    ResourceType LoadResource(ResourceType target);
  }
}

こうして

namespace Tsukikage.GameSDK.Direct3D
{
  public class D3DDevice : DXResource,
    IDXResourceLoader<D3DTexture>, IDXResourceLoader<D3DFont>
  {
    public D3DTexture LoadResource(D3DTexture target)
    {
      LoadTexture(target);
      return target;
    }
  }
}

こうやって


using Ref = System.Reflection;
namespace Tsukikage.GameSDK.Base
{
  /// <summary>
  /// staticリソース読み込み支援クラス
  /// </summary>
  public class StaticResourceLoader
  {
    static Dictionary<Type, StaticResourceLoader> loaders = new Dictionary<Type, StaticResourceLoader>();
    public static void Load<TypeToLoad>(Type target, IDXResourceLoader<TypeToLoad> loader)
    {
      lock (loaders)
      {
        if (loaders.ContainsKey(target) ) 
          return;
        
        loaders[target] = new StaticResourceLoader();

        foreach (Ref.FieldInfo fi in target.GetFields(Ref.BindingFlags.Public | Ref.BindingFlags.Static))
        {
          if (fi.FieldType == typeof(TypeToLoad) && fi.GetValue(null) != null)
            loader.LoadResource((TypeToLoad)fi.GetValue(null));
        }
      }
    }
  }
}

で、こう。


namespace WindowsGame1.Scenes
{
  public class Textures
  {
    public static D3DTexture Circle = new D3DTexture("circle.png");
  }

  class Scene1 : Scene
  {
    public override void Initialize()
    {
      StaticResourceLoader.Load<D3DTexture>(typeof(Textures), GSDK.D3D);
    }
  }
}

……。

まず口から出てくるのは「キメェ」の一言かもしれない。

ただ、大富豪的プログラミング時代においては、中規模程度のゲームまではこういうリソースの持ち方もありかなぁと思わないでもない。

(自分も含めて)ゲーム作り初心者が多いうちのサークルでは、この前もテクスチャリソースがリークして大変なことになってたけど。

ここを読んでくださっているみなさんはどう思われますか、なんつて。

ここを見てる人はきっとリソース管理なんて朝飯前で、こんなことしないのかもしれない……。

あー、ゲーム作りてぇなぁ……。

2009/05/07(Thr)ブロック崩し

はてブ数 2009/05/07 5:32 計算機な日記::ソフト作り つーさ

そういえば5月に入ってから日記を書いていないじゃないか。

ブロック崩しを作っている。

作っているといっても、まだ、1文字もコードは書いてないので
作ろうかなぁと考えていると言った方が正しいか。

簡単だと思っていたけど1つわからないことがでてきてしまった。

ボールが長方形であるブロックにぶつかったときに、
X軸速度成分を反転するのか、Y軸速度成分を反転するのか。
これを判定するスマートなアルゴリズムとはなんだろか。

ブロックの縦横の辺の長さの比とatanを使う?
ボールの半径分太らせた長方形を用意して、ボ線分と円の交差ール中心が今どの矩形内に収まっているかを判定する?
ブロックの4辺に対して、線分と円の交差判定を適用する?
いずれの方法でもやればできそうなのだけど、なにぶん面倒くさがりなもので。

それに、ボールは離散時間上を動くわけでブロックや壁にめり込む。
単に衝突を矩形判定してると、2つのブロックに同時にぶつかりうる。
よくよく考えないと2回反射して貫通弾になってしまうだろう。

現フレームで移動するはずのブロックの軌道を線分で表して、
衝突面での反射をシミュレーションするとか。

ブロックを円にするという誰もが思いつきそうなアイディアを採用すると、
当たり判定は円判定になって、反射方向はベクトルを射影して計算するーとか。

でも、よりうまく反射させるには、同じように軌道を線分化、
ボール半径分太らせたブロック円との交差判定、
めり込むはずだった分の距離を、その交点で反射、か……。

とまぁ、改めていろいろ考えてみると、
アクションゲーム作りを学ぶにはブロック崩しはなかなかいい題材なのかも。
そのうちプロジェクト自体放り出しそうだなぁω

2009/02/25(Wed)反マニュアル主義

はてブ数 2009/02/25 6:30 計算機な日記::ソフト作り つーさ

「一般の人」にとっては、もうそういう時代、ね。
理解に2秒を要したらその時点でその機能は使ってもらえない。
FAQ、ヘルプが必要なシステムは設計からして間違ってる。
でも、最後に勝つのはマニュアルを事細かに読んだ人間。

昔は、パソコンのマニュアルとか周辺機器のマニュアルとか分厚いのがついてきて、
私はそのほとんどに目を通したもの。だから、所謂普通の人よりはパソコンに詳しかった。
最近、普通の人と自分を差別化するのが難しいと感じるようになってきたのは、
C#とかインテリセンスとか使ってるせいであり、
すっかり「マニュアル」というものを読まなくなってしまったせいであり、
世の中のソフトウェアが親切になってきたせい、なのかもしれない、なぁ。
そんな私は、未だにマニュアルが必要なプログラムを書き続けている、気がする、が。