Browsed by
Category: Programming

Demoscene is not dead

Demoscene is not dead

Comments 0 Comment

Andreas from Insomniac Games made a Amiga 500 demo in 2019 as part of this work with The Black Lotus demo group. He presented not only the Eon Amiga 500 demo, but tons of great technical information about the 4 years it took to develop it.

Old demo scene programmers hold amazing amounts of wisdom. When solving the core pieces of logic, I found this is true (but when doing larger, complete system development, these don’t work)

Work backwards from desired outcome to discover your constraints. Don’t just brute force. Instead, ask, what must be in place for us to get the peak performance from the key component we’re dependent on (render, disk load, etc). Then work from that constraint.

Do everything you can at compile time, not run time. Pre-compute tons of things – even the build-up of the data structures in memory. Just run it and then save and reload that blob automatically.

Over-generalizing early is a trap many devs fall into. Solve the problem in front of you. Trust that you can delete the code and do something else if it sucks. It’s cheaper and faster than trying to anticipate things ahead of time. Do the simplest thing that will work and if it sucks come back and delete it.

If you end up with a small runtime table/code that doesn’t require runtime checks because you can prove it can’t go wrong, you’re doing something right.

When developing, the actual Amiga is super slow and limited. They took an Amiga emulator and hacked it up so they could debug on it instead. Using calltraps to trigger the emulator, they added memory protection, fast forward, trigger debug, loading symbols, cycle accurate profiling, single step, high-resolution timers, etc. Also allows perfect input playback.

Modern threading and consumer/producer components (disk loading, data transfer, decompressors, etc) often just throw things in buffers and YOLO. There’s no clear backpressure to show you where you’re wasting time/space. Running on this kind of hardware/simulator shows you how much time the design is wasting by poorly and inefficiently designed algorithms/constraints.

Presented at Handmade Cities event in Seattle at: https://handmadecities.com/

Making a game in Assembly

Making a game in Assembly

Comments 0 Comment

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.

Doordash Principal Engineer on Microservices

Doordash Principal Engineer on Microservices

Comments 0 Comment

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

Comments 0 Comment

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.

Programming for the Larrabee/Xeon Phi

Programming for the Larrabee/Xeon Phi

Comments 0 Comment

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.

ASCII render shader

ASCII render shader

Comments 0 Comment

Acerola created a graphics to text shader. He talks about a number of interesting techniques beyond just ASCII lookups such as: edge detection, depth color falloff, blooming and tone mapping, color tones, color quantization, and other filters, etc.
Definitely worth a watch and you can check out a good amount of his code on his github repro.

Blue-screen Windows on purpose

Blue-screen Windows on purpose

Comments 0 Comment

I wrote awhile back on how to crash Linux/cause a Linux kernel panic in order to test how your program can handle a crash – but can you cause a Windows blue-screen programmatically?

Raymond Chen of the New Old Thing describes a variety of methods to crash Windows purposefully. He also cautions against ad-hoc methods like killing winlogin.

Methods you can use to cause a Windows Blue-screen:

  1. Windows allows you to configure a specific keyboard combination to cause a crash. You set some registry keys and then can crash a system by holding right CTRL then pressing scroll lock key twice. You can also customize the key sequence via registering custom keyboard scan codes. If you have a kernel debugger attached it will trigger the kernel debugger after the crash dump is written.
  2. The best way to trigger an artificial kernel crash is to use NotMyFault, which is part of the Microsoft Windows SysInternals tools.
Demo scenes are not dead

Demo scenes are not dead

Comments 0 Comment

Massive in the 90’s, Demoscenes are not dead. Revision 2024 demo party just took place March 29th to April 1st in Saarbrücken Germany.

There was music, seminars, videos, livestreams, a 5k run, and of course – amazing code demos. This included some competing 256-byte demos here. One of the best was a post-apocalyptic black-and-white city created with just 256 bytes of Gopher code running on DOS.