Questions regarding development style

[kd7tck]

Questions regarding development style

[raysan5]

I usually recommend setting a framerate (SetTargetFPS()) and using a framesCounter for animations but I understand that people can prefer time-based animations; a function is already available for that (it returns deltaTime). Not sure if that's enough for your needs...

float GetFrameTime(void); 

Right now, animation should be controlled by user, there is no specific mechanism in raylib. I understand you propose some mechanism similar to javascript:

window.setInterval(function, milliseconds);
window.setTimeout(function, milliseconds);

I need to think how to manage that internally...

[raysan5]

Hi @kd7tck, that's a great idea.

Actually, that was my intention (kind of) with the introduced issues; related functions are listed in the issue description.

Maybe I could add more fine-grained detail to the description for better understanding and function implementation...

[kd7tck]

The GetTime() function, I would like to have it global so I can animate things in game with it. Could we make that function global and not static?
Perhaps there are better ways to animate, like creating hooked functions that can be called at certain time intervals from the raylib side. Something like: HookedCall(Function&, double interval);

[kd7tck]

I am assuming that the fixed interval animation type works because there is frame synchronization on the BeginDrawing or EndDrawing Call. Unfortunately I prefer frame rates that go as fast as possible and are not bound to any fixed value.

The following is code I am trying to optimize:

//returns true once complete
bool DrawAnimatedLine(Vector2 origin, Vector2 destination, double percentPerSec, Color color, double *percentComplete)
{
    if(*percentComplete >= 1.0){//what to do when already done
        DrawLineV(origin,destination,color);
        return true;
    }

    Vector3 a3 = {origin.x, origin.y, 0};
    Vector3 b3 = {destination.x, destination.y, 0};
    Vector3 c3 = VectorLerp(a3,b3,(float)*percentComplete);
    Vector2 c2 = {c3.x, c3.y};
    DrawLineV(origin,c2,color);

    //update then return
    *percentComplete += GetFrameTime() * percentPerSec;
    return false;
}

Any feedback or recommendations?

[kd7tck]

Another thing that I do not understand;
Why raymath is part of the lib, and not just a plain header file. You could have the math function definitions set to auto inline themselves. This would greatly increase game speeds.

I would be willing to volunteer my time to do this for you if you wished.

[raysan5]

Hi @kd7tck

About animation management, your method is ok but I personally prefer to separate update logic from drawing. I would use an update function like:

Vector2 UpdateAnimLine(Vector2 initValue, Vector2 finalValue, int framesDuration, int framesCounter);

The return value is directly the current value. Some extra parameters could also be added as int framesDelay or int easingFunc. Actually, I got a single header file easings.h with multiple easing functions (based on Robert Penner's Easings). Don't know why I didn't uploaded it... I try to upload it tonight at home.

About raymath becoming a plain header file, it's a good idea, I just designed the other way to follow the standard C programming way. Inline functions where introduced in C99, so that's ok for raylib.

[kd7tck]

I just realized that the update rate is tied to the draw rate. So even if I get faster frame rates, it would simply speed up the animations. Is the version of GLFW you use threadable?

[raysan5]

About GLFW3 threads: http://www.glfw.org/docs/latest/intro.html#thread_safety

[kd7tck]

I have a sample diff, (linked bellow) of the changes for the single raymath header file. Look it over and tell me if this is the direction it should go in.

https://drive.google.com/file/d/0B2jDwEP2AbatUUZ2TEVJeUtkU3c/view

[raysan5]

Thanks very much for the effort @kd7tck! :)

I've been checking the diff and it's not exactly what I'm looking for; I want to avoid any additional #include in raylib.h. I always try to decouple modules as much as possible.

My idea for raymath.h was something similar to stb_image.h and just #include "raymath.h" in required modules (core, rlgl). Library itself should also be available to be used in standalone mode.

The problem here are the types definition, they must be in raylib.h but are also required in raymath.h; this should be managed using some #defines.

[kd7tck]

You mean like this

https://drive.google.com/file/d/0B2jDwEP2AbatUUZ2TEVJeUtkU3c/view?usp=sharing

[raysan5]

Hi @kd7tck,

Despite being a bit difficult to see clearly all the changes in the .diff file, it seems you are in the right track, I like the solution.

Right now I'm investigating about the use of inline functions, not sure if that's the better option for all the functions, taking into consideration that some of them are quite big...

Here there are some references:

http://www.drdobbs.com/the-new-c-inline-functions/184401540
http://stackoverflow.com/questions/1932311/when-to-use-inline-function-and-when-not-to-use-it

[kd7tck]

The only downsides are when using 32 bit. 64 bit does not have page faults nearly as often, like 32 bit does. There should only be a performance boost, if you restrict the inlining to functions that are used every draw cycle. For me, math is one that always comes to mind.

[kd7tck]

Here is a more clear example not in diff.

https://drive.google.com/folderview?id=0B2jDwEP2AbatVDdrTTFRVG1GMVE&usp=sharing

[raysan5]

Hi @kd7tck ,

Instead of defining for every function:

#ifdef RAYMATH_INLINE
static inline 
#else
static 
#endif

you can just define at the beginning:

#ifdef RAYMATH_INLINE
#define RMDEF static inline
#else
#define RMDEF static
#endif

and prepend functions with:

RMDEF Vector3 VectorAdd(Vector3 v1, Vector3 v2)

I really like stb_image.h single header style. I would follow that style defining:

#define RAYMATH_IMPLEMENTATION        // RAYMATH_DEFINE
#define RAYMATH_STANDALONE            // !RAYLIB_MATH_STRUCTS

Actually, maybe RAYMATH_IMPLEMENTATION could be skipped and just use RAYMATH_STANDALONE to include or not raymath structs (or use raylib structs instead).

Again, thank you very much for your time and effort and excuse me if I'm a bit picky... I really care about readable code and simplicity.

[kd7tck]

Not a problem. I went ahead and updated the code, look over my changes to the defines.

[raysan5]

Hi @kd7tck !

I'm working on raylib v1.4 and I would like to include the raymath.h header-only file.

Please, could you make a pull-request with your current implementation? I will review it.

Thanks! :D

[raysan5]

Changes merged and reviewed! 👍