えでぃたを作るかどうか考え中

作るならリージョン使って
非矩形ウィンドウなんだけど

C#.NETの開発環境は入れられない、ので
WinAPI直うち、でウィンドウは作って
中身はRubyで動かすとか、

ruby-gtkでできるサンプルはあったけど、意味不明な事になってた
タイトルﾊﾞｰが見えてるけどふざけてんの?

内部作ってから非矩形にするのでもいいんだけどな
どうすっか
そっちのほうがいいか

モチベーションは大切にしよう
また明日

いま関東の真上に、短い飛行機雲みたいのがあってびっくりした
俗に言われる地震雲
しかも月も大きいし

くるか・・・・

http://jp.rubyist.net/magazine/?0003-Win32OLE

require 'win32ole'

# puts WIN32OLE_TYPE.progids

ym = WIN32OLE.new("RDE.CodeWindow")
puts ym.ole_methods


適当に

遊んでた


IEやエクセルなら情報でてるけど
流石にRDEのCOM情報なんてWebで拾えるわけがなかった

oleメソッド一覧みたけど、よくわかんなかった
COMは確かに便利だと思うけど、はっきりいって外部から調べようがなくね

有名アプリケーション以外のCOMを操作するのはあきらめたほうがよさそう
つうか個人の作ったアプリのCOM利用はちょっと不安な技術、
そのうちWindowsが何とかするでしょこれ
COMていうものがありますよ～ってのは、中級レベルくらいになれば知る技術だと思うけど
ありますよ～ってだけで使える人は絶対に少ない、目に見えない機械語の塊を
関数オブジェクトと見て、プログラミングするっていう不安な技術
だから情報が出ない

COMの作り方はこんな感じらしい
http://www.dinop.com/vc/com003.html

これを見てわかるとおり、ただでさえCOMはソースコードの見えない機械語の塊を関数コールするようなもので
思い通りに動作しないときに、自分のCOMを扱うコードが間違っているか、COM側のコードが間違っているかがわからない

なのでWindowsに標準でついているアプリや有名アプリ以外のCOMを利用するのは
ちょっとあまりに不安すぎる

COMってこのままじゃちょっとダメだ
しいていうなら仕様の公開されていないdllライブラリを関数名と引数を調べながら
printfデバッグしながら使うような感じ
「ぁ、動いたｗ　これでよさそうだｗ」　みたいな。
exe側のソースコードとかはすべて見えるようにして貰わないとこれは無理

もう必要のない概念。
COMを作る代わりにアプリケーション側が外部設定ファイルや
外部スクリプトを読み込めるように設計していればCOMいらなくなる
スクリプト言語なんて実行してられないレベルのpc実行速度の時代には
重宝した技術かも知れないね
普通に見えないソースコードをソースコードで包むなんてどう考えても危ないから、多分これもういらないはず

a=[4,5,56].each_with_index.each_with_object(10).map do | ( a , i ) , b |
p i
p b
77  
end

p a

みんなーのー明日の夢ーー　守るんだーー

って歌詞いいね



ストライクウィッチーズは、

最初はなにこれって思ったけど
徐々にクオリティあがってくるアニメだった

いいと思う


マジで　最近は　周りへの奉仕活動　やら　ボランティア活動ばかりしてる気がする

自分の為でもあるんだろうけど

どちらかといえば
昔からそうだったか

そうだ

最近は自分のやりたい事っていうのを
何一つやっていない気がする

自分が誰かの為じゃなくて

本当にやりたいことって、なんだろう
テファみたいな女の子を


----
とかここまでかいて寝てた


天気いいから今日は出かけるか

とりあえずウィンドウ表示
まともに描くと長いから色々てきとーにかいているのでコンパイル通るかはわかりません

まともなWinprocは
http://www.geocities.jp/ky_webid/win32c/002.html
とかで

#include <windows.h>
#include <iostream>
using namespace std;

LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wp, LPARAM lp);
void mainloop();

