About GarGlk 0.7 and Windows Glulxe
Eliuk Blau
update the library of GarGlk Gargoyle to version 0.7.0.
Ben, taking advantage of changes you're doing, I would like to report
a couple of bugs that crawl a long time in Gargoyle, to see if you can
include corrections is this new version. =)
First of all, Ben: please, make that in Windows, the Gargoyle launcher
uses first the Glulxe interpreter, and not Git (as is right now),
because this last one doesn't work well in a lot of configurations
(actually it has a lot of problems with a Spanish system called
Superglus and with some configurations of the new version of Damusix
I6 [v3/0801104] to be used in the version of Damusix for Inform 7).
The first bug relates to the playback of Ogg Vorbis audio files. When
a file Vorbis has more than 2 minutes, Gargoyle takes a little while
to load. The delay is quite noticeable. If the file is longer than 4
minutes, the delay is very noticeable. More than 6 minutes produced an
annoying delay (and the interpreter was "stagnant" for a while).
This error apparently has no relation to the size in bytes of the
Vorbis file, but with the length of the sound. If you use the same
music in AIFF format (for example), with the same duration, then the
load is immediate.
Windows Glulxe not have this problem. And IF with background music did
not take anything to load.
Another bug: Ogg vorbis plays very fast in GarGlk when the bitrate is
too lower or samplerate is lower than 44.1khz.
----------------
The other bug occurs when you use the text style "reverse" in Glulx.
If more than one space followed in the text to be displayed, these
spaces (previous and final) are not shown in "reverse color." In
addition, the text alignment "centered" for the style
"style_Blockquote" is not working properly, and the texts are not
printing centered, but left aligned.
This prevents you can write a routine to "emulate" the style of
command Box as seen in the machine-Z.
To avoid showing these "non-reversed spaces" I discovered a trick that
is to print any character (eg one point) before and after the spaces
before and end, respectively. Example:
(# Represents the spaces, please note the dots)
.###Hello#World###.
With this trick, the spaces are displayed in the style "reverse"
correctly (but it is a "dirty trick").
Ben, please corrects these bugs that you have said, especially for the
Bug of the files Vorbis, which is very important for those designing
interactive fiction with multimedia content.
Thanks for your time and your work!
------------------------------------
This is for David Kinder. David, in Windows Glulxe when images are
drawn with climbing glk_draw_image_scaled(), the drawing is quite
slow, really.
I suppose that is for a scaling algorithm that you use (bilinear,
bicubic?). The fact is that in games that are "animated graphics" or
need to paint a picture many times, the delay in the drawing is very
noticeable. So much so that sometimes affects the execution speed of
the game.
At Gargoyle (GarGlk) scaling is quite fast, giving the possibility to
create complex graphics animations, "as in the following game:
http://www.caad.es/modulos.php?modulo=descarga&id=1414
(to view the animation, type "SALIR" when the game starts).
This animation works correctly in Gargoyle, but in Windows Glulxe
works very slow. Equally, I have programmed a library for Inform6 that
can display a nice graphical compass. To achieve this requires a
certain amount of paint pictures several times, and the result is a
bit slower on Windows Glulxe (in Gargoyle simply is not any delay).
Please improving the code scaling of images to work faster. =)
Thank you again for this request and you excellent work in Windows
Glulxe.
Thanks to both authors for reading this message.
Sorry for the bad English.
Greetings!
Eliuk Blau.
Emily Short
> I suppose that is for a scaling algorithm that you use (bilinear,
> bicubic?). The fact is that in games that are "animated graphics" or
> need to paint a picture many times, the delay in the drawing is very
> noticeable. So much so that sometimes affects the execution speed of
> the game.
...
> Please improving the code scaling of images to work faster. =)
It's possible that one might be able to speed up the existing
algorithm, but I kind of hope that David Kinder and other Glulx
maintainers do not change to a lower-quality scaling mechanism. A few
years ago it was the case that scaling on some Glulxe interpreters was
very simply done. Scaled images looked so bad on those systems that in
creating City of Secrets I had to provide a bunch of sizes of the same
images in order to pick the one most appropriate for the player's
screen size, so as to get away from scaling the pictures at all.
Having bicubic scaling (if that is what it is) reduces the burden on
the author and produces considerably better results for non-animated
images.
I hope there is a way to address this that speeds up the performance
of the algorithm that is already used, instead.
Andrew Plotkin
> On Nov 6, 3:13 am, Eliuk Blau <eliukb...@gmail.com> wrote:
>
> > I suppose that is for a scaling algorithm that you use (bilinear,
> > bicubic?). The fact is that in games that are "animated graphics" or
> > need to paint a picture many times, the delay in the drawing is very
> > noticeable. So much so that sometimes affects the execution speed of
> > the game.
> ...
> > Please improving the code scaling of images to work faster. =)
>
> It's possible that one might be able to speed up the existing
> algorithm, but I kind of hope that David Kinder and other Glulx
> maintainers do not change to a lower-quality scaling mechanism.
For what it's worth... (I need some kind of "whim of the figurehead"
tag for these pronouncements...) This Glk feature is about displaying
images. That's what it should do well. Using the image feature to
synthesize animation is a Neat Idea, but it's not the goal and it's
not worth compromising the goals to support it. A new animation
subsystem would be a better way of making animation work.
In other words, the author should be able to rely on scaled images
looking good, but he should not count on scaled images being fast
enough for this kind of animation.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Good job everybody.
David Kinder
> bicubic?). The fact is that in games that are "animated graphics" or
> need to paint a picture many times, the delay in the drawing is very
> noticeable. So much so that sometimes affects the execution speed of
> the game.
Hi Eliuk,
The scaling algorithm is bilinear, which shouldn't be too slow. I'm
reluctant to change the algorithm to one that scales less well, but I will
look into seeing if the implementation can be optimized.
By the way, the link you gave doesn't work: I get
Se ha producido un error
Fichero no encontrado
Si este error persiste puedes contactar con el administrador.
David
Ben Cressey
> uses first the Glulxe interpreter, and not Git (as is right now),
This may be related to the rather old version of Git bundled with
Gargoyle; it was 1.1.3 and the new release will include 1.2.1. I'm
reluctant to change the default since Git is generally regarded as the
faster of the two interpreters. I agree that it could be easier to
let the user choose which interpreter is used on Windows.
> The first bug relates to the playback of Ogg Vorbis audio files. When
> a file Vorbis has more than 2 minutes, Gargoyle takes a little while
> to load. The delay is quite noticeable. If the file is longer than 4
> minutes, the delay is very noticeable. More than 6 minutes produced an
> annoying delay (and the interpreter was "stagnant" for a while).
I've added a fix for this to the latest sources (but see below). It
could certainly stand some testing. I tried it with "A Martian
Odyssey" from IFComp 2008 and noticed a significant improvement
for .ogg playback.
> Another bug: Ogg vorbis plays very fast in GarGlk when the bitrate is
> too lower or samplerate is lower than 44.1khz.
The SDL mixer needs to be initialized with a specific output
frequency; 44.1 KHz is the current setting. Samples that do not
conform may not fare too well during the conversion process. Is it
too much to ask for all game sounds to use the same frequency? ;)
More seriously: the idea of replacing SDL has been floated on the
development list, but there aren't a huge number of open source, cross
platform audio libraries to choose from. That difficulty is
compounded by the deplorable state of audio drivers under Linux (or
Windows Vista, for that matter.)
> The other bug occurs when you use the text style "reverse" in Glulx.
> If more than one space followed in the text to be displayed, these
> spaces (previous and final) are not shown in "reverse color." In
> addition, the text alignment "centered" for the style
> "style_Blockquote" is not working properly, and the texts are not
> printing centered, but left aligned.
I'll see what I can do about this as well. I'd also encourage you to
use the issue form on the project site (http://code.google.com/p/
garglk/issues/list), as that is much more likely to get my attention.
Eliuk Blau
> It's possible that one might be able to speed up the existing
> algorithm, but I kind of hope that David Kinder and other Glulx
> maintainers do not change to a lower-quality scaling mechanism. A few
> years ago it was the case that scaling on some Glulxe interpreters was
> very simply done. Scaled images looked so bad on those systems that in
> creating City of Secrets I had to provide a bunch of sizes of the same
> images in order to pick the one most appropriate for the player's
> screen size, so as to get away from scaling the pictures at all.
> Having bicubic scaling (if that is what it is) reduces the burden on
> the author and produces considerably better results for non-animated
> images.
>
> I hope there is a way to address this that speeds up the performance
> of the algorithm that is already used, instead.
The GarGlk's algorithm for reescaled draw is aceptable. Not very good,
but aceptable and fast.
=D Saludos!
Eliuk Blau
Oh, I totally agree with you, Andrew. The fact is that even if they
are not used them (which I personally do not consider very important),
still remains very slow-drawn images of "great" that need to be drawn
many times.
For example, as I commented: my graphic compass. It is not an
animation, it's completely static, but needs at least 1 picture
painted by each cardinal point. At Gargoyle (GarGlk) is going very
well. But in Windows Glulxe will have significant delays in the
drawing.
The same goes for GWindows. If you build a UI more or less complex, if
it has a lot of graphics component, the delay in showing the UI will
also be noticeable. (And here I am again talking about IU without
animations.)
In Windows Glulxe non-scaled images are going very fast. But it is a
verifiable fact that the scaled images that are drawn have a slight
delay. And if this "delay" occurs many times (many scaled images) then
it becomes very noticeable.
If GarGlk is fast, Windows Glulxe should be no different. I guess. =)
Greetings!
Eliuk Blau
Hi David.
Thank you very much for addressing my request. I agree with you that
it is best to seek an "optimization" and not changing the algorithm
that gives very good results.
As I said, scaling images GarGlk is acceptable (but not excellent) and
fast (SDL?). Scaling Windows Image Glulxe is much much better,
excellent, but slower.
I copy the link again:
"Regreso al Edén" (5114 KB)
http://www.caad.es/modulos.php?modulo=descarga&id=1402
(at the start typing "SALIR" to see the animation. If you need more
evidence, I have a few files that can serve [and have no animation,
simply have "traditional" UI]).
Try this game with Windows Glulxe and Gargoyle-Glulxe and you will
notice the speed difference (for scaling).
Greetings!
And again, thank you very much. =)
Eliuk Blau
> This may be related to the rather old version of Git bundled with
> Gargoyle; it was 1.1.3 and the new release will include 1.2.1. I'm
> reluctant to change the default since Git is generally regarded as the
> faster of the two interpreters. I agree that it could be easier to
> let the user choose which interpreter is used on Windows.
Yes. It's faster. But please, permit the user choose which interpreter
is used on Windows. In Linux, in your new version of Gargoyle, Glulxe
is the default interpreter. But in Windows, there is no choice, that
is not "rename" the executable file (and that's a trick a little
dirty, truth =D).
> I've added a fix for this to the latest sources (but see below). It
> could certainly stand some testing. I tried it with "A Martian
> Odyssey" from IFComp 2008 and noticed a significant improvement
> for .ogg playback.
I will also try to test with Damusix and I will send you the comments
if I find something strange. Thank you very much for your work. =)
> The SDL mixer needs to be initialized with a specific output
> frequency; 44.1 KHz is the current setting. Samples that do not
> conform may not fare too well during the conversion process. Is it
> too much to ask for all game sounds to use the same frequency? ;)
>
> More seriously: the idea of replacing SDL has been floated on the
> development list, but there aren't a huge number of open source, cross
> platform audio libraries to choose from. That difficulty is
> compounded by the deplorable state of audio drivers under Linux (or
> Windows Vista, for that matter.)
Hahaha! =D I understand what you say. In any case, a friend asked me
to tell the samplerate bug. I agree with you that it is best that all
sounds use the same samplerate. In fact, I always use 44.1kHz
(apparently, not my friend, hehehe =P)
Thank you for your clarification. =)
> I'll see what I can do about this as well. I'd also encourage you to
> use the issue form on the project site (http://code.google.com/p/
> garglk/issues/list), as that is much more likely to get my attention.
Oh, sorry. Is that I do not understand much about these systems. The
next time I try to do as you suggest.
Thanks for everything.
Saludos!
Eliuk.
Eliuk Blau
> Gargoyle; it was 1.1.3 and the new release will include 1.2.1. I'm
> reluctant to change the default since Git is generally regarded as the
> faster of the two interpreters. I agree that it could be easier to
> let the user choose which interpreter is used on Windows.
I copy something I wrote in Emily's Blog (I regret not being able to
express myself better in English):
On the RAIF post that mentions Eric Eve, I wrote what I meant GIT of
Gargoyle, actually.
GIT 1.2.0 (Gargoyle) and Windows GIT 1.2.1 does not work well with the
new version of Damusix (v3/081104). This will be the version to be
used in the extension to Inform7.
Damusix v3 uses the Opcode “@protect” for a new feature that allows
“don’t restart the sounds that are playing in the background” if it
does UNDO/RESTORE. In GIT, this opcode is not fully implemented,
apparently. It produces totally unpredictable errors in the
interpreter. Sometimes it fails, other times not. Sometimes it does
not protect the memory area that follows... Other times the
interpreter crash (at least in the version of Gargoyle).
At least for now, GIT is not a good interpreter for the adventures of
Inform7 that could be used Damusix in the future.
[I am providing optionally a conditional compilation constant for not
using this new mechanism of Damusix, and then it works effectively in
GIT, but I really think that this should not be so ... =(]
I apologize if this comment seems very pretentious on my part. Only
attempt to comment the bugs I've found. =) Thanks for your time.
Saludos!
Eliuk.
David Kinder
> "Regreso al Edén" (5114 KB)
> http://www.caad.es/modulos.php?modulo=descarga&id=1402
Thanks, I've got the file now.
David
Erik Temple
> "Regreso al Edén" (5114 KB)http://www.caad.es/modulos.php?modulo=descarga&id=1402
>
> (at the start typing "SALIR" to see the animation. If you need more
> evidence, I have a few files that can serve [and have no animation,
> simply have "traditional" UI]).
Just a note from the Mac side: Regreso al Edén fails to load under
Zoom 1.1.2 (CocoaGlk version 1.0.4, Glulxe version 0.4.2), but works
fine under the newest Spatterlight. Zoom objects with the following
message:
"Glk Error: glk_window_close called with an invalid winid"
I don't know if this an error with the game file or the interpreter,
but it looks like the game file may contain a bug that other
interpreters besides Zoom are capable of ignoring. In any case, I've
let Andrew Hunter know, but it looks like the author might potentially
need to correct something as well. Anyway, the multimedia stuff in the
game is pretty slick--worth checking out!
--Erik
Eliuk Blau
It's a bug's gamefile. The author does not verify the existence of the
window and tries to close it involved no more.
This bug only manifests itself in interpreters who can not create
"true" type of windows. And it is a mistake of lack of foresight of
the author and not the interpreter.
In fact, it's excellent that the interpreter has warned that failure,
without falling into an irrecoverable CRASH.
Zoom is a good interpreter. =)
Saludos!
Eliuk.
Eliuk Blau
Say: who can not create all type of windows. Sorry.