How Additional Aerodynamic Drag Helped Make GTA III Work On PS2

The PlayStation 2 was a revelation when it hit the market in 2000, and yet by modern standards, it’s almost hopelessly weak. In fact, it’s so under-powered, Rockstar developers had to pull every trick in the book to make Grand Theft Auto III even work on the platform.

The story comes to us from developer [Obbe Vermeij]. He explains that the PlayStation 2 couldn’t keep the entire open-world game map in its tiny 32 MB of RAM. Instead, models had to be streamed from the DVD drive as the player moved around the world. However, even the DVD drive wasn’t fast enough. If the player moved too quickly, they would outpace the system’s ability to load new assets, and the world would fall apart. Roads would vanish, buildings simply wouldn’t appear before the player passed by them.

According to [Obbe], getting around this challenge was the job of one [Adam Fowler]. He notes that even optimizing the layout of data on the DVD wasn’t enough to help. Nifty hacks had to be employed to slow the player down. Road networks were changed to stop the player speeding towards areas that needed lots of new models. In other areas, vehicles in the game would experience a nearly-imperceptible 5% increase in air drag to dull their speed. This was chosen as a more invisible solution; cutting engine power directly was audible to players as the audio changed.

It shows you just how hard developers had to work back when resources were far more constrained than they are today!

Microsoft Updates MS-DOS GitHub Repo To 4.0

We’re not 100% sure which phase of Microsoft’s “Embrace, Extend, and Extinguish” gameplan this represents, but just yesterday the Redmond software giant decided to grace us with the source code for MS-DOS v4.0.

To be clear, the GitHub repository itself has been around for several years, and previously contained the source and binaries for MS-DOS v1.25 and v2.0 under the MIT license. This latest update adds the source code for v4.0 (no binaries this time), which originally hit the market back in 1988. We can’t help but notice that DOS v3.0 didn’t get invited to the party — perhaps it was decided that it wasn’t historically significant enough to include.

That said, readers with sufficiently gray beards may recall that DOS 4.0 wasn’t particularly well received back in the day. It was the sort of thing where you either stuck with something in the 3.x line if you had older hardware, or waited it out and jumped to the greatly improved v5 when it was released. Modern equivalents would probably be the response to Windows Vista, Windows 8, and maybe even Windows 11. Hey, at least Microsoft keeps some things consistent.

It’s interesting that they would preserve what’s arguably the least popular version of MS-DOS in this way, but then again there’s something to be said for having a historical record on what not to do for future generations. If you’re waiting to take a look at what was under the hood in the final MS-DOS 6.22 release, sit tight. At this rate we should be seeing it sometime in the 2030s.

Combadge Project Wants To Bring Trek Tech To Life

While there’s still something undeniably cool about the flip-open communicators used in the original Star Trek, the fact is, they don’t really look all that futuristic compared to modern mobile phones. But the upgraded “combadges” used in Star Trek: The Next Generation and its various large and small screen spin-offs — now that’s a tech we’re still trying to catch up to.

As it turns out, it might not be as far away as we thought. A company called Vocera actually put out a few models of WiFi “Communication Badges” in the early 2000s that were intended for hospital use, which these days can be had on eBay for as little as $25 USD. Unfortunately, they’re basically worthless without a proprietary back-end system. Or at least, that was the case before the Combadge project got involved.

Designed for folks who really want to start each conversation with a brisk tap on the chest, the primary project of Combadge is the Spin Doctor server, which is a drop-in replacement for the original software that controlled the Vocera badges. Or at least, that’s the goal. Right now not everything is working, but it’s at the point where you can connect multiple badges to a server, assign them users, and make calls between them.

It also features some early speech recognition capabilities, with transcriptions being generated for the voices picked up on each badge. Long-term, one of the goals is to be able to plug the output of this server into your home automation system. So you could tap your chest and ask the computer to turn on the front porch light, or as the documentation hopefully prophesies, start the coffee maker.

There hasn’t been much activity on the project in the last year or so, but perhaps that’s just because the right group of rabid nerds dedicated developers has yet to come onboard. Maybe the Hackaday community could lend a hand? After all, we know how much you like talking to your electronics. The hardware is cheap and the source is open, what more could you ask for?

3D Printer Streaming Solution Unlocks Webcam Features

While 3D printer hardware has come along way in the past decade and a half, the real development has been in the software. Open source slicers are constantly improving, and OctoPrint can turn even the most basic of printers into a network-connected powerhouse. But despite all these improvements, there’s still certain combinations of hardware that require a bit of manual work.

[Reticulated] wanted an easy way to monitor his prints over streaming video, but didn’t have any of the cameras that are supported by OctoPrint. Of course he could just point a cheap network-connected camera at the printer and be done with it, but he was looking for a bit better integration than that. In the process, he demonstrates how to unlock some features hidden in inexpensive webcams.

