Giters

google / liquidfun

2D physics engine for games

Home Page:http://google.github.io/liquidfun

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

New release?

sab39 opened this issue · comments

commented

It looks like the last liquidfun release was in 2014 even though there have been a bunch of commits since then. Are there any plans to make a new release?

commented

@sab39 if only we had the time to cut one. We haven't rebased to the latest box2d for a long time either. If folks were interested in helping out we would be happy to guide them through the process. Though I'm sure there is a huge amount of work in cutting a new release now considering how things tend to rot when they're not touched for a while.

commented

I'm hypothetically interested in helping out, but I've learned the hard way that despite my best intentions I'm pretty bad at following through on things like this, so I don't want to waste your time or commit to something knowing there's a good chance I'll flake on it. What specifically would need to happen to make a release? Is there any low-hanging fruit that I could try my hand at for starters?

commented

@johnb003 was the last person to hack on LiquidFun, any suggestions John?

@sab39 it really depends upon how far you want to go down the rabbit hole. If you want to just cut a release from head then there are a few things to do here:

  • Manually test LiquidFun (unit tests and testbed) on all supported platforms
  • Cherry pick all changes from the master branch to develop (our pristine branch with no dependencies)
  • In the develop branch:
    • Update version number at the top of liquidfun/Readme.md
    • Update liquidfun/ReleaseNotes.md with changes since the last release.
    • Update version numbers in liquidfun/ReleaseNotes.md. This includes the currently released version
      referenced at the top of the document and the title of the latest release section.
    • Update version number in liquidfun/Box2D/Box2D/b2Settings.cpp
      LIQUIDFUN_VERSION_MAJOR
      LIQUIDFUN_VERSION_MINOR
      LIQUIDFUN_VERSION_REVISION
    • Rebuild the doxygen docs using generate_docs.sh
  • Merge develop branch into master
  • Build a new release zip file with projects for each platform (we used to to use build_distribution.sh not sure whether it still works)
  • Label the release (see tags]
  • Poke one of the maintainers to help publish the built artifacts (i.e us) and push the docs

If you want to go all out you could also:

  • Rebase to the latest Box2d which is going to be quite a pain since we have a git history that was converted from the old subversion repo. There will be a lot of conflicts to fix.
  • Update Testbed to work with the latest Box2d on all platforms (I think it moved from Freeglut to another abstraction layer which means it may need to be ported to Android and iOS)
commented

My git fu wasn't quite up to par when I tried to take this on last time.

Here's what I remember...

There was quite a bit of divergence between our branch and head, and some things that really made it challenging like some git settings that affect the recognition of newline differences, \r\n, vs \n which made the entire branch line we are based on and head completely "different". And there's some weird git properties there I'd never messed with that would invalidate the cache when syncing over it, and made a gigantic mess.

It all got really complicated because the code moved from google-code svn to github or something along those lines, and so effectively the entire history was re-written and none of our commits are based on current branch line.

I attempted to write some scripts to rebase things as they were technically the same changes on both branch lines, which sort of worked, but it was a bit manual. This also got tricky with merges, so I had to apply feature branches as squashed commits.

Stewart always suggested we just attempt the massive merge from the new baseline and just merge the entire tree we have. However due to the newline thing and other weird stuff like moved content, it really is a pain to do that merge.

I did all that work, but I think we basically shelved it for other priorities.

I'll spend some time today to dig up whatever I still have, and share it.

commented

Would it be an option to just give up on merging entirely, call the old release branch obsolete, and make a brand new release branch based on the development head?

commented

Possible though it would still need a merge of the patches we applied on top of box2d to produce LiquidFun. There is a load of work in porting TestBed, getting tests working again, JS bindings etc.

commented
commented

JFYI, I have a derivative of Box2D that's called PlayRho which I intend to merge LiquidFun in with. PlayRho is also open to contributions while Box2D isn't.

commented
commented

From https://github.com/erincatto/Box2D:

Please do not submit pull requests with new features.

Also from erincatto's Apr 29, 2016 comment in "Box2D is dead":

I do not accept pull requests because Box2D is not open contribution.

I've seen him taking doc changes or CMake changes; I've also seen him reject PRs for changes to the library code however. He explains his reasoning in the above linked thread. I can see his point and understand why he's chosen this. OTOH, later he states:

I'm totally fine with forking. I'm fine with giving other people control of their version of Box2D. I just don't want people to be able to take control of my version of Box2D.

commented
commented

wouldn't it be interesting to simplify the problem liquid simulation in browser? Web assembly comes to mind but I am by no means expert on low level code. If some here can help with the C/web assembly part, I could help with the javascript/interface part. Squoosh is a example of such a project where C and javascript do image codecs. The C code is minimal and you can control it with javascript. See https://github.com/GoogleChromeLabs/squoosh it's open source

commented

@stewartmiles @johnb003 et al - any interest in giving this another push?

Box2D (and various clones, forks, rewrites etc) has taken on a new role in an ML/AI context - e.g. in Gym environments (https://gym.openai.com/envs/#box2d https://github.com/hardmaru/estool https://cloud.google.com/blog/products/ai-machine-learning/how-to-run-evolution-strategies-on-google-kubernetes-engine ...) or JS things like https://github.com/mishig25/neuroevolution-robots and https://github.com/adityathebe/evolutionSimulator ... Having a particle system in the mix might make for some more interesting ML environments?

commented

@danbri TBH I really don't have time to rebase this project on the latest Box2D. Happy to take a community contribution to rebase the project, it's quite a bit of work to do that though.

commented

@Birch-san - I've said this elsewhere, but that is awesome - thanks again!

It isn't clear to me where liquidfun could, should, or might go with things in 2021 - and to be clear I have no role in the project beyond wellwisher and dabbler - but we're all in a much more informed position thanks to your efforts exploring all this :)

@stewartmiles it feels like the burden of targeting so many platforms, and of keeping the version history, makes liquidfun potentially rather more static than the name suggests. Any thoughts on the options here?

commented

@danbri if ditching the version history is a blocker for merging an update then archiving the existing history in another branch seems reasonable to me.

However, since this is a library targeting game developers, supporting platforms that game developers value (i.e where they make their living), which consists of major desktop (console because you know they're not that different anymore) and mobile platforms is really a requirement to keep this interesting to the game dev community.