LÖVE

Thanks for all the help, by the way, I'm just busy lately with college, but I fully intend to re-write my code from scratch to incorporate everything I need when I've got some spare time. I'm confident I'll now have all the tools I need if I decide to continue with the softbody game.

Connorses wrote:Thanks for all the help, by the way, I'm just busy lately with college, but I fully intend to re-write my code from scratch to incorporate everything I need when I've got some spare time. I'm confident I'll now have all the tools I need if I decide to continue with the softbody game.

Awesome! If you make anything using it let me know, I'd love to see it

Love you lib, now we can do games like microtrip
But I'd like to ask some changes if you don't mind.

1. Instead of having the global "Softbody" maybe you could local that variable in init.lua and in the then return it, like this:
init.lua main.lua or 2. We have to update every softbody we create individually, it'd be great if we could create a softbody world which then we would use to create bodies and then we'd just need to update the world instead of every body:
main.lua What do you think ?

Ranguna259 wrote: -snip-

Microtrip looks incredibly cute and fun , too bad im not too big a fan of mobile games

If you want to have the changes made then perhaps pull request the project on github - I would do so myself seeing as i might want the softbody world aswell for future ideas (ive never need for it yet as my on hold project only had one softbody to deal with at a time)

Ranguna259 wrote:Love you lib, now we can do games like microtrip
But I'd like to ask some changes if you don't mind.

1. Instead of having the global "Softbody" maybe you could local that variable in init.lua and in the then return it, like this:
init.lua

Code: Select all

--Softbody lib by Shorefire/Steven
--tesselate function by Amadiro/Jonathan Ringstad
local path = ...;
require(path.."/class");
local Softbody = newclass("Softbody");

...

function tessellate(vertices, new_vertices)

  ...

  for i = 1,#new_vertices,4 do
    if i == 1 then
      -- x coordinate
      new_vertices[1] = MIX_FACTOR*(new_vertices[#new_vertices - 1] + new_vertices[3])/2 + (1 - MIX_FACTOR)*new_vertices[1]
      -- y coordinate
      new_vertices[2] = MIX_FACTOR*(new_vertices[#new_vertices - 0] + new_vertices[4])/2 + (1 - MIX_FACTOR)*new_vertices[2]
    else
      -- x coordinate
      new_vertices[i] = MIX_FACTOR*(new_vertices[i - 2] + new_vertices[i + 2])/2 + (1 - MIX_FACTOR)*new_vertices[i]
      -- y coordinate
      new_vertices[i + 1] = MIX_FACTOR*(new_vertices[i - 1] + new_vertices[i + 3])/2 + (1 - MIX_FACTOR)*new_vertices[i + 1]
    end
  end
end

return Softbody

main.lua

Code: Select all

softbody = require('loveballs')

or

Code: Select all

randomvariablename = require('loveballs')

2. We have to update every softbody we create individually, it'd be great if we could create a softbody world which then we would use to create bodies and then we'd just need to update the world instead of every body:
main.lua

Code: Select all

softbody = require('loveballs')
function love.load()
  physWorld = love.physics.newWorld(0,9.81,true)
  softWorld = softbody:newWorld(physWorld)
  soft1 = softWorld:newBody(world, 400, -200, 100, 2, 4)
  soft2 = softWorld:newBody(world, 400, 0, 35, 2, 4)
end

function love.update()
  softWorld:update()
end

function love.draw()
  soft1:draw()
  soft2:draw("line")
end

What do you think ?

As for the first point, I'll probably do that at somepoint when I get a chance.

But the second point, personally I dislike this as I find it better to keep each softbody individual, as each one is its own object you may want to update them at different times, or store them in your own tables and iterate over those tables to draw/update them as you please. It's just generally better coding imo.

Besides, the updating isnt to actually update the physics object, thats all handled in Box2D's world update, the softbody update is for updaing the tesselation for drawing, which realistically you should only ever call when drawing it, so its good to keep these things seperate and let the programmer call them when they need them :p

But I'll 100% implement that first idea at some point, when I get the chance. I really need to go over all the code at somepoint and clean it all up, add a few useful functions and make it more modular.

Small update released, fixed a few bugs and things.

See first post for changes.

Update released, see first post for details.

Where has this gone ?

Ulydev wrote:Where has this gone ?

It's back up now.

Neat ! Thank you

That'd be very much appreciated if you put the source for the example shown here, with dragging features : https://www.youtube.com/watch?t=13&v=LFBQypY7E3E