5 ms·
Yeah this seems like the exact scenario where hand-rolled assembly and perhaps some hand-optimized C will really shine. You don't see a lot of embedded process
by flatline 15y ago
Yeah this seems like the exact scenario where hand-rolled assembly and perhaps some hand-optimized C will really shine. You don't see a lot of embedded processors running javascript, for example. If your ship can process data and respond 5% faster than an opponent's, all other things being equal, you will come out ahead.
If the current level of interest persists, by the time the game launches, I imagine that the vast majority of people will be downloading and running programs written by others. These will have been pored over and optimized to an extent that most of us would be unable to achieve by ourselves, and it will not pay to roll your own trivial implementation. I'd be curious to see what Notch can do to still encourage people to learn how the CPU works themselves. If the environment and game dynamics are rich enough, perhaps this will not really be a problem?
- DanBC 15y ago> I'd be curious to see what Notch can do to still encourage people to learn how the CPU works themselves. Have some ship customisation stuff tied to assembly programming. People love changing the colour of carpets or wearing hats or collecting and displaying fossils. Then allow the community to create simple how to guides - "This program will do $THIS_THING; here's how it works; now try to change it to do something slightly different." I guess Codecademy should have a DCPU section too.
- seanp2k2 15y agoDID SOMEONE SAY HATS?! Agreed that higher-level langs would be helpful for "newbies". I wonder if this was at all inspire by Schemaerse (google it, but TL;DR it's a space game written mostly with Postgres triggers where /you build the game client/ in whatever you want to use to interface with the pgsql :)
- dons 15y agoI think we're going to see some clever optimizing DSLs (a la FFTW) -- restricted languages for the kinds of embedded programs you write on such an architecture will be easier to optimize than general purpose languages. Particularly if they have a clear cost model. The Haskell embedding is very likely to head in that direction. (See e.g. in this style : http://www.fftw.org/faq/section4.html#whyfast http://www.fftw.org/faq/section4.html#whyfast or this style : http://www.cse.unsw.edu.au/~chak/papers/polymer.pdf http://www.cse.unsw.edu.au/~chak/papers/polymer.pdf -- code generation + DSL + constraint solver for instruction level timings). At least, that's what I'd do.
- masklinn 15y agoLow-level lisps à la GOOL/GOAL[0] will probably gain some traction as well, or so I hope. [0] http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
- cpeterso 15y agoI agree that 0x10c DSLs that control game play will be more successful than a C compiler. :)
- mzl 15y agoThe polymer article was very interesting, really cool stuff. However, I could not find any mention of using a constraint solver for instruction level timings. Is that in another article, or did I just miss it?
- zxoq 15y agoYep, only thing I dislike is that the processor does not simulate the importance of cache. If the in-game processors allowed the selection of different cache-line sizes (both instruction cache and data cache) for different costs (paid via the in-game currency), it would add another level of depth to the game market. It would also mean getting into the nitty-gritty of optimization would be even more worth it.
- rictic 15y agoWhy currency and not cycles? The VM is designed to give each CPU ~100k cycles per second (billed per instruction).