Browsed by
Category: Technical

Making a game in Assembly

Making a game in Assembly

When teaching myself to program as a kid, my first language was type-in BASIC programs. After that, I made the very un-orthodox choice to learn assembly. I wrote a small database, a TSR (Terminate and stay resident program), and a couple other small creations.

Looks like GreatCorn did one better by writing his own game in x86 assembly.

RESound: Interactive Sound Rendering for Dynamic Virtual Environments

RESound: Interactive Sound Rendering for Dynamic Virtual Environments

About 15 years ago, people noticed that rendering virtual scenes with ray tracing was a lot like how sound propagates through an environment. Light rays travel through open spaces, hit objects and then reflect, refract, and bend. Sound waves follow many of the same principles.

What if you use the same ray casting methods to simulate sound traveling through an environment? Instead of standard hacks on sound to make something sound like it’s in a tiled bathroom or a big orchestra hall, you could accurately simulate it – reducing artist time. Simply play the sound and let the algorithm figure out how it should sound.

Not sure what other research has happened since. It was too computationally expensive for real time back then, but it was a cool idea and maybe we have the compute for it with today’s GPU’s.

Paper: https://gamma.cs.unc.edu/Sound/RESound

Doordash Principal Engineer on Microservices

Doordash Principal Engineer on Microservices

A reasonable good, simple discussion on the pros/cons of monoliths and microservices.

Some interesting comments:

  • Conway’s law – the structure of a system reflects the structure of the organization that makes it.
  • Microservices have their issues because they are a technical solution to an organizational problem – trying to solve when a team gets too big.

Here are the links referenced:

The gritty world of retro game analysis

The gritty world of retro game analysis

The world has gotten very familiar to retro hardware re-creations, game emulation, re-releases, speed runs, creating new games for old platforms, as well as new exploits, tools, and discoveries. The nitty gritty work of doing all of this, however, is a labor of love. For those that dig into the binary, there’s tricky copyright concerns that need to be managed, only scraps of information about old hardware and software, highly optimized/tricky code that is tough to read, and almost no financial gain – except for commercial re-releases.

Made Up of Wires walks us through a live bit of decompiling of the PS1 classic: Castlevania: Symphony of the Night to give you a taste of the work involved in this kind of work. Not really that different than any other reverse engineering but surprisingly accessible as these old games were relatively small and simple.

Make your own video card!

Make your own video card!

Ben Eater decided to build his own VGA video card. Well, technically it’s more of a display adapter/controller since the card doesn’t provide any rendering or accelerate the image buffer generation portion – but it’s still a pretty fun watch.

This is pretty much how computer graphics started. Someone built a display controller. Then others added some helper hardware to speed up the buffer fills, then blitting, then rendering, AI upscaling/noise reduction, and now full on AI rendering. What a wild technology ride – but it was this early stuff that really got me excited about technology. You could create and build all of this kind of amazing stuff yourself.

Programming for the Larrabee/Xeon Phi

Programming for the Larrabee/Xeon Phi

Back in the day, I worked on this little project called Larrabee – which later turned into the Intel Xeon Phi coprocessor. It was an ambitious and exciting platform. It consisted of a ton of 512 bit wide instructions to operate like a lot of streaming GPU architectures, yet was fully general purpose x86.

It turned out that getting performance out of this hardware was difficult. In order to get the full potential of the hardware, you simply had to utilize the vector units. Without that, it is like writing a single threaded app on a 8 core system. Single SIMD lane operation just wasn’t going to cut it as was written about in 2017 International Journal of Parallel Programming article:

“Our results show that, although the Xeon Phi delivers a relatively good speedup in comparison with a shared-memory architecture in terms of scalability, the relatively low computing power of its computational units when specific vectorization and SIMD instructions are not fully exploited makes this first generation of Xeon Phi architectures not competitive”

Using the Xeon Phi Platform to Run Speculatively Parallelized Codes

The paper, and the host of others linked on the page as references, are a good read and gives some hints why fixed-function GPUs have an advantage when it comes to raw streaming throughput. Hint: cache and data flow behavior is as, if not more, important as utilizing vectorization in such architectures.

Utilizing YouTube for infinite storage

Utilizing YouTube for infinite storage

Cloud storage is increasingly becoming less free. You can’t go long before your iPhone or Google account notifies you that you’re almost full or already full – and give you a link to a handy-dandy subscription. But there is one place where you can upload all you want and the storage is still free – YouTube.

Adam Conway wrote up a fun little program that does exactly that. He creates video frames full of data and uploads them to YouTube. He tried QR codes, but YouTube compression artifacts made that untenable. Instead, he went brute force and each 1 or 0 was a 5×5 block of pixels set to the same color. At 1920×1080, that generates about 10KB of storage per frame.

He fired it up and gave it a whirl. It worked! He even posted the code on github. It’s definitely too slow and uses a tremendous amount of storage. To use for any meaningful data as you need to take the input file and encode each bit into a 5×5 pixel in an image, then encode the images together into a video file.

Still, it’s the one free place on the internet.

Article:

Connecting an external GPU

Connecting an external GPU

Do you want to do AI work but have have a laptop, NUC, or other tiny form factor computer that cannot accept a gigantic GPU? Does your system have an Oculink port? Then maybe one of this external GPU doc is for you.

Minisforum DEG1 eGPU Dock allows you to plug in an external GPU to your small form factor PC. The only trick is that you’ll need an Oculink port. A number of small form factor PC’s now come with Oculink (like this AtomMan X7 Ti).

OCuLink is short for “Optical-Copper Link” that allows you to connect PCIe devices using an external cable rather than an internal slot. OCuLink has been around in the server world for about a decade, but starting in 2024 has becoming increasingly present on tiny form factor pc’s like the Intel’s NUCs. OCuLink is gaining popularity because it’s cheaper than complex solutions like Thunderbolt and offers almost direct PCI speeds. OCuLink is virtually an extension of your device’s PCIe slot, boasting a bandwidth of up to 16 GB/s which is much faster than Thunderbolt 4 which caps out at 5 GB/s.

You can also buy desktop PC versions of Oculink (like this one) to try things out. They’re kind of unique because they come with 2 components. A shim M.2 card to plug into your PCIe slots, and then it connects via Oculink to a small connector board that your graphics card plugs into:

Here’s a review of the setup and performance. It’s extremely impressive. You can play Cyberpunk in 4K raytracing on a connected 4090 in Ultra at a steady 70fps. Even in overdrive it maintains a steady 50+ fps. Horizon Forbidden West at 4k Very High settings plays at a stable 80-100fps – even without framegen.

While it’s still too much of a Frankenstein approach right now that isn’t consumer friendly, but I think OCuLink has really raised the bar and is going to make Thunderbolt and USB have to really up their game.