Hi folks,
I’m currently trying to port Dumb Frotz into C++, so I can use it with Unity, but to be honest this is a little above my skill level and I’m having trouble finding the relevant parts of the code, specifically where text input and output are handled. Does anyone know if it is possible to separate the input/output from the console and put them into functions I can call externally?
Thank you!
3 Likes
People often run the interpreter in a separate process. If you’re trying to do it all in one binary then a Glk based interpreter might be more straightforward. Really depends on what you’re trying to do, and what technical restrictions you have.
2 Likes
Not to discourage you from porting Frotz, but it may be easier to use Bocfel, as it’s already written in C++. By default it builds in a manner similar to Dumb Frotz, in that it only uses standard I/O routines for input and output. It assumes Unix with Curses by default, but if you do:
make PLATFORM=
it’ll assume nothing about the target platform and will work with any C++14 environment.
But that assumes Unity can attach to stdin/stdout of a process. If you need something a bit more structured, I’d say there are a couple of options (if you go this route):
- Modify Bocfel’s
io.cppcode and hook intostandard_in()andstandard_out(). In non-Glk mode, Bocfel uses these to communicate with the outside world. If you can use aFILE*handle for communication, then it’s not much work at all, as the IO system already understands those. - Use Glk. Something like remglk might be useful, depending on your needs, or you could take cheapglk and hack it to whatever ends you need.
Disclaimer: I’m the author of Bocfel.
5 Likes
I haven’t done this yet, but it would be very easy to add a function mode to RemGlk-rs, such that all IO would be transmitted simply through two functions (sending JSON as C buffers). For embedded interpreters that could be a simple API to handle, and would allow you to support a fuller interface than the “dumb”/“cheap” interpreters have.
2 Likes