4.0.6 "Inexorable Advance"

This release doesn't include a ton of new changes to SquidSquad, but it does include a lot of improvements to dependencies, many of which have been updated. A notable change here is that Coord-based Maps and Sets in squidgrid now will increase capacity when needed based on the size of the Coord pool. This is meant to reduce the likelihood of multiple resizes being required, and ensures that enough of each Coord's hashCode is used to differentiate even huge amounts of Coords without collisions (8192x8192 is the likely limit). Since the last release on GitHub (4.0.0), there have been more changes, such as Region getting new overloads for many methods that can reuse a buffer Region rather than allocating a temporary one. Nullity annotations have been removed from the repo (and jdkgdxds); they created more work than they saved. I was already using null-safe approaches in jdkgdxds anyway, because the annotations aren't exactly reliable.

I'm only including some of the most common JARs here. This includes squidcore, squidgrid, squidpath, and squidplace. You can download any that aren't here from Maven Central (see the README.md for a link), or better yet, use Gradle to depend on SquidSquad. That last suggestion would take care of the dependencies too; there are a lot of them.

4.0.0 "Aye-Aye, Captain!"

This is the first stable release of SquidSquad, only about 5 years into the development. Better late than never, I suppose! All dependencies are on stable versions: digital 0.9.2, juniper 0.8.2, jdkgdxds 1.12.1, TextraTypist 2.1.3, and so on. I haven't needed to make drastic changes in a while to SquidSquad, so releasing this stable version seemed like a natural choice! Relative to SquidLib, everything is different! Relative to earlier SquidSquad beta releases, not so much is different! I didn't fit squidseek changes into this release, and those may come in a future update to the 4.x.x line, but the big feature here is that everything pretty much works reliably. There's quite a lot of updates to those dependencies mentioned earlier between the last release and this one, and there are breaking changes for those. Updating the demos might be an adventure, but it shouldn't take long after this.

A limited set of the JARs published by this release are present in this release, but I Strongly Encourage You To Use Gradle (or Maven) instead to get the correct JARs from Maven Central.

Gdx-Liftoff should be updated soon to be able to download SquidSquad dependencies with simple checkboxes, in addition to any other dependencies you might want.

Enjoy!

4.0.0-beta2 "Feel My Wrath"

This is the second beta release of SquidSquad, coming after 3 alpha releases and one other beta release. This is a lighter release when it comes to SquidSquad itself, but many dependencies were updated, some with noticeable improvements. The main improvement here is the addition of the squidwrath modules, which allow types here to be serialized and deserialized with the Apache project's Fury library. This coincides with updates to dependencies that allow them to be easily serialized/deserialized with Fury, by way of the Externalizable interface. Externalizable doesn't require a dependency on Fury, so code that doesn't use Fury won't be affected at all. Other updates improve collection performance on GWT (in jdkgdxds), add enum-based Maps and Sets that are compatible with libGDX Json (also in jdkgdxds), and quite a lot of work improving the set of gradient vectors used by various noise algorithms. There's some new things, like CellularNoise as an INoise type, and some fixed bugs in various places. In general, this is an incremental improvement.

Unlike SquidLib, which this effectively acts as successor to, SquidSquad is split up vigorously into semi-independent modules, some of which have their own dependencies or depend on other modules. Using Gradle Is Very Strongly Encouraged; gdx-liftoff offers SquidSquad as a third-party extension, and the next version will have the updated artifact IDs so you can automatically set up a project using a GUI. Maven also works, among other tools such as Leiningen and sbt. Instructions on how to add a module to your project for each of those tools are provided on the Maven Central pages for each of the dependencies there currently on version 4.0.0-beta2 .

Docs are currently sparse, and mostly in the form of code JavaDocs. You can browse the JavaDocs by module:

• squidcore
• squidgrid
• squidplace
• squidpath
• squidglyph
• squidsmooth
• squidworld
• squidtext
• squidold
• squidpress
• squidfreezecore
• squidfreezegrid
• squidfreezepath
• squidfreezeold
• squidfreezetext
• squidstorecore
• squidstoregrid
• squidstoreold
• squidstorepath
• squidstoretext
• squidwrathcore
• squidwrathgrid
• squidwrathpath
• squidwrathold
• squidwrathtext

There are clearly a lot of modules here. I'm not going to upload JARs for every one of them; you can use Maven Central to access the same JARs you would get through Gradle or Maven, but by a laborious click-and-navigate process instead of automated dependency fetching.

