だいれくとしょうについて

DirectShowについて、、、

お仕事で使っていて　『ん？... あん///』

となったことを書いておきます。

フルHD( 1920x1080 : 1080pi )の動画をDirectShowでフルスクリーン再生しようと思った場合、

ソースフィルタのアウトプットピンと描画ピンの接続でエラーが出た。

コーディックもちゃんと入れて　ウィンドウズメディアプレイヤーで再生もできる（ DirectShowを扱う上で、ウィンドウズメディアプレイヤーで再生できるなら何でも再生できる）

のに、何故か失敗。

迷った挙句、

モードを 32bit から 64bit に変えた。

DirectX のライブラリを x64 に。
そして、DirectShow関係も全部 x64にする。　この時、Strmbasd も予め、 BaseClassesを64bitでビルドを通して出来た 64bitのを使用する。

そしたらフルスクリーンでも美味く行った！！

おいしいいいいいいいいいいいいい！！！！！

恐らくは64ビットじゃないと能力が足りないのかもしれない。

でも、出来たのでほんとうに嬉しい。

これで仕事終わる
(´；ω；｀)

切実....

うわあああああああああ！！！（AA略

ふぇえぇ・・・　

この二週間あまり年度末ということで仕事が建て込み、ブログなんてしてる暇がねぇ！( ﾟдﾟ)!

と、自暴自棄、、死屍累々、、奇妙奇天烈摩訶不思議、社畜

となったので更新出来ませんでした。
すいません。。。

しかぁし！！

社畜の中の社畜。

シャチキングの私は、徹夜を行くどか繰り返し、そろそろ終わりそうな兆しが見えて来ました！！！

なので近日更新予定！

次回！！！　　トンジ... 死す！？

っぱい

( ﾟдﾟ)ﾊｯ!

仕事中に小一時間ブラジャーwiki を眺めてしまった・・・

なんなんだこの情報量・・・

ふらっと偶然にもブラジャーwikiを見てしまった俺。

圧倒的なまでの情報量の前に僕は目を背けることは出来なかった。

なんかすごい力が湧いた気分。　コレヤバイ。

みんな見るべき。

サイズやらワイヤーやらカップやら・・・・　なんなんだこの種類の大きさは・・・

プッチンプリンのカップに紐を通してセットしたらいいんじゃないんですかねぇ！？

寄せてあげるブラとかありますけど、あんなもんタダの詐欺だ！つД｀)･ﾟ･｡･ﾟﾟ･*:.｡..｡.:*･ﾟ

ブラジャーの歴史は古く、古代ギリシャからあったそうな。

その頃はまだカップの定義など無かっただろうが、この現代。
女性はカップ１つあげるために血で血を洗う争いを繰り広げている。

・アンダーバスト : 胸囲の下の周り。
・トップバスト : ティクビの周り。

そこから引いた大きさを「カップサイズ」という。

なるほど。

10cm ならば Aカップ。

ここから 2.5cmずつ大きくなるとカップサイズがランクアップ。

つまり B、C、D、E・・・　と巨乳の階段を一歩一歩歩いて行く。

しかし！ 10cm 以下の場合、こちらも 2.5cm刻みで

7.5cm → AA カップ
5cm → AAAカップ　となる。

ゲームセンターのランキングやスコアなどでは AAA が出ると大いに喜ぶもの。

そう、AAAだからって悲観することはないのだ。

『私トリプルエー決めちゃったのよー！』　

ｴｰｳｿｰ!!　ｽｺﾞｰｲ!!　　　
ｷｬｰｷｬｰ!!!

次の日から貴方のアダ名は"まな板の上の鯉"。

5cm ない人はどうなるのだろうか。

普通に 5cm ない人っていると思う。

ティクビすら見放された存在。　それこそまさしく　S級

難易度高そうな存在である。　攻略も難しそう。

ここで外人と日本人の違い。

外人は窮屈な感じがすきらしく、サイズを図る時にやや押さえ気味に図る模様。
日本人は見えを張るのでふんわりと。

なので日本人は外人に比べて基準が甘い！！　甘すぎるっ！！！　もっと厳しく当たらなければ！！！！

男はなぁ！　悲しいことに”胸が大きい”ってだけで気持ちがﾊﾞｽﾄｼｭｰﾄしてしまうのだよ！

本当に悲しいことにな！！(T_T)

偽りの情報、それが虚実だとしても信じてしまう。そして心動いてしまう。そして騙される。

やめてくれ

