-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Swing/AWT display in 3.0 release? #83
Comments
OK, I'm preparing to do this. I will leave the last commit with Swing intact in its own branch, where if someone wants to pick up the Swing display, they can do that without going through Point->Coord refactoring all over again. I may port a few more demos first; I already ported the MetsaMapFactory demo to the GDX project as WorldMapDemo. For some cases the libGDX code will be slightly more complex, but for anything that looks like an actual game (like EverythingDemo in Swing vs. in GDX), the code should be smaller and cleaner. |
@tommyettinger maybe you should add a tag like "last working swing version" to the commit as well? |
Good idea. I'll scan for anything like MetsaMapFactory that doesn't have a clear parallel anywhere else, and I'll add a tag before I make the change. |
One of the thing I'll miss from AWT is the availability of the default super good looking complete font 😢 |
@smelc : thoughts on this font? |
@tommyettinger> it looks awesome! I'll try that at home this evening. So far, I did not succeed to obtain a good looking font of my own (I used libgdx's hiero and dejavu sans mono, the result is OK but not as smooth as your screenshot). |
I can do quite a few manipulations to the font if need be, including making it square as an option. I didn't use Hiero, since it had all sorts of trouble with monospace anything; to make a font in the AngelCode format it turns out the BMFont generator from AngelCode is best (surprise!). I'm posting the TTF and BMFont config in the etc subfolder of squidlib-gdx, at the same level as src. That way they won't be included in a jar, I think, but will be kept in the repository. |
Thanks @tommyettinger. I could use BMFont to generate the font in all the sizes I need using a variant of your config file. For those who read that, I'm running linux and could run BMFont with wine 1.5 (it was crashing with 1.4, I updated and it worked without any tricks with 1.5). Then I generated all the fonts I need with this script (Inconsolata-LGC-my-config.bmfc is a variant of the file that @tommyettinger commited to squidlib-gdx/etc/): #!/bin/sh
# This script must be placed in the directory where bmfont.com lives
prefix=font-
for i in `seq 6 2 50`
do
sed "s/fontSize=-20/fontSize=-$i/g" Inconsolata-LGC-my-config.bmfc > config.bmfc
filename=$prefix$i
wine bmfont.com -c config.bmfc -o $filename
done So thanks @tommyettinger for this font 👍, that looks better than the font I generated with libgdx's hiero. I still have some glitches with some sizes (in my game, but maybe in the demo too, but they are hidden because the demo renders the whole map every time) because characters are placed too low and sometimes they overlap on the cell right below them, but I think I can correct that by fiddling with the configuration file for BMFont. |
I think the font may actually be 12x25 at the resolution I rendered first... The font isn't truly rectangular, and I wasn't thinking about sizes other than the ones I had tried it on when I was editing it. It's likely that it could be edited to make it truly rectangular, but it would take some time; there's a lot of glyphs in there... |
For the moment, I'm good with using a font smaller than the cell's size (- 2). Maybe it does not suffice yet for characters that are really low (like 'g'), but I'll see later (if I use a -4 difference, then it starts looking weird, so I can't just make the font smaller again). |
Well, I pushed 3.0.0b1 as the final release to include Swing, then followed up after the release by moving the last Swing-using version into the branch |
I'm posting this as a new issue to focus any discussion on this topic in one place, instead of all over PRs and issues where it was before. It has been suggested that Swing/AWT display should be kept in the 2.x series of releases, and 3.x should move to only supporting LibGDX for text-grid display. This avoids spreading interfaces across rather dissimilar display techniques, uses a game development library for its intended purpose instead of a GUI library for a very unintended purpose, ensures more modern visual effects can be used without poor performance, and allows SquidLib to be used for both display and logic on almost every platform LibGDX supports (Windows, Mac OS X, Linux, Android, and iOS, but not HTML5 due to some missing APIs). I documented the pros and cons in this wiki article, and it has a place to record votes if you feel strongly either way. You can also feel free to give an opinion here.
I'm currently inclined to remove Swing rendering from the official repo and move it into a different repo if anyone specifically needs Swing support, and they can maintain it if they feel like it. In that case, it should be assumed that
squidlib-swing
releases will lag behind official releases ofsquidlib-util
andsquidlib
(with the GDX display code becoming the inheritor of the name that currently belongs to the Swing display code,squidlib
, and withsquidlib-gdx
not ever in any stable release, the name change doesn't matter for it).This is relevant for several other issues/PRs, #54 and #81 especially. This seems mostly resolved, with 2 strong yes votes, my moderate yes vote, and zero no votes, but I haven't heard from @smelc and I thought that someone mentioned requiring Swing for their job, though I don't know if SquidLib would be used on that job as well. @smelc also contributed the PR #81 , so possibly the shared interface is more important for the kinds of games developed in Smelc Labs Inc. It would be good to get a better idea of what features are actually needed by SquidLib library users. Ivan Polozhentsev uses SquidLib in one of his repos, and mentioned not updating libraries to try to get a game out sooner. I don't think he used GDX because he was using a version before it was included. If that's a common response to a library update, then we should push ahead on quality and worry less about backwards compatibility (which 3.0 breaks all over with the Coord refactoring...), since people who need compatibility may never update in the first place.
The text was updated successfully, but these errors were encountered: