This tells Inform to use temporary files (Inftemp1.tmp, Inftemp2.tmp) for storage while compiling, rather than stashing all data in RAM. This reduces the RAM usage of the compiler, at the cost of some speed.
This would only be important when compiling on really old machines. So this may be a question for only @KrocCamen . :)
(For comparison: when compiling a one-room z5 game with the 6/11 library, Inform allocates 851kb of memory normally; 785kb with the -F1 switch.)
If nobody is using this switch, it would simplify the compiler quite a bit to get rid of it.
My latest game Hibernated 1 Director’s Cut had been released for 25 classic platforms and modern PC. I am not compiling on old systems though for the sake of efficiency. I’ve created a set of automated build tools that goes from Inform 6 source to 25 ready to use disk images in under 5 seconds. That performance is absolutely priceless so even though I am a retro developer by heart, I likely won’t ever use the feature and I am fine with getting rid of it.
as I narrated in past, I used inform86 only once, then happily switched to inform386… (1995 or so, Inform 5.4 on a 386sx/20 with 4 Mb)
Best regards from Italy
ps. I still have around that zip, whose form a sort of “inform kit” for dos from a 1995 DOS PD/shareware CD,containing I5.4 DOS binaries, library 5/9, Curses and Busted, raif and rgif faqs, DM3 in .txt and .dvi format CoA in txt format , and is not in the Archive, (the only thing I know NOT in the archive is inform 5.4 DOS binaries; can be of interest uploading it to ifArchive ?
How big is the biggest storyfile? Even the cheapest computer, which is $10 Raspberry Pi ZeroW has 300 MB free memory. And it can use virtual memory, so no problem. Normal Raspberry Pi is 2GB. I have 4 GB model, and have yet to run out.
No problem with dropping intermediate file feature.
I was actually just thinking about building and developing on older systems as part of a retro experience. The trouble is that Inform 6’s “era” was the mid-90s, when we all had megabytes of RAM and more comfortable editors in the form of things like language-specific EMACS modes and vim scripts and such.
I’m sure there were people writing I6 on XT-class DOS machines (I vaguely remember installing it on a DR-DOS box I had in '94 and never getting around to learning it properly), but I don’t know if that’s the kind of retro experience people want to live in right now.
If there were a retro-dev experience to get people excited about, I’d hope it could be a “fantasy console” more like TIC-80/PICO8/etc where a live z-machine gives you an experience closer to Borogove in terms of interactive instant-feedback on a self-hosted system. But that would require compiling the compiler to I6, which would be charmingly Quixotic at best and would also require the modern memory capacity and processor speeds that the “fantasy console” movement have covered in pixelated drapery.
Oh yes, this will be shared soon. The only thing to consider is that it does make use of PunyInform and not the standard I6 library. Only PunyInform is able to perform well on all these classic systems as it has been created with the constraints of 8-bit systems in mind.
Speaking of features that were useful at the time, I remember it was quite a big deal when it became possible to use pre-compiled modules because it sped up compiling quite a bit. Is this still used for anything? I haven’t looked much at Inform for ages, but I get the impression that the Inform Library can no longer be pre-compiled.
Maybe this is a naive question, but couldn’t the process be independent of which language and/or library you use as long as result is a program that runs on a Z-machine?
I understand that if you use the standard I6 library the file will be to big for most 8-bit computers, but I have recollections of another small librariy for I6 (Tiny, or someting?). There is also ZILF that produces small and compact files for the Z-machine. It would be great if the process supported these too. (Please)
Yeah, in theory you could use any z-code file. The wrapper that has been used for the buildtools has an option to configure it with any Inform library, regardless whether it makes sense or not. To use something else (like ZILF) you’d have to alter the Bash file that comes with the buildtools and add the compilation parameters of the ZILF compiler to it but generally it is possible already. But I’d like to clarify here that my mission was creating a set of buildtools which I can use for my future projects and since I am using Puny exclusively and I likely won’t change that anytime soon, I won’t implement other compilers / features myself. But if someone throws in a ZILF bash script to go with the buildtools, I’ll happily accept that pull request. It really is about changing a single file and boom, magic.
Yes, your assumption is right. Generally about 90% of the targets run in z3 capable interpreters and a few (where the machine supports it and a corresponding interpreter is available) run in z5. Sometimes, I even chose a z3 compatible interpreter for the sake of compatibility. On the Amiga, I could have used Frotz to realize z5, but it only works with late Amigas so it would have ruled out early Amigas including the very popular Amiga 500. Instead I went for a special version of ZIP which runs on all Amigas. The Atari ST on the other hand does have a z5 interpreter, so has MS-DOS (Frotz). It really was a tedious job alone finding the best interpreter for each platform and then creating template disks and all that is necessary to have a fully automated process. The truth though is that if using the buildtools you are always bound to the smallest common denominator, at least when using all 25 targets, which is z3. For my recent release (Hibernated 1 Director’s Cut), the z5 versions are the same as the z3 versions (content wise) but also use the UNDO feature which is not available for z3. Anway, 128k will be your god if going that path.
On the Psion the RAM is shared as the main battery-backed RAM disk, so your 8 MB of RAM is both storage and runtime. Writing to temporary files in this instance makes no difference. Some devices have CompactFlash storage so memory could be saved this way but writes to CF require a burst of high voltage (reads don’t) making writing to CF very battery draining.
I would need a sufficiently large enough game to compile to test the memory usage on EPOC32. How do you get memory readings from the compiler?
We may have the biggest story file. We do not currently use this option… but maybe we might need to? Currently, compilation uses above 10 GB of RAM (screenshot attached). I have a machine with 128GB RAM so that I can compile all 7 versions of the game in parallel (since it takes 20+ minutes to compile).
I don’t know if I can say for sure that we would never want to use the temporary files! I’m scared we might one day hit the absolute limit for what Inform will allow us to compile using just RAM. We’ve already had to do some hacking to remove some arbritrary limits configured within the compiler.
Oh, wow! What games are you making? 10 GB seems excessive to me. Looks more like a big database project as opposed to story files.
Anyway, if you’re using a modern OS, it should have Virtual Memory system where RAM pages are stored on Hard Disk (or equivalent storage). Suggested ratio is 1:1, but I know some people who ran out of RAM, set up theirs as 1:4 ratio. It does slow things down a lot, but if you’re using SSD 3GB/sec, it should at least be acceptable.