もうおっぱいのことで闘うのは辞めたい。おっぱいで誰かが傷つく世の中は嫌なんだ・・・

僕は・・・　僕は純粋におっぱいを楽しみたいんだ・・・

夜、月明かりに照らされたおっぱいを眺め、
静かに、静かにその双丘を天辺を眺め日本酒を一口流し込み気持ちよくなる。。

至福の時

これだけで・・・　これだけでいいから。。

おっぱい下さい・・・・

Android買ってから iPod が埃かぶっとる・・・

久々、あいぽんのプログラムに付いて書きたいと思います。

ゲーム作っている時に実際に出たバグなんです。。。が。。。

皆様は音を再生するとき何を使用しておりますか？

僕は一番良く使われてる（？）

AVFoundation の AVAudioPlayer なるものを使用しています。

こいつが中々のクッサイものでした。

初期化は下のようにして

/**

* ファイル名からメディアを取得する

+ ( IOSMediaSound* ) GetSound:( NSString* )pSoundname

{

/** リソースから読み込み **/

NSString* path = [ [ NSBundle mainBundle ] pathForResource:pSoundname ofType:@"mp3"];

if ( !path )

{

NSLog(@"音楽ファイル : %@がありません", pSoundname);

return NULL;

}

NSError* playererror;

NSURL* url = [ NSURL fileURLWithPath:path ];

AVAudioPlayer* pSound = [[AVAudioPlayer alloc] initWithContentsOfURL:url error:&playererror];

/** メモリに読み込ませておく **/

if ( ![ pSound prepareToPlay ] )

NSLog( @"音 : バッファ読み込み失敗" );

if ( playererror != NULL )

NSLog(@"Error %@", playererror);

IOSMediaSound* pMediaSound = [ [ IOSMediaSound alloc ] initWithSound:pSound ];

return pMediaSound;

}

prepareToPlay にて、『再生時の遅延を無くすために予めバッファに読み込んでおく』

ということをしました。

これで、いきなり　”再生！”　ってしてもすぐ再生されます。( 成功してたら )

ここはファクトリクラスの一部なので、サウンドの生成しかしていません。

実際は IOSMediaSound ってクラスがサウンドを保持しているクラスです。

@interface IOSMediaSound : NSObject

< AVAudioPlayerDelegate >

{

@public

/** サウンド **/

AVAudioPlayer* mpSound;

/** 管理クラス : ここに様々なイベントの処理を書く **/

IOSAudioPresenter* mpPresenter;

}

管理クラスを持っているのはいけないことだと思ってますが、なにか使うかもわからないので一応ｗ

で。

再生は play、停止は stop、一時停止は pause。

基本。

これはわかりました。

何が頭を悩ませたって..

stop したらせっかく
prepareToPlay で読み込んでおいた音をバッファから取り除くんですね。

