Bundle basic vector/math functions and whatnots in Gideros

Dafb

Hello,

I love Gideros. Until now, each time I have a problem, there is a solution. And the problems I had, I basically created them by lack of skill or lack of knowledge

I do not consider myself as a good programmer. I am a hobby programmer, meaning a bad one! However, I do have creative ideas, and I have reasonable art/photoshop skills. It means that with enough time and effort, I can achieve my game dev goals alone.

Since 20 years, I usually argue that math above middle school level is rather useless in daily life. Now that I am making a 2D game, I kinda regret this statement. I have to relearn everything the hard way. So I started and continue to do so. I figured out a lot of things. But time could have been more efficiently spent if most of the classic geometry needs would have been baked already in the Gideros distribution. When you have a job and a family, time is really precious.

Classic examples would be different kind of sprite motions, basic collision formula or some of the functions available here. And we can think about more...

Yes, I know: this is the proof there is already a lot of resources online. But I also think that delivering maybe an optimized version of these functions would give potentially Gideros a boost in productivity and popularity by attracting more beginners.

Gideros is a heaven for good programmers. It gives them a lot of control. But I think, it would cost not so much in elbow grease to make it better for less skilled ones. The classic problems, most of you have already faced them and solved them. And probably you did it in a better way that any newcomer could think about! Don't let them reinvent the wheel(especially an oval one)! Why not reunite these well-thought solutions in a plugin, set of plugins, or directly in the distribution?

hgy29

While I generally agree, could you be a bit more specific ? When it comes to using maths to solve a problem, you'll find most of the time that either your maths need to be dedicated to the particular problem you want to solve, and if it isn't then it is often easier to just type it than to look up in the documentation for an equivalent function to call.

SinisterSoft

@Dafb The example link you showed how to incrementally move a sprite to a destination. It's pretty simple stuff.

Like @hgy29 said, the maths at this type of simplicity are usually custom per game. For example: One of the routines showed having to get the square root to find the distance, this is an expensive operation. If you are doing something like seeing which object is nearest then you don't have to do this bit at all.

There are useful math functions - eg atan2, etc that help with the type of things you linked to. We also added some operators to Gideros so you don't need to use deg or rad, see: https://wiki.giderosmobile.com/index.php/Trigonometry_Conversion_Operators

SinisterSoft

Another thing specific to the routines you linked to is that a few of them repeat the same operation, squaring a variable - eg x*x and y*y. In my routines I see if that's done more than once and if so I make a new variable, eg local x2=x*x, or local xx=x*x - that way it need only be done once.

That said, if you would like to make a Lua plugin for these then I'm sure others may welcome it. If you look in the allplugins folder within the Gideros program files folder you will see an example of some Lua plugins. See the VirtualPad and Chroma plugins...

hgy29

But it is true that providing a few very common math helpers would be good, to bring both speed and simplicity. I am thinking about:
- length (a vector length)
- distance (distance between two points, in 2D or in 3D)
- normalize (divide a vector by its length)
- raycasting, that is intersection between a line and some basic shapes (circle, line, polys)

oleg

@Dafb I think you don't need plugins, You need code examples
You can create your own function library and then use it.

Many examples are posted on the forum:
http://forum.giderosmobile.com/categories/code-snippets

For collisions in the game, you better use the bump plugin
https://wiki.giderosmobile.com/index.php/Bump

On this page below you will find the examples of collisions you need


https://github.com/kikito/bump.lua
I wrote a bit about game physics in my blog, but I don't write in English
https://simartinfo.blogspot.com/p/blog-page_89.html

You can check the collision between 2 sprites without a plugin with the following function:

function collision(sprite1,sprite2) self =sprite1 -- self bottom < other sprite top if self:getY() + self:getHeight()/3 < sprite2:getY() then return false end -- self top > other sprite bottom if self:getY() > sprite2:getY() + sprite2:getHeight() then return false end -- self left > other sprite right if self:getX() > sprite2:getX() + sprite2:getWidth() then return false end -- self right < other sprite left if self:getX() + self:getWidth()/3 < sprite2:getX() then return false end return true end ------------------------------------- Візіваем функцію так ------------------------------------- if collision(sprite1,sprite2) then --действия при коллизии end

