devlog

- 05/10 15:33:
    Cloned repo. Quantum vault still proves to be really useful when starting projects. Granted, this is very simple and doesn't require many dependicies.
    Something cool to build would be an auto update makefile.

    Thinking about the init and game loop process, I quite liked the one I had previously. I'm also thinking about conventions to use , there too I quite like what I had before
    but I think it could be improved in some ways : 
        ------ Naming and vars -------
        - Functions, files, struct names to be prefixed with SDLX_, unless internal in which case to be prefixed with _SDLX_internal
        - Functions must follow the following scheme : SDLX_TargetObject_FunctionPurpose (to follow SDL's convention)
        - Variables must follow the following scheme : snake_case 
            -prefixed : 
                internal:   _intern_, 
                safe/sanitized: s_ 
                user input: usr_
                relevant to rendering system : rdr_

        - Use uint types or SDL_int if there is sucha  thing (very minor, but as in length is implementation defined, still useful)
        - Functions shall return a proper error code, and it shall be linked to an enum contianing all error codes
        - SDLX shall NOT allocate any data (or allocate as little as it possibly can)
        - SDLX shall not hide any varibales or structs or do so as little as it possibly can

- 05/10 16:39
    After a lot of thinking and wrting up the above, it is time to start coding;

- 05/10 19:39
    I just had a good thought about animation and how it may be diffrerent/better than the previous system. 
    Previously, animations revolved around 3 components : Animator, Animation and Sprite where :
        - An animator, which would take care of keeping track of the current frames and array of animations and update the sprite's texture, dst and src accordingly
        - An array of Animation which would each contain a texture and an array of SDL_rect srcs
        - Sprite which is the struct modified by Animator
    Since one of my goals is to move away from OOP and have a more Data oriented approach, I though maybe keeping all the animations in the animator is a waste of ressources since only 1 of those will be used. It would be much better to keep all the animations in a separate array and ONLY access it if we need to change the animation. Animator would then only have a pointer to the current Animation instead of the whole array, and maybe also a pointer to the Animations struct which holds all the relevant Animations.

    Of coursethe problem with that is that eitehr the user has to manually do the swicth or we need an SDLX_Anim_Switch function whose sole purpose is to take in a new state and update the current anim pointer and reset the frame count. I think it would be an improvment though.
    In the previous system,there was also an internal animator handler which would keep track of all created animators and update them all at once. Since it had to keep track of them SDLX had to allocate some memory for it and occasionally grow it as more animators are added. I think I will get rid of this and provide a single Animator_Update function, that the user may or may not call on their Animators. I may or may not also add an Animator_UpadateBulk. Though I don't really see a use case for it at the moment. Overall I also think this would be a good change, as it lets the user store things the way they want, for the cost of a little more overhead.
    . In any case, animation is for a later project.

    ---- Rendering -----

    This article makes a good case for using 3d engines to render 2D sprites http://ithare.com/game-graphics-101-rendering-2d-on-gpu-shaders/

    However I am not there yet, and I will still be using render queues. The question is... One render queue? Or multiple? 
    - One renderQueue : Minimal memory allocation, but needs to either sort at the end or insert in order
    - Multiple queues : More alloactions, but no sorting required
    As ever, it is the speed vs memory tradeoff...
    On furhter thought, multiple render queues seem to achieve both... A Sprite may have a primary and a secondayr layer. The primary layer would be to assign it to the correct renderQueue, the secondary, to sort within the queue. It is somewhat of a middle point, with the user being able to create new renderQueues and let them sort or not sort

- 05/11 01:37

    A config file would be useful. Some things like default render queue amount are not easily changeable, or at least are in the source code and need a recompile... 
    So far I'm thinking of having :
    - Window name
    - Window width / height,
    - Window x / y (only problem isit would take more work to use SDL's macros)
    - Default renderqueue amount

- 05/12 17:45
    I'm getting a 'corrupted size vs. prev_size' error... I've never had it before and quite frankly I'm not sure what's causing it. It have it tracked down to the SDL_Exit() function.... But it must be something that is messing with memory somewhere... though I'm not sure why at alll since sdlx is very small so far and doesn't do much at all. Seems to break even when not using SDLX...

    Okay, found the problem.... I lied, it's 100% because of SDLX.. 
    I was iterating over DEFAULT_QUEUE_SIZE of queues when the size was set to 
    DEFAULT_QUEUE_AMOUNT. I thought those names were descriptive but it turns out they are interchangeable and therefore confusing

-05/12 11:27

    I've decide not to dwell into the resizeable window issue at the momement.. It is too many things to focus on, as resizing the window also implies resizing the textures and changing where they appear.... It is something that needs to be thought about further before being implemented. 
    I think the important part is to somehow preserve the aspect ratio,but do the resizing relative to the smallest of width or height.

    For text,I'm thinking of letting the user set a font, or else use a default font.

- 05/13 12:51

    The key to upadting and rendering properly seems to be to update independently of rendering. Meaning one update won't necessarily equal one render.
    I'm going to set a "n updates per ms" macro, and use the FPS one as a n of frames rendered per sec

- 05?15 3:01 

    After further analysize of Wanted's gameplay, I have come to revise the movement algorithm I originally wanted to makefile
    There seem to be 2 kind of original position :
        - Pattern
        - Random
    And 3 kinds of movement :
        - Random
        - Pattern
        - Static
    Where any of the original position may be paired with any of the movements.
    Here they are in further details : 
       - Position -
            - Pattern : Images of a kind are arranged together to form a shape or formation
            - Random : Random placement
        - Movement -
            - Random : All images independent of kind move in a random position and bounce off the screen
            - Pattern : All images of a kind move the same way and teleport to other side of screen
            - Static : No movement

    This is not "Hard to code" per se, rather, it is harder to code in an organized fashion
    The combination : Static + patterm should only appear in the earlier levels;

    One of the challenges is finding a way to divide the sprites into organice chunks( not of the same size)
    If one defines min amount in parttern and max getting organic divisons could be as simple as doing a call to rand %(max - min) + min
    This should give a number at least min but not max
    Should have a max of 4 patterns. if by 3 iteration of the above there is still someremaining sprites, make a 4th patern out of it
    Of course the trouble is to not get two overlapping patterns. Solution : Either set it randomly or set next value


- 05/16 9:28

    I was going to do the above , at least the part for creating organic divisions, when I stumbled across a problem
    I need keep track of all entities in an array in order to do collisions. Of course, I can just iterate through the formations's enitity 
    array and do it that way, but it is less efficient, I think?

    The other way would be  to call rand() for each entitiy and assign it to that formation. It works but it is less elegant in my opinion and has the
    side effect of potentially overfilling the formation array(in which case I should probably re roll and add to another formation)
    Though thinking about it, there is also a certain elegance to it and an added sense of randomness. From time to time there would just be a few sprite that are just
    not part of anything, and it might actually be nice. It is a feature I guess. It is also the simpler code to write, so maybe I will go with that