2010年7月19日月曜日
「いめーじぺたぺた」v1.06
「いめーじぺたぺた」v1.06
http://cid-8cd7cf5ea9fbca55.office.live.com/self.aspx/Public/program/imgPt106.zip
size: 1.09MB
■更新履歴
2010-07-19 ver1.06
「マスクのコピー」機能を追加
「マスクをファイルに出力」で横幅が4の倍数でないときに正常に保存できないのを修正
「使用色カウント」が範囲外を選択中でも使用可能なのを修正
コピーデータビューアでホイール押し込みでも画像の表示移動が可能なように修正
起動→「開く」の場合は更新マークが付いてしまうのを修正
更新マークがついてないときに「開く」を行っても、更新マークが付かない
マスクのコピーを実装ついでに目に付いた部分を修正。
2010年7月16日金曜日
「いめーじぺたぺた」ver1.05c
「いめーじぺたぺた」ver1.05c
http://cid-8cd7cf5ea9fbca55.office.live.com/self.aspx/Public/program/imgPt105c.zip
size: 1.0MB
■更新履歴
2010-07-16
起動直後の「開く」のときは更新マークをつけないように修正
http://cid-8cd7cf5ea9fbca55.office.live.com/self.aspx/Public/program/imgPt105c.zip
size: 1.0MB
■更新履歴
2010-07-16
起動直後の「開く」のときは更新マークをつけないように修正
日記ちゃんCAVE新作情報 ヵ
赤い刀
http://www.cave.co.jp/gameonline/akaikatana/
まったく中身が想像できねえ! エロい!
今回の戦車の形状が気になるね。デススマⅡは戦車不在だった気がするし。
http://www.cave.co.jp/gameonline/akaikatana/
まったく中身が想像できねえ! エロい!
今回の戦車の形状が気になるね。デススマⅡは戦車不在だった気がするし。
2010年7月14日水曜日
「いめーじぺたぺた」ver 1.05b
「いめーじぺたぺた」ver 1.05b
http://cid-8cd7cf5ea9fbca55.office.live.com/self.aspx/Public/program/imgPt105b.zip
size: 1.00MB
■更新履歴
2010-07-14
「指定色を変更」の指定色の透過率を維持するよう修正
使ってて不便だったので修正。
http://cid-8cd7cf5ea9fbca55.office.live.com/self.aspx/Public/program/imgPt105b.zip
size: 1.00MB
■更新履歴
2010-07-14
「指定色を変更」の指定色の透過率を維持するよう修正
使ってて不便だったので修正。
日記ちゃん
2010年7月12日月曜日
2010年7月11日日曜日
日記ちゃん
雑魚敵は64x64だったが、
中型機は256x256はいるかもしれない。
128x128だとちょっと大きめの雑魚敵ぐらいの印象にしかならなかった。
ところでアイテムの発光エフェクトを手抜きして、半透明合成にする実験を行ってみた。
作り方はみてのとおりで、マスクの適用には手前味噌だが「いめーじぺたぺた」を使った。
発光エフェクトについては
生産がす: 物体と背景について
http://sumishiro.blogspot.com/2009/11/blog-post_13.html
や
生産がす: 壁の設置
http://sumishiro.blogspot.com/2008/09/blog-post_22.html
ですこし触れたが、手間の割りに見た目の印象がいいので重宝する。
このときには発光エフェクト→オブジェクトと2度レンダリングしたが、今回は1回のレンダリングで済ませているのでコストも低い。
2010年7月10日土曜日
「いめーじぺたぺた」v1.05
いめーじぺたぺた ver1.05
http://cid-8cd7cf5ea9fbca55.office.live.com/self.aspx/Public/program/imgPt105.zip
size: 1.0MB
■更新履歴
2010-07-10 ver1.05
ドロップ起動に対応
ファイルリストウィンドウのサイズを大きく
今回はバグ修正なし。
ファイルドロップ起動機能の追加だけ。
__argcと__argvでさくっと実装。
http://cid-8cd7cf5ea9fbca55.office.live.com/self.aspx/Public/program/imgPt105.zip
size: 1.0MB
■更新履歴
2010-07-10 ver1.05
ドロップ起動に対応
ファイルリストウィンドウのサイズを大きく
今回はバグ修正なし。
ファイルドロップ起動機能の追加だけ。
__argcと__argvでさくっと実装。
日記ちゃん
ハードの仕様でテクスチャ2048x2048まで可とあるから読んでみたら読まないでやんの。
ビデオメモリも10MBぐらいを実験段階で使っててすでに許容範囲を超えてる……。
初期のXPのころのノートPCはビデオメモリ4MBとかだけど、よくゲームが動いたなまじで。
ギルティゼクスの体験版なんかはキャラが写ったり写らなかったりしてたが、ぎりぎりだったんだろうなあ。
画像を使いまわすに当たり、敵と敵弾の表示サイズを2倍にしたら既存のに近い感じなった。
敵は雑魚が64x64。
敵弾は小さめなのが16x16といった具合。
画面が縦長だとバランスをとるのが凄い難しい。
画面上にいるときと下にいるときで難易度に差がで過ぎる。
背景を結構うるさくしないと画面スカスカになるし。
思い切って敵をもう一段階大きくしたほうがいいかもしれない。
爆発画像をでっち上げる。
メイン爆発サイズは128x128px
小さい爆発が64x64px
自機も64x64で、この解像度だとだいたいのオブジェクトは64x64が基準になるかと思う。
鉄粉は解像度4倍になったから8x8pxぐらいかなと適当に作ってみたらでっかくて笑った。
1pxの表示物は解像度がいくらか大ききなっても1pxのままのほうがいいみたい。
爆発なんかは大きいほうがいいんだけど、
128pxでも16コマ並べるだけで2048pxになって読み込み不能になるのである。死ね!
2列に並べるとかすればどうとでもなるが先が思いやられる。
特にボスなんかは大きい画像を使うことが多いから下手なアニメーションをすると詰む。
1コマに画像1枚つかうとかエロゲみたいなことすれば大丈夫かもしれない。
ハード的には何枚可能なのかよくわからんが。メモリがあれば何ぼでもいけるのかな?
解像度800x600だとメインの縦画面のサイズが450x600。
これは縦置きのディスプレイ比率3:4を基準にしている。
横の余った領域はそれぞれ175x600。
ビデオメモリも10MBぐらいを実験段階で使っててすでに許容範囲を超えてる……。
初期のXPのころのノートPCはビデオメモリ4MBとかだけど、よくゲームが動いたなまじで。
ギルティゼクスの体験版なんかはキャラが写ったり写らなかったりしてたが、ぎりぎりだったんだろうなあ。
画像を使いまわすに当たり、敵と敵弾の表示サイズを2倍にしたら既存のに近い感じなった。
敵は雑魚が64x64。
敵弾は小さめなのが16x16といった具合。
画面が縦長だとバランスをとるのが凄い難しい。
画面上にいるときと下にいるときで難易度に差がで過ぎる。
背景を結構うるさくしないと画面スカスカになるし。
思い切って敵をもう一段階大きくしたほうがいいかもしれない。
爆発画像をでっち上げる。
メイン爆発サイズは128x128px
小さい爆発が64x64px
自機も64x64で、この解像度だとだいたいのオブジェクトは64x64が基準になるかと思う。
鉄粉は解像度4倍になったから8x8pxぐらいかなと適当に作ってみたらでっかくて笑った。
1pxの表示物は解像度がいくらか大ききなっても1pxのままのほうがいいみたい。
爆発なんかは大きいほうがいいんだけど、
128pxでも16コマ並べるだけで2048pxになって読み込み不能になるのである。死ね!
2列に並べるとかすればどうとでもなるが先が思いやられる。
特にボスなんかは大きい画像を使うことが多いから下手なアニメーションをすると詰む。
1コマに画像1枚つかうとかエロゲみたいなことすれば大丈夫かもしれない。
ハード的には何枚可能なのかよくわからんが。メモリがあれば何ぼでもいけるのかな?
解像度800x600だとメインの縦画面のサイズが450x600。
これは縦置きのディスプレイ比率3:4を基準にしている。
横の余った領域はそれぞれ175x600。
2010年7月6日火曜日
日記ちゃん本末転倒
よくよく考えたら高解像度にするなら素直にDirectXに戻ったほうが問題が少ないと今気が付いた。
何で16色なんかでやってたんだっけとおもったら、
生産がす: 日記ちゃん
http://sumishiro.blogspot.com/2010/01/blog-post_23.html
もとはといえば、
GBサイズで作ろう!
どうせだから色も少な目がいいな!
ってのが発端だったんだ。
フルカラー高解像度にするんならGDIは捨ててもいいか。
ところがPDのときよりはプログラム技術が向上してるのか、
640x480でも昔よりぜんぜん高速にレンダリングできるという……。
いめーじぺたぺたを作るときに1から作り直したのが利いてて、
1ピクセルごとに半透明率を分けられるとかいろいろ特典も満載。
回転描画とか不必要だった実装は行ってないからゲームへの流用はやや不向きか。
背景3DをDirectXのカメラで行って数学的な不都合を少なくすべきか、
自前のカメラで処理を軽量にするかでやや悩む。
あああああ、DirectXだと座標が上下が逆になるの忘れてた。これは面倒だ!
何で16色なんかでやってたんだっけとおもったら、
生産がす: 日記ちゃん
http://sumishiro.blogspot.com/2010/01/blog-post_23.html
もとはといえば、
GBサイズで作ろう!
どうせだから色も少な目がいいな!
ってのが発端だったんだ。
フルカラー高解像度にするんならGDIは捨ててもいいか。
ところがPDのときよりはプログラム技術が向上してるのか、
640x480でも昔よりぜんぜん高速にレンダリングできるという……。
いめーじぺたぺたを作るときに1から作り直したのが利いてて、
1ピクセルごとに半透明率を分けられるとかいろいろ特典も満載。
回転描画とか不必要だった実装は行ってないからゲームへの流用はやや不向きか。
背景3DをDirectXのカメラで行って数学的な不都合を少なくすべきか、
自前のカメラで処理を軽量にするかでやや悩む。
あああああ、DirectXだと座標が上下が逆になるの忘れてた。これは面倒だ!
2010年7月5日月曜日
日記ちゃん
解像度を160x144から640x480に変更するときに、
ついでにゲームオブジェクトをスクリーン座標系からワールド座標に管理方法を変えた。
画像サイズはそのままだからスカスカ。
今まで、敵やエフェクトの座標が100なら画面上でも100ドット目にレンダリングしてたけど、
移植するときとか別作品に使いまわしたいときに、
解像度が違うと1から組みなおしだったので結構大変。
特に摩擦係数とか加速度なんか毎回変更してチェックしてと時間がかかってしょうがない。
ワールド座標で管理するとスクリーン座標に変換する部分を変更するだけで対応できるので、
動作周りなんかはコピペできて少し手を抜ける。
見てのとおり画像の表示サイズは変更されないので、結局手を入れないといけないのだけど。
考えてみれば、複数パーツもちの敵なんかだと、
画像的には32ドットずれた位置表示するには、ワールド座標上で256ほどずれてるとかいう面倒なことになるのな。
逆算すればなんとでもなるがそれはそれで気持ち悪いような。
それにしてもオブジェクトが小さい割りに画面が華やかなのは経験ゆえかたまたまか。
個人的に大きいは正義だと思うんだけど、メモリがそれをゆるさないという。
表示はフルカラーにして画像データは256色ぐらいで管理するのがほどほどのドット感が出つつも、
メモリを節約できていいんじゃないかと思わなくもない。懐古主義かもしれないが。
登録:
投稿 (Atom)