He set about building something that wouldn’t require buying more equipment or overloading the limited hardware responsible for the actual printing. A few of his existing cameras have RTMP support, which allows a fairly straightforward setup with YouTube Live once Monaserver is set up to handle the RTMP feeds from the cameras and OBS Studio is configured to stream it out to YouTube. Using the OctoPrint API, he was able to pull data such as the current extruder temperature and overlay it on the video.

One of the other interesting parts of this build is that not all of [Reticulated]’s cameras have built-in RTMP support but following this guide he was able to get more of them working with this setup than otherwise would have had this capability by default. Even beyond 3D printing, this is an excellent guide (and tip) for getting a quick live stream going for whatever reason. For anything more mobile than a working 3D printer, though, you might want to look at taking your streaming setup mobile instead.

Get Today’s Forecast In Classic 90s Weather Channel Style

Remember when The Weather Channel actually had weather? It’s been a while, but we sure remember what a boon Local on the 8’s was when getting ready for the day. Not having to wait for the low-information national forecast on the morning shows or putting up with the antics of [Willard Scott] or [Al Roker] was just icing on the cake.

Recreating the retro look and feel of the Weather Channel experience is what this 1990s-style weather feed is all about, and we have to say that [Mitchell Scott] knocked it out of the park. Luckily, a lot of the heavy lifting was done already thanks to the WeatherStar 4000+ emulator project, which renders forecasts using online weather APIs in the distinctive retro graphics The Weather Channel used back in the day. He combined the graphics with the original smooth jazz soundtracks that TWC used back then; they’re online, because of course they are.

To really sell the look, [Mitchell] tracked down a period-correct Zenith TV with a 9″ CRT to display the feed from a Raspberry Pi 4’s composite video output. Why such a small screen? Easy. [Mitchell] wanted it on a shelf behind him to be visible during videoconferences. It’s a bit of a weird flex, but we respect it. Getting the composite video output working was a bit of a chore, as was tricking the TV into starting up on channel 14 so the feed is instantly visible.

The nostalgia is strong with this one, especially for weather geeks. For a more in-depth look at how The Weather Channel brought those local forecasts to cable, make sure you check out how the WeatherStar box was reverse-engineered.

Thanks to [USA-RedDragon] for the tip.

IRC Client On Bare Metal

In the beginning, there was the BIOS, and it was good. A PC’s BIOS knows how to set up the different hardware devices, grab a fixed part of a hard drive, load it, and run it. That’s all you need. While it might be all you need, it isn’t everything people want, so a consortium developed UEFI, which can do all the things a normal BIOS can’t. Among other things, UEFI can load code for the operating system over the network instead of from the hard drive.

In true hacker fashion, [Phillip Tennen] thought, “Does it have to be an operating system?” The answer, of course, is no. It could be an IRC client. He chose Rust to implement everything. While UEFI does provide a network stack, it isn’t very easy to use, apparently. It also provides support for a mouse. [Phillip] ported his GUI toolkit library over, and then the rest is just building an IRC client.

The client isn’t the easiest to use because, after all, this is a lark. Why would you want to do this? On the other hand, we can think of reasons we might want to take control of a UEFI motherboard and use it for something. If you want to do that, this project is a great template to jump-start your endeavors.

We’ve looked at the UEFI system a few times. Or, you can use it to play DOOM.

Continue reading “IRC Client On Bare Metal”

Playing Chess Against Your Printer, With PostScript

Can you play chess against your printer? The answer will soon be yes, and it’s thanks to [Nicolas Seriot]’s PSChess. It’s a chess engine implemented in PostScript, of all things. It’s entirely working except for one last hurdle, but more on that in a moment.

What’s it like to play PSChess? Currently, one uses a PostScript interpreter (such as GhostScript) to run it, much like one would use the Python interpreter to run Python code. The user inputs moves by typing in commands like d2d4 (representing a piece’s source coordinate and a destination coordinate on the 2D board). Then the program makes a move, and outputs an updated board state to both the console and a PDF document. Then it’s the user’s turn again, and so on until somebody loses.

The chess parts are all working, but there’s one last feature in progress. The final step of the project is to enable PSChess to be run directly on a printer instead of using GhostScript as the interpreter. Intrigued? You can find the code at the project’s GitHub repository.

So why PostScript? While it is a Turing-complete stack-based interpreted language, it was never intended to be used directly by humans. There are no meaningful development tools to speak of. Nevertheless, [Nicolas] finds PostScript an appealing tool for programming projects and provides tips and techniques for like-minded folks. One of the appeals is working within constraints to solve a problem, just like implementing a chess engine in only 4k, or draw poker in 10 lines of BASIC.