Skip to content

SquidLib 3.0 Changes

Jump to bottom
smelc edited this page Oct 5, 2015 · 3 revisions

SquidLib is undergoing major changes for version 3.0, and many of those changes break existing code in small or somewhat-significant ways even in the current master. There has been talk across various issues and pull requests of making more significant changes for optimization reasons (especially in squidlib-util), for platform compatibility (SquidLib 3.0 will support Android, so desktop-specific classes needed to be removed from at least squidlib-util; this should mostly be done), or for contributor sanity. Any opinionated wording in here should be blamed on tommyettinger.

Sanity

Do we need to support two different display methods when the performance and responsiveness of LibGDX relative to Swing are so vastly superior, even if Swing has no dependencies on desktop? LibGDX is somewhat more challenging to set up, but avoiding lag on rapid key presses and horrendous performance when showing animations is probably worth it. Swing was never meant for games, and LibGDX is meant specifically for games, so that should be an indicator already. The display code should still be split from the utility code, but the squidlib-gdx module would replace the (Swing-based) squidlib module.

Remove Swing?

Advantages

  • Simpler codebase
  • Added features only need to apply to one display mode, and don't need to duplicate work with subtle differences between two different display modes
  • Less confusion as to "which display mode do I pick" for new users
  • Games won't require an understanding of threads to do animations that get part-way to reasonable performance
  • Games made with SquidLib won't have slug-like performance/responsiveness if they try anything more complicated than a truly basic roguelike, so the library shouldn't get a reputation for poor speed caused by Swing
  • Can claim 100% support of Android and iOS (via RoboVM) instead of the partial support now.

Disadvantages

  • Essentially requires the use of a dependency manager like Maven or Gradle to handle SquidLib's and LibGDX's dependencies.
  • LibGDX requires a rather specific technique for the code that launches the game, which does however enable it to work on more than just desktop platforms. Certain unusual environments may not find this acceptable, but they are also not likely to use any library's display mode anyway (I suspect the only areas where LibGDX's method for launching the game are unusable are servers or highly-customized games that probably only need squidlib-util).
  • Existing tutorials and examples other than the ones in SquidLib become even less relevant
  • All the code from before SquidLib 2.2 or so is now virtually guaranteed to be broken
  • Some contributors may become unable to use SquidLib for display if they require AWT

Other Options

  • Swing display could be shuffled into a 3rd-party module if someone needs it for whatever reason; the interfaces added with a recent pull request would possibly be removed from squidlib-util unless there's a reason to have them in the utilities (Colored strings make sense because non-graphical code may want to specify what colors to use when text gets handed off to graphical code, just like a string specifies what characters to use. SquidPanel abstractions may not make as much sense with only LibGDX as a display mode in the official repo.). It may make more sense to ensure the interfaces that are present in squidlib-util avoid trying to bridge compatibility between very different display modes (one display mode that's possible is printing to a VT220-compatible 16-color console; how can that be reconciled with SColor's hundreds of true-color constants...) and instead only focus on specific concepts that are reasonable for any display method.

Votes In Favor Of Removing Swing

  • SquidPony (Owner, Head Honcho, Big Boss. Vote could, uh, swing, either way, but the most recent word on the matter suggests a yes vote.)
    • I love me some Swing, but it's not the direction roguelike developers are heading. For those that do want to use Swing, older versions of SquidLib should still work just fine. Therefore in order to get more performance and broader device compatibility, I'm strongly in favor of removing Swing to prevent interface creep in the codebase.
  • tommyettinger (Collaborator, technically has committed more (measured in lines of code and total commits) than anyone else, see Graphs. Voting yes, not insisting on removal.)
  • davidbecker (Should probably be considered a collaborator considering the amount and quality of PRs submitted. Strong yes vote.)
  • Add your yes vote here, it's a wiki

Votes Against Removing Swing

  • Add your no vote here, it's a wiki

No opinion

  • smelc: it was nice for me to have the swing output, since I could have a basic roguelike up and running in a few evenings. But I don't mind if it gets removed, since I'm moving to the gdx backend. If swing gets removed, I think it'd be nice to provide an example Eclipse project (and an intellij one) to newcomers. That being said, I think we should still have an interface for SquidPanel 😄, as an interface allows to do subpanels, panels at given offsets, virtual (horizontal|vertical) splits, etc. But I'll make my case later on ;-)
Clone this wiki locally