Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

FYI: The processed code is big enough, that in my install at least, Unity outright stops rendering text beyond a certain point in the code editor because of how long the string is.  "String too long for TextMeshGenerator. Cutting off characters."  Still functions normally, far as I can tell - the rendering's just messed up.

I can't say as that I've been able to test it yet, something's going wrong in my install that's preventing the processor from ticking as it should (probably just at low clockspeeds, like Default Mode's) - will update this when I fix whatever's broken.

All that being said: whoa.  This is a super neat idea, and I'm curious to know what one could actually pull off with it.  Given the proclivity of programmers to occasionally do utterly insane things (see also: Senbir itself, this interpreter, etc), there are tools for compiling/processing code from other languages into BF code, like this C compiler.  Though it's in a roundabout way, this does officially mean it's possible to write things in higher-level (?) languages, like C, and then run them in Senbir.  Would an OS or game made in Senbir-BF be usable?  Not in Default mode, or even Extended - I cannot begin to comprehend how slow it'd be with the base clockspeed of 60Hz.  Would it be a fun experiment?  Hell yeah, it would be!

(Also, sorry about kinda disappearing on everyone - I'm still working on the next update, but been sidetracked by playing Warframe, and working on Astronaut Plus Skateboard as of the past few weeks.)

I've seen that too, actually, Unity not rendering all the text. And yes, as far as I could tell too, it still worked, even allowed editing, it just didn't render all of it. I'd guess it's not really built for text-heavy applications. (At least not without some end-programmer effort to do things like split the text up into more manageable chunks.)

I don't see it much, though, probably in part since I've taken to minifying my code before pasting it in - not so much because of this, but because it means I don't have to scroll so much after pasting it in. (It's pretty easy to do, even - I just have the preprocessor output open in my editor, and use its regex replace to remove all instances of \s*//.*$ before I copy what remains. I've been thinking of making the preprocessor do it, but haven't bothered yet - dunno if I will.)

In theory, one could pull off essentially anything (computation-wise anyway) with it. In practice, though - what someone actually manages to do - yeah, that's where the interest lies, indeed. :) (I'll probably not do much/anything with BF myself, as making the asm do what I want in the space I have is tricky enough, but I certainly don't mind if others do.)

I'll note that clockspeed isn't the only problem for this with the default mode, I'd think the disk space is a bigger problem. I haven't tried it, so I'm making assumptions here, but I figure that anything even semi-significant having been compiled down to BF is likely to be large - and there's not really much space available here.

Also, the output method this interpreter uses means that it's even more limited than usual in user interaction, so game-type stuff is rather limited by that. OS-type stuff similarly. The thing about Turing-completeness is that it only talks about computation - and a lot of what modern computers do isn't really about that, instead involving things like real-time user interaction. Sure, a program on a Turing-complete computer could simulate such user interaction - but then it wouldn't be actual user interaction, now would it?

Still, even with those limitations, there's quite a lot that is possible. All it needs is for someone crazy enough to actually do it to come along... :)

The disk space and low computation speeds are both major issues, especially for the Default mode (I think you've probably made a program as fancy as is possible with your text echoer), but would probably be easier to handle with, say, the stats I have set up for working on SenbOS.

One major way I see to potentially improve the ability to make fancy stuff (like OSes, games, etc), would be to replace the current IO stream's binary representation with one pixel on an 8-bit-color monitor.  You'd have to choose between an 8-bit RGB palette (with 3 bits of R & G and 2 B, or similar), or an 8-bit grayscale, BUT, the payoff would be that actual output would likely be faster, and you can actually draw on a pixel-by-pixel basis with relative ease - the main challenge becomes picking where the pixel actually gets drawn (e.g, where in the 1-dimensional array of currentPixels is the output pointer), and I'm not sure if there's a way TO pick that.  Need to poke through the interpreter code more.

If that is possible, then the main issue remaining is that getting mouse input is impossible, and as such your OS probably has to be either command-line, or you control the mouse cursor with arrow keys or something.  Also, no first person shooters, but that's kind of a given with the super-low processor speed :P