The forum removes some characters in the code, so you should fix it before use !!

Dafb

Exactly: speed and simplicity. And I would also add: popularity.

hgy29 said:

- length (a vector length)
- distance (distance between two points, in 2D or in 3D)
- normalize (divide a vector by its length)
- raycasting, that is intersection between a line and some basic shapes (circle, line, polys)

I love this list. Especially the raycasting part!

SinisterSoft said:

Like @hgy29 said, the maths at this type of simplicity are usually custom per game.

You are right. At the same time, this kind of operation is really common in many types of game. That would be a check in my book to have it bundled in some way.

I do not think I am the right person to establish a list, simply because my experience is limited: I did not even finish yet my 1st project!

Look: if I would not dig in the forum, I would never have written the distance formula this way:

d = ((x2-x1)(x2-x1) + (y2-y1)(y2-y1))^0.5

but I would have kept it like this instead:

d = math.sqrt((x2-x1)^2 + (y2-y1)^2)

And to find the closest sprite to a given one(which is another very common need), I think it would have taken an eternity for me to realize that the square root was not mandatory in this formula!

However, you guys have coding and game developing experience that I will never have. At the end of the day, you know way better than me what should be implemented and how to implement it. Here I am just sharing an experience that led to an idea.

Now it's up to you!

keszegh

"...that I will never have. " - don't be so sure.

hgy29

hgy29 said:

- length (a vector length)
- distance (distance between two points, in 2D or in 3D)
- normalize (divide a vector by its length)
- raycasting, that is intersection between a line and some basic shapes (circle, line, polys)

Thinking of it, it would be nice to have two more functions:
- inside (check if a point is inside, outside or on the dge of a shape)
- edge (get the nearest point on the edge of a shape)

SinisterSoft

The 'distance' function could have an option to leave out the square root - to make it slightly faster when you only need to see if one is further away than another.

SinisterSoft

Also - if this is offloading to a C function then maybe it would somehow take a table of values that has multiple tables of 3 values (a pointer, x and y). The table find the distances and sort them in order, returning a new table with a distance set.

sortedByDistanceTable=SortDistance(x,y,{{obj1.sprite,obj1.x,obj1.y},{obj2.sprite,obj2.x,obj2.y}},realDistanceFlag)

sortedByDistanceTable would then be a table that had the obj.sprite pointers and the distance for each subtable, sorted. The realDistanceFlag is used to decide if they need to be square rooted or not.

A nearest(x,y,{{obj1.sprite,obj1.x,obj1.y},{obj2.sprite,obj2.x,obj2.y}}) function could return just the nearest object - no need for a sort - just compare to current nearest.

hgy29

Now that all platforms have FPU, I don't think it is worth skipping the sqrt() call. It is useful in lua because lua is interpreted, but it shouldn't make a notable difference in C

hgy29

Quick performance test:

local X1,Y1,X2,Y2=1,2,3,4 local function dist_lua1(a) return ((X1-X2)*(X1-X2)+(Y1-Y2)*(Y1-Y2))^0.5 end local function dist_lua(X1,Y1,X2,Y2) return ((X1-X2)*(X1-X2)+(Y1-Y2)*(Y1-Y2))^0.5 end local function dist_lua2(a) return dist_lua(X1,Y1,X2,Y2) end local gdistance=math.distance local function dist_g1(a) return gdistance(X1,X2,Y1,Y2) end   local function measure(f) local tos=os:timer() for i=1,10000000 do f() end print(os:timer()-tos) end measure(dist_lua1) measure(dist_lua2) measure(dist_g1) print("done")

Results:

1.1219358 1.2146656 1.0871566999999 done

Native version (latest test) wins, which is a bit of a surprise for me given the amount of wrapper code.

hgy29

I am also adding cross and dot products, since they are useful in geometry

hgy29

Upcoming API: https://wiki.giderosmobile.com/index.php/Math

keszegh

@hgy29 , pretty cool.

Dafb

Amazing!