Agreed. It’s weird that this isn’t easy, but I gave it the old college try and I’m comfortable with failure here.
1 Like
What’s your exact release along with line, what figure of definitions do you have in your source, if any, what jpgs are in your project’s materials folder, and what jpgs are in the Figures folder under your project’s materials folder?
To work with the template, Cover.jpg and Small Cover.jpg must be in the materials folder and you must use release along with a cover image, an interpreter, and [...whatever else].
I wonder whether you might have your cover image under Figures and are manually displaying it when the game starts.
2 Likes
In spite of Inform’s sort-of invitation to make an interpreter change from the IDE, I don’t think I’ve ever seen it done. So I would not bother/worry about that.
I strongly suspect all your one (as opposed to Amanda’s) needs is the image-processing step. That step alone IS a big nuisance if you build your game via “Release along with an interpreter” and then seek to apply the step. The easiest way to do it now is to use ifsitegen.py, which does both at once. If you’d like me to run this script on your project (without even playing your game, and with me signing a verbal NDA publicly here for all to see, which I declare to be doing now!) and then send back the resulting files, I’d be happy to do that. PM me if you are interested.
-Wade
3 Likes
It would probably be wise to take Wade up on his offer, because his method is surely easier than what I’m about to discuss (for those who know what they’re doing).
That said, there is a brute force workaround to process the images without any knowledge of Python or any other language they speak in Byzantium.
First, make sure you’ve set up everything correctly in the source:
Release along with an interpreter and cover art.
Figure of Whatever is the file “Whatever.png”.
Figure of Some Stuff is the file “Some Stuff.png”.
After doing whatever:
display the Figure of Whatever.
Then, generate a release, and open up play.html in a text editor (e.g. Notepad++). There will be a line that looks like this:
image_info_map: ‘StaticImageInfo’, // image data is here, not in blorb
The image_info_map part is where the images need to get referenced. Again, ifsitegen.py exists to make this easy, but if a person would rather do it manually, that is eminently possible. Here’s how a person would enter the info, continuing from the above example:
image_info_map: { 3: { “image”: 3, “url”: “Whatever.png”, “width”: 512, “height”: 512 }, 4: { “image”: 4, “url”: “Some Stuff.png”, “width”: 512, “height”: 512 } }, // image data is here, not in blorb
…and that’ll do it. Note that the images are indexed beginning with the number 3 (because 1 and 2 are already used for the cover/small cover), and they need to be indexed in the same order as they are declared in the source. Width and height also need to match whatever the image is. Then just save play.html with your edits. Also recommended: copying the edited section into another file for safekeeping in case you overwrite play.html in a new release.
As for this, which I think is probably a completely separate issue from the one pinkunz is having, I haven’t a clue why it’s doing that. It should be displaying the small cover in that area, not the regular cover at all. Afraid I have no ideas except the pyrrhic workaround of just resizing the cover image to match the small cover.
Edit for clarity: the image processing step I discussed in the first part of this post is relevant in situations where images are being inserted throughout the game; it has nothing to do with cover art, which SHOULD work without that step.
3 Likes
For the Puddle BuildTools I created a Powershell script that wraps ifsitegen.py to bundle the modern PC release of a game. Puddle-BuildTools/modern.ps1 at master · ByteProject/Puddle-BuildTools · GitHub
You don’t necessarily have to use the script of course but it is a good example of how to work with ifsitegen.py.
All you need is an Inform 7 installation and additionally a Python interpreter installed, which can be downloaded from the Windows store. I suggest you update the Parchment that came with I7 though as mine was outdated and caused a few problems.
Edit: Powershell is installed by default on Windows 10 (or later)
1 Like
When I ran into a similar problem with an Inform 7 game (my cover art was all right but game images were absent) I found blorbtool.py to be better than ifsitegen.py.
1 Like
“interpreter” here means a web-based interpreter with a corresponding prepared template, a directory that includes (manifest).txt and typically some javascript and css. There are only three choices, Quixe, Parchment, and Vorple. I7 will look for a requested template in these three places in this order:
- your project’s materials folder’s Templates dir
- your External directory’s Templates dir
- your I7 installation’s Internal directory’s Templates dir, which will have any of those three, but the versions there are very old.
This was me a year ago struggling to grasp basics about template organization and Dannii kindly giving me some clues. There are kind of a lot of moving parts involved in these topics, and the docs talk about one or two of them at a time, but then what they mean and how you make them work together is left to be a thing you learn on the streets.
1 Like
OK, I woke up and came at this fresh and discovered the problem, and it will shock everyone to learn that this was user error. I know. So unlike me.
I had the dimensions of the small cover set to what Aaron asked for, but it turns out that the interpreter wants it to be 120 x 120. I simply hadn’t considered that Spring Thing’s small cover requirements might be different than Inform’s. I had the game set to display the cover as soon as the game began, so I had to remove that to eliminate a “pause the game” that existed for no reason, since it won’t display the picture.
This will be a huge problem for my TALP game, which displays a lot of images, but it’s fine for this one.
But I have a month to try and figure it out for TALP.
7 Likes
So thinking ahead to releasing a game dependent on graphics, I had a look at the blorbtool, and I have no idea how to implement this. Are there some step-by-step instructions somewhere with an English translation of the computerese?
1 Like
Dannii mentioned this, but I’m not sure if it got noticed or lost in the conversation. If you want a Glulx game playable online (with graphics) the easiest approach is to use iplayif.com, which effectively does all this for you. All you have to do is make sure that the Blorb file containing the game and graphics is available online somewhere.
For example, Emily Short’s “City of Secrets”. The IFDB page from it is City of Secrets - Details. From that I can see that the Blorb file is hosted on the IFArchive, at https://ifarchive.org/if-archive/games/glulx/CoS.blb. The “Play On-line” button on the IFDB page is just another link, to the URL
https://iplayif.com/?story=https%3A%2F%2Fifarchive.org%2Fif-archive%2Fgames%2Fglulx%2FCoS.blb
If you follow that link, you get the game running in the browser with graphics. All iplayif.com does really is interpret the bit of the URL after the question mark as where to the get the game from, and it does the rest.
If you want to host the entire interpreter on a web site then yes, you need Parchment and the Blorb tools and all that, but it is not the simplest way to make this work online. The above is:
- Put your game online, get its URL, e.g. amanda.com
- Convert that URL to a format that can be passed to iplayif.com: turn colons into %3A, slashes into %2F.
- Make an iplayif URL, which in this case would be https://iplayif.com/?story=https%3A%2F%2Fwww.amanda.com%2Fgame.gblorb. That’s all there is to it.
1 Like
So I need to get a website to make this work? I am not sure I care enough about anything I write to do that. Perhaps it’s time for me to leap forward into the late 20th century, but perhaps not. Thank you for the detailed response! Aside from getting a website, all that looks manageable.
1 Like
You will need web space somewhere to make this work by either method, the game and interpreter have to be visible on the Internet for anyone else to play it. It doesn’t have to be your own website, though, there’s the IF-Archive, or you could use something like DropBox. The point is that the file needs to be accessible from the Internet.
1 Like
This is a good solution if I can work out the timing with the TALP Comp so it’s not released prematurely. Thanks for your patience.
1 Like
Thank you so very much for your help. I cannot express how grateful I was to read that last night.
Thank you. To be honest, this method intimidated me less than the ifsitegen.py thread did and I largely followed it. Thank you for sharing this.
That helps my understanding sooo much. Thank you! Shame these two lines aren’t in the documentation.
I did see this and I tried using it, but it wasn’t immediately clear how to set up a link making this work. “Please download this, then go to this site, browse for the file, and then you should be good to go.” seemed like not much of an improvement to “download this, figure it out”. This explanation is much clearer and I now feel confident that I can successfully use this tool. I wish your explanation were summarized or linked to on the site’s landing page.
1 Like
From the Parchment Github page, it looks like this has already been discussed: Publicly document how to use arbitrary URLs · Issue #120 · curiousdannii/parchment · GitHub. Even better, @Zed has submitted a pull request for a change that adds a widget to the iplayif.com page that lets you work out the URL: URL generator by zedlopez · Pull Request #121 · curiousdannii/parchment · GitHub
2 Likes
I can take a shot at explaining the background… and if I get anything wrong, I hope Andrew or Dannii or someone will correct me…
When you compile a game you get the .ulx file (or .z8 if you’ve specified zcode instead of glulx) that is the actual game file that an interpreter interprets. But it doesn’t have your cover image or any included assets. The .ulx game file, and the cover image, and assets are bundled together into a “blorb”, a file packaging format created for IF. By default, it gets suffixed .gblorb when the game file is glulx and .zblorb when it’s zcode. This works great for Gargoyle and any number of interpreters, which can extract the files just fine.
When you “release along with an interpreter” you get a collection of files under your project’s materials directory’s Release directory. You can then actually access it with a web browser locally on your machine. I don’t know how exactly that would look for other people, but for me it could be:
file:///home/zed/inf7/mygame/mygame.materials/Release/play.html
For everyone the end will be the same… gamename.materials/Release/play.html, but the part before that will vary.
If you were to upload the contents of that Release directory onto a machine running a web server (in a part of that machine’s filesystem that the server knows it’s supposed to serve), maybe renaming “Release” to “mygame” then suddenly the whole world could also access it at something like: https://subdomain.domain.com/mygame/play.html (assuming mygame were at the top level of the web server’s DocumentRoot, otherwise other directory names would come before /mygame).
If you look in the Release/interpreter folder, you’ll see something called mygame.gblorb.js. It’s a little bit of javascript code wrapped around your .ulx file translated into ASCII. Except for some text substitutions in the HTML files, everything else about the web pages generated by the templates is generic: this one file is your game. (What iplayif does is to accept specified ulx or zcode or blorb files from elsewhere, to dynamically translate it into a usable form, and to serve it up with its own somewhat customized version of the html/css.)
And though it calls itself .gblorb.js… it lies. It’s not a representation of your blorb, it’s a representation of just the .ulx. Your figures have been left behind (except Cover.jpg and Small Cover.jpg, which are a special case – the template generation keeps them as standalone files that the HTML can access directly).
If it weren’t a lie, and if it really were a representation of a gblorb including images, Quixe actually could handle it out of the box. But then javascript would be handling extracting images or other files from the blorb, which can be slow. (This is what iplayif does when you use it with a gblorb.)
This is where those blorbtool instructions come in: now that you’ve gone to all the bother of specifying your figures and getting them into your blorb, now you would use blorbtool to take them back out and put them as individual files into the interpreter directory under Release so that Quixe can find them and use them without processing overhead, thus making things faster for the player. (I believe the modern Quixe template already has the changes to the manifest that page discusses, so it would be less work to use the current version.)
But doing that doesn’t do any good unless you’re going to be hosting it on a website where you’re free to upload all of the stuff under the Release directory.
2 Likes
That’s what I was going to ask if it didn’t get addressed down thread. The reason it asks for Cover and Small Cover is because Small Cover is intended as a thumbnail to be used in that context (most specifically the sidebar of Inform’s published website - but any web design can potentially make use of it) and should be 120x120. The full Cover can be anything, but square is recommended at 300x300 at least. If you don’t provide a Small Cover, Inform will use the plain Cover and smoosh or crop it in random and interesting ways.
Inform’s default web template prefers 120x120 for that side image, but this can be adjusted with the resulting published HTML’s CSS if you’re inclined to fiddle with the website presentation. Many people can and do - either remove it or do all kinds of fancy things. Since your art was so large and that sidebar has a hard horizontal limit, it sliced it into a bookmark-style image - which surprisingly looked kind of cool by accident, except for being unsuitable as a background for the menu text links.
The advantage of the Small Cover is that if you have art or text that doesn’t look good shrunk to a thumbnail, you can re-edit the picture so the text is readable or completely eliminated, or a custom-cropped version of the art instead of the full thing.
This is actually addressed in the Releasing section of the manual starting at 25:1, which is quite helpful with all this type of info including bibliographic data, different web templates, and potential online interpreters. (Usually the choice is Parchment or Quix-E)
I know in at least one past IFComp there was a lot of fuss because Parchment was out of date and everyone needed to do this step and choose a different interpreter after the games were published.
Cover art for a work should be prepared in either JPEG (“.jpg”) or PNG (“.png”) format, and we recommend that it should be square, like a music album cover. Programs which notice the cover art for a work of IF are likely to scale this up or down as convenient for their own display purposes, but it would be helpful to provide the original art at 960 by 960 resolution. (Remember, it is intended for use on screen, so providing art at magazine full-page print quality will add nothing and will only make the resulting release an annoyingly large download: even as it is, 960x960 will print out as a pretty respectable CD insert sleeve.) The cover art must not be smaller than 120 pixels in either dimension.
2 Likes
It’ll disappear without notice someday, but for now my demo iplayif url generator is available.
2 Likes
One further option: you can host a .gblorb file at Borogove.io which will handle the online interpreter for you. And you can set the access link to be unlisted so you don’t need to worry about it being seen before a competition is open for voting.
3 Likes