Glimmr Canvas-Based Drawing: No Image

I’ve downloaded and, I believe, successfully integrated Glimmr Canvas-Based Drawing. However, no images appear during gameplay. Instead, I get a black background. I’ve been tinkering with this for about two hours, and still no success. As it stands, here’s my code:

[code]The portrait-window is a graphics g-window. The main-window spawns the portrait-window. The position of the portrait-window is g-placeright. The scale method of the portrait-window is g-fixed-size. The measurement of the portrait-window is 300.

The portrait-canvas is a g-canvas. The associated canvas of the portrait-window is the portrait-canvas. The canvas-width of the portrait-canvas is 300. The canvas-height of the portrait-canvas is 600.

A portrait-sprite is a kind of a sprite. The associated canvas of a portrait-sprite is the portrait-canvas. The display-layer of a portrait-sprite is 2. The display status of a portrait-sprite is g-active. A portrait-sprite has a number called the associated portrait. The origin of a portrait-sprite is { 150, 300 }.

Some portrait-sprites are defined by the Table of Portrait Elements.

Figure of Mary is the file “Mary.png”.

Table of Portrait Elements
image-ID associated portrait sprite
Figure of Mary 20 Mary[/code]

Any idea what I’m doing wrong? I’ve troubleshot in the IDE, Gargoyle, and Glulxe.

Additionally, when I get past the intro (just as the command prompt appears), I get an error. This is the only code I’ve added since successfully running the game. The error reads:

[**Programming error: tried to read outside memory usage -> **]

There seem to be two little problems here that have dovetailed in a perfect-storm kind of way. First, Inform assumes that the first column in your table is the name of the sprite–since yours starts with the image-ID (figure name), Inform assumed that the figure name was actually the name of the sprite. And because it assumed that the image-ID column was the name of the sprite, it didn’t assign the image-ID property at all.

Normally, Inform would have choked on the attempt to call the sprite Figure of Mary, since Figure of Mary has been already been defined as a figure. However, the placement of the Figure of Mary is the file… declaration between the definition of the sprite subkind and the table defining the instances of that kind seems to have put it into a kind of no-man’s land, where the normal checks weren’t made. The upshot is that you have both a figure named Figure of Mary and a sprite. This is a bug, but it also illustrates the general principle that defining figures should occur before any code that has anything to do with images.

Here’s a working version of the code, with the only modifications being to the table and the placement of the figure name declaration:

[code]Include Glimmr Canvas-Based Drawing by Erik Temple.

[Use Glimmr debugging.]

Figure of Mary is the file “Mary.png”.

The portrait-window is a graphics g-window. The main-window spawns the portrait-window. The position of the portrait-window is g-placeright. The scale method of the portrait-window is g-fixed-size. The measurement of the portrait-window is 300.

The portrait-canvas is a g-canvas. The associated canvas of the portrait-window is the portrait-canvas. The canvas-width of the portrait-canvas is 300. The canvas-height of the portrait-canvas is 600.

A portrait-sprite is a kind of a sprite. The associated canvas of a portrait-sprite is the portrait-canvas. The display-layer of a portrait-sprite is 2. The display status of a portrait-sprite is g-active. A portrait-sprite has a number called the associated portrait. The origin of a portrait-sprite is { 150, 300 }.

Some portrait-sprites are defined by the Table of Portrait Elements.

Table of Portrait Elements
portrait-sprite image-ID associated portrait
Mary Figure of Mary 20

When play begins:
open up the portrait-window.

There is a room.[/code]

Incidentally, there a couple of tools you could use to deduce what was happening here. The World tab in the Index shows all sprite (and windows and canvases), and shows Figure of Mary to be the sprite name. Including the “Use Glimmr debugging” line will produced a verbose debugging log that show you that the game is attempting to draw a sprite called “Figure of Mary” rather than “Mary,” as well as the fact that the image-ID for that sprite is undefined.

–Erik

That solved it! Thanks again, Erik.

My game is still crashing after the intro, though. By selectively removing snippets of the code, I’ve isolated the problem to:

The portrait-canvas is a g-canvas.  The associated canvas of the portrait-window is the portrait-canvas.  The canvas-width of the portrait-canvas is 300.  The canvas-height of the portrait-canvas is 600.

When this line is present, the game crashes. When I remove it, it runs fine. (I also remove the following lines on portrait-sprites. If I only remove the lines on portrait-sprites, the game still crashes.) I think the g-canvas line itself isn’t the problem, though. I’ve more-or-less copied and pasted this from the documentation. Can you think of what it could be interacting with to cause the run-time error?

For reference, I have several other text-buffer windows open. In addition, I’m running this with your Text Window Input-Output Control. The main output window is the main screen, and the main input window is a text-buffer beneath the main screen.

I don’t really have a clue, unfortunately. There’s nothing about the code you isolated that would lead to that error (at least, not that I can think of). I haven’t really tested Glimmr with the Input-Output Control extension, but it’s hard to see how there would be an error there either. Maybe you could post your full code; or rather, the full text of the smallest source code file you can make that exhibits this error? You can attach .txt files to forum posts, which might be the best way to go.

–Erik

While trying to create a compact example, I stumbled across the real problem. When play begins, the game creates seventeen generic NPCs using Jesse McGrew’s Dynamic Objects, each with randomly selected traits such as “interest in science,” “interest in sports,” “humor,” etc. This includes two NPCs with the personality profile of a librarian.

For some reason, creating two semi-identical NPCs at the start of the game was causing it to crash, though only if I’d already created the portrait-canvas. (Though, curiously, the canvas wasn’t yet linked to any of the NPCs. I had yet to assign them portraits.) By removing one of the librarians, the game ran fine. After that, I could procedurally generate as many librarians as I wanted.

I’m not sure why this error was happening, but it seems fairly benign. The seventeen generic NPCs I created at the start of the game are purely for testing purposes, so as long as this error is isolated to when the game begins, I should be fine. I’ll keep you posted about further developments, though hopefully there won’t be any.

I think other folks have also reported trouble creating dynamic objects when play begins. I suspect that this has nothing whatsoever to do with the canvas or the portraits; probably any object declaration could have created the issue.

–Erik