Earlier quoted context omitted.
It's good to see Notch working on the Little Coder problem, even if that's not his direct intention. :)
Little Coder problem = how to get people interested in coding by writing little programs. Hard to do on consoles and iPhones. I started thinking that if I was going to get people interested in coding, I'd start with something more approachable - maybe something like a subset of Python, Java, Ruby or even JavaScript (it's where so many people write little programs anyway now). I heard Lua mentioned as a good scripting…
Notch's Specification for the In-Game DCPU-16
71–80 of 177 posts
Re: Notch's Specification for the In-Game DCPU-16
#72Earlier quoted context omitted.
Couldn't the permission system exist outside of the constraints of the in-game computer (as just some game mechanism)? If each of the ship's discrete components were accessible at some address, couldn't the game enforce the permissions at a level above the simulated CPU? A rough static analysis of the code might reveal where those components are accessed, and as long as you enforce permissions while the software runs…
Go back and look at the first post in this very thread. Notch explicitly intends nothing of the kind, and I certainly can't see why it would be done -- it runs counter to the vision thus far articulated.
Re: Notch's Specification for the In-Game DCPU-16
#73Earlier quoted context omitted.
You don't need the full python repl/compiler/interpreter/libraries, you "just" need the python virtual machine. Once there's a C compiler for the platform that should be relatively straightforward, because I sincerely doubt that takes all 128KiB.
I wonder how hard would it be to get a working DCPU-16 backend for GCC or Clang.
Re: Notch's Specification for the In-Game DCPU-16
#74Re: Notch's Specification for the In-Game DCPU-16
#75Re: Notch's Specification for the In-Game DCPU-16
#76Now here's an interesting bit: "Question: can we trade the programs we create? How will you stop malicious viruses etc?" "yes. And I won't stop viruses, the players will have to do that themselves." ~ https://twitter.com/#!/notch/status/187474819980328962
Re: Notch's Specification for the In-Game DCPU-16
#77I will admit, I used to think Notch was just a regular-joe programmer who had gotten extremely lucky with his strain of adventure game. Now I know I was dead wrong.
Re: Notch's Specification for the In-Game DCPU-16
#78For those interested, there is a C based implementation of Notch's DCPU-16 in github: https://github.com/swetland/dcpu16 I haven't tested it much, but it seems to work pretty well.
Re: Notch's Specification for the In-Game DCPU-16
#79Earlier quoted context omitted.
> a highly dynamic language is unlikely Lua, perhaps? There was an article how to reduce its binary size, for an older version of the language (Lua 4.0): http://www.lua.org/notes/ltn002.html With no reductions, and for x86 assembly, it started at ~64KB, so not very useful here; but after dropping standard libraries and parser , they got to ~24KB. Now however, some further questions arise I'm not sure about: - whether…
Lua is a good place to start! And the VM minus parser is useful, though it may make debugging harder. You simply write out the bytecode and upload that. The VM is only part of the problem, though. I consider the bigger problem to be memory management. A garbage collected language operating reliably in 128KB? I'm deeply skeptical.
"Historically, languages intended for beginners, such as BASIC and Logo, have often used garbage collection for heap-allocated variable-length data types, such as strings and lists, so as not to burden programmers with manual memory management. On early microcomputers, with their limited memory and slow processors, BASIC garbage collection could often cause apparently random, inexplicable pauses in the midst of program operation. Some BASIC interpreters such as Applesoft BASIC on the Apple II family, had terribly inefficient garbage collectors for strings which repeatedly scanned the string descriptors for the string having the highest address in order to compact it toward high memory. This one-string-at-a-time processing loop resulted in O(N * N) time performance in the number of strings, which would introduce a pause more than one minute long into the execution of string-intensive programs. A replacement garbage collector for Applesoft BASIC published in Call-A.P.P.L.E. (January 1981, pages 40–45, Randy Wiggington) identified a group of strings in every pass over the heap, reducing a pause of two minutes into less than a second depending on the size of the group. Other approaches were published, but none ever made it into a new revision of the BASIC interpreter."
http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc...
Re: Notch's Specification for the In-Game DCPU-16
#80I will admit, I used to think Notch was just a regular-joe programmer who had gotten extremely lucky with his strain of adventure game. Now I know I was dead wrong.
Emulating a very simple computer like this isn't hard at all; it's basically just a big array for memory, a few variables for registers, and a switch statement for instruction handling.