realloc＋Key＠シューティング

さて、前回に引き続いて関数の見直しをしています。

シナリオスクリプト＋敵動作スクリプトはもう少しです。
スクリプトの読み込みですが、学習的な意味も兼ねてread関数の読み込んだバイト数を取得して、その度にreallocしています。
reallocが再割り当てすると、違うポインタになる可能性があるんですね。今までは違うポインタになることはなかったですが、後で違った時コピーしてくるロジックも書いておこうかな。

・
・
・

ううむ、mallocでエラー？らしきダイアログが出ます。

ただ、継続してもウインドウが表示されませんが、（敵出現！とかの）ログを見ている正しく動いている様子。

ううむ、メモリの知識がない〜；；
→原因はreallocのポインタの参照先が被っていることでした。
シナリオと敵動作スクリプトでreallocで再割付を行っているのですが、再割付したときに、シナリオ用のreallocが敵動作用の領域にも踏み入ってました。
自分としては、reallocでポインタの参照先が変わってメモリを確保できることを期待していたのですが、違う結果となりました。
とりあえず、回避策として、メモリを最初に大きくとってしまうことで回避。

では、次へー
細々としたことですが、まだ実現できてなかった入力制御です。
入力制御できなくちゃデバッグがままならないですからね＾＾；

というわけで、調べてみるとSDLではイベントという扱い（構造体）だそうです。
SDL_KEYUP/DOWNが定数で宣言されていて、SDL_Event構造体をSDL_PollEvent関数へ渡してSDL_Event内の変数を取得することで入力されたキーがわかる。という仕組みです。
DxLibではキーが押されているかどうかだけを判定していたので、ロジックの変更が必要。

冒頭部分はこうなっています。

while( SDL_PollEvent( &input_event ) ){
        switch( input_event.type ){
            // キーが押されたら
            case SDL_KEYDOWN:
                
                // SDLKey値で分岐処理 
                switch( input_event.key.keysym.sym ){
                    case SDLK_a:
                        fighter.core.move.x = -(fighter.core.speed);
                        input_key_a_d = TRUE;
                        break;
                    case SDLK_d:
                        fighter.core.move.x = fighter.core.speed;
                        input_key_a_d = TRUE;
                        break;
                }

イベントとして取得しているので、関数内に持っていたキー状態を外に持ちます。
よし、ﾃﾞｷｰﾀ

次は本題。
ロックオン機能とホーミング弾（？）の実装です
まず、ロックオンのカーソルを表示します。ペイントでそれらしきものを作って。
イメージを取り込みます。

できました。画面上方の自機の上に「＋」的なカーソルがあります。
ちなみに、自機と一緒に動きます。

このカーソルに当たった敵を登録しておき、ホーミング弾発射（Jキー押下）すると登録された全ての敵にホーミング弾が飛ぶイメージです。