Simulator-style video games are designed to scale in complexity, allowing players to engage at anything from a casual level to highly detailed, realistic simulation. Microsoft Flight Simulator, for example, can be played with a keyboard and mouse, a controller, or a huge, expensive simulator designed to replicate a specific airplane in every detail. Driving simulators are similar, and [CNCDan] has been hard at work on his DIY immersive driving sim rig, with this hand brake as his latest addition.

For this build, [CNCDan] is going with a lever-style handbrake which is common in motorsports like drifting and rallying. He has already built a set of custom pedals, so this design borrows heavily from them. That means that the sensor is a load cell, which takes input force from a lever connected to it with a spring mechanism. The signal is sent to an Arduino for processing, which is set up to send data over USB like any joystick or controller. In this case, he’s using an Arduino that was already handling inputs from his custom shifter, so he only needed to use another input and add some code to get his handbrake added into his sim.

[CNCDan] built a version of this out of laser-cut metal parts, but also has a fully 3D printable one available as well. Plenty of his other videos about his driving rig are available as well, from the pedal assembly we mentioned earlier to the force-feedback steering wheel. It’s an impressive set of hardware with a feel that replicates racing about as faithfully as a simulator could. Interestingly, we’ve also seen this process in reverse as well where a real car was used instead as a video game controller.

[Jer Schmidt] needed a way to put a lot of M8 bolts into a piece of square steel tubing, but just drilling and tapping threads into the thin steel wouldn’t be strong enough. So he figured out a way to reliably weld nuts to the inside of the tube, and his technique works even if the tube is long and the inside isn’t accessible.

Essentially, one drills a hole for the bolt, plus two smaller holes on either side. Then one welds the nut to the tubing through those small holes, in a sort of plug weld. A little grinding is all it takes to smooth out the surface, and one is left with a strong threaded hole in a thin-walled tube, using little more than hardware store fasteners.

The technique doesn’t require access to the inside of the tube for the welding part, although getting the nut back there in the first place does require a simple helper tool the nut can slot into. [Jer] makes one with some scrap wood and a table saw, just to show it doesn’t need to be anything fancy.

Another way to put a threaded hole into thin material is to use a rivnut, or rivet nut (sometimes also used to put durable threads into 3D prints) but welding a plain old nut to the inside was far more aligned with what [Jer] needed, and doesn’t rely on any specialty parts or tools.

[Jer]’s upcoming project requires a lot of bolts all the way down long tubing, which is what got him into all of this. Watch it in action in the video below, because [Jer] has definitely worked out the kinks, and he steps through a lot of tips and tricks to make the process painless.

Thanks [paulvdh] for the tip!

Before the Internet, there was a certain value to knowing how to find out about things. Reference librarians could help you locate specialized data like the Thomas Register, the EE and IC Masters for electronics, or even an encyclopedia or CRC handbook. But if you wanted up-to-date info on any country of the world, you’d often turn to the CIA. The originally classified document was what the CIA knew about every country in the world. Well, at least what they’d admit to knowing, anyway. But now, the Factbook is gone.

The publication started in 1962 as the classified “The National Basic Intelligence Factbook,” it went public in 1971 and became “The World Factbook” in the 1980s. While it is gone, you can rewind it, including a snapshot taken just before it went dark on Archive.org.

Browsing the archives, it looks like the last update was in September of 2025. It would be interesting to see a project like Wikipedia take the dataset, house it, and update it, although you can presume the CIA was better equipped. The data is public domain, after all.

Want to know things about Croatia? Unfortunately, the archive seems to have missed some parts of some pages. However, there are other mirrors, including some that have snapshots of the data in one form or another. Of course, these are not always the absolute latest (the link has data from 2023). But we would guess the main languages (Croatian and Serbian) haven’t changed. You can also find the internet country suffix (.hr) and rankings (for example, in 2020, Croatia ranked 29th in the world for the number of broadband internet subscribers scaled for population and 75th in total broadband usage.

We are sorry to see such a useful reference go, but reference books are definitely an endangered species these days.

Although often tossed together into a singular ‘retro game’ aesthetic, the first game consoles that focused on 3D graphics like the Nintendo 64 and Sony PlayStation featured very distinct visuals that make these different systems easy to distinguish. Yet whereas the N64 mostly suffered from a small texture buffer, the PS’s weak graphics hardware necessitated compromises that led to the highly defining jittery and wobbly PlayStation graphics.

These weaknesses of the PlayStation and their results are explored by [LorD of Nerds] in a recent video. Make sure to toggle on subtitles if you do not speak German.

It could be argued that the PlayStation didn’t have a 3D graphics chip at all, just a video chip that could blit primitives and sprites to the framebuffer. This forced PS developers to draw 3D graphics without such niceties like a Z-buffer, putting a lot of extra work on the CPU.

This problem extends also to texture mapping, by doing affine texture mapping, as it’s called on the PS. This mapping of textures is rather flawed and leads to the constant shifting of textures as the camera’s perspective is not taken into account. Although this texture mapping can be improved, the developers of the game have to add more polygons for this, which of course reduces performance. This is the main cause of the shifting and wobbling of textures.

Another issue on the PS was a lack of mipmapping support, which means a sequence of the same texture, each with each a different resolution. This allows for high-resolution textures to be used when the camera is close, and low-resolution textures when far away. On the PS this lack of mipmapping led to many texture pixels being rendered to the same point on the display, with camera movement leading to interesting flickering effects.

When it came to rendering to the output format, the Nintendo 64 created smooth gradients between the texture pixels (texels) to make them fit on the output resolution, whereas the PS used the much more primitive nearest neighbor interpolation that made especially edges of objects look like they both shimmered and changed shape and color.

The PS also lacked a dedicated floating point unit to handle graphics calculations, forcing a special Geometry Transformation Engine (GTE) in the CPU to handle transformation calculations, but all in integer calculations instead of with floating point values. This made e.g. fixed camera angles as in Resident Evil games very attractive for developers as movement would inevitably lead to visible artefacts.

Finally, the cartridge-based games of the N64 could load data from the mask ROMs about 100x faster than from the PS’s CDs, and with much lower latency. All of these differences would lead to entirely different games for both game consoles, with the N64 being clearly superior for 3D games, yet the PS being released long before the N64 for a competitive price along with the backing of Sony would make sure that it became a commercial success.