I've just published the source code to a port of Quake to the Android platform . This is something I did a while ago as a internal test application. It's not very useful as a game, because there hasn't been any attempt to optimize the controls for the mobile phone. It's also awkward to install because the end user has to supply the Quake data files on their own. Still, I thought people might enjoy seeing a full-sized example of how to write a native code video game for the Android platform. So there it is, in all its retro glory. (Porting Quake II or Quake III is left as an exercise for the reader. :-) What's different about this particular port of Quake? Converted the original application into a DLL Android applications are written in Java, but they are allowed to call native languge DLLs, and the native language DLLs are allowed to call a limited selection of OS APIs, which include OpenGL ES and Linux File I/O. I was able to make the game work by using Java for: T...
This is a BitTorrent client. There are many like it, but this one is mine. -- the BitTorrent Implementer's Creed For fun I've started writing a command-line BitTorrent client in Google's go programming language. The program, Taipei-Torrent , is about 70% done. It can successfully download a torrent, but there are still lots of edge cases to implement. Go routines and channels are a good base for writing multithreaded network code. My design uses goroutines as follows: a single main goroutine contains most of the BitTorrent client logic. each BitTorrent peer is serviced by two goroutines: one to read data from the peer, the other to write data to the peer. a goroutine is used to communicate with the tracker some "time.Tick" goroutines are used to wake the main goroutine up periodically to perform housekeeping duties. All the complicated data structures are owned by the main goroutine. The other goroutines just perform potentially blocking network I/O using channel...
Intel showed their new Larrabee GPU publicly for the first time at their annual developer conference. They showed Larrabee running a ray tracer that was rendering QuakeWars geometry . The enthusiast scene (e.g. beyond3d ) was not impressed by this demo, because, frankly, it wasn't very impressive at an emotional level. The scene was static, no people in it, just waves and a few very small helicopters. It's strange that they didn't even move the camera, which is something that a ray tracing engine should easily be able to to. The camera angle they chose was effective for showing dynamic reflections, but keeping the camera locked down meant a much less interesting demo. For the same amount of effort they could have come up with a much more visually and emotionally interesting demo. For example, a cascade of brightly colored chrome balls tumbling down a staircase, which would show off both physics and ray tracing. That they didn't use this early opportunity to sell Larrab...
Comments