これは中々・・・ﾌﾞﾌｯ∵(´ε(○＝(ﾟ∀ﾟ　)

実際、 SE もこのクラスで使用していて、

SE の再生中に別の SE が流れると、
前のSEは stop して新しい SE を play していました。

そして stop するとバッファから消えるので、
新たに prepareToPlay を書いていました。

これで、シュミレーターでは全然普通に動きました。

そう、問題は実機。

恐らく、デバイスの処理能力の問題だと思いますが、

stop の後に、 prepareToPlay を書くとエラーﾟ(ﾟ´ω`ﾟ)ﾟ｡

止まりはしません。遅延が起こります。

================================================================

『ふぅー・・・　ようやく出来た－！　後は申請かなー♪』

↓　実機テスト

連続したSE再生の所で音がならない（　＾ω＾）・・・

↓

『おっぱい揉みたいなぁ～( 現実逃避 )』

↓

以下ループ

================================================================

随分悩まされました( ´Д｀)=3

で、
『どうしたらいいんだ・・・』　と考えた結果

↓

そう。

stop がダメなら pause にして、
後は音の位置を先頭に戻したらいーじゃーん！　FOOOO！！

ってしましたｗ

『pause だからバッファも開放されないし(b´∀｀)ﾈｯ!　』

果たしてこれで大丈夫なのか。

心配で夜もグッスリです。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

後、実機でテスト中に IOS4.3 だと起動しないバグが出た。

これはよくよく見たら

IOS 5.0 以降の　
『GLKit』と『CoreImage』をフレームワークに追加していたからだった・・・

いや、もうなんかね・・・

しかもこの２つ、アプリ内では使ってなかったというｗｗｗｗ

なんで追加してたんだろ　俺・・・

以上！

音の管理や画像の管理は色々と工夫しようと思った。

それこそ前の記事のファクトリクラスで読み込み部分は別に書くとか？

わからん。。。勉強あるのみだわ

工場長直下去勢許可局っ！！　（舌噛み

C++ をお勉強していると時たま目撃する Factory という文字。

デザインパータンの一種である彼は、

ただ、 new してオブジェクトを返す。

class Human{};

;// 人間を作る工場
class HumanFactory
{
public:
Human* CreateInstance()
{
return new Human;
}
};

~~~~~~~~~~~~~~~~~~

HumanFactory* pHumanFactory = new HumanFactory;

// Humanが生成される
Human* pHuman = pHumanFactory->CreateInstance();

↑ Human が new されて戻ってくる。
そして上の例では delete を忘れてしまいそうなので本当はスマートポインタにしたい所。

『なんだそれ？？　
生成とか自分で new 書いてするし特にいらねーじゃん・・・』

と、ずっと思って使ってなかったのですが、

　『おぉ～！』と思える例がありました。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

① : 生成コードを分ける。

ゲーム作成時、ある所でモンスターを作りたいとなりました。

識別子によって生成したいモンスターを変えたいです。

現在、モンスター情報クラス自体が生成コードを持つ書き方をしています ↓

// モンスター情報を持つ
class MonsterInfo
{
private:
Monster* pMonster;

public:
Monster( MONSTER_TYPE )
{
switch( MONSTER_TYPE )
{
case SLIME: pMonster = new Slime;
　・
　・
　・
}
}
};

う～ん・・・
あまり長いコードを１つのクラスに書くのは可読性を殺してしまう・・・

出来れば生成コードは別の所に移したい。。

それにモンスター生成コードだけは別の場所でも使うかも。

そこでまた書くの面倒くっっさ　Σ(ﾟёﾟノ)ﾉ

って時にFactoryクラスを別で作成し、この中でｶﾞｯｼｬﾝｶﾞｯｼｬﾝ作っちまいます。

//** モンスターを作成する工場
class MonsterFactory
{
public:
Monster* CreateInstance( MONSTER_TYPE type )
{
Monster* pMonster;

switch( type )
{
case FASHION_MONSTER: pMonster = new FashionMonster;
case OPPAI_MONSTER: pMonster = new OppaiMonster;
};

return pMonster;
}
};

なんか、
人間やモンスターを工場で生成するって思うと悲しくなりますねｗ

これでモンスターの生成を分けることが出来、

ファクトリーに識別子を渡すだけでモンスターが返ってきます。

MonsterFactory* pMonsterFactory = new MonsterFactory;

Monster* pMonster = pMonsterFactory->CreateInstance( FASION_MONSTER );

↑のファクトリーは、
様々なクラスに使用する可能性もあり、使い回しできそうなので

シングルトン化するといいかもしれないです。

② : 色々変化するぜ！

class Human{};

という人間の元クラスがあり、こいつを継承しているクラスがたくさんあるとします。

識別子を使わず、生成をその場その場で切り替えたい時。

class Human{};
class Woman : public Human {};
class Gentleman : public Human {};

class HumanFactory
{
public:
virtual Human* CreateInstance() = 0;
};

という基底ファクトリークラスを作って、

Class WomanFactory : public HumanFactory
{
public:
virtual Human* CreateInstance() { return new Woman; }
};

Class GentlemanFactory : public HumanFactory
{
public:
virtual Human* CreateInstance() { return new Gentleman; }
};

・
・
・

~~~~~~~~~~~~~~~~~~~~~~~~

HumanFactory* pHumanFactory = new pWomanFactory();

// 女性が生成される(*´Д`)
Human* pHuman;
pHuman = pHumanFactory->CreateInstance();

識別子がないので良い感じ///

しかし、型によってこんなの作っていては使いにくい。 いや、面倒くさい

③ : 柔軟なFactory

型によって作成するのが面倒臭いなら型をなくせばいいじゃ～ん。

そういうことで template を使ってみます。

template < class T >
class Factory
{
public:
virtual T* CreateInstance() { return new T; }
};

~~~~~~~~~~~~~~

Factory< Woman > pHumanFactory;

Human* pHuman = pHumanFactory.CreateInstance();

↑ Woman インスタンスが作成される。

これで大分Factoryが使いやすくなりました。

④ : 変身

次に、

メタモンがいます。

・・・って、まぁ実際にはいないし、特に意味もないんですがｗ

何でも変身できるメタモン。　

Object というクラスを継承したクラスに何でもなれるとします。
実際は Objectクラスを内部にもち、使用出来る。。とする。

コンストラクタに変身先の識別子を渡すようにした場合、

class Metamon
{
private:
OBJECT_TYPE mObjectType;
Object* mpObject;

public:
Metamon( OBJECT_TYPE type )
: mObjectType( type )
{
switch( type )
{
case TYPE_NAKED_LADY: mpObject = new NakedLady;
case TYPE_OPPAI: mpObject = new Oppai;
　　　　・
　　　　・
　　　　・
}
}
}

まぁ、臭い。

そして、後から新たな変身先を追加した場合、

Metamonクラスをいじらなければなりません。

しかし、Metamonクラスをライブラリ化していた場合
Metamonクラスをいじることは不可能になります。

これでは新しく何かを追加したい場合、恐らく現実から逃走します。

なので、
ファクトリークラスを渡すようにします。

class Metamon
{
private:
Object* mpObject;

// Object型のFACTORYクラスを内部に持つ
Factory< Object > mObjectFactory;

public:

Metamon( Factory< Object >& objectFactory )
: mObjectFactory( objectFactory )
{
// 例ではコンストラクタで生成してるが、
// いろいろな場所で生成できる。
mpObject = objectFactory.CreateInstance();
}
};

（こんな作りをする人がいるかわかりませんがｗ）

コレだと自分でファクトリークラスを色々書きなおしてから

渡すだけでそれに変身してくれるので良い感じ、じゃないでしょうか？

Metamonがライブラリ化していても変身先を増やせる。

まぁ、こんな感じに作りたいと思った場合、

コンストラクタで Object を継承したクラスのtemplateファクトリークラスを渡したいです。

// Objectを継承したクラス。

class Oppai : public Object
{};

// Oppaiに変身して欲しいからOppai型のFactoryを作成
Factory< Oppai > objectFactory;

// こんなかんじに渡すのかな？
Metamon* pMetamon = new Metamon( objectFactory );

しかし、これはエラーが出ます。

Oppaiが Object を継承しているとはいえ、

Factory< Oppai > と Factory< Object > の間にはなんの継承関係もないのでダメです。

なので新たなファクトリクラス。。

// T が基底クラス。 S は Tを継承したクラス。
template < class T, class S >
class SecondFactory : Factory< T > // Factory< T >を継承している
{
public:
// SをTに変換して返す
virtual T* CreateInstance() { return new S; }
};

を作ってみる。

こうすれば、

// Object と、それを継承した Oppai を template に渡す

SecondFactory < Object, Oppai > objectFactory;

// Oppaiに変身するメタモン
Metamon* pMetamon = new Metamon( objectFactory );

と、

引数のファクトリークラス( SecondFactory< T, S >)とメタモン内にあるファクトリークラス( Factory< T > )は

継承関係にあるのでエラーは出ません。

かつ、 Metamon内でファクトリーを使うと Oppai クラスが生成されます。

なんか当たり前のようですが、ファクトリーの有用性がわかった気がしました。

こんなかんじに、

　後から、生成したいクラスを増やす or 変えたい！

という時にすごい便利です。

たとえば、
上記に加えてメタモンにお金にも変身して欲しい時、

Factory クラスを新たに

class Money : public Object
{};

そして新たなFactory...

SecondFactory < Object, Money > objectFactory;

と作れば、

~~~~~~~~~~~~~~

// お金に変身するメタモン
Metamon* pMetamon = new Metamon( objectFactory );

メタモンはお金に変身します。　　

お金ほしいわー・・・
(´；ω；｀)

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

これまで、Factoryを使って来なかったので、コレを踏まえて僕も

Factoryをまな板の鯉のように、踊るように使ってゲームを作成してみたいです( - ω - )

↑の SeconFactory は、もっと使いやすく出来ます。

一々コンストラクタに引数で渡してるあたりを消して、、、
デフォルトでは Oppai を生成ようにする。　指定があれば生成するObjectを変化させる。

という風にしたいです( ﾟρﾟ )

Windowsプロフェッショナルプログラミングという本に
完全実装が載っております。

C++ を初めて『そろそろ新しいこと覚えたいなぁ～・・・』　

となってる方に是非進めたい一品でございまする。

中古ではものすっごやすいですｗ

中古といえど、僕のは新品同様でした。CDも未開封でしたし..