[Rich Olson] really likes MakerWare and the Makerbot slicer – the software package that comes with every Makerbot – but sometimes he needs to change a few settings. Makerware doesn’t allow the user access to 90% of the setting for slicing and printing, so [Rich] did something about that. He came up with ProfTweak, a tool to change all the MakerWare slicing and printing parameters, giving him precise control over every print.
ProfTweak handles common settings changes such as turning the fan on or off, adjusting the filament diameter, changing feed rate options, and turning your infills into cats. It’s a handy GUI app that should work under Windows, OS X, and Linux, so if you’re running MakerWare right now, you can get up and running with this easily.
One thing [Rich] has been using his new software for is experimenting with alternative filaments. With his Makerbot, he’s able to print in nylon, the wood and stone PLAs, flex PLA, and PET. That’s a lot more material than what the Makerbot natively supports, so we have to give [Rich] some credit for that.
Our Chrome browser thinks it’s a Chromecast dongle. Here’s a screenshot of it playing a YouTube video. Note the tile banner and onscreen controls which are just like the ones you’d see on the actual hardware. Give it a try yourself by downloading the Leapcast Python package which [dz0ny] programmed.
After cloning the GitHub repo we had a few problems compiling the package. Turns out we needed to install python-dev and that took care of it. Starting the daemon is a simple command, we specified our Chrome binary path as well as added a few flags
leapcast --name HAD --chrome /usr/bin/google-chrome --fullscreen
Once that was running the Android YouTube app automatically detected Leapcast as a Chromecast device. It gave us a tutorial overlay mentioning the new share icon on the interface. Pressing that icon during playback launched an Incognito window which played the video. [dz0ny] links to a device config JSON file in the README. If you check it out you’ll notice that Netflix is listed as “external” while the others are not. This is because the Chromecast protocol uses a binary for Netflix. The others do it with local websockets or a cloud proxy so they work just fine with this setup.
This is a screenshot from the Atari 5200 version of the classic game Berserk. But the write-up we’re featuring actually looks at the original coin-op version. The maze for each level was established on the fly using a seed number fed into a rudimentary algorithm . Here’s a close look at how the maze building code actually worked.
Recently we saw a talk by Pitfall creator [David Crane] as part of our Retrotechtacular series. That is a real gem of programming history, and one of our favorite take-aways was that the levels were not hardcoded, but built using a random number generator algorithm with a hardcoded seed (so that the game was the same each time you played it). This uses a similar method but with a somewhat random seed.
The maze building was reverse engineered by observing the game in a MAME emulator, and by digging through disassembled code. Each time the code is “cold started” the seed starts out at zero, but from there the room number is used as the next seed. This is fed through a very simple algorithm. It generates directions for the walls, which use s few bit-wise operations to add the pillars inside the rooms.
It’s a great thing to study if you’re writing games for your embedded projects. By generating the room programmatically you don’t use up as much program memory. Of course these days even simple hobby controllers have way more storage to work with than [Alan McNeil] had when he designed Berserk.
Modern operating systems may seem baroque in their complexity, but nearly every one of them – except for Windows, natch – are based on the idea of simplicity and modularity. This is the lesson that UNIX taught us, explained perfectly in a little film from Bell Labs in 1982 starring giants of computation, [Dennis Ritchie], [Ken Thompson], [Brian Kernighan], and others.
At the time this film was made, UNIX had been around for about 10 years. In that time, it had moved far from an OS cloistered in giant mainframes attached to teletypes to slightly smaller minicomputers wired up to video terminals. Yes, smallish computers like the Apple II and the VIC-20 were around by this time, but they were toys compared to the hulking racks inside Bell Labs.
The film explains the core concept of UNIX by demonstrating modularity with a great example by [Brian Kernighan]. He took a short passage from a paper he wrote and found spelling errors by piping his paper though different commands from the shell. First the words in the paper were separated line by line, made lowercase, and sorted alphabetically. All the unique words were extracted from this list, and compared to a dictionary. A spell checker in one line of code, brought to you by the power of UNIX.
This week we’re taking another departure from the ordinarily campy videos featured in the Retrotechtacular section. This time around the video is only two years old, but the subject matter is from the early 1980’s. [David Crane], designer of Pitfall for the Atari 2600 gave a talk at the 2011 Game Developer’s Conference. His 38-minute presentation rounds up to a full hour with the Q&A afterwards. It’s a bit dry to start, but he hits his stride about half way through and it’s chock-full of juicy morsels about the way things used to be.
[David] wrote the game for Activision, a company that was started after game designers left Atari having been told they were no more important than assembly line workers that assembled the actual cartridges. We wonder if any heads rolled at Atari once Pitfall had spent 64-weeks as the number one worldwide selling game?
This was a developer’s panel so you can bet the video below digs deep into coding challenges. Frame buffer? No way! The 2600 could only pump out 160 pixels at once; a single TV scan line. The programs were hopelessly synced with the TV refresh rate, and were even limited on how many things could be drawn within a single scan line. For us the most interesting part is near the end when [David] describes how the set of game screens are nothing more than a pseudo-random number generator with a carefully chosen seed. But then again, the recollection of hand optimizating the code to fit a 6k game on a 4k ROM is equally compelling.
If you like this you should take a look at an effort to fix coding glitches in Atari games.
Continue reading “Retrotechtacular: How I wrote Pitfall for the Atari 2600″
Some people know [Tom Murphy] as [Dr. Tom Murphy VII Ph.D.] and this hack makes it obvious that he earned those accolades. He decided to see if he could teach a computer to win at Super Mario Bros. But he went about it in a way that we’d bet is different that 99.9% of readers would first think of. The game doesn’t care about Mario, power-ups, or really even about enemies. It’s simply looking at the metrics which indicate you’re doing well at the game, namely score and world/level.
The link above includes his whitepaper, but we think you’ll want to watch the 16-minute video (after the break) before trying to tackle that. In the clip he explains the process in laymen’s terms which so far is the only part we really understand (hence the reference to voodoo in the title). His program uses heuristics to assemble a set of evolving controller inputs to drive the scores ever higher. In other words, instead of following in the footstep of Minesweeper solvers or Bejeweled Blitz bots which play as a human would by observing the game space, his software plays the game over and over, learning what combinations of controller inputs result in success and which do not. The image to the right is a graph of it’s learning progress. Makes total sense, huh?
Continue reading “Teaching a computer to play Mario… seemingly through voodoo”
This hack has got to be every gamer’s dream. Someone actually took the time to dig through the binary file of E.T. the Extra-Terrestrial and fix the errors that made it an abomination of a title for the Atari 2600.
This is quite a feat in many ways. First off, you need to know the game well enough to understand where they problems lie. The Internet is a huge help in that regard as there’s no shortage of sources complaining about the game’s shortcomings. This turns out to be one of the articles strongest points as the author takes time to address the most common myths about bugs in the game. From there he goes on to discuss the problems that were actually fixed. Some are just general tweaks like the color fix listed above. But most of them are genuine improvements in the game play, like the falling fix which prevents E.T. from falling in this pit when his feet are obviously not anywhere near the edge.
So you couldn’t get your hard earned bucks back for a bummer of a game back in the day. But at least a few decades later you can fix the things that made it suck and play it through the way it should have been.