As summer draws to a close, I am planning my family's computer use for the 2015-2016 school year.
My plans for this year are:
Each family member gets their own mobile phone and laptop.
We also have a shared desktop and a few shared tablets.
Shared network scanner/laser printer.
We print color documents and pictures at the library or at the drugstore.
Android TV for shared movie watching.
Chromecast for audio sharing.
Comcast Business Internet
Apple Time Capsule for backup / WiFi / NAT
Note the lack of a dedicated game console. The kids play games on mobile, tablets, and laptops (for Minecraft specifically!).
My two youngest kids are getting their first phones this year. I'm worried about their phones getting lost, broken, or stolen. So for the first six months my kids will use hand-me-down phones. After they've learned to take care of phones, I'm going to give them better phones. (Still used, though!)
To achieve my plan I need to buy one laptop and three mobile phones. For the laptop I'm leaning towards a 13" Retina Macbook Pro. For the phones I'm leaning towards used iPhone 5Ss.
Why a Macbook and not a Chromebook? Build quality and applications. I have a low-end ARM Chromebook, and I noticed that nobody in the family uses it by choice, due to its low speed and poor quality screen. I _could_ get a Chromebook Pixel, but for my family, at that price level a Macbook is a better deal.
Why iOS and not Android? It comes down to ease-of-administration. I want to lock down my kids' phones, and unfortunately experience with my oldest child using Android is that it's all-too-easy for him to defeat the aftermarket Android parental control apps.
For phone service I'm probably going to go with the BYOD T-Mobile Family Plan, because:
It is cheap.
Unmetered music streaming.
When you hit your data cap it switches to low speed data for the rest of the month, rather than charging more.
It has free 2G international roaming.
Thoughts on laptops and other legacy hardware
If I were on a tighter budget, or starting from scratch, I'd consider dropping the laptops, the Comcast Internet, and the home WiFi, and going pure mobile. I would get bluetooth keyboards to make typing school assignments easier.
Think of an idea for a small application to write to learn a new technology and incidentally make my life better.
Prototype the app.
Plan a MVP, estimate costs in time and money to develop.
Search Play Market and/or IOS App Store, find that reasonable equivalent already exists, and is only $2.
Buy the existing app, get on with life.
This happened to me last week with the concept of a "comic book reader". I wrote a prototype that let me browse my collection. I was starting to list out all the features I needed to add (zooming, panning, sorting,RAR archive support...). And then I did a web search for comic book reader, spent a couple of minutes reading reviews, and bought one of the popular ones for $2. Sure it's got UI issues, and bugs, and doesn't quite work like it should, but I saved myself weeks of development time.
I need to think through how best to spend my hacking time in today's world of super abundance. What's my comparative advantage in this new world? What's my compliment? What am I trying to learn, trying to achieve? What is worth working on? Existential questions on a Sunday morning. :-)
Maybe Andy forgot to mention it; it's been a while since I've read the whole series.
The code was C and lisp so it didn't really require any effort to port other than replacing the rendering pipeline. And we used the SGIs to pre-render every frame anyway, to precompute the polygon sort order. (The PS1 had no Z-buffer, so you were stuck sorting polygons at run-time if you didn't do something clever.)
So we already had the rendering pipeline ported. Obviously you couldn't save your game to the memory card, etc. -- some stuff didn't work. But the game was playable (albeit very frustrating with keyboard controls).
That blows my mind, I always assumed it did have a z buffer. So what did you guys do to remedy 'z fighting' triangles? My interest is; I wrote a 3d renderer in Java using fillPolygon() many years ago, and used polygon sorting in place of a z buffer. Z fighting was of course a problem.
Some day I will write this up for real, but without going into detail, here's a summary.
The camera in Crash was on a rail. It could rotate left, right, up, and down (in Crash 2 and beyond, at least), but could not translate except by moving forward/backward on the rail. This motivates a key insight: if you're only rotating the camera, the sort order of the polygons in the scene cannot change.
This allowed us to sample points on the rail and render the frame at each sample point ahead of time, as a batch job, on the SGI using a Z-buffer. (We may have done the Z-buffer with software; I don't remember.) Then we could recover the polygon order of each frame by looking at the Z-buffer. And, even better, at run-time we could simply not render at all those polygons that weren't ultimately visible in the pre-rendered scene. This solved both the sorting and clipping problem nicely, and made the look of the game closer to 3K polygons/frame vs. the 1K polygons we were actually rendering in real time. (Many polygons were occluded by other polygons.)
The trick, though, was what exactly to do with this sort/occlusion information. In a nutshell, what I did was write a custom delta-compression algorithm tailored to the purpose of maintaining the sorted polygon list from frame to frame, in R3000 assembly language. Miraculously, this ended up being quite feasible because the delta between frames was in practice very small -- a hundred bytes or so was typical. And if a transition was too heavyweight (i.e., the delta was too big) we'd either sample more finely in that area or tell the artists to take stuff out. :)
One thing nobody talks about but which is obvious in retrospect is that without a Z-buffer you're pretty screwed: sorting polygons is not O(N lg N) -- it's O(N^2). This is because polygons don't obey the transitivity property, because you can have cyclic overlap. (I.e., A > B and B > C does not imply A > C). This is why virtually every game from that era has flickery polygons -- they were using bucket sorting, which has the advantage of being linear time complexity, but the disadvantage of being wrong, and producing this flickery effect as polygons jump from bucket to bucket between frames.
I'll leave the matter of weaving the foreground characters -- Crash himself and the other creatures -- into the pre-sorted background for another day.
The first time your run this it will take a few minutes to download and install minecraft. After that it should be much faster
View the Minecraft Server Log
docker logs $CONTAINER
This prints out the logs from the container (you set the CONTAINER variable as part of the docker run command above.)
If you've lost track of your container, you can list all currently running containers.
If you don't see any containers, you container may have already exited. The Minecraft server will exit if it encounters an error while running.
You can shut down all running containers and quit boot2Docker by using the stop command:
Note that the Minecraft Server files will be stored in /Users/yourname/minecraft/data, and when you've stopped the server you can edit the files using your mac. (You might want to edit the files in order to modify the server settings.)