plClient Resources

[Deledrius]

This branch incorporates an automatic script to create the resource.dat file necessary to run plClient, which includes replacement art for the cursors, the loading book spinner, the Updating/Loading text splashes, and the Speaker/Microphone voice chat enabled/disabled icons.

All art assets are SVGs, rendered by a cross-platform python2.7 script (Windows users will need PyGTK for cairo and rsvg) to PNGs, optionally optimized by pngcrush (currently a size difference around 50kB), and then packed by another python script into a resource.dat file in the format used by Myst5 and HexIsle.

The resultant resource.dat file will need to be copied from the Plasma/Sources/Plasma/Apps/plClient/external directory to the location of the plClient or UruExplorer executable.

[cwalther]

Great work! Much more thorough than what I did, and I like the completely automated building of resources from SVG too. First bunch of comments, besides what I already mentioned by e-mail:

• I have two additions concerning the Thumbs.db files that Windows likes to litter any folder containing images with: Don't include them in resources.dat (cwalther/Plasma@84a97b4), and when garbage files still end up in resources.dat by mistake, cope with them on reading instead of letting the stream go out of sync (cwalther/Plasma@c170b50).
• The linking book animation is backwards compared to Cyan’s client: it should be clockwise. (For some reason Cyan’s image files are numbered backwards.) This is probably best fixed by reversing the rotation sign in render_svg.py.
• I dislike your use of Hobo for the "Updating" text. I would rather have changed both texts to Collegiate. Is Hobo even used anywhere else in the user interface? (Is it used anywhere at all, seeing as the "Linking" text is not used?) I think Collegiate fits better style-wise anyway.
• In reply to your last e-mail, but I think that discussion is better held here in public:

I'm not sure if adding rsvg/cairo as a required build-time dependency is a good idea (setting up a minimal build environment should be as simple as possible).

I agree, and I tried to avoid it, but it seemed to be the only way I could have the python scripts be able to manipulate the SVGs at compile time, which allows me to hide/show layers and do nifty things like rotate the circles for the Linking Book image. I felt that making a single set for the cursors and enabling and disabling the layers to create the desired cursor would make it easier to make edits. I still wasn't convinced it was a great solution but I found that both cairo and rsvg could be installed with a single package (PyGTK for Windows), comes installed by default with Ubuntu, and can be easily installed in macports, so that assuaged my doubts. It's not perfectly ideal, but it's a low enough barrier I felt it was worth the benefits for the script I wanted. I was trying to focus on making it easier to edit the art at the expense of a little more effort on the compile, rather than the other way around.

I do like the automated building. I just think it should be optional for those who don’t wish to change the resources. I agree it’s not a strong barrier (building libpng was harder than installing PyGTK…) By the way, I haven’t tried what happens when you don’t have Python installed. Can we assume Python to be such an essential development tool that everyone has it (on Windows, where it isn’t part of the operating system)?

