Quixe beta-test
Andrew Plotkin
demoable version of Quixe, the pure-javascript Glulx interpreter.
http://eblong.com/zarf/glulx/quixe/
A few Glulx games are set up for play.
The big feature still missing is save and restore. (Undo works,
however.) You can type "save", and choose a save slot, and then type
"restore", and look through the saved games. However, restoring will
always fail. (The data that gets written to the slot is meaningless.)
Other unimplemented features: sound, graphics, stylehints. (Also line
input in grid windows, but I don't think any games use that.) There is
no iPhone/Android support.
It isn't all that fast. Reliques of Tolti-Aph, in particular, has a
miserably long startup time. There are some debugging lines and
assertions that will be trimmed out in the final release, and I
haven't implemented the Glulx acceleration opcodes. But you can assume
that anything which is slow now will be pretty slow in the future as
well.
To run any other Glulx game using Quixe, you'll have to convert it to
Javascript data by hand. (Sorry! I will eventually use Parchment's
tricks of loading data files directly, but that isn't in place yet.)
You'll need the zcode2js tool from the Parchment project. (Yes, even
though the tool is called "zcode2js" and not "glulx2js". Just use it.)
Run that on your .ulx or .gblorb file to generate a .js file. Put that
up on a web server, and then drop it into the "story=" part of the
URL.
Let me know how it works.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
George Oliver
>
> Let me know how it works.
I banged around on Rover's Day Out and it works well! Pretty quick on
chrome too (other than the start-up time, but that was bearable).
Since glulx games can read and write to files (for persisting state
between games in a series, say), where is Quixe at as far as supporting
the I7 file reading and writing capabilities?
Andrew Plotkin
Completely functional, as far as I know. I have a test for this
(http://eblong.com/zarf/glulx/externalfile.ulx), and Quixe passes it,
although it's not exciting to watch. You can even turn on transcript
mode, and the transcript will get written.
However, Quixe doesn't write to normal disk files -- the browser
doesn't have that capability. Instead, it records information using
the browser storage feature (localStorage). There's currently no way
to get that data out. I've been thinking I should add a little
file-browser, so that you can (e.g.) *see* that transcript after it's
written... but I've been concentrating on core functionality, for
obvious reasons.
Carlos Sánchez
I'm really interested in testing Quixe with Superglus games, so I will
do so this evening.
Also, maybe you are interested in trying the Superglus compatibility
test file:
http://www.superglus.com/doku.php/interpreter_programmers_help
It is basically a multimedia and timer test, that should be passed
without problems, but is good to know, and a good test for Quixe as
Superglus apparently uses some addressing modes Inform is never using.
Cheers.
Dannii
We need to have a chat about how to best integrate Quixe and Parchment
to minimise effort on both our parts.
In that regard it should now be possible to include Prototype without
conflicts (though I would still want to change GlkOte to use jQuery in
the future), and the Z-Machine specific code has been removed from
parchment.html. It shouldn't now take much more than writing a
launch_glulx() function I hope.
The bigger work will be unifying the UI (both HTML and storage) where
possible.
In other news, Typed Arrays <https://cvs.khronos.org/svn/repos/
registry/trunk/public/webgl/doc/spec/TypedArray-spec.html> will soon
be supported in a few browsers (not IE any time soon.) I am very much
looking forward to using it, it seems to be a wonderful spec.
Dannii
Also, have you profiled it yet? Do you know what is taking up so much
time?
Ben Collins-Sussman
to View->Developer->Developer Tools, and then choose 'timeline'. You
can hit the 'record' button and then load up a quixe game to see what
it's doing.
Erik Temple
> After a holiday-weekend's worth of pounding the punchcards, I have a
> demoable version of Quixe, the pure-javascript Glulx interpreter.
>
> http://eblong.com/zarf/glulx/quixe/
This is great. Congrats!
> Other unimplemented features: sound, graphics, stylehints. (Also line
> input in grid windows, but I don't think any games use that.)
I think you're right that no games use it, but last week I wrote an I7
extension that makes it easy to do; in fact, one of the examples
involves line input in a text-grid. Also, the new Flexible Windows
will allow easy char and hyperlink input in text-grids (e.g., "wait
for any key in my text grid window"). This doesn't mean that folks
will want to get input in text-grid windows--it's never been very
hard, yet no one seems to have felt the need in the past--but doing so
is now quite accessible to I7 authors. (There is still no I7-level
support for mouse input in text-grid windows.)
> It isn't all that fast. Reliques of Tolti-Aph, in particular, has a
> miserably long startup time. There are some debugging lines and
> assertions that will be trimmed out in the final release, and I
> haven't implemented the Glulx acceleration opcodes. But you can assume
> that anything which is slow now will be pretty slow in the future as
> well.
Testing a few moves in the I7 games on Safari: Load-up times are
pretty slow (I didn't notice that Reliques was any worse than Rover,
though), and while there is a noticeable delay between line input and
response, it is livable--less than 1/2 second, probably.
Also, during char input (e.g., the help menu in Rover's Day Out),
there is a blinking line input cursor visible on screen. I imagine
that this is simply a level of display detail you haven't got to yet,
but I thought I'd mention it.
Good work.
--Erik
Dannii
I was about to complain about Chrome's lack of linux support but it
seems its now supported! I use Firebug too, but didn't have it on that
computer.
Carlos Sánchez
Sorry, I didn't realize you said graphics and sound is not implemented
so obviously a multimedia test is worthless. Anyway, I have tried to
run the test file on Quixe and I have to say it works great so far:
http://eblong.com/zarf/glulx/quixe/demo/?story=http://www.caad.es/superglus/ficheros/EnglishTest.js
Graphics and sounds not working, and stylehints ignored, but all that
was expected. On the other hand is so good to see the game is running
without any single problem, even being created with Glulxa and not
with Inform. Great job!
Andrew Plotkin
> On May 31, 11:34�pm, Andrew Plotkin <erkyr...@eblong.com> wrote:
> > After a holiday-weekend's worth of pounding the punchcards, I have a
> > demoable version of Quixe, the pure-javascript Glulx interpreter.
> >
> > http://eblong.com/zarf/glulx/quixe/
>
> This is great. Congrats!
>
> > Other unimplemented features: sound, graphics, stylehints. (Also line
> > input in grid windows, but I don't think any games use that.)
>
> I think you're right that no games use it, but last week I wrote an I7
> extension that makes it easy to do; in fact, one of the examples
> involves line input in a text-grid.
Yeah, I'll get to it.
> Also, the new Flexible Windows
> will allow easy char and hyperlink input in text-grids (e.g., "wait
> for any key in my text grid window").
These work. You can test the former by typing "help" in Adventure; for
the latter, load WindowTest and type "open", "links".
> Also, during char input (e.g., the help menu in Rover's Day Out),
> there is a blinking line input cursor visible on screen.
I'd rather leave that, actually. It's a valid indicator of where the
input focus is. Z-code interpreters used to do this (or a blinking
square cursor) -- you'd see it in menus.
As to other questions: I have not done any profiling. As I said, there
are some trivial improvements I can make. Aside from those, the system
is already about as smart as I can make it. My two cleverest ideas for
*non*-trivial improvements are:
- Keep the memory map as an array of words, rather than an array of
bytes. This would speed up aligned word access, but slow down
everything else. I don't know whether it would be an improvement in
practice.
- Make the JIT compilation smart enough to recognize loops and
branches, and compile them as loops and branches. (Right now every
code-path, beginning and ending at a loop-or-branch point, is a
separate function.) This is harder than it sounds, because Javascript
doesn't have "goto" and I6 does.
(Yes, I tested the switch-in-loop pattern for faking "goto"! It didn't
seem to be faster than what I'm doing now.)
Andrew Plotkin
>
> We need to have a chat about how to best integrate Quixe and Parchment
> to minimise effort on both our parts.
Yyyeah, but this may still be a ways off. The next-mile goal is
getting a package that can be dropped into I7.
> In that regard it should now be possible to include Prototype without
> conflicts (though I would still want to change GlkOte to use jQuery in
> the future)
Agreed.
> The bigger work will be unifying the UI (both HTML and storage) where
> possible.
Right. My HTML structure is pretty specific, and doesn't resemble
yours at all.
The storage part is a separate library:
<http://eblong.com/zarf/glulx/quixe/demo/dialog.js>
This handles both the dialog box and the localStorage access. It isn't
Quixe or GlkOte specific, and you could drop it into Parchment --
except that it's Prototype-based too.
Jim Aikin
One question that maybe nobody has asked yet ... how is it pronounced?
Is that "keesh" or "quick-see" or "keekz" or "kwish", or perhaps
"Raymond luxury-yacht"?
--JA
Mike Tarbert
It's obviously "Raymond luxury-yacht" -- except the "Y's" are silent.
Skinny Mike
vaporware
My guess is "key-hay".
vw
Matt Weiner
> Fantastic work, Zarf! I haven't looked at it yet, but I'm heartened.
>
Seconded -- this is very exciting.
mw
Michael Neal Tenuis
"Throatwobbler Mangrove", of course!
Wei-ju Wu
great job ! Actually I thought that the speed on Chrome/Mac OS X is
quite ok (knowing what amount of instructions ROTA throws out at the
start, do I remember correctly seeing a JIT in the Quixe code ?), most
modern web browsers have pretty good Javascript implementations
nowadays.
Wei-ju
Andrew Plotkin
>
> great job ! Actually I thought that the speed on Chrome/Mac OS X is
> quite ok (knowing what amount of instructions ROTA throws out at the
> start, do I remember correctly seeing a JIT in the Quixe code ?)
Yes, it compiles opcode sequences into Javascript functions and then
caches them.
> most modern web browsers have pretty good Javascript implementations
> nowadays.
Browsers are good and getting better, but we're also seeing more and
more low-power devices used for web browsing. I also worry about RAM
consumption; I wind up with a *lot* of cached compiled functions. (I
haven't actually measured how many, but, well, a lot.)
vaporware
> Here, Wei-ju Wu <weiju...@gmail.com> wrote:
>
>
>
> > great job ! Actually I thought that the speed on Chrome/Mac OS X is
> > quite ok (knowing what amount of instructions ROTA throws out at the
> > start, do I remember correctly seeing a JIT in the Quixe code ?)
>
> Yes, it compiles opcode sequences into Javascript functions and then
> caches them.
>
> > most modern web browsers have pretty good Javascript implementations
> > nowadays.
>
> Browsers are good and getting better, but we're also seeing more and
> more low-power devices used for web browsing. I also worry about RAM
> consumption; I wind up with a *lot* of cached compiled functions. (I
> haven't actually measured how many, but, well, a lot.)
I had that concern with ZLR as well (which is one reason why Guncho
now uses FyreVM). My suspicion was that a lot of the RAM usage was
from overlapping fragments, which could be combined with a smarter
JIT, but I didn't collect any real statistics on it.
vw
Adam Thornton
My WIP plays adequately--although I can't make the damn thing load any
games in IE8, but I've only tried from work, so it might be a work-ish
setting thing. I'll try eventually from home when I feel like firing up
Windows.
There's a noticeable pause between commands, and running a test script
is very slow indeed.
Chrome is faster than Safari is faster than Firefox, it feels like, on
Mac and (for Chrome and Firefox) Linux and Windows.
My WIP is a Big Damn Game, so it's really pretty impressive.
Adam
Dannii
> In article <hu22li$kf...@reader1.panix.com>,
> Andrew Plotkin <erkyr...@eblong.com> wrote:
>
> >Let me know how it works.
>
> My WIP plays adequately--although I can't make the damn thing load any
> games in IE8, but I've only tried from work, so it might be a work-ish
> setting thing. I'll try eventually from home when I feel like firing up
> Windows.
>
> There's a noticeable pause between commands, and running a test script
> is very slow indeed.
>
> Chrome is faster than Safari is faster than Firefox, it feels like, on
> Mac and (for Chrome and Firefox) Linux and Windows.
>
> My WIP is a Big Damn Game, so it's really pretty impressive.
>
> Adam
Quixe won't work in IE as it needs window.atob().
Dannii
There are some memory profiling browser plugins now, which would help
us to at least find out what's going on. Adding a tracer and GC
wouldn't be too infeasible either.
Andrew Plotkin
Whoops -- I will add the replacement implementation that Parchment
uses. Not tonight, though.
Adam Thornton
Dannii <curiou...@gmail.com> wrote:
>On Jun 2, 9:03=A0am, a...@fileserver.fsf.net (Adam Thornton) wrote:
>> In article <hu22li$kf...@reader1.panix.com>,
>> >Let me know how it works.
>> My WIP plays adequately--although I can't make the damn thing load any
>> games in IE8, but I've only tried from work, so it might be a work-ish
>p
>> Windows.
>Quixe won't work in IE as it needs window.atob().
Are there any plans to work around this?
I mean, I'm not exactly a Microsoft fanboy, but IE *is* a fairly popular
browser....
Adam
Adam Thornton
Andrew Plotkin
> In article <88641dba-e183-408b...@11g2000prv.googlegroups.com>,
> Dannii <curiou...@gmail.com> wrote:
>
> >Quixe won't work in IE as it needs window.atob().
>
> Are there any plans to work around this?
I put in the workaround. Reload and try it again.
Carlos Sánchez
I posted about Quixe beta in spanish forums and some people started
checking it. Apparently your examples work most of the times, but some
people report that their browsers remain on the state of "loading"
forever. I've been trying to determine if there is some browser
failing and some not, but I don't see any relation: apparently the
same browser who works for some user fails for others. In general,
I've seen they are testing with many different brosers (Firefox,
Safari, Chrome and Opera at least) and same browser can fail on some
computers.
One user also tried an spanish game made with I7, and people say they
have same problem: some people report the game never finished loading.
This is the link to the game itself:
It is not an IE problem, those who tried with IE got the known error,
obviously.
Hope this helps.
i-k
>
> I posted about Quixe beta in spanish forums and some people started
> checking it. Apparently your examples work most of the times, but some
> people report that their browsers remain on the state of "loading"
> forever. I've been trying to determine if there is some browser
> failing and some not, but I don't see any relation: apparently the
> same browser who works for some user fails for others. In general,
> I've seen they are testing with many different brosers (Firefox,
> Safari, Chrome and Opera at least) and same browser can fail on some
> computers.
>
Same here:
I tried loading with Opera/IE/Chrome/Firefox, none work for me.
Question of OS?
I currently have access only to Windows XP, so I wasn't able to
experiment.
A quick glance at debuggers: with all browsers, the problematic bits
(at least for me) seem to be:
- undefined variable TriggerLoadGameFile
- unexpected token 'var' at line 129
I'm no JavaScript expert, so whether this helps or not, can't say.
- i-k
Matt Weiner
> Hi again,
>
> I posted about Quixe beta in spanish forums and some people started
> checking it. Apparently your examples work most of the times, but some
> people report that their browsers remain on the state of "loading"
> forever. I've been trying to determine if there is some browser
> failing and some not, but I don't see any relation: apparently the
> same browser who works for some user fails for others. In general,
> I've seen they are testing with many different brosers (Firefox,
> Safari, Chrome and Opera at least) and same browser can fail on some
> computers.
>
For what it's worth, when I tried "Reliques of Tolti-Aph" (before the
latest patch was released) I got two or three "unresponsive script
on this page" error messages before it finally loaded. I think this
was just due to its long loading time. (The annoying thing was
that I had fired it up to check Quixe's undo depth, and you can't
undo in "Reliques.") I didn't have this problem with "Rover's Day
Out."
If it's not too soon for a feature request, maybe the preloader
could show the percent of the game that's loaded? I don't know
how hard that would be to do.
Matt
Josh Lawrence
> Hi again,
>
> I posted about Quixe beta in spanish forums and some people started
> checking it. Apparently your examples work most of the times, but some
> people report that their browsers remain on the state of "loading"
> forever. I've been trying to determine if there is some browser
> failing and some not, but I don't see any relation: apparently the
> same browser who works for some user fails for others. In general,
> I've seen they are testing with many different brosers (Firefox,
> Safari, Chrome and Opera at least) and same browser can fail on some
> computers.
>
> One user also tried an spanish game made with I7, and people say they
> have same problem: some people report the game never finished loading.
> This is the link to the game itself:
>
>
> It is not an IE problem, those who tried with IE got the known error,
> obviously.
>
> Hope this helps.
I'm seeing this never-finishing-loading issue as well in my at home
testing. On OS X 10.6.3, in Safari 4.0.4, the games seem to load and
play fine, but in Chrome 5.0.375.55 and Firefox 3.5.9, the games hang
on the "Loading..." screen with the animated compass graphic.
Josh
Dannii
> Here, Adam Thornton <a...@fileserver.fsf.net> wrote:
>
> > In article <88641dba-e183-408b-befd-2238cd096...@11g2000prv.googlegroups.com>,
> > Dannii <curiousdan...@gmail.com> wrote:
>
> > >Quixe won't work in IE as it needs window.atob().
>
> > Are there any plans to work around this?
>
> I put in the workaround. Reload and try it again.
>
> --Z
>
> --
> "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
> *
There's a syntax error, check my Github comment.
Andrew Plotkin
>
> A quick glance at debuggers: with all browsers, the problematic bits
> (at least for me) seem to be:
> - undefined variable TriggerLoadGameFile
> - unexpected token 'var' at line 129
Whoops! Fixed now. (On my site, not yet in version control.)
Dannii
I've also forked and fixed this and more syntax errors.
http://github.com/curiousdannii/quixe/commit/170a290298d95ee28233ff737a10ef83292777d7
Also, anyone who's interested should get the quixe branch of
parchment, to try Parchment with Glulx support! It's not live, but you
can run it from your computer.
http://github.com/curiousdannii/parchment/archives/quixe
Andrew Plotkin
>
> One user also tried an spanish game made with I7, and people say they
> have same problem: some people report the game never finished loading.
> This is the link to the game itself:
>
> http://eblong.com/zarf/glulx/quixe/demo/?story=http://sites.google.com/site/sarganar/Home/output.ulx.js
It's something about the way http://sites.google.com/ does redirects.
You're not getting the encoded game data -- you're getting a redirect
page.
At least, that's what I see in Firefox 3.0.
I don't know whether this is a bug in my code, in my browser, or in
Google. But if you move the file to a different hosting site, it
should work.
Dannii
> Here, Carlos S nchez <csanche...@gmail.com> wrote:
>
>
>
> > One user also tried an spanish game made with I7, and people say they
> > have same problem: some people report the game never finished loading.
> > This is the link to the game itself:
>
>
> It's something about the wayhttp://sites.google.com/does redirects.
> You're not getting the encoded game data -- you're getting a redirect
> page.
>
> At least, that's what I see in Firefox 3.0.
>
> I don't know whether this is a bug in my code, in my browser, or in
> Google. But if you move the file to a different hosting site, it
> should work.
>
> --Z
>
> --
> "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
> *
I think Google is just not allowing hotlinking. That's a sad policy
for them to have.
sarganar
>
> It's something about the wayhttp://sites.google.com/does redirects.
> You're not getting the encoded game data -- you're getting a redirect
> page.
>
Moved to dropbox.
Now it seems that works fine (with Chrome, Firefox and Opera)
Thanx!
(and great job!).
Saludos!
Carlos Sánchez
> You're not getting the encoded game data -- you're getting a redirect
> page.
>
You are right, actually when I tested the Superglus test first it
failed just because of that, once I changed to a URL that was not a
redirection it worked, so it is for sure something related with the
redirects :)
i-k
And, behold, there was Glulx on my browser! (And it was good.)
Oh, very nice, indeed!
- i-k
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>Here, Adam Thornton <ad...@fileserver.fsf.net> wrote:
>> In article <88641dba-e183-408b...@11g2000prv.googlegroups.com>,
>> Dannii <curiou...@gmail.com> wrote:
>>
>> >Quixe won't work in IE as it needs window.atob().
>>
>> Are there any plans to work around this?
>
>I put in the workaround. Reload and try it again.
It started that time, but (possibly because I loaded windowtest.ulx
first) all input was in a little one-line window at the top, and
scrolling didn't work, even after I loaded a different game.
Adam
Andrew Plotkin
> In article <hu74kn$juc$1...@reader1.panix.com>,
> Andrew Plotkin <erky...@eblong.com> wrote:
> >Here, Adam Thornton <ad...@fileserver.fsf.net> wrote:
> >> In article <88641dba-e183-408b...@11g2000prv.googlegroups.com>,
> >> Dannii <curiou...@gmail.com> wrote:
> >>
> >> >Quixe won't work in IE as it needs window.atob().
> >>
> >> Are there any plans to work around this?
> >
> >I put in the workaround. Reload and try it again.
>
> It started that time, but (possibly because I loaded windowtest.ulx
> first) all input was in a little one-line window at the top, and
> scrolling didn't work, even after I loaded a different game.
Well, that's weird.
Do you have the same problem with the demo at
<http://eblong.com/zarf/glk/glkote/sample-demo.html>?
It's the same display code, albeit an earlier version.
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>Here, Adam Thornton <ad...@fileserver.fsf.net> wrote:
>> In article <hu74kn$juc$1...@reader1.panix.com>,
>> Andrew Plotkin <erky...@eblong.com> wrote:
>> >Here, Adam Thornton <ad...@fileserver.fsf.net> wrote:
>> >> In article
><88641dba-e183-408b...@11g2000prv.googlegroups.com>,
>> >> Dannii <curiou...@gmail.com> wrote:
>> >>
>> >> >Quixe won't work in IE as it needs window.atob().
>> >>
>> >> Are there any plans to work around this?
>> >
>> >I put in the workaround. Reload and try it again.
>>
>> It started that time, but (possibly because I loaded windowtest.ulx
>> first) all input was in a little one-line window at the top, and
>> scrolling didn't work, even after I loaded a different game.
>
>Well, that's weird.
>
>Do you have the same problem with the demo at
><http://eblong.com/zarf/glk/glkote/sample-demo.html>?
>It's the same display code, albeit an earlier version.
>
I'll try that next time I'm near IE. I did however replicate the
problem with the javascript hosted on both your site and mine, with
glulxercise and with my WIP.
Adam
Roger
interpreter developer or any such thing), I think it looks nifty,
Andrew.
As for the pronunciation of "Quixe" - I always thought of it as "KIX-
eee" in my head. Either that or "QUICKS." My third guess would have
been "Wooster."
Jim Aikin
> As for the pronunciation of "Quixe" - I always thought of it as "KIX-
> eee" in my head. Either that or "QUICKS." My third guess would have
> been "Wooster."
Get your Quixe ... on Route Suixety-Suixe.
Erik Temple
> Let me know how it works.
I have a test file for line input in a second (buffer) window that
fails to open in Safari, Firefox 3.6, and Chrome. In all of these
cases (and also when trying to open direct from the gblorb using
Danii's new quixotic parchment), the browser declares that a script
has become unresponsive. Unfortunately, I don't have any ideas about
why it might fail, as the same operations (line input, glk_set_window,
etc.) seem to work fine in the WindowTest demo; perhaps the issue is
more general?
A bit more info: Chrome's javascript console doesn't list any errors,
and it also indicates that the story file has loaded (after 1.02
seconds in my last attempt). Chrome's javascript log does list "###
accept_ui_event: init, gen 0" as having been called/reported by
glkapi.js. So it seems that Quixe becomes unresponsive just when the
game should have initialized, but before the loading gif is dismissed.
Link to the js-ified file:
http://eblong.com/zarf/glulx/quixe/demo/?story=http://dl.dropbox.com/u/947038/AW.gblorb.js
Original file for reference:
http://dl.dropbox.com/u/947038/Alternate%20Window%20Input.gblorb
On the plus side, text printed teletype style using the timer works
pretty nicely:
http://eblong.com/zarf/glulx/quixe/demo/?story=http://dl.dropbox.com/u/947038/Test.gblorb.js
(TURN IT ON)
--Erik
Andrew Plotkin
> On May 31, 11:34 pm, Andrew Plotkin <erkyr...@eblong.com> wrote:
>
> > Let me know how it works.
>
> I have a test file for line input in a second (buffer) window that
> fails to open in Safari, Firefox 3.6, and Chrome. In all of these
> cases (and also when trying to open direct from the gblorb using
> Danii's new quixotic parchment), the browser declares that a script
> has become unresponsive.
This also hangs (infinite loop) in Glulxe/GlkTerm. This doesn't
diagnose the problem, but it's not specifically in Quixe. Can you post
your source code?
> On the plus side, text printed teletype style using the timer works
> pretty nicely:
>
> http://eblong.com/zarf/glulx/quixe/demo/?story=http://dl.dropbox.com/u/947038/Test.gblorb.js
>
> (TURN IT ON)
Cute. Slow on my slow computer, though -- I'm getting between 3 and
3.5 characters per second.
Are you requesting and cancelling character input for each character
printed? I see an input cursor, which implies that you are. I bet it
wouldn't lag as much (on slow machines) if you only had timer events
requested, not character events.
Roger
> On May 31, 11:34 pm, Andrew Plotkin <erkyr...@eblong.com> wrote:
>
> > Let me know how it works.
>
> I have a test file for line input in a second (buffer) window that
> fails to open in Safari, Firefox 3.6, and Chrome. In all of these
> cases (and also when trying to open direct from the gblorb using
> Danii's new quixotic parchment), the browser declares that a script
> has become unresponsive. Unfortunately, I don't have any ideas about
> why it might fail, as the same operations (line input, glk_set_window,
> etc.) seem to work fine in the WindowTest demo; perhaps the issue is
> more general?
>
> A bit more info: Chrome's javascript console doesn't list any errors,
> and it also indicates that the story file has loaded (after 1.02
> seconds in my last attempt). Chrome's javascript log does list "###
> accept_ui_event: init, gen 0" as having been called/reported by
> glkapi.js. So it seems that Quixe becomes unresponsive just when the
> game should have initialized, but before the loading gif is dismissed.
> Link to the js-ified file:
>
>
> Original file for reference:http://dl.dropbox.com/u/947038/Alternate%20Window%20Input.gblorb
>
> On the plus side, text printed teletype style using the timer works
> pretty nicely:
>
>
> (TURN IT ON)
>
> --Erik
This is a complete tangent I guess (and sorry for that) but I feel
like this post was destined for me. I was just wondering yesterday if
something like this was possible through Gluxe (the teletype effect -
is that what it is called? Where the user can see the text typing on
his screen?) and I was going to make a thread asking, but lo and
behold you mention it here.
Is that something you concocted on your own, or is it something that
Gluxe or a Gluxe-compatible extension can do easily? I haven't really
delved into common special effects one can accomplish with Gluxe (as
opposed to z5/z8)...
Erik Temple
> Here, Erik Temple <ek.tem...@gmail.com> wrote:
>
> > On May 31, 11:34 pm, Andrew Plotkin <erkyr...@eblong.com> wrote:
>
> > > Let me know how it works.
>
> > I have a test file for line input in a second (buffer) window that
> > fails to open in Safari, Firefox 3.6, and Chrome. In all of these
> > cases (and also when trying to open direct from the gblorb using
> > Danii's new quixotic parchment), the browser declares that a script
> > has become unresponsive.
>
> This also hangs (infinite loop) in Glulxe/GlkTerm. This doesn't
> diagnose the problem, but it's not specifically in Quixe. Can you post
> your source code?
Interesting, since it works in all of the full-spec terps (WinGlulxe,
Zoom, Gargoyle, Spatterlight). Maybe I'm making some unsupported glk
call without checking gestalts, though looking at the code I can't see
what that could be. Anyway, here's the auto.inf:
http://dl.dropbox.com/u/947038/OnTheEdge.inf
And a new gblorb (I don't have the source for the original sample, but
this is a descendant that suffers from the same issue):
http://dl.dropbox.com/u/947038/OnTheEdge.gblorb
> > On the plus side, text printed teletype style using the timer works
> > pretty nicely:
>
> >http://eblong.com/zarf/glulx/quixe/demo/?story=http://dl.dropbox.com/...
>
> > (TURN IT ON)
>
> Cute. Slow on my slow computer, though -- I'm getting between 3 and
> 3.5 characters per second.
>
> Are you requesting and cancelling character input for each character
> printed? I see an input cursor, which implies that you are. I bet it
> wouldn't lag as much (on slow machines) if you only had timer events
> requested, not character events.
Thanks for the data point--on my machine (which is a couple of years
old), this runs just as fast as it does in Zoom. I'm using repurposed
code that allows the player to escape a timer loop with a keypress
(originally written for the folks who want to do timed delays between
output). That serves no function here, obviously. I'll remove it
before I release the extension.
Thanks!
Erik
Erik Temple
> Here, Erik Temple <ek.tem...@gmail.com> wrote:
> > pretty nicely:
>
>
> > (TURN IT ON)
>
> Cute. Slow on my slow computer, though -- I'm getting between 3 and
> 3.5 characters per second.
>
> Are you requesting and cancelling character input for each character
> printed? I see an input cursor, which implies that you are. I bet it
> wouldn't lag as much (on slow machines) if you only had timer events
> requested, not character events.
>
> --Z
Zarf or anyone else who found this slow: Could you try again and see
if the speed has improved? (The input requests have been removed.)
http://eblong.com/zarf/glulx/quixe/demo/?story=http://dl.dropbox.com/u/947038/Test2.gblorb.js
Compare with the earlier version if you like:
http://eblong.com/zarf/glulx/quixe/demo/?story=http://dl.dropbox.com/u/947038/Test.gblorb.js
Thanks!
Erik
Andrew Plotkin
> >
> > This also hangs (infinite loop) in Glulxe/GlkTerm. This doesn't
> > diagnose the problem, but it's not specifically in Quixe. Can you post
> > your source code?
>
> Interesting, since it works in all of the full-spec terps (WinGlulxe,
> Zoom, Gargoyle, Spatterlight). Maybe I'm making some unsupported glk
> call without checking gestalts, though looking at the code I can't see
> what that could be. Anyway, here's the auto.inf:
>
> http://dl.dropbox.com/u/947038/OnTheEdge.inf
I don't have a complete explanation, but I can see that (in GlkTerm)
it's stuck in a loop calling glk_window_open().
The call sequence is:
glk_window_open (splitwin=0x0, method=0, size=0, wintype=3, rock=201)
glk_window_open (splitwin=0x101e80, method=18, size=1, wintype=4, rock=202)
glk_window_open (splitwin=0x101e80, method=35, size=10, wintype=3, rock=210)
glk_window_open (splitwin=0x101e80, method=19, size=2, wintype=5, rock=220)
...(last call repeats)
Translating into named constants:
glk_window_open (<no windows yet>, 0, 0, wintype_TextBuffer, rock=201)
glk_window_open (<window>, winmethod_Fixed+winmethod_Above,
size=1, wintype_TextGrid, rock=202)
glk_window_open (<window>, winmethod_Proportional+winmethod_Below,
size=10, wintype_TextBuffer, rock=210)
glk_window_open (<window>, winmethod_Fixed+winmethod_Below,
size=2, wintype_Graphics, rock=220)
...(last call repeats)
The last one is obviously the joker. Neither GlkTerm nor Quixe
supports graphics windows. The call fails, returning zero. The game
obviously responds to that by trying again, and that's your loop.
Trawling through your code, I see bordered windows, and Jon's
extension seems to implement those borders by narrow graphics windows.
That's not going to work here. I don't know why he gets into a loop
when failing to create windows, though.
Erik Temple
Yes, it's pretty easy to do. I'm not sure how fast my implementation
is on slow machines--Zarf reported that it was quite slow, and I've
tweaked it, but haven't yet heard whether that helped.
Anyway, I've written an extension that lets you do this and other
timer-delay effects relatively easily. It hasn't been submitted to the
extensions library yet, but you can download it here:
http://dl.dropbox.com/u/947038/Real-Time%20Delays.i7x
By the way, the timer's performance varies from interpreter to
interpreter--Gargoyle's current pre-release builds have an extremely
responsive timer that can print text (at least on my machine) so fast
that it looks like it's being applied to the screen with a smooth
"wipe" effect (it can also print more slowly, of course). Zoom's timer
is fast, but not as fast as Gargoyle's. Interpreters that descend from
glulxe have a fairly low-resolution timer.
--Erik
Andrew Plotkin
> >
> > Are you requesting and cancelling character input for each character
> > printed? I see an input cursor, which implies that you are. I bet it
> > wouldn't lag as much (on slow machines) if you only had timer events
> > requested, not character events.
>
> if the speed has improved? (The input requests have been removed.)
No, no difference at all. I was totally wrong. Sorry!
(Sigh...)
I tried suppressing the log messages that are sent to the console on
each input event, but it turns out they weren't significant either.
This is an *old* computer (2001 G4, slightly under a megahertz) and I
believe Safari's Javascript engine isn't nearly as optimized on G4 as
on Intel. So, the best I can say is "probably not a problem for most
people". (Except that Quixe isn't up to mobile-webkit testing yet, so
no bets there.)
mwigdahl
According to one of the image files I found when searching for Quixe,
the pronunciation is "Cuish":
http://www.wigdahl.net/quern/wp-content/uploads/2010/06/3748568507_a855ed694a1.jpg
Matt
Roger
Excellent, thank you. I'm a big fan of Gargoyle, as interpreters go,
so I'll mess around with your extension it on there.
As for your demo - it seemed to run at a good speed on my machine, in
Firefox. It doesn't seem to want to load at all in Chrome though. It's
been "Loading..." for 4 minutes or so.
Dannii
That probably indicates a JS error. Can you check the error log?
Erik Temple
> glk_window_open (<window>, winmethod_Fixed+winmethod_Below,
> size=2, wintype_Graphics, rock=220)
> ...(last call repeats)
>
> The last one is obviously the joker. Neither GlkTerm nor Quixe
> supports graphics windows. The call fails, returning zero. The game
> obviously responds to that by trying again, and that's your loop.
>
> Trawling through your code, I see bordered windows, and Jon's
> extension seems to implement those borders by narrow graphics windows.
> That's not going to work here. I don't know why he gets into a loop
> when failing to create windows, though.
Ugh, I should have remembered that I was using a border window in that
example. Sorry for the goose chase.
The endless loop is caused by exactly the situation you suggest: when
Flexible Windows can't open a window, it assumes the situation is
temporary and keeps on trying. I've rebuilt using a patch that
prevents a graphics window from opening when unsupported, but it will
probably be better to warn authors to test for support themselves
whenever they open a graphics window (that way, they can set up
alternate window-chains if the graphics window has any descendants).
Anyway, here's the link to the functional Quixe dual-window I/O demo:
http://eblong.com/zarf/glulx/quixe/demo/?story=http://dl.dropbox.com/u/947038/OnTheEdge.gblorb.js
It works very nicely!
A quick final note: Parchment + Quixe (or at least the version Dannii
posted the other day) does not visually represent the second window,
but it does receive input, and the game responds appropriately. I
strongly suspect that this is due to the same CSS issue that prevents
the status line from appearing.
--Erik
Erik Temple
Dannii, I don't have any trouble opening this demo in Chrome (OS X)
using Quixe. However, I can't load any game at all in Chrome using
Parchment + Quixe. The javascript log doesn't throw any errors, but it
refuses to load any files after GlkOte.js.
--Erik
Erik Temple
> Here, Erik Temple <ek.tem...@gmail.com> wrote:
>
> > On Jun 5, 4:55 pm, Andrew Plotkin <erkyr...@eblong.com> wrote:
>
> > > Are you requesting and cancelling character input for each character
> > > printed? I see an input cursor, which implies that you are. I bet it
> > > wouldn't lag as much (on slow machines) if you only had timer events
> > > requested, not character events.
>
> > Zarf or anyone else who found this slow: Could you try again and see
> > if the speed has improved? (The input requests have been removed.)
>
> No, no difference at all. I was totally wrong. Sorry!
>
> (Sigh...)
>
> I tried suppressing the log messages that are sent to the console on
> each input event, but it turns out they weren't significant either.
>
> This is an *old* computer (2001 G4, slightly under a megahertz) and I
> believe Safari's Javascript engine isn't nearly as optimized on G4 as
> on Intel. So, the best I can say is "probably not a problem for most
> people". (Except that Quixe isn't up to mobile-webkit testing yet, so
> no bets there.)
Thanks. The way I'm doing the text animation is a bit more intensive
than it probably needs to be. Here's what happens for each character:
1) request a timer event;
2) while we await the event, repeatedly call glk_select and pass the
result to HandleGlkEvent;
3) when the timer event occurs, cancel it;
4) print the character;
5) repeat from step 1 until we've printed everything;
The reason for all this is that I could never get a routine within
HandleGlkEvent to actually print anything, so I manage the whole
process from outside of HandleGlkEvent; the timer event routine is
step 3 (it just sets a flag and cancels the current timer). Step 2 is
necessary because we need to prevent anything else (input or output)
from occurring while still allowing the timer event to fire.
The upshot is that, while there aren't any character input events
being requested and canceled, there are still a few events going on
that could result in the slowness you're seeing, particularly if
Safari doesn't handle javascript as quickly on a powerpc machine.
(Off topic: If anyone has any ideas about whether and how the
implementation could be improved, please feel free to comment. The
source code is here:
http://dl.dropbox.com/u/947038/Real-Time%20Delays.i7x
The demo posted is the second example in the extension.)
--Erik
Andrew Plotkin
> posted the other day) does not visually represent the second window,
> but it does receive input, and the game responds appropriately. I
> strongly suspect that this is due to the same CSS issue that prevents
> the status line from appearing.
Right. My current theory is that it's getting wrong results for its
size measurements. GlkOte tries to figure out your font sizes by
measuring some hidden objects, and then uses that information to set
window sizes (so that the status window can be exactly N lines high
including leading and padding, etc). If the measurements come back as
zero, you get zero-height windows.
Dannii
Found the problem... I hadn't included the inline styles you have in
index.html. I'll add them to glkote.js.
Carlos Sánchez
Superglus game, that I've played about a 50% of its length, without
any problem, all seems to work fine.
http://eblong.com/zarf/glulx/quixe/demo/?story=http://www.caad.es/superglus/ficheros/sidra.js
(Warning: js file is 13Mb long, it takes a bit to load, depending on
your bandwidth).
Chris Conroy
> After a holiday-weekend's worth of pounding the punchcards, I have a
> demoable version of Quixe, the pure-javascript Glulx interpreter.
Very cool! Minor, minor issue: After typing a command and pressing
Enter, the command text jumps one or two pixels to the left. (Firefox
3.6.3/Windows XP) Just enough to be slightly distracting if you're
apt to notice that sort of thing.
-CC
Andrew Plotkin
Yes, that's true. I'm not sure it's fixable in a general way. An input
field gets more padding than a text span, even if you set
margin/border/padding to zero.
I could shift the "Input" style right, but then it would match weirdly
with text in the middle of a paragraph. If anybody did that, which
they usually don't. Maybe it's the best solution, I dunno.
Dannii
That's really odd. I tried a bunch of things but couldn't remove it.
Do you have a timer that adds in input elements??? Because all of a
sudden there'd suddenly be two of them.
Andrew Plotkin
>
> Do you have a timer that adds in input elements??? Because all of a
> sudden there'd suddenly be two of them.
No, I don't have anything like that. I only see one input element.
The only timers are to do with resize events, and a tiny one for
calling input.focus(). (Because it was the only way to get focus
working right in IE.)