Various dependencies have updated, and some have been added. The most important dependency is probably jdkgdxds (data structures), which depends on digital (common number-related code) and funderby (functional interfaces for more types). All SquidSquad projects depend on that, as well as juniper (random number generation) and regexodus (cross-platform regular expressions). Most code will depend on the squidgrid module here, and it depends on crux (which generalizes an API for points). The squidfreeze modules depend on kryo (binary serialization). The new squidwrath modules depend on the Apache project's fury (different, faster binary serialization). The squidglyph, squidsmooth, and squidstore modules depend on libgdx (the game development framework for Java that I'm a collaborator on). All of this is handled automatically by Gradle if you have the dependencies right, though for the HTML target using GWT, it's more complicated and you should probably just use Liftoff.

I'm not including any JARs here because some of the names conflict, apparently, though none that you would probably want in one app at the same time. Each of squidfreeze, squidstore, and squidwrath has a file called core-4.0.0-beta2.jar, as well as one for other submodules, so I'm just going to reiterate that you should use Maven Central if you want JARs manually, or you can just build SquidSquad yourself locally (using Gradle, which really isn't hard at all here...), or even just copy out relevant code to your own project. I'm not your real dad, I'm not going to tell you what to do.

Good luck out there!

4.0.0-beta1 "Oh Lawd He Comin'"

This is the first beta release of SquidSquad, coming after 3 alpha releases. It is a big, hefty, chonky release. It has been over 9 months since the previous release. Whoops. Unlike SquidLib, which this effectively acts as successor to, SquidSquad is split up vigorously into semi-independent modules, some of which have their own dependencies or depend on other modules. Using Gradle Is Very Strongly Encouraged; gdx-liftoff offers SquidSquad as a third-party extension, and the next version will have the updated artifact IDs so you can automatically set up a project using a GUI. Maven also works, among other tools such as Leiningen and sbt. Instructions on how to add a module to your project for each of those tools are provided on the Maven Central pages for each of the dependencies there currently on version 4.0.0-beta1 .

Docs are currently sparse, and mostly in the form of code JavaDocs. You can browse the JavaDocs by module:

• SquidCore
• SquidGrid
• SquidPlace
• SquidPath
• SquidGlyph
• SquidSmooth
• SquidWorld
• SquidText
• SquidOld
• SquidPress
• SquidFreezeCore
• SquidFreezeGrid
• SquidFreezePath
• SquidFreezeOld
• SquidFreezeText
• SquidStoreCore
• SquidStoreGrid
• SquidStoreOld
• SquidStorePath
• SquidStoreText

There are clearly a lot of modules here. I'm not going to upload JARs for every one of them; you can use Maven Central to access the same JARs you would get through Gradle or Maven, but by a laborious click-and-navigate process instead of automated dependency fetching.

Various dependencies have updated, and some have been added. The most important dependency is probably jdkgdxds (data structures), which depends on digital (common number-related code) and funderby (functional interfaces for more types). All SquidSquad projects depend on that, as well as juniper (random number generation) and regexodus (cross-platform regular expressions). Most code will depend on the squidgrid module here, and it depends on crux now (which is just a few interfaces and one class, generalizing an API for points). The squidfreeze modules depend on kryo (binary serialization). The squidglyph, squidsmooth, and squidstore modules depend on libgdx (the game development framework for Java that I'm a collaborator on). All of this is handled automatically by Gradle if you have the dependencies right, though for the HTML target using GWT, it's more complicated and you should probably just use Liftoff.

Good luck out there!

4.0.0-alpha1 "Wisdom Of The Ages"

This is the first alpha release of SquidSquad. It has been over 28 months in the making. Sorry about that. Unlike SquidLib, which this effectively acts as successor to, SquidSquad is split up vigorously into semi-independent modules, some of which have their own dependencies or depend on other modules. Using Gradle Is Very Strongly Encouraged; the next release of gdx-liftoff will offer SquidSquad as a third-party extension.

Docs are currently sparse, and mostly in the form of code JavaDocs. You can browse the JavaDocs by module:

• SquidCore
• SquidGrid
• SquidPlace
• SquidPath
• SquidGlyph
• SquidSmooth
• SquidWorld
• SquidText
• SquidOld
• SquidFreezeCore
• SquidFreezeGrid
• SquidFreezeOld
• SquidFreezeText
• SquidStoreCore
• SquidStoreGrid
• SquidStoreOld
• SquidStoreText

There are clearly a lot of modules here. I'm not going to upload JARs for every one of them; you can use Maven Central to access the same JARs you would get through Gradle or Maven, but by a laborious click-and-navigate process instead of automated dependency fetching.