I7: Looking for beta tester(s) for new Glulx extension
Erik Temple
I'm looking for someone who'd be willing to beta-test a new extension
I've worked up to manage complex sprite-based graphical displays
(Glulx-only, obviously). It's designed to be useful in the
construction of gradually revealed or otherwise dynamic maps, visual
puzzles, games such as poker or tic-tac-toe, and visual scenes and
narratives. I've used it to construct a couple of map-based examples,
one of which can be downloaded here:
http://dl.getdropbox.com/u/947038/Robner%20House%20Sprite%20Example.gblorb
Shoot me an email if you'd can help put the extension through some
more testing, or just download the extension, I guess:
http://dl.getdropbox.com/u/947038/Simple%20Scaled%20Sprites.i7x
In addition to any bugs, I'm particularly interested in suggestions
for code optimization. I haven't run into any performance issues
whatsoever, and all the major graphics-capable interpreters seem to
work well, but that doesn't mean that the code is as minimal as it
could be.
Oh, the extension requires both Simple Graphical Window (Emily Short)
and Fixed Point Maths (Michael Callaghan).
Thanks!
--Erik
Emily Short
> Hi all,
>
> I'm looking for someone who'd be willing to beta-test a new extension
> I've worked up to manage complex sprite-based graphical displays
> (Glulx-only, obviously). It's designed to be useful in the
> construction of gradually revealed or otherwise dynamic maps, visual
> puzzles, games such as poker or tic-tac-toe, and visual scenes and
> narratives. I've used it to construct a couple of map-based examples,
> one of which can be downloaded here:
>
>
> Shoot me an email if you'd can help put the extension through some
> more testing, or just download the extension, I guess:
>
> http://dl.getdropbox.com/u/947038/Simple%20Scaled%20Sprites.i7x
I probably won't have time to do much with this right away, but I
wanted to say the gblorb looks really nice -- a very crisp
presentation.
carma...@googlemail.com
Unfortunately it crashes when I try to open it in Spatterlight - a Mac
interpreter. I have heard that Spatterlight is more lax when it comes
to the Glk implementation, so it might not be a problem with your
code; but unfortunately, it seems that Spatterlight is no longer being
developed.
Erik Temple
> I probably won't have time to do much with this right away, but I
> wanted to say the gblorb looks really nice -- a very crisp
> presentation.
Great, thanks for taking a look! Re Spatterlight, are you using the
latest version (0.50)? The example gblorb works fine for me in
Spatterlight under Mac OS 10.5.6 (Intel). Here's hoping that it's a
version or platform issue.
--Erik
Erik Temple
of the example, so here's a link to the source text and image files:
http://dl.getdropbox.com/u/947038/Example%20source%20and%20images.zip
stuffisthings
> Hi all,
>
> I'm looking for someone who'd be willing to beta-test a new extension
> I've worked up to manage complex sprite-based graphical displays
> (Glulx-only, obviously). It's designed to be useful in the
> construction of gradually revealed or otherwise dynamic maps, visual
> puzzles, games such as poker or tic-tac-toe, and visual scenes and
> narratives. I've used it to construct a couple of map-based examples,
> one of which can be downloaded here:
>
>
> Shoot me an email if you'd can help put the extension through some
> more testing, or just download the extension, I guess:
>
> http://dl.getdropbox.com/u/947038/Simple%20Scaled%20Sprites.i7x
>
> In addition to any bugs, I'm particularly interested in suggestions
> for code optimization. I haven't run into any performance issues
> whatsoever, and all the major graphics-capable interpreters seem to
> work well, but that doesn't mean that the code is as minimal as it
> could be.
>
> Oh, the extension requires both Simple Graphical Window (Emily Short)
> and Fixed Point Maths (Michael Callaghan).
>
> Thanks!
>
> --Erik
VERY cool. I have a terrible time visualizing maps in games, so if
this kind of thing becomes more common I would be one happy player.
Also, I may be in the minority on this, but I think there is lots of
room in this world for parser-based IF where graphics are an integral
part of the gameplay rather than a "nice to have" additional feature.
At the very least it could add a lot to usability, for example, saving
you having to examine an elevator control panel 800 times. And it
would do away with a whole class of "puzzles" where the difficulty
comes largely from correctly visualizing the construction of some
strange machine based on the author's descriptions. I will definitely
be playing around with this, though I'm not sure how much help I will
be as a beta tester, since I have near-zero experience with I7 and
none at all with glulx-only advanced features...
aar...@gmail.com
I'm using Spatterlight 0.50 on a Mac and it works fine for me. I'm
guessing the poster doesn't have the newest version, since 0.5 is a
relatively recent update.
This looks really, really wonderful. I'm definitely going to play
around with it for a while... a couple of my percolating game ideas
would greatly benefit from this functionality. Thanks for making
this. :)
--Aaron
aar...@gmail.com
> I'm using Spatterlight 0.50 on a Mac and it works fine for me. I'm
> guessing the poster doesn't have the newest version, since 0.5 is a
> relatively recent update.
Although actually, there may be a problem with Spatterlight after all.
It looks from the documentation as if the image is supposed to be
automatically scaling, but in the example game at least, this isn't
happening for me. Screenshots:
http://www.aaronareed.net/if/screen-capture-1.jpg
http://www.aaronareed.net/if/screen-capture-2.jpg
--Aaron
Erik Temple
> Although actually, there may be a problem with Spatterlight after all.
> It looks from the documentation as if the image is supposed to be
> automatically scaling, but in the example game at least, this isn't
> happening for me. Screenshots:
>
> http://www.aaronareed.net/if/screen-capture-1.jpghttp://www.aaronareed.net/if/screen-capture-2.jpg
>
> --Aaron
No, it's working as it should. But maybe I should adjust the
documentatin, or even the name of the extension (Simple SCALED
Sprites). While the extension is very capable of scaling, the example
game doesn't scale; it only centers the image, and the player will
need to adjust the horizontal width of the window to fit. The reason
the example game doesn't scale is that I didn't design the tiles that
occlude the map to overlap, so the inaccuracies inherent in scaling
create visible seams between tiles. The lesson: if you design
something with close-fitting pieces, have them overlap one another at
the edges!
If you want to see the scaling in action, download the example source
and images and replace the final section (Display Elements chapter)
with:
[/]
The graphics window proportion is 50.
When play begins:
now the currently shown picture is Figure of House Plan;
change graphics background color to g-light-gray;
now the current graphics drawing rule is the sprite-background scaled-
centered display rule.
Table of Common Color Values (continued)
glulx color value assigned number
g-light-gray 14540253 [== $FFFBCC]
[\]
Now you can adjust the window size while you're playing and it will
scale. This works for me in Spatterlight.
I've thought about doing an extension that would require the player to
resize the window at startup until it reached the desired size, before
the game will begin. Actually, this could even be checked afterword
any time the window is resized below a certain set of dimensions. Any
thoughts on something like that?
Anyhow, I'm glad to hear this looks useful to folks.
Thanks for checking it out!
--Erik
P.S. Hell, I went ahead and uploaded a second, scaling gblorb.
Remember, folks, this one has unsightly seams!
http://dl.getdropbox.com/u/947038/Robner%20House_SCALING.gblorb
aar...@gmail.com
> On May 6, 7:29 pm, aar...@gmail.com wrote:
>
> > Although actually, there may be a problem with Spatterlight after all.
> > It looks from the documentation as if the image is supposed to be
> > automatically scaling, but in the example game at least, this isn't
> > happening for me. Screenshots:
>
Thanks for the clarification and the second example. :)
--Aaron
carma...@googlemail.com
> On May 6, 1:00 pm, Erik Temple <Ek.Tem...@gmail.com> wrote:
>
>
>
> > On May 6, 1:32 pm, Emily Short <emsh...@mindspring.com> wrote:
>
> > > I probably won't have time to do much with this right away, but I
> > > wanted to say the gblorb looks really nice -- a very crisp
> > > presentation.
>
> > On May 6, 1:39 pm, carmafer...@googlemail.com wrote:
>
> > > It sounds great, and the example is very, very impressive.
> > > Unfortunately it crashes when I try to open it in Spatterlight - a Mac
> > > interpreter. I have heard that Spatterlight is more lax when it comes
> > > to the Glk implementation, so it might not be a problem with your
> > > code; but unfortunately, it seems that Spatterlight is no longer being
> > > developed.
>
> > Great, thanks for taking a look! Re Spatterlight, are you using the
> > latest version (0.50)? The example gblorb works fine for me in
> > Spatterlight under Mac OS 10.5.6 (Intel). Here's hoping that it's a
> > version or platform issue.
>
> > --Erik
>
> I'm using Spatterlight 0.50 on a Mac and it works fine for me. I'm
> guessing the poster doesn't have the newest version, since 0.5 is a
> relatively recent update.
Oh, thanks for pointing out the new version. Yes, it seems it was only
a problem with version 0.4.9.
Jon Ingold
> I'm looking for someone who'd be willing to beta-test a new extension
> I've worked up to manage complex sprite-based graphical displays
> (Glulx-only, obviously). It's designed to be useful in the
> construction of gradually revealed or otherwise dynamic maps, visual
> puzzles, games such as poker or tic-tac-toe, and visual scenes and
> narratives.
This is absolutely wonderful.
jon
Erik Temple
but I'll ask it anyway. Sorry, it will take a bit to get to the actual
question...
I now have a working prototype of hyperlinking functionality built on
top of the sprite extension (cannibalized from Jeff Sheets' Graphic
Links). Basically, the author sets a given sprite as graphlink-active
and indicates what parser command a click will produce, and the sprite
management framework takes care of the rest (determining whether the
sprite is onscreen, automatically centering/scaling the hot zone along
with the sprite image, etc.). I think it's swell.
Philosophically, I'd like to provide this hyperlinking functionality
as a separate extension that would extend the basic sprite extension--
some people are going to want the ability to create hyperlinked
graphics, others aren't. However, much of the information needed to
create graphlinks is currently exposed only as local variables within
the sprite-drawing routines of the main Simple Scaled Sprites
extension. Basically, a number of properties (the x,y of the sprite
plus an individualized scaling factor--each sprite can be individually
scaled) are exposed to the author. From these "global" variables
(properties of the sprite object), local variables within the draw
routine are used to calculate the scaled coordinates and dimensions of
the sprite for the glk_draw_scaled call. My impression is that this
saves on overhead, especially since the derived calculations will
change anytime the screen is resized.
The problem is, I need those same local variables to set up the
hyperlink's bounding box. Right now, I'm using a modified drawing
routine that sets up each graphic hyperlink immediately after the
sprite is drawn, within the same drawing rule. Again, this seems the
most efficient way to do things to me.
So, my question: Is there a way to write some kind of hook into the
basic sprites extension that would let the sprite hyperlink extension
use the variables? In pseudocode, I'm imagining something like this:
...
draw current sprite at coordinates x-coord and y-coord with dimensions
x-dim and y-dim;
if the Sprite-Hyperlinks extension is installed:
set hyperlink with ID current sprite from x-coord by y-coord to
(x-coord + x-dim) by (y-coord + y-dim).
I'm afraid that this way of doing it is basically a feature request,
and I'm definitely open to other ways of doing it...
Another, unrelated question: is there a way (dropping into I6
perhaps?) to delete all of the rows in a table without repeating
through it and removing them one by one? This would basically the
equivalent of the soon-to-be-implemented "empty" command for lists...
I ask for elegance's sake more than anything.
Thanks,
Erik
JDC
> So, my question: Is there a way to write some kind of hook into the
> basic sprites extension that would let the sprite hyperlink extension
> use the variables? In pseudocode, I'm imagining something like this:
>
> ...
> draw current sprite at coordinates x-coord and y-coord with dimensions
> x-dim and y-dim;
> if the Sprite-Hyperlinks extension is installed:
> set hyperlink with ID current sprite from x-coord by y-coord to
> (x-coord + x-dim) by (y-coord + y-dim).
>
> I'm afraid that this way of doing it is basically a feature request,
> and I'm definitely open to other ways of doing it...
I think you should be able to do this with use options (there's a
chapter on this in the documentation). Create a use option in the
sprties extension ("hyperlinked sprites", say). Then have your
hyperlink extension include the command "Use hyperlinked sprites."
Your code in the sprite extension could then test for the activation
of this use option, e.g.:
draw current sprite at coordinates x-coord and y-coord with
dimensions x-dim and y-dim;
if using the hyperlinked sprites option:
set hyperlink with ID current sprite from x-coord by y-
coord to (x-coord + x-dim) by (y-coord + y-dim).
(My syntax may be a bit off; haven't had much time with Inform
lately). You could alternately roll the hyperlink extension code into
the sprites code as well this way, only activating hyperlinks if the
use option is set (I guess this depends on whether or not there is any
use to the hyperlinks part independent of the sprites).
-JDC
Erik Temple
Thanks! Honestly, that sounds like something I should have thought of,
but I guess I had the thinking-inside-the-box idea that use options
get called from the project's source text, not from another extension.
Anyway, this is how I'll set it up.
(And no, the hyperlinks wouldn't be useful without the sprites, which
is why I didn't want to include them in the sprites extension. I
guess, though, that there's no reason to worry about overhead in a
Glulx project...)
--Erik
JDC
It just occurred to me that you can also mark sections as "for use
with/without (a given extension)", so you could have two sections, one
for use with hyperlinks, one without, where you give different
definitions of the relevant phrases. Maybe a bit more effort, though,
if there are just a couple of changes between the two.
-JDC
Erik Temple
> I think you should be able to do this with use options (there's a
> chapter on this in the documentation). Create a use option in the
> sprties extension ("hyperlinked sprites", say). Then have your
> hyperlink extension include the command "Use hyperlinked sprites."
> Your code in the sprite extension could then test for the activation
> of this use option, e.g.:
Actually, I don't think this will work after all. The phrase for
setting graphlinks would be defined in the hyperlinks extension, and
so, use option or no use option, the main sprites extension wouldn't
compile without the hyperlinks extension being installed. Or is there
something special about use options, so that code "protected" by them
bypasses compile-time checks?
I guess I'll just roll the two extensions into one after all. I
suppose it'll be less work for the extensions librarian, anyway!
--Erik
Erik Temple
> It just occurred to me that you can also mark sections as "for use
> with/without (a given extension)", so you could have two sections, one
> for use with hyperlinks, one without, where you give different
> definitions of the relevant phrases. Maybe a bit more effort, though,
> if there are just a couple of changes between the two.
>
> -JDC
Interesting, I didn't know about this. It would be a bit repetitive,
since the hyperlink setting is really just tacked onto the end of a
sequence of calculations that otherwise terminates in the call to a
draw function (basically exactly as in the pseudocode I posted before,
only I left out the calculations). Still, I think it would work, since
obviously the compiler should simply ignore everything within the "for
use with the Hyperlinked Sprites extension" section.
Thanks! I'll think about whether I prefer the repetition of longish
blocks of code to simply wrapping both extensions into one...
--Erik
Erik Temple
built-in hyperlinking extensions, courtesy of code cannibalized from
Jeff Sheets' Graphic Links extension. I've also changed the name of
the extension, to "Graphical Window Sprites." A new download, sans
documentation of the hyperlink capability, can be found here:
http://dl.getdropbox.com/u/947038/Graphical%20Window%20Sprites.i7x
And a new version of the Robner House example, where clicking on doors
opens and closes them, and clicking on the player's icon takes
inventory:
http://dl.getdropbox.com/u/947038/Robner%20House_HYPERLINKS.gblorb
If no bug reports or requests for new features turn up in the next
week or so, I'll submit the extension to the librarian.
Thanks for the help and encouragement!
--Erik
Erik Temple
...And here's a link to the updated source and the images for the
example:
http://dl.getdropbox.com/u/947038/Example%20source%20and%20images.zip
--Erik