Ok, so I’m using paint and whipping up prototypes where I want to put GUI elements in my game, but after reviewing the glk library, I might be having a bad time at this…
Here’s the problem…
I’m trying to do a kind of visual novel/mixed interface. There are certain ascetics that are required for visual novels. Now, what I’m seeing is possible in glk and what glimmer can do seems to be different things.
Here’s my very basic GUI idea
The idea is most the game narration is in the center blue (Though I may have a bit below that that’s just for input). The brown bit on the left is a book that if you click will open a full-screen screen graphic for menus and such. The green box on the right side is a “character” that will help you with the game (She’s an electronic dictionary)
The big thing is the characters on top is how the game exposition is done. The boxes under the characters are dialog boxes that pop up when the characters talk to each other. All text boxes, btw have to support unicode, especially the characters dialog boxes as the will probably be full of nothing but Japanese text.
Now, I was thinking of making the white window on top a big Glimmr canvas and just draw directly on that. But graphic windows can’t do text? What about The canvas? I might have to invisibly split some boxes (like the the green box) where the graphic can be below and the text can be on top. But I’m trying to come up with a slick way of doing the character dialogs above. Maybe I can subdivide the canvas and place text boxes (With graphic borders) up there? Maybe overlap windows? Anyone have some neat tricks that I can use with text boxes? I would really hate to have to Blit Unicode characters to make the text.
You might be better off trying to use something like vorple, though it isn’t currently available for glulx, nor does quixe support graphics. But maybe those two facts will change by the time you’re ready to publish it…
No no, not HTML… I might of underestimated what Glimmr could do. I thought it was a graphic library like SDL.
In the end I’m going to have my own custom interpreter. There are a myriad of reasons for this, but mostly so I can control things Glulx simply can’t. For example I need the ability to control the client window and set a static resolution for the game. I also need better font control, and, by the looks of it, a better graphics system.
I just want to see how far I can go “out of the box” first. I’m kind of hoping to leverage the graphics portion of Glulx the same way I’m leveraging Inform for my narrative. That way, in the end, I just need to create my own terp to “solidify” the interface. If the graphics system is too limiting, I can just develop my own interpreter and hook into SDL, Allegro, or some other 2D graphics lib. Before I do that, I’ll start a project tomorrow and lean on the graphics system, just to see what it can do
I’m obviously partial, but developing your own interpreter just to get better control over the layout sounds a bit over the top solution. It will take a lot of time and effort for little gain over modifying existing systems. HTML doesn’t give complete control over fonts but very likely enough for your needs. At least building the layout would be almost trivial in HTML, and even if the project doesn’t fit in Z-machine you can hack Quixe to work with the HTML layout much easier than creating the whole thing from scratch.
Obviously it’s your choice if you want to go through with the custom interpreter idea and it might be a fun project to tackle, but just FYI that there are easier options available.
Glimmr is just an I7 library, it can’t provide anything that standard Glk doesn’t already allow for (e.g., image rotation, direct painting of fonts read from the user’s font folder, and quite a few other things). However, it can paint text to a graphics window, using custom “fonts”: either pixel fonts (plotted using pixel matrices defined by the author), or fonts where each glyph is supplied in its own PNG file. These fonts are a bit of work to put together (though ImageMagick can automate the generation of images via simple shell script), but the Glimmr package does include one font of each type.
If you’re going to want to do both Japanese and English characters in your graphics window(s), then you will have a very large font and it will take a lot of time to put together. Likely not as much time as designing your own interpreter, though!
Due to a bug in Inform that has since been fixed, I limited the text-painting routines to a single line. But you could pretty easily adapt them to respect simple manual line breaks, or even to automate line breaking (a bit more ambitious). Most desktop interpreters are slow at painting text, however–only Gargoyle reliably achieves the kind of speed you’d want.
Based on what you’ve said about your plans, I would not bother with the Glulx graphics system. Leverage HTML or some other graphics system instead. I wouldn’t even put in the effort with Glimmr. (You might have a look at FyreVM, if you want to go the route of building your own interpreter.)
I would suggest looking at Undum with Vorple (as opposed to Inform with Vorple). The main thing you can’t do with Undum – not without a lot of hand coding – is allow user text input. It’s set up for gameplay via clickable links. And of course, Javascript is not exactly a smooth language in which to write IF. But Undum is terrific at handling graphics and screen layout, precisely because it’s a Javascript library. (It has other downsides, of course, such as issues with how the game state is saved.)
Just as an experiment I’m just playing with window positioning… But I can’t seem to spawn things correctly
Include Flexible Windows by Jon Ingold.
Use no status line.
the lab is a room.
[MAIN WINDOW]
The main-window spawns the scene-center.
The main-window has back-colour g-steelblue.
[SCENE-CENTER]
The position of the scene-center is g-placeabove.
the scene-center is a graphics g-window.
the scene-center has back-colour g-red.
The scale method of the scene-center is g-fixed-size.
The measurement of the scene-center is 500.
[SCENE-LEFT]
the scene-center spawns the scene-left.
the scene-left is a graphics g-window.
The position of the scene-left is g-placeleft.
the scene-left has back-colour g-blue.
The scale method of the scene-left is g-fixed-size.
The measurement of the scene-left is 420.
[SCENE-RIGHT]
the scene-center spawns the scene-right.
the scene-right is a graphics g-window.
The position of the scene-right is g-placeright.
the scene-right has back-colour g-green.
The scale method of the scene-right is g-fixed-size.
The measurement of the scene-right is 420.
When play begins:
open up scene-left.
open up scene-right.
It’s failing on “open up scene-right”. I can seem to open one or the other, but not both. It seems to “forget” the ‘open up’ verb.
