The game itself I love. But I have some issues with it's implementation.
To be specific, it maxes out the CPU even when it's not doing anything. Given that it's supposed to emulate low-level hardware, at very slow speeds, and does not have any demanding graphics, I fail to see why it should do that.
(It's something I've seen happening in more games as of late, actually. For example, Desktop Dungeons - a very fun game which has no business demanding anything from my computer since it's turn-based, uses sprites, and barely animated. And yet my laptop heats up as soon as I open the game.)
In fact, it's a bit ironic, given that the whole theme of the game is squeezing out performance out of bare metal hardware, and I admit that I'm more annoyed by it for that somewhat irrational reason.
IIRC TIS-100 is implemented using Unity, which doesn't really give you a lot of leeway as to when you update and render (e.g. you choose a framerate and it renders and updates your objects at that rate). Admittedly, since most of the time in TIS100 the screen does not change, if it were implemented using a custom engine this could be fixed.
For desktop dungeons, I'm not aware of the specifics about that game (though I have played it), but generally, if you're using OpenGL or DirectX to render, repainting only part of the screen isn't an option, so if anything is animated (no matter how slight the animation), you have to redraw the screen every frame. There are exceptions to this (like the mouse pointer, although this requires platform specific code), but not many of them.
This is common with games nowadays. Almost no one throttles the game loop outside of mobile I guess. I've had the same issue with the Analog/Hate _visual novel_ series. My laptop doesn't need to turn into a lapheater for some text....
It's still in early access, perhaps a bug report to the developer would be in order? It doesn't do this on my machine, so it might not be occurring for them.
To be fair the TIS-100 runs slower in the game to improve the visuals. To let you see (albeit in a blur at higher speeds) your code run rather than a click button, instant "level complete" popup. (note: I don't own TIS-100 yet, but it's fairly similar to their other game spacechem)
(Currently trapped in legal hell. I work for one of those annoying companies that claims ownership of everything I do, even in my personal time, so I have to get it cleared before I can push it to github...)
I added some extensions to allow one node to program another; the PROGRAM <dir> opcode resets the node in that direction, and it can then be fed a series of numbers which form the program. Once complete it starts executing.
With this, it ought to be possible to program an arbitrary network with programs from a boot ROM attached to a single node at the corner. It would have to propagate the distribution program through the network, which would then in turn propagate the program to the right place and reprogram each node in turn. Because a programmed node wouldn't contain the distribution program any more we'd have to start at the outer edge and work inwards.
I do wonder whether it would be possible to get real work done with this. I bet a node could be implemented in a tiny handful of FPGA gates.
I've been looking for a simple computer/CPU simulator for kids to play on. Something like this http://thlorenz.com/visulator/ is almost there but it's a bit too complex for elementary/middle school level kids to start on. A game would be even better but the one we're discussing here (TIS-100) is basically designed to confuse and challenge rather than illuminate. Suggestions and pointers are extremely welcome.
It doesn't have much in the way of a tutorial yet - this PDF might be a better place to grow your understanding of Assembly Language: http://www.drpaulcarter.com/pcasm/
Doubtful. Having only one usable register (plus another non-addressable "backup" register) places a (IMO) insurmountable constraint on running any multiuser unix-like kernel.
vanderZwan|10 years ago
To be specific, it maxes out the CPU even when it's not doing anything. Given that it's supposed to emulate low-level hardware, at very slow speeds, and does not have any demanding graphics, I fail to see why it should do that.
(It's something I've seen happening in more games as of late, actually. For example, Desktop Dungeons - a very fun game which has no business demanding anything from my computer since it's turn-based, uses sprites, and barely animated. And yet my laptop heats up as soon as I open the game.)
In fact, it's a bit ironic, given that the whole theme of the game is squeezing out performance out of bare metal hardware, and I admit that I'm more annoyed by it for that somewhat irrational reason.
yoklov|10 years ago
For desktop dungeons, I'm not aware of the specifics about that game (though I have played it), but generally, if you're using OpenGL or DirectX to render, repainting only part of the screen isn't an option, so if anything is animated (no matter how slight the animation), you have to redraw the screen every frame. There are exceptions to this (like the mouse pointer, although this requires platform specific code), but not many of them.
lfowles|10 years ago
falcolas|10 years ago
tehbeard|10 years ago
hthh|10 years ago
(I get a bunch of errors on OS X unless I change "CC=gcc" to "CC=clang", btw)
david-given|10 years ago
(Currently trapped in legal hell. I work for one of those annoying companies that claims ownership of everything I do, even in my personal time, so I have to get it cleared before I can push it to github...)
I added some extensions to allow one node to program another; the PROGRAM <dir> opcode resets the node in that direction, and it can then be fed a series of numbers which form the program. Once complete it starts executing.
With this, it ought to be possible to program an arbitrary network with programs from a boot ROM attached to a single node at the corner. It would have to propagate the distribution program through the network, which would then in turn propagate the program to the right place and reprogram each node in turn. Because a programmed node wouldn't contain the distribution program any more we'd have to start at the outer edge and work inwards.
I do wonder whether it would be possible to get real work done with this. I bet a node could be implemented in a tiny handful of FPGA gates.
jeffreyrogers|10 years ago
Here's my output of `gcc --version` on OS X 10.10:
edit: also, should've said that's really cool and thanks for posting your source code.EvilTrout|10 years ago
kyberias|10 years ago
Zardoz84|10 years ago
chetanahuja|10 years ago
FreeFull|10 years ago
bashinator|10 years ago
http://www.zachtronics.com/
cmdrfred|10 years ago
markdeloura|10 years ago
DanWaterworth|10 years ago
LoSboccacc|10 years ago
SIGALARM|10 years ago
npongratz|10 years ago
static_noise|10 years ago