4k here means that the program is 4096 bytes long and not the screen resolution. Yes, that's only four thousand and ninety six 8-bit octets.
And they are supposed to run on a machine with 985.248 kHz clock frequency. Yes, thats kilo as in one thousand.
The machine in question has only a single core (with a single thread), but the demo cleverly uses the CPU of the floppy drive for a speed up, so you could say it features true parallelism on multiple cores.
Also arithmetic on the machine operates only on 8-bit values and of course there is no hardware multiplication. Division, you wouldn't even think about.
To state the implicit/obvious, the CPU is a 6502 from the assembler mnemonics and specifically a 6510 in a C64 from reference to the 1541 external floppy drive.
> Note that as far as the slope math goes, Bresenham is special since it doesn't require the division of x by y, but BRR lines do. So for short line segments, Bresenham can still "win". In fact, BRR lines also need a bit more elaborate math for the remainder. (So this method really shines if you're able to pull in the 1541 for help. See my upcoming post about drivecode)
The BRR algorithm is 5 cycles per position vs 8-10 cycles for Bresenham, which is impressive. Its step position inner loop calculation is only
cpx #imm ;compare x-register to constant
adc zp ;add with carry the value in (0-page) address to accumulator (a-register)
This is a cool and simple technique, it seems like the sort of thing that should have been discovered 50 years ago. Not only is it more cycle efficient, the lines are more stable in animation, which to me seems like the primary benefit. Amazing this stuff is still being improved.
Indeed impressive, but compared to when the demo scene fist started, a C64 programmer today has access to all the world’s knowledge via the Internet, and is not constrained by having to host the development environment on the same machine used for testing. Just the fact that you don’t have to reboot the entire setup and possibly even recreate your program every time it crashes, will greatly improve development throughout.
"You will have noticed that the slope-based lines above "wiggle" more. This is true, and might be considered one of the drawbacks of the algorithm. However, the fact that BRR lines are more temporally stable can also conceivably be useful in some applications."
For nearly all applications, better quality for trivial cost is preferred.
The "instability" of classic lies is almost always a benefit -- it provides a very cheap form of motion blur / time-dimension dithering anti-aliasing that hides the ugly pixel aliasing of stable lines.
BRR is only better when generating extremely complicated demos, where hyperoptimization matters more than control over the image. For most applications, drawing what the developer/user wants is more important than more complex but arbitrary effects.
On that topic there's so many things that are so simple and should have been discovered 50 years. Diffusion feels like it should have been discovered 30 years ago (adding noise to an image and solving for the reverse to generate new images of the same kind).
> adding noise to an image and solving for the reverse to generate new images of the same kind [should have been discovered 30 years ago]
Diffusion networks sre new, but denoising autoencoders work on the principle you outlined and were invented in the eighties.
The reason neural nets didn't become popular sooner is because achieving the sorts of results they produce nowadays requires a ton of computing power and a ton of data to train from.
If anyone wants to see a recording of the demo, click on the "Boo!" link in the article to view its entry on the CSDb site. The blue sidebar on the right has a YouTube link.
The new technique enables a bigger cube at full frame rate. From the article:
> “Apart from unlocking a number of improvements in XOR fillers and similar effects, the method, as used in the 4k, also significantly raises the bar for realtime filled sprite vector cubes. The cube displayed in "Boo!" draws over an area of size 172x172, up from 140x140 in Protogeo 100%. This improvement to size is because line computation that previously either took 7+ cycles per pixel (or exhaustive amounts of memory) can now, thanks to the BRR ("bit reverse rendered") line method, done in just 5 cycles per pixel.”
Here's the non-size-limited competition winner, for the curious. It's freakin' incredible - and 23 minutes!, but you can skip from 5m - 8m (I think extended for music):
I'm surprised the demo scene is still targeting the C64.
Why not the browser?
Would be a lot of fun to try the different demos then. Would be entertaining and educational to see different things you can actually do in the frontend these days.
Also, why not directly link the demos to a C64 emulator, so at least on can try them out?
There are browser demos, but it’s not really a unique platform. With WebGL and WebAssembly and soon WebGPU, you can pretty much render anything in the browser. There’s not much difference between making a Windows demo and a browser demo.
Old platforms like the C-64 are appealing to a certain kind of clever person because the constraints are fixed and a lot of the possible tricks have already been thoroughly exploited in the past. When you find a novel trick, it will be remembered by the aficionados.
Pure Wasm is, OTOH, a fairly interesting constrained platform if you keep the JS glue to a bare minimum (essentially requestAnimationFrame, call Wasm, and blit the TypedArray you get onto a <canvas>, plus similar for the audio) and don’t export any JS APIs to the Wasm side either. Then essentially all you can do is pure computation without side effects, writing the results to a fixed chunk of memory to be blitted. No HW acceleration, no OS services, no "unbounded" heap to allocate from at your leisure…
Of course you can do all this natively too, but you have to enforce the constraints yourself.
Demoscene targets whatever platform can display some graphics and make some sound. People write C64 demos because they want to. It’s a subculture within the greater scene, and approximately zero percent of C64 sceners would want to move to writing browser-based demos. The whole point of the C64 scene is to cycle-shave and torture the hardware into performing tricks its designers would never have thought about.
WebGL is a very high level API because OpenGL itself is a very high level API in this context. People have been coding directly on top of OpenGL since it was first created, including 4k demos. A demoscene demo will itself implement whatever custom "graphics engine" is needed (for a 4k, essentially nothing is needed). Demos don’t commonly use third-party dependencies because the entire idea is to show off your (group’s) programming and art savvy.
What draws me to the C64 demo scene is that they use a fixed hardware in ways that it was never supposed to. Doing all this wonderful graphics and sound in just a couple of bytes on hardware that's less capable than an average washing machine is just mind blowing.
The palette is quite clever. It’s optimized for being able to reasonably represent real-world things, as well as gradients, unlike the garish primary color based palettes of some of its contemporaries.
I once tried to figure out the smallest modification to cga hardware that could be made to substantially improve the palette.
Inverting the digital red line produces some amazing options. Not least because the palettes containing red became black enabling the colour that was typically used for black to be reused as this was the only palette entry that could be set to any of the 16 colours.
You can make funny tricks when passing image as composite. Where with those you can produce other colours. And state of computers were quite limited and primitive then.
On other hand for business use, those are still acceptable, everything was text anyway.
Cave painting is less limiting than an old computer, not more. You can paint anything you want in a cave wall: reproduce a flat old painting; make a graffiti with a 3D effect; carve the wall to create depth; programatically generate a pattern of colours that is then painted by a robotic arm…
On a computer you’re constrained by the hardware and software. It’s its own smaller world which exists outside of you and has intractable limitations. But if you dedicate enough time to understand the system and keep trying, you may achieve what was otherwise thought impossible. The process of discovery can be more enjoyable, interesting, useful, and artistic than the output itself.
Absolutely not. If I said “grey is lighter than black” would you think I was saying “grey is the lightest colour imaginable”? That would be quite the extrapolation.
I have never considered what “the most restrictive artform imaginable” is. I’m not even convinced that’s possible to assert definitely. Could make for an interesting thought experiment, though.
I think you missed my point. Let's say for the sake of argument that HP48 art is more restrictive than C64 art. Why weren't the C64 artists using HP48 calculators instead? And why aren't we looking at HP48 art in awe, instead of this C64 "non-art"?
Let’s take pixel art on console gaming as an example. In the early days, games used pixel graphics due to technical constraints. Artists were limited in what they could achieve and had to get creative within the limitations to push the software and hardware to its limits in pursuit of a specific vision. Everyone had the same set of restrictions but thanks to creative technical decisions some rose above as exceptional.
There is a particular kind of enjoyment in creating a lot with very little. If your digital art can be hundreds of GBs in size, your 3D rendition of the Sistine Chapel will be judged by its faithfulness; but if you’re only allowed a handful of KBs and everyone believes any kind of 3D graphics are impossible at that size, your dinky little rotating cube becomes an impressive technological feat. Context matters. A tractor pulling a plane is not impressive; a man pulling a plane is. Most people could do the former but not the latter.
Furthermore, not all limitations are equally interesting. Nostalgia and popularity also play a role. Today, pixel graphics are an aesthetic choice. Developers and artist can go beyond what was possible when they were a necessity and create something entirely new. Yet some still derive enjoyment and pride from following the limitations of yore to the letter: there are games created in the 2000s which work on the NES.
Browser doesn’t really have limitations in that regard. Thus it offers nothing unique in that sense that’s not already in normal windows/whatever desktop platform demos.
If some frontend developer would make a demo without using webgl or webgpu that would actually get interesting.
I love this comment. It just cuts through all the pseudo-traditionalist cargo cult BS that surrounds topics like the one being discussed here.
To be clear, I think those demos are cool and contain interesting technology. But the pretense that the cutting edge equipment of a specific time is somehow the measure of art and what came after is "just not that interesting" is difficult to stomach. Pity that attitude is so common on HN, I would enjoy being here much more if it weren't.
> the pretense that the cutting edge equipment of a specific time is somehow the measure of art and what came after is “just not that interesting” is difficult to stomach.
Nobody meant that C64 demos are the measure of all art, or that things done today aren’t interesting. It seems like you’re taking what @Ekaros said out of context and making big assumptions and projecting them and making yourself unhappy. Demos on old hardware are a measure of demo scene demo art, not of art in general. That’s what the comments here are saying. The point of demo scene is pulling clever tricks in a very constrained environment, so doing the very same demos in the browser, as was suggested at the top, misses the entire point. It would be very easy to do, wouldn’t push the hardware, and it’s relatively bad art compared to what you can do in the browser, so it would be totally boring. In the context of C64 software, these demos are difficult to make, push the hardware beyond it’s design, and are aesthetically much better and/or more interesting than the relative ‘cave paintings’ people were actually making on C64s in the 90s.
There are, however, other kinds of demos done in the browser today (see for example ShaderToy.com) and they pull other tricks with a similar mentality, of having artificial constraints and seeing what you can do within those constraints. There’s tons and tons of great digital art made on modern hardware that can be appreciated in it’s own context. The context is what makes C64 demos interesting, which is why changing the context makes it less interesting, and why calling it names is unfair and demonstrates a misunderstanding on your part.
I disagree. I think it misses the point completely.
The C64 had limitations not because of its relative capabilities from today but t because of its literal limitations. Even back in 80s and 90s, when those systems were still relevant, people were pushing the capabilities of those systems for fun.
There are demo scenes for web browsers of sorts but they’re not the same as the C64 era because there simply isn’t any limitations on what you can do in a modern browser. So instead of the demos like in this article, you get people either implementing $game in x lines of code (often with about a hundred thousand lines of additional dependencies that weren’t counted), or someone building interesting mini games in WebGL.
However when you look back at the web prior to WebGL, WASM, etc, there were the more C64-like demos because the web back then was limited. Which is when you saw things like Linux running on an x86 emulator in pure JavaScript.
So it absolutely is about the fun of trying to build something that the platform shouldn’t support given the platform’s limitations. For some people, it is like a sudoku for crossword. The fun in the challenge.
Now you can argue whether calling that an “art form” is pretentious not. But art is subjective so I say just live and let live on that particular point. If people think of it as an art then it is art to them. If you don’t then it’s not art to you. But it’s silly to argue other whether it is or isn’t art.
For this particular form of demo, modern hardware is just too powerful, and the quality of the demo is purely the quality of the assets. So a demo for a modern platform would require the same scale as what big AAA game or movie studios produce. Which is also art, but a different kind.
With limitations, more interesting cleverness, and a scale of project a single person can muster, can thrive instead. So there probably really is something to this particular generation of hardware, the order of thousands of bytes is more "human scale".
yes, I was a keen follower of the demo scene in the 16 bit days. not so much the C64, but the Amiga, and then the mid-late 90s PC scene.
Back then, it wasn't so much about limitation, though size-coding was always a thing. It was about seeing something new and cool that hadn't been done before. Pushing things further artistically and technically at the same time.
The Amiga was one of the most powerful machines available to the home market so programming it didn't feel like working under constraint, it felt like pushing the envelope of what was possible. Nobody had anything to compare it to, except maybe SGI workstations, which you'd only see on TV shows about movie special effects.
At that time demo programmers had parity with game developers and were sometimes the same people. You generally saw higher quality and more innovative effects in a demo than you did in even the biggest video games. And there was no video playback on computers, so all graphical effects you saw had some element of demo-scene adjacency, which made the whole thing feel unified, progressive and relevant.
As time went on and technology changed, it became less feasible for lone bedroom coders and small groups of Scandinavian teens to reach that "edge", and keep pushing the boundaries with the same mindset as before, so the emphasis of the artform seems to have changed towards constraint, and towards working with retro machines as historical artefacts.
The scene has had to reinvent itself a few times. I remember reading articles in HUGI diskmag 20-odd years ago discussing how demos had changed from being about hardware hacking, and getting graphics chips to do unusual things, to becoming more of an "algorithmic trip" thanks to the new pc graphics cards that were coming out.
Fixed hardware platforms are more interesting for demos, because they provide a level playing field, and because anything that the hardware will allow goes.
If anyone wonders why it starts with a lot of character garbage on the screen: I can be wrong, but I think it is usually the decompression. The demo is only 4K in size, but gets expanded after loading so it fills the entirety of the available memory. Not to waste space for the decompression routine, it runs directly in the video RAM which is latter overwritten.
What you can see is literally program execution, with the fastest changing characters often being inner loop vars.
Yes; throwing the decompression routine and/or its variables into screen RAM also has the bonus of making it obvious to the user that something is happening without spending any time implementing a progress bar. Sometimes there's text like "Decrunching..." or "SuperPacker2.4 by c00lDude/TLA".
This was my first introduction to the “demoscene”. I would really like to get into this type of programming, it is so beautiful. The efficiency and creativeness of the programmers who make these c64 demos is jaw dropping when looking at any of the top submissions.
I will be investigating further but to anyone else interested in this specific rabbit hole:
And they are supposed to run on a machine with 985.248 kHz clock frequency. Yes, thats kilo as in one thousand.
The machine in question has only a single core (with a single thread), but the demo cleverly uses the CPU of the floppy drive for a speed up, so you could say it features true parallelism on multiple cores.
Also arithmetic on the machine operates only on 8-bit values and of course there is no hardware multiplication. Division, you wouldn't even think about.