Hi all. I could not follow closely the DCPU-16 movement, and now I am having troubles to put the pieces together; can anybody put together a brief explaination of what is going on? I can see from wikipedia http://en.wikipedia.org/wiki/DCPU-16#0x10c that the game developer notch, known for Minecraft, is working on a new game called 0x10^c (why this name?), and this is somehow related to the whole DCPI-16 thing. I can guess that notch is writing an ad-hoc assembler to develop this game, correct? What did he need more than the framework he used in the past? I can also see that there is a channel on freenode called #0x10c-dcpu (8 people as of now) and another called #dcpu16 (8 people too). Can somebody give me the big picture?
Notch's 0x10c[1] is going to be a space exploration/trading game set in the distant future; players will customize and operate their own spaceships. One of its unique features is that the spaceships will be controlled by actual programmable computers; players will be able to write their own software and execute it within the game. DCPU-16 is the architecture for the in-game computers, and lots of people have jumped into developing software and tools for it.
It's pretty amazing how much stuff that the community has generated so rapidly. Lots of emulators, IDEs, compilers, code repositories, original software, ports of classic games, etc., have all reached a surprising level of maturity in only about a month.
There's nostalgia for the era when hackers completely understood a machine architecture, and worked by manually writing machine code.
Notch released an invented machine architecture - 0x10c. Many people who'd been thinking about these things (for romance, or 'cos they've written similar systems for uni assignments) have thrown energy at the specification. Hence, even though we only have a vague idea of what Notch is working on, there's a stack of VMs and related tooling for this invented architecture he's defined.
I'm excited about it. I was thinking about how I could create devices and arrange memory to talk to them on my walk in this morning.
It's only 15 minutes that I learnt about the project, and 'excitement' is really a good word to describe my feelings.
I lost interest in videogames in my teens, because I felt that writing my own code was much more interesting than running someone else's programs (my own opinion, totally subjective). But gosh, this man is writing a game where the better coder you are, the better you perform in the game (that's my understanding of the programmable-starships thing). Woah -- i might be actually back on stage :-)
Complementary to the descriptions provided: I run http://dcpuworld.com, which is a small news site I've been building to aggregate all the cool DCPU related projects, tools and tutorials.
Typical, install instructions are several times more effort in Windows (not to mention Cygwin and having to restart your computer to play nice with VS). Is it not possible to get this working using MSYS and Mingw32?
Windows is pretty much always going to be a second class citizen once you take a half-step outside the mainstream. I would just try to "get used to it" (i.e. run Linux/Mac).
I was hoping this one would course-correct itself... (Reading comprehension). "Windows is pretty much always going to be a second class citizen once you take a half-step outside the mainstream."
He said... Windows is a pain in the ass if you do anything off the really-well-beaten path (like Haskell). And even then, yes, C/C++ can be a pain in Windows (again, see the linked project).
I do. I still lament for others'. There've been more than one occasion where I want to collaborate with my peers that refuse to make the leap and it's always a nightmare.
These days, it seems like POSIX has become just another VM environment, like Smalltalk, Erlang, the JVM or the CLR. Mingw/Cygwin doesn't run *nix programs "on" Windows, really; it just provides them with a really half-assed VM implementation. Why not instead just go all the way and run, say, Ubuntu Server in a headless VMware appliance? If nothing else, it gives your spare cores something to do :)
From my experience of doing software development professionally in several flavors of UNIX and Windows systems, I would say Linux is no better as there is seldom a way that works flawlessly across distributions.
I can't remember the last time I struggled building something on a random distribution that worked on another. What are you doing that you run into incompatibilities across modern Linux distributions?
It's certainly better than: "use VS" or "suffer through any other sort of Windows dev" in my opinion.
I'm constantly running into incompatibilities with my own code, all of them due to Debian. The one that's still causing me trouble is being able to invoke a pyuic4 that has access to both pykde and pyqwt; as far as I can tell that's impossible on Debian.
The third is the only that's tangentially related to the development pains we're discussing here. Packaging is a "fun" issue, but it's apples and oranges with multiple compatibility layers to get to a common denominator to be able to ... build a DCPU toolchain for example.
>Regarding your comment, there are many other ways to develop software for Windows besides VS.
Uh huh, and as seen even... right here... it's normally a (relatively) major pain in the ass to orchestrate.
... I can't tell if you don't understand what the issue is here (from this post and your others), or if you really think that forcing complex workarounds into one-off IDEs is a good way to solve this problem.
I am playing a bit devil's advocate, probably with not so much success.
The thing is, that each operating system has it own way of doing things, and many people in open source tend to think that everywhere else should be like GNU/Linux.
I used to think like that, until I got the opportunity to work with several different types of operating systems, all UNIX flavours, Windows, OS/400, Symbian, VMS and see that there are many ways to do certain things.
Here is an example how someone else did a Windows based development environment for DCPU,
