pyxissociety / sandal2 Goto Github PK

Change from Makefile to CMakeLists and update readme to integrate cmakelists

Old version:

int setImageTextureElement(Element *e,SDL_Texture * image);

Wanted version:

int setImageSurfaceElement(Element *e,SDL_Surface * image);

Analyze SDL2 joystick support to see how to add it

Fuse SANDAL2_documentation repo and put SANDAL2 doxygen documentation in docs folder (github architecture)

The current Make process does not take into consideration the prerequisites such as:

• SDL2
• Doxygen
• Coverage tools
  ...

A CMakeLists would improve the way to find the requirements, to define easier more steps and to split among several targets the UT, E2E tests, Coverages...

Moreover, that will be a nice advance for the Continuous Integration.

From examples/setPlan/main.c

 /* initializing blocks */
    //for(i = 0; i < 4; ++i)
    createBlock(20 + 0 * 60, 200, 50, 50, colors[0], 0, 1);
    
    e = createBlock(20, 150, 60 * 4, 60, colors[4], 0, 0);
    if(!e){
	run = 0;
    }else{
	setKeyPressedElement(e, keyElement);
    }

    setPlanElement(e, 0, 2);

The red element should be over the white but it is not.

Also :

 /* initializing blocks */
    for(i = 0; i < 4; ++i)
      createBlock(20 + i * 60, 200, 50, 50, colors[i], 0, i);
    
    e = createBlock(20, 150, 60 * i, 60, colors[i], 0, 0);
    if(!e){
	run = 0;
    }else{
	setKeyPressedElement(e, keyElement);
    }

    setPlanElement(e, 0, 5);

works fine when calling setPlan with a plan < 3 but if the plan is > 3 it does not work #anylonger.

When calling setPlanElement to change the plan of the element, the element disapear.

a = createBlock(0,0,50,50,white,0,0);
setPlanElement(a,0,4);

Adding Continuous integration to prevent regressions

Add ids to element and allow retrieving them using their ids

Use SDL2 to add sound utilities

• Bind sound to animations (continuously and on occurrence)
• Bind sound to a window (which can optionally be blocked if window not focused)
• Add sound on event occurrence (on element AND on window)

It should be interesting to add some prebuild actions to speed up the manipulation of elements.

Change the action prototype

Actually, the action attribute of EventElement has the following prototype:

void (*action)(struct Element*);

I think it should be important to include a second parameter dt corresponding to the ellapsed time since the last call of this function:

int (*action)(struct Element*, float);

The return type int indicates the action is finished when the function return TRUE.

The action library

In some game engines, there are functions (or class) which allows to handle the element characteristics like position, scale, rotation, ... in a short instruction. I add links here to the cocos2d-x action documentation and th libGDX action documentation.

Here is an example. If I want to move my element by 200 pixels to the right during 1 seconds then scale it by 2 during .5 seconds and make a 360° rotation during .5 seconds, I should write something like:

setActionElement(actionSequence(
    actionMoveBy(100, 0, 1), /* (x, y, time) */
    actionScaleBy(1, .5),  /* (scaleXY, time) */
    actionRotateBy(360, .5), /* (angle, time) */
    NULL
));

The NULL parameter is only used to simplify parsing the variadic function actionSequence(...). Obviously, the syntax of this example can be improved but I think the idea is clear.

Here is a list of actions frequently used on other game engines:

To go further, it is also possible to define the interpolation method. For example, it allows to avoid the boring linear movement of an element and make a funky elastic appearance! I put here a plot of the interpolation functions used in cocos2d-x:

Since I pulled the new version of SANDAL2 there is a segfault when I changed from my game to another window (my shell for example)

Add tutorials on those subjects:

• Move the window origin
• Having more than one window
• scenary graph

create an equivalent of createBlock which creates a rotable block

Add unitary tests using LAssert

Add a blocking run function that contains the main loop and can be regulated to set a number of frame per seconds to be displayed
Add an "auto regulated" version of this function so that if one iteration (update / display) is longer than the time needed for the number of frames per seconds, the restriction for the next run will be less time.

Not using the rotation point of SDL2_RenderCopyEx

See #19 for details