The cursors etc. shouldn't change all that often, so maybe it would be worth checking in the generated PNGs too and making rebuilding them optional, to make things easier for the people who don't want to change them (in particular those who don't intend to do any development at all, but just want to build binaries).

I considered that, too. I discussed it with Branan in the IRC channel before commiting to an organization for it, and while he agreed that ideally these are game-specific client resources (the same as the moul-python repos, and a hypothetical Age-content-to-PRP repos), we aren't really set up for it yet but it will all likely get moved if and when such a reorganization takes place. Thus it was better to pull it in as-is for now.
In theory one could check in a complete resource.dat file, and so long as the scripts or resources aren't touched Visual Studio won't attempt to recreate it during the build... so that option is technically already available to us if we want to go that route. It just seemed like a bad idea to check in both the source and the output, as it defeats the usual concept for such thing, even though I admit it seemed like it might be useful at this stage. What do you think?

I agree that putting generated files under version control isn’t usually a good practice, but there are exceptions (e.g. including configure scripts so that not everyone has to have autoconf to generate them), and I think this is one of them. I would either check in a complete resource.dat, or make it available for download separately somewhere, maybe as part of the cwe-prefix package. The build script could then even try to copy it from there if the prerequisites for rebuilding it aren’t installed.

[dpogue]

Can we assume Python to be such an essential development tool that everyone has it (on Windows, where it isn’t part of the operating system)?
Given that Plasma itself requires Python (both the runtime and the development libraries as far as I know), it seems like a reasonable assumption here.

[cwalther]

Those who use the GoW cwe-prefix package (unless it has changed since I got it) only have the libraries, but not the interpreter executable.

[Deledrius]

I think I fixed the backwards spin at one point and forgot to commit that change. I know I remember noticing it. As I recall, I just flipped the sign as you say.

I used Hobo for the font because it's what Cyan was using on the Linking text as well as other places in the game (there are a few dialogs that use it, I believe). I'm not particularly fond of it myself, but I decided (as with much of the code here) to stay as close as possible to existing assets for consistency's sake while making it easy for us to continue to enhance them later. Unfortunately due to the nature of fonts and rendering them as SVG, I converted it to curves so that those building wouldn't need the font to create the resources. Using that simple SVG however, it should be trivial to create new layers for those strings using a better font if desired. I'm not sure if Collegiate is the best fit for Uru, personally, but I don't have especially strong opinions about it either way.

I used Python for the scripts as it was something I felt could be assumed to be available cross-platform, unlike my original bash script I was using, especially in an environment where we will be building Uru itself which uses Python fairly heavily. If the scripts fail or Python is unavailable it should return an error.

If there's a better way to deal with this through CMake, I wasn't able to find one, but I'm still learning to use it. I'd rather have the resource.dat built as a separate target altogether, as it's not really a dependency (or dependent upon) the client or any of its libraries. I'm just not sure how best to organize that here.

[cwalther]

Consistency with existing assets is exactly why I would argue for keeping the font on the element that’s used (Collegiate on “Updating”) rather than on the one that’s not used (Hobo on “Linking”)… (aside from my personal aesthetic preferences)

Using Python is fine with me, by the way, I’m a Python fan too.

Having resource.dat as a separate build target rather than a dependency of plClient or anything is probably fine. What would be nice to have CMake deal with is that Cursor_Base.svg is a dependency of cursor_open.png and cursor_open.png is a dependency of resource.dat. As far as I understand the current CMakeLists.txt, at least the latter is currently not codified. But I’m unfamiliar with CMake too, and I don’t consider this particularly important.

[Deledrius]

Ah, I see what you mean now about Collegiate. I didn't recognize that one when I was making those (and never could figure out why Linking and Updating were two different fonts). It's a good point; I'll commit a new Loading_Text_rasterfont.svg with the proper font for that as soon as I can.

[cwalther]

Okay, got some time to look into it and it doesn't appear to be Collegiate. Compare:

http://www.dafont.com/sf-collegiate.font?text=UPDATING
https://github.com/Deledrius/Plasma/raw/master/Sources/Plasma/Apps/plClient/res/xLoading_Updating_Text.jpg

It's definitely not Hobo, but unfortunately I don't recognize it. Any other suggestions?

Looks like there are different Collegiates… here’s the right one that also matches dat/Collegiate-*.p2f (open Collegiate-28.p2f as a 30 pixel wide raw 8-bit-per-pixel grayscale image to compare):

http://new.myfonts.com/fonts/k-type/collegiate/?testdrive=text%3DUPDATING

[Deledrius]

Yeah, I eventually realized that after spending a couple of hours hunting when I should have been asleep (which I suspect was the problem).

There was discussion last night about replacing these text plates entirely with a plDynamicTextMap instead, which would simplify this particular resource question greatly.

[cwalther]

That could be an option. I have no idea if it would be easier though. And maybe some future non-Uru games would like to display something fancier than simple text. Also, Collegiate-28.p2f only seems to have the Latin-1 character set, not Windows-1252, so there’s no bullet character (•) – these would be lost.

One thing I have wondered in a similar regard is if the linking book animation should be rendered in real-time rather than as an image sequence – with two statically textured plates, one of which rotates. (That’s how I always imagined it to work anyway before I saw the image resources.) Rotating a plate shouldn’t be too hard.

But we’re probably getting off-topic here. Let’s integrate the resource system without too many other changes first, and think about those later.

[Deledrius]

Yeah, looking at the available character set in the bitmap fonts led me down a "What would it take for Uru to support actual font files...?" which would be better left for a different changeset entirely.