中間報告2

FFXIのverUPが終わらないので更新。さすがに挨拶は無しで。

敵機に耐久度を導入しました。それと同時にまとめて処理していた爆発のエフェクトの処理を個別に変更。相変わらず敵3(赤十字)には当たり判定がないのですが、これはちょっと考えてあることがあるので後日改めて紹介になるかと・・・。おそらく相当ウザイ敵になること間違いなしですが(笑

それが導入できたらボム(画面全体当たり判定＆全敵弾消滅）導入しますかね。これでシステム側は完成かな？

武器の強化をどういうタイプにするのか(アイテム取得形式やクリア時にスコアを消費して購入など）とか1コマ毎にグラフィックを変更するのかとか決めないといけないことがあるので、確実に作っておく必要があるシステムはここまでかと。

連休中に1面ぐらいは完成させたいですね。そのためにはデザイン依頼してる人がしっかりやってくれる必要があるわけなんですが…。

しまった・・・

前回の記事投稿した時と実際に表示されるもののレイアウトがかなり違っていて表示が壊れてます。こんばんは。

前回投稿した時はアクセス集中(？)で確認できなかったので、まぁいっかと思って放置してたら…予想以上におかしなことに・・・orz

次回からはちゃんと確認しないとだめですね…どの道アメブロ側が表示してくれないときは確認しようがないわけですが・・・。

('∇')

 描写見直し終了ーーー！
こんばんは。

2日がかりで見直して、新しいサブマシンでも処理落ちなく動くようになりました。これで大学でも開発可能になｒ

というわけで(?)、このSTGの最低スペックはSHARPのPC-MM70Gとしてこの先進めて行きたいと思います。PC-MM70Gはかなり新しい機種ですが、モバイルタイプのためスペック自体はかなり低めなのでコレで動けば大概動くだろうと･･･思っちゃダメですかね？

左はこのゲームを作り始めた初日のSSで、右はつい最近のSSです。

自分で言うのもなんですが、進歩したなぁ…とｗ

最初の頃はどうやって出現処理させるかずーと悩んでいた気がします。

最後に、今回の修正で以前ソース公開した得点処理が大幅に変わっています。以前書いた物は負荷が非常に高いのでお勧めできません。

(´Д⊂

新しいPCを買ったので、ウキウキ気分でSTGを動かしてみました。こんばんは。



結果･･･



┗(；´Д｀)┛超おもてええぇぇぇぇeeeeeeeeeeeeeeeeeeeeeeeeeee…。



すみません、取り乱しました･･･。(;´ρ`) ｸﾞｯﾀﾘ


いや、決して遅いPCじゃないんですよ…現に推奨環境１G以上の3Dゲームがさくさく動いてるし･･･。
はい、私のゲームが重すぎなんですね･･･2Dなのに･･･orz
実はちょっと前のverから起動したらすぐ落ちるやら明らかに処理落ちしてるやらの報告が来てたんです。ただ、私の環境では十分動いてたので大丈夫だろうと思っていたんですが･･･。
以前のPCからの違いはVRAMが16MでCPUが1Gちょいのメモリ512MBで処理性能的にはちょっとランクが落ちる程度で、処理がそこまで負けてるとは思えない。つまり半減してるVRAMの問題である可能性が高いことから、グラフィックの描写に問題があるということなわけで･･･。

当分は開発は後回しにして描写の見直しになりそうです…orz

中間報告1

何日目かわからなくなってきたので題名の形式を変更。まぁここから先見える変更は当分無いので更新頻度は間違いなく落ちます。

更新しなくてもアクセス数が増える不思議。こんばんは。

とりあえず自機の残機を導入。当たったら引き算をしてまだ1以上残っていれば一定時間無敵になりその間はグラフィックを変えて、０以下になれば爆発処理＞ゲームオーバーという処理にしてあります。コレ応用すれば敵の耐久度設定もすぐ出来そうです。

また、重いと評判だった爆発処理を軽量化。おそらく負荷は半分程度になっているはず…。ただ、自機が以前の描写方法のままなので、こっちもどうにかしないとなぁ…。

寝る前に･･･

見た目は変わりませんが、内部的には結構に変わっています。こんばんは。

初期に導入した偽敵を本格的に書き換え新たに敵3として導入。動き方は壁にぶつかると跳ね返るというものを継承しています。以前のは出現処理を無効にしただけなのでデータ自体は残っています。敵３を完全に導入できたら消す予定ですが･･･。以前のは敵弾の発射位置に敵を描写して当たり判定を持たせたものだったため、自機の残機と敵の耐久度の導入するための前準備として行いました。実はそんな中途半端な設定のおかげで今まで当たり判定が設定できなかっｔ

そろそろシステムバランスの調整とゲームの方向性を考えないとな･･･

18日目

ソース公開初めてからアクセス数が凹んでいます。こんばんは。
誰も見たくないのね･･･。というわけで(?)、ソース公開はとりあえず終了します。


相変わらずシステム周りをいじってます。分割した小さいグラフィックを多く描くより、大きい1枚絵の方が負荷が少ないようなのでそれにあわせて全体的に調整。当たり判定をまとめてみようかとやってみたんですが…「これってフツーに書いても一緒じゃね？」程度にしかならないためやめました。素直に書くことにします。

そーろそろ本番の絵ほしいんだけど…どうするか･･･。

17日目

久々に昼間の書き込みです、こんにちは。

今日は多分これ以上作業しないので書き込み。

キャラのサイズを64×64から48×48に、敵弾のサイズを32×32に変更。それに伴って全体的に動き方の見直し。これでかなり負荷を軽減できたようです。このまま敵を追加せずにプレイヤー側のシステムを先に完成させますかね…敵を増やすとシステム変更するたびに見直さないといけないので手間が増えそう…。

さて、ソースの一部紹介。今回は得点処理の一部を抜粋。全部書くと100行じゃ終わらないので…f(^_^;

↓↓↓↓↓得点処理↓↓↓↓↓

       if (player.Point >=10) and (player.Point < 100) then
        begin
        pointtexture.free;
        pointtexturea.free;
        pointtextureb.free;
        pointtexture:=TDGTexture.Create(DG,DGFMT_ARGB);
        pointtexture.BorderColor:=$00000000;
        pointtexture.LoadFromFile('00.bmp');
        pointtexture.SetColorKey//黒（=#000000)
        (
            Rect(0,0,pointtexture.Width,pointtexture.Height),
            D3DCOLOR_ARGB(0,0,0,0)
        );

        if (Player.Point-((player.Point div 10)*10))=1 then
         begin
          pointtexturea:=TDGTexture.Create(DG,DGFMT_ARGB);
          pointtexturea.BorderColor:=$00000000;
          pointtexturea.LoadFromFile('1.bmp');
          pointtexturea.SetColorKey//黒（=#000000)
          (
            Rect(0,0,pointtexturea.Width,pointtexturea.Height),
            D3DCOLOR_ARGB(0,0,0,0)
          );
         end;

        if ((player.Point div 10)=1) then
         begin
          pointtextureb:=TDGTexture.Create(DG,DGFMT_ARGB);
          pointtextureb.BorderColor:=$00000000;
          pointtextureb.LoadFromFile('1.bmp');
          pointtextureb.SetColorKey//黒（=#000000)
          (
            Rect(0,0,pointtextureb.Width,pointtextureb.Height),
            D3DCOLOR_ARGB(0,0,0,0)
          );
         end;

         putsprite(PointTexture,round(586),round(240));
         putsprite(Pointtexturea,round(561),round(240));
         putsprite(Pointtextureb,round(536),round(240));

↑↑↑↑↑得点処理↑↑↑↑↑

敵を倒した時に入る得点をplayer.pointとして処理し、それをifで分岐させて描写するという方法を取っています。正直頭の悪い方法だとは思うのですが…下手にCase使うとそれはそれで問題があるのでこの方法を取っています。むしろ誰かいい方法知ってたら教えてほし

15日目

ベースシステムがやっと仕上げに入れそうです。こんばんは。

移動範囲が広すぎるとの指摘を受けて640×480のうち移動できる範囲を320×480に限定。また、描写タイミングをずらして敵機出現時の負荷を軽減。これで出現時の処理落ちはなくなった模様。まだ全体的に重いそうですが…。

今度はキャラサイズ見直しかな？　移動範囲のわりに大きめになってるし。そろそろ自機に残機処理追加しないとな…。

さて、予告通りソースの無料版Delphi6でSTGをつくるためのプログラミング講座のチュートリアルに追加した部分の一部紹介をしていこうと思います。今回は背景処理部分の紹介。Delphiの知識のある方だけお読みください。(笑

↓↓↓↓↓背景処理↓↓↓↓↓

//背景処理wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
          if BGY < 0 then begin
          BGY:=2.0;
          end;
          BGY:=BGY-0.005;

　　   Scene.PushSprite(
        Vector2D(0, 0),
        [
          SXVertexSP((ClientWidth div 4), 0, $FFFFFFFF, 0.0,BGY),
          SXVertexSP(bgcgtexture.TotalWidth+(ClientWidth div 4),0,   $FFFFFFFF, 1.0,BGY),
          SXVertexSP((ClientWidth div 4),bgcgtexture.TotalHeight*2, $FFFFFFFF, 0.0,BGY+2.0),
          SXVertexSP(bgcgtexture.TotalWidth+(ClientWidth div 4),bgcgtexture.TotalHeight*2, $FFFFFFFF, 1.0,BGY+2.0)
        ],
        bgcgTexture,
        sxbAlpha,
        true
      );

↑↑↑↑↑背景処理ここまで↑↑↑↑↑

某サイトに載っていたものを少し改造したものです。BGYはinteger、360×240で描いてある背景画像をbgcgtextureとして読み込んであります。これで背景を動かせるのですが、なぜか1枚ごとに隙間ができるためそこの処理を考えているところです。どうするかな…。

犯人は…

おまえだ！＠モニターの画面を指しながら

こんばんは。

とりあえず動いたのでそのままにしていた部分が重くなる原因でした…。

↓↓↓↓↓詳細↓↓↓↓↓

自分としてはTextureの呼び込んだbmpデータは再度ロードすれば書き換えられると思っていたんですが、一度開放してから呼び込まないとメモリを開放しないまま新たにメモリを占有し、グラフィックを書き換えるたびにどんどん消費メモリが増えていくという状況になっていた模様…足りない知識を行き詰まってから調べるということをやっていたため、とりあえず動作はする場所を完全に見逃していました。Destroyイベントにある唯一のメモリ開放で蓄積した無駄な消費メモリを開放していたようで、デバッグ終了にやたら時間かかることからやっと気づきました。

↑↑↑↑↑詳細↑↑↑↑↑

詳細は読みたい方のみごらんください。次あたりからこんな感じでチュートリアルに追加した部分を小出しにして行こうかと思います。少しは役立つ情報を提供しないとね♪

ゲームのシステムをコレだけいじっているとオブジェクト指向というのはdelphiではProcedureとFunctionのことなんだな…となんとなく感じ始めています。以前諦めた当たり判定のオブジェクト化にもう1回挑戦してみるかな…。