A new line drawing method for the cycle savvy
quiss.org
quiss.org
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.
> 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)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.
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.
> “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.”
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?
They are good ways to distribute programs for customers but that’s it.
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.
Of course you can do all this natively too, but you have to enforce the constraints yourself.
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.
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.
The browser itself is not very a interesting target for this kind of demo, since it doesn't have much limitations and changes over time too.
And with browsers, why not just push video? Could pre-render it in some farm.
In the end it is not just that interesting platform compared to even native things.
Ok, but then back in the era of the C64 why weren't they making cave paintings? ;)
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.
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".
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.
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.
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.
If some frontend developer would make a demo without using webgl or webgpu that would actually get interesting.
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.
What are you trying to say here? That old computer art is the most restrictive artform imaginable?
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.
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.
https://8bitworkshop.com/v3.10.1/?platform=c64&file=hello.da...
Also has NES, Sega Master System, ZX Spectrum, etc.
EDIT: I think it’s this? https://youtu.be/FpGwT0QqJbY
What you can see is literally program execution, with the fastest changing characters often being inner loop vars.
I will be investigating further but to anyone else interested in this specific rabbit hole:
VICE, also OS agnostic: https://vice-emu.sourceforge.io/
Enjoy.