int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR pCmdLine, int showCmd)
{
	WNDCLASSEX wc = { 0 };
	MSG msg;
	HWND hWnd;

	wc.cbSize = sizeof(wc);
	wc.lpfnWndProc = WndProc;             // ウィンドウプロシージャ
	wc.lpszClassName = "name";
	RegisterClassEx( &wc );

	// ウィンドウを作成する
	hWnd = CreateWindow(wc.lpszClassName,"title",WS_OVERLAPPEDWINDOW, 0,0,0,0,0,0,0,0);
	// ウィンドウを表示する
	ShowWindow( hWnd, SW_SHOW );

	while( true )
	{
		if(PeekMessage(&msg, 0, 0, 0, PM_NOREMOVE)) {
			if(!GetMessage(&msg, NULL, 0, 0)) break;
			TranslateMessage( &msg );
			DispatchMessage( &msg );
			mainloop(); // メインループ
		}
	}
    return msg.wParam;
}

// ウィンドウプロシージャ
LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wp, LPARAM lp)
{
	switch (msg) 
	{
		case WM_CLOSE:
			DestroyWindow(hWnd);
			break;
		case WM_DESTROY:
			PostQuitMessage(0);
			break;
   	}
	return DefWindowProc( hWnd, msg, wp, lp );
}

//メインの処理をここにかく
void mainloop() {

}

WinAPIのこの手の最初のウィンドウ表示プログラムがネット上に何種類もあったり

tchar使ってたり意味わからない事になっているのは
WinAPIの歴史が長いから、「これからの時代はこうしたほうがいいかな？」「いや、これからの時代はこうかくべきでしょう」
みたいな、そんな主張がソースコードに込められて
意味わからないくらい無駄に多種多様になってしまいましたとさ

どれが一番いいのか
それは、もうどれもいらないっていう状況

今の時代に書くWinAPIのソースコードなんて
動けば何でもいいんです
歴史も長いので、コンパイラが大体融通きかせて何とかするからね。

WinAPIは.NETに置き換えられたので
C,C++からWinAPIでプログラミングするくらいなら、C#.NETでやるのが最善です
なので、WinAPIはこうかいたほうがいい！みたいな主張はもういらなくて、
本当は極力WinAPIのソースコードをかかないのがいいんです
それでも、いろんなしがらみ上、WinAPIを学びたいって人は、まだこれからもでてくるはずなので
WinAPIアンチとともに、WinAPIで（WinAPIの学習目的で）ゲーム作りたい人のために、
少し文章をかいていきます

WinAPIでゼロからゲームプログラムを作るなら、
以下のライブラリを自作する必要があります。

WinAPIでやるなら、まず最初にライブラリを作らないといけない
そうしないとバグが残ってしまう ＆ ソースコードが冗長しすぎるんです
行数自慢とか古いんです。行数は少ないほうが良いに決まってる。


