IBNIZ - A hardcore audiovisual VM | Hacker News Reader

IBNIZ - A hardcore audiovisual VM

countercomplex.blogspot.com

55 pointspaufernandez10 comments

A good demonstration of how stack architectures can produce stunningly concise code. I'm definitely going to poke around with the documentation and examples.

I have a Forth VM of my own[1] that also has graphical capabilities, but it's designed for creating NES/SNES style games from tiles and sprites- interesting to compare some of the design decisions. I notice that IBNIZ has support for handling keyboard and mouse input- I wonder how hard it would be to write some simple games for this VM?

[1]https://github.com/JohnEarnest/Mako

Have you taken a look at the Ngaro VM over at http://retroforth.org/docs/html/Implementations.html ?

Beautiful abstractions in Mako btw. I like it. Did you see the recent discussion on the VM used in http://en.wikipedia.org/wiki/Another_World_(video_game)

http://www.reddit.com/r/programming/comments/no0dy/another_w...

From what I can tell IBNIZ is meant as an ultra minimal target for demos. Not necessarily end user games. I think it is probably overly constrained. Much like a http://en.wikipedia.org/wiki/Lipogram

Thanks! I encountered Ngaro shortly after I started designing Mako. Aside from I/O functionality they are fairly similar, but I think storing the stacks and registers in addressable memory is a more flexible design than keeping them separate as Ngaro does. For one thing it means it's possible to remap the stacks at runtime and easily implement cooperative multitasking.[1] Games of the type I'm writing don't really need Ngaro's file I/O capabilities, but they could be very useful if I wanted to make a bootstrapped version of my Forth compiler.

Trying to recompile Ngaro bytecode to run on Mako could be an interesting weekend project...

[1] https://github.com/JohnEarnest/Mako/blob/master/examples/Thr...

Is making your own demo platform going to be the new hipster coder equivalent of rolling your own framework? I hope so. I like ibniz and mako- I like the ideas here. The javascript ibniz does some extremely silly things though that are hurting its performance by a significant amount. I've tinkered with it a bit and was able to squeeze a couple more FPS out of the rotozoomer, but the problem is really with the way the interpreter is structured- Evaluating a huge switch statement per pixel is not going to be very fast in javascript no matter what you do. I would perhaps consider instead compiling the ibniz script into a GLSL shader.

After tinkering with the source for a bit longer, I can see that it will be very difficult to make ibniz go fast because of an inherent inter-pixel dependency in the stack. The semantics of the language seem to imply that the pixel kernel can pass information on to the next pixel via the stack. To be able to split up the rendering work that dependency needs to be eliminated such that each pixel depends only on x,y,t- and values pushed by the last run are implicitly cleared in single thread implementations. What sort of impact will that have on existing demo programs?

The roto-zoomer example, so you can copy/paste into the javascript demo[1] (typing it in doesn't seem to work)(edit: later version which doesn't keep zooming out):

  v8rdsx.6+s4X3)Lx~2Xv*vv*+i!L1@2@^

I'll happily admit I have no f^@!in clue why it does what it does. Nifty, though.

[1]: http://ibniz.asiekierka.pl/ibniz.html

Copy-pasting what you have works, but I found that whenever I type 'v' in the Javascript version, it freezes up.

From the documentation, 'v' is supposed to rotate the top 3 items on the stack. If you're in TYX-video mode, there should be 3 items by default. The documentation also mentions that it's supposed to use T-video mode if it detects that, where there is only one item on the stack. Perhaps it's incorrectly detecting T-video mode and then running into problems when it tries to do the v-rotate past the end of the stack?

when the program parses the ibniz string, it seems to look for a character AFTER v. if v is the last character in the string, then when it does this , it gets undefined, attempts to get the char code for it, and thus throws an error since undefined isn't a string with a charCodeAt method. This is easily fixed by guarding that section of code to make sure that it always returns a string and never returns undefined.

Awesome. The aesthetics of this make me really wish I owned a hardware implementation I could plug into a busted old television.

Heh, I started watching the video and after about a minute of so was thinking "this sounds like COH" (aka Ivan Pavlov).

More to the point, this environment looks fun (for those of us that class our fun as being of the TV noise variety :) ).

Thanks for posting this!

Reply on news.ycombinator.com