Star Wars: Yoda Stories was released by LucasArts in 1997 to minimal critical acclaim. As IGN said, “like Phantom Menace proved, just because it’s Star Wars doesn’t mean it’s good.” This didn’t stop [Zach] from playing it, and years later, taking an interest in reverse engineering the game.
[Zach]’s reverse engineering of Star Wars: Yoda Stories (google cache) takes a look at the game’s data file. This binary file is parsed by the game at run time to extract sound effects, sprites, and map tiles. Perhaps the best known game data file type was Doom’s WAD file, which had purpose built editing programs from third parties.
After a quick look at the data file in HxD, [Zach] began writing scripts in C# to extract different sections of the data file. Once the sections were found, more code was used to apply a color palette and generate bitmaps.
In the end, [Zach] managed to get a couple thousand tiles of the game’s data. He found some interesting ones, such as the sports car that he replaced the X-Wing with in his mod. The engine for an earlier Lucasarts game, Indiana Jones and His Desktop Adventures, should be very similar, and once we find the Mac install disk and a copy of ResEdit, we’ll post something on Hackaday.io.
[Gadget Addict] found out about a contest being held by a shoe seller. Their mobile app has a game very much like Bejeweled. The high scorer each month gets £500. His choices were to be better at the game than everyone else, or to be smarter. He chose the latter by writing a computer vision program to play the game.
There are two distinct parts of a hack like this one. The first is just figuring out a way to programmatically detect the game board and correctly identify each icon on it. This is an iPad game. [Gadget Addict] is mirroring the screen on his laptop, which gives him easy access to the game board and also allows for simulated swipes for automatic play. Above you can see two examples where black pixels may be counted in order to identify the icon. A set of secondary checks differentiates similar entries after the first filtering. The other part of the hack involves writing the algorithms to solve for the best move.
If you liked this one, check out a super-fast Bejeweled solver from several years back. We should also mention that this was just a proof of concept and [GA] never actually entered the contest.
While most embedded development is still done in C and/or assembly, some people are working with more modern languages. The team over at Gobot has successfully managed to get Go running on the Intel Edison.
The Go programming language, which has been around for about five years, compiles to machine code like C. It has a number of modern features including concurrency, garbage collection, and packages.
Getting Go to work on the Edison hardware wasn’t particularly difficult, since it supports the Pentium instruction set and MMX. However, a library was needed to interface with the Edison’s peripherals. The Gobot team whipped up gobot-intel-iot, which makes it easy to work with GPIO, I2C, and PWM.
Computer animation is a task both delicate and tedious, requiring the manipulation of a computer model into a series of poses over time saved as keyframes, further refined by adjusting how the computer interpolates between each frame. You need a rig (a kind of digital skeleton) to accurately control that model, and researcher [Alec Jacobson] and his team have developed a hands-on alternative to pushing pixels around.
The skeletal systems of computer animated characters consists of kinematic chains—joints that sprout from a root node out to the smallest extremity. Manipulating those joints usually requires the addition of easy-to-select control curves, which simplify the way joints rotate down the chain. Control curves do some behind-the-curtain math that allows the animator to move a character by grabbing a natural end-node, such as a hand or a foot. Lifting a character’s foot to place it on chair requires manipulating one control curve: grab foot control, move foot. Without these curves, an animator’s work is usually tripled: she has to first rotate the joint where the leg meets the hip, sticking the leg straight out, then rotate the knee back down, then rotate the ankle. A nightmare.
[Alec] and his team’s unique alternative is a system of interchangeable, 3D-printed mechanical pieces used to drive an on-screen character. The effect is that of digital puppetry, but with an eye toward precision. Their device consists of a central controller, joints, splitters, extensions, and endcaps. Joints connected to the controller appear in the 3D environment in real-time as they are assembled, and differences between the real-world rig and the model’s proportions can be adjusted in the software or through plastic extension pieces.
The plastic joints spin in all 3 directions (X,Y,Z), and record measurements via embedded Hall sensors and permanent magnets. Check out the accompanying article here (PDF) for specifics on the articulation device, then hang around after the break for a demonstration video.
[Bharath] recently uploaded the source code for an OpenCV based pattern recognition platform that can be used for Augmented Reality, or even robots. It was built with C++ and utilized the OpenCV library to translate marker notations within a single frame.
The program started out by focusing in on one object at a time. This method was chosen to eliminate the creation of additional arrays that contained information of all of the blobs inside the image; which could cause some problems.
Although this implementation did not track marker information through multiple frames, it did provide a nice foundation for integrating pattern recognition into computer systems. The tutorial was straightforward and easy to ready. The entire program and source code can be found on Github which comes with a ZERO license so that anyone can use it. A video of the program comes up after the break:
First person video – between Google Glass, GoPro, and other sports cameras, it seems like everyone has a camera on their head these days. If you’re a surfer or skydiver, that might make for some awesome footage. For the rest of us though, it means hours of boring video. The obvious way to fix this is time-lapse. Typically time-lapse throws frames away. Taking 1 of every 10 frames results in a 10x speed increase. Unfortunately, speeding up a head mounted camera often leads to a video so bouncy it can’t be watched without an air sickness bag handy. [Johannes Kopf], [Michael Cohen], and [Richard Szeliski] at Microsoft Research have come up with a novel solution to this problem with Hyperlapse.
Hyperlapse photography is not a new term. Typically, hyperlapse films require careful planning, camera rigs, and labor-intensive post-production to achieve a usable video. [Johannes] and team have thrown computer vision and graphics algorithms at the problem. The results are nothing short of amazing.
The full details are available in the team’s report (35MB PDF warning). To obtain usable data, the fisheye lenses often used on these cameras must be calibrated. The team accomplished that with the OCamCalib toolbox. Imported video is broken down frame by frame. Using structure from motion algorithms, hyperlapse creates a 3D models of the various scenes in the video. With the scenes in this virtual world, the camera can be moved and aimed at will. The team’s algorithms then pick a smooth path that follows the original cameras trajectory. Once the camera’s position is known, it’s simply a matter of rendering the final video.
The results aren’t perfect. The mountain climbing scenes show some artifacts caused by the camera frame rate and exposure changing due to the varied lighting conditions. People appear and disappear in the bicycling portion of the video.
One thing the team doesn’t mention is how long the process takes. We’re sure this kind of rendering must require some serious time and processing power. Still, the output video is stunning.
Net neutrality is one of those topics we’ve been hearing more and more about in recent years. The basic idea of net neutrality is that all Internet traffic should be treated equally no matter what. It shouldn’t matter if it’s email, web sites, or streaming video. It shouldn’t matter if the traffic is coming from Wikipedia, Netflix, Youtube, etc. It shouldn’t matter which Internet Service Provider you choose. This is the way the Internet has worked since it’s inception. Of course, not everyone agrees that this is how things should stay. We didn’t always have the technology to filter and classify traffic. Now that it’s here, some believe that we should be able to classify internet traffic and treat it differently based on that classification.
It seems like much of the tech savvy community argues that net neutrality is a “given right” of the Internet. They believe that it’s the way the Internet has always been, and always should be. The other side of the argument is generally lobbied by Internet service providers. They argue that ISP’s have the right to classify Internet traffic that flows through their equipment and treat it differently if they so choose. As for everyone else, just about everyone these days relies on the Internet for business, banking, and entertainment but many of those people have no idea how the Internet works, nor do they really care. It’s like the electricity in their home or the engine in their car. As long as it’s working properly that’s all that matters to them. If they can check Facebook on their phone while watching Breaking Bad on Netflix in full HD, why should they care how that stuff gets prioritized? It work’s doesn’t it? Continue reading “Net Neutrality: FCC Hack is a Speed Bump on the Internet Fast Lane”→