1 ダブルバッファリング　（ 画面をちらつかせない為に
2 スプライト　（　画像の透明化などをする
3 PlgBlt関数　( 画像の回転
4 GC等 （ WinAPIは無駄にいろんなオブジェクトが多いので、
　　実際に少し大きなソースコードを書こうとしたら、自分でGC等を作ってそれを使わないとすぐメモリリークで死ねる
5 デバッグ用の表示関数　
6 sin / cos / tan 使ってオブジェクトの移動処理
7 当たり判定各種

WinAPIは、調べていけば一応Windows上でのすべての事ができます。
でも、WinAPI関数はたまに「なんでこんな引数なの・・・・」とか、そういうひどい関数にも時より巡りあう
（ ウィンドウプロシージャのところが既にそうだと思う ）

1 ダブルバッファリング
2 スプライト 画像の透明化
3 PlgBlt関数　画像の回転
6 sin / cos / tan 使ってオブジェクトの移動処理
7 当たり判定各種
このあたりは、ゲームライブラリで標準で備わってる

WinAPIでかくと、その１～７だけで１０００行程度にはなるでしょうね
設計がど下手でしかもWinAPIを丁寧に書いちゃう人だと、これだけで下手すると１００００行とかいくはずです。ｶﾜｲｿ
結局、最終的にはそうやって自分でライブラリを作って

Window.draw(hdc2 , 0, 0 );
とか
Sprite.draw(g , 100 , 200 );

なんていうソースコードを描くだけなので
ライブラリ側をWinAPIで作るか、最初から用意されてるライブラリを使うかの違いです
もしライブラリ側で、備わっているのであれば、
丁寧にC++WinAPIで１万行かけたソースコードは、数十行になります

一番大きな点は、4で
WinAPIだと、かなりの時間をかけなければ
ちゃんとWinAPIをラップできないんです（ WinAPI直うちしてると普通にバグが残る ）
だから、（無駄な）オブジェクトの取得開放が、WinAPI以外のライブラリでは
WinAPIほどは気にしなくていいので、メモリリークがずっと少なくなるはずです
はっきりいってWinAPIでメモリリークなしにプログラムを完成させれる人は
自分でGC等を作れるか、よほど慣れているかのどちらかです
WinAPI以外でプログラミングする時にも、GC等はあったほうがいいんだけど、WinAPIほどオブジェクトの取得開放が
キチガイ染みてるライブラリは無いと思うので、なくても何とかなるレベルです
そういうところがWinAPIでゲームつくりは無駄ですよって思うところ

ようはなるべく、自分でゼロからソースコードを書くというのだけは本当に一番最初の頃だけ
「自分はまだまだ初心者かな」って思う時だけにして、少しできるようになったら
極力自分ではソースコードを書かずに、Webから既に作られたライブラリを探して
それを使うようにすべきです

自分が、ゲームプログラミングしようとした頃は、
検索すると、C++とWinAPIとDirectXの資料ばっかり出てきたので
あ、これでいいのかなって思って
C++/WinAPIで普通に作っていた時期がありました
数万行の無駄過ぎるソースコードがHDDに眠ってます


上に上げた1～7のライブラリに加えて、
そこら辺のゲームライブラリにある機能は、だいたいすべて何もかもWinAPIで実装してしまいました
なんていうかライブラリっていうか、フレームワークって呼んでもいいレベルですけど
　
もうC++使わないし、WinAPIも使わないので
すべていま無駄になっています＾＾

あひゃひゃ


こんなことにならないように、WinAPIはやめましょうってことをいいたい

一応、経験にはなったけどねｗｗｗｗｗｗｗｗｗｗｗｗｗ



だから何を使えばいいかって事だけど、的確に答える自信がない
っていうか、自分から言わせれば2012年にはいいものが何もない
ゲームライブラリのほとんどは、C++かC#で使うものだけど、
C++,C#をあまり勧める気にはならない

スクリプト言語側では、Rubyがかなり完成度高いから
速度必要のないゲーム作るんだったらそれでいいんだけど
速度を必要とするゲームを作ろうとした場合は
ネイティブ言語側には、2012年の時点でまだ完成度の高い言語が存在していない
なので数年置きに「どの言語を使えばいいのか？」なんていう問いへの答えはどんどん変わっていくって事でした
確かにC++よりは良くて、今はC#がいいみたいに言われてるけど、C#が誕生したせいでVBが使われなくなった事を知っていれば
C#があと5年先も存在してるかどうか怪しい事は・・・わかるよね、どんなに長くてもC#は10年後には絶対に非推奨の言語になってるだろう
結局まだ今の時代はまだ色んな物が発展途中だから、流行りの言語やLibを使っていくしかないかも
とりあえずWinAPIでゲームプログラミングだけはやめておくべき

勉強目的や、WinAPIが、いかにカスみたいな実装されているかを知りたければ
やってみてもいいと思う
いずれにせよ、.NETがもう少しC#以外の言語からも使いやすいようにされてくれば
WinAPIは完全に使われなくなっていくはずで、初心者が迷い込むことなくなると思うんだけど
まだ他言語から.NETがっぜんぜん触りにくいんだよMS仕事してほしい

少し時間がたてばまた意見は変わると思うけど
2012年2月時点で、もし自分がまともにゲーム作りをするなら
C++/Ruby/DirectXでやりますね
C#のほうがC++より言語仕様はいいんだけど･･･､
どうせ将来成長も止まって使われなくなる事が決定してるような言語でソースコードの遺産を作ろうとは思わない
MSはもうD作り始めてるからね,C#捨てる気満々ですよ
一応C++はまだ成長し続けてるから、C#よりは先の未来を期待できる

世界の９割のコードがキチガイかと思った