64k

2 Articles

Generating Instead Of Storing Meshes

March 30, 2023 by 23 Comments

The 64kB is a category in the demoscene where the total executable size must be less than 65,536 bytes, and at that size, storing vertexes, edges, and normal maps is a waste of space. [Ctrl-Alt-Test] is a French Demoscene group that has been doing incredible animations for the last 13 years. They’ve written an excellent guide on how they’ve been procedurally generating the meshes in their demos.

It all starts with cubes. By stacking them, overlaying them, reusing them, and tiling them you can get better compression than raw vertexes. Revolution was the next trick, as it uses just a few points, plotting it via Catmul-Rom splines, and revolving around an axis. The numbers are pairs of 32-bit floats and before compression, a detailed pawn on a chess board can weigh in at just 40 bytes. Just these few techniques can take you surprisingly far (as seen in the picture above).

They later worked on deforming cubes and placing them into a semi-randomized column, which happened to look a lot like plants. This isn’t the first generated vegetation we’ve seen, and the demoscene technique focused more on getting the shape and setting the mood rather than being accurate.

Signed distance fields are another useful trick that allows you to generate a mesh by implementing a signed distance function and then running a marching cubes algorithm on it. In a nutshell, a signed distance function just returns the distance to the closest point on a surface from a given point. This means you can describe shapes with just a single mathematical equation. As you can imagine, this is a popular technique in the demoscene world because it is so space efficient in terms of code and data. [Ctrl-Alt-Test] even has a deep dive into one of their projects, Immersion, with a breakdown of where the space is allocated.

There are plenty of other tips and tricks here, such as generating textures and developing a C++ hot reload system for faster iteration. It’s just incredible that the executable that plays the whole video is smaller than just a JPEG screenshot of the video. It’s a reminder that the demoscene is still fascinating with new tricks and experiences even as the hardware stays the same. Continue reading “Generating Instead Of Storing Meshes” →

Make Your Commodore 16 64k, But Not A Commodore 64

March 23, 2019 by 25 Comments

The Commodore 16 was a budget home computer from the mid 1980s, the entry-level model in a wider range of machines. As its name suggests it only has 16k of memory in keeping with its budget status, and while it has the rest of the hardware necessary to run software intended for its 64k stablemates, that 16k is impossible to expand without modifying the machine. Should you have a ’16 in your collection this is not a particularly arduous process, and Tynemouth Software have gone into great detail over how it can be achieved.

As was quite common in machines of the period, the address lines for the RAM area above the fitted 16k are not wired to disable it when those addresses are selected, so the same 16k appears mirrored three times in the space between it and the 64k limit. Thus simply plugging in a 64k cartridge would result in the top 48k being unusable, and some means of disabling or supplanting the internal chips was called for. Contemporary upgrades required pin or track snipping, but as they go on to show us there are some less ugly alternatives both permanent and reversible. Whichever you might favor they all at least don’t carry the huge cost hurdle in 2019 that they might have been when the machine was new. Sadly even though their cases may be similar the resulting machine will not be a Commodore 64, not even a new one.

Long-time Hackaday readers will know that the hardware designer for these machines was our Hackaday colleague [Bil Herd], and all followers of Commodore and his work should read his account of the CES trade show at the heady height of Commodore’s  fame.