So although I have been able to get quixe working with channel IO, the glk implementation is tightly-coupled to quixe, which leaves something to be desired. I’ll work with what I have, but because I’m passionate about having a clean build of Glulx without Glk, I’ve engaged an Elance developer to port FyreVM to TypeScript. I actually found a developer that’s interested in IF, so he’s doing this at a significantly reduced rate.
The resulting project has already started and will be hosted on Github at: github.com/thiloplanz/glulx-typescript
It will be public domain, CC:0 license.
Phase 1 is the VM and Channel IO and include unit tests.
Phase 2 is a reference application in Firefox with possible React and/or Angular 2.0 implementations.
Should be ready by end of July.
So yeah, porting the general C# will be easy. The hard part will be porting orthogonal aspects, which I don’t think TS supports.
But it will be more readable than plain JS, at least to someone used to Java or C# or any other OO language.
I have written up my notes on decoupling:
github.com/erkyrath/quixe/wiki/ … out-GlkOte
Not sure if anyone is following along or is interested in VM works, but the development of glulx-typescript is moving along. It’s interesting to me at least.
So Thilo is at the point with gulx-typescript where it’s usable, but buggy. The veneer routines for performance are not implemented yet either. He’s opened up the Issues on Github and we’d appreciate it if you grab a ulx game (doesn’t have to be fyrevm) and test it.
You’ll need to install typescript (and nodeunit of you want to run the unit tests).
node test/node/runGameImage.js yourgamefile.ulx
Report bugs as you see fit.
The Angular2 example web project is up and running. Any game played in it requires the latest FyreVM Core extension found in my fyrevm-web repo on github.
Performance with Shadow is less than optimal, but we’re improving things.
It currently does not implement any veneer routines.
Is it worth trying to support that as a second VM? is that code up somewhere?
I can dig around later, but it’s not in my Github repo anymore. Frankly that code is just too complex for anyone to spend time rewiring. I consider that effort a failure.
Just to add…I’m putting my efforts into a straight fyrevm_web implementation. The IO layer is strictly channels (key/value pairs) on a turn by turn basis. I’ve been able to layer on excellent JS support through descriptive I7 extensions and automated parsing in the browser so that all of the channel data ends up in a global fyrevm object (with readable properties).
When I get back to this, next steps are:
- add the same optimizations that quixe enjoys (I’m still trying to cajole Thilo to do this work)
- build standard template
- build alternate template with paging mechanisms
- build desktop interpreters for windows, mac, linux
- build CMS for designing template
- build site for hosted CMS and stories
A looong way to go…
If quixe performs significantly faster it might be easier to just add FyreVM’s opcodes to Quixe.
I went down that road and that’s the part I consider a failure. The quixe code is too intertwined with the “intent” of using glk as an IO paradigm and, well, I wanted TypeScript classes for the VM. The optimizations done in Quixe can be done in fyrevm, and Thilo has said he will get to it, but it’s just a lagging effort. Even so, it’s not absolutely necessary to have those optimizations right now. fyrevm_web works very well for small stories and probably is capable of handling medium and large stories that don’t implement performance-intensive I7 constructs.
The short term goals are to build out the platform to be useful. If people actually start adopting it, then the optimizations will happen.