Hacker News Reader

Comment by Tepix | Hacker News Reader

At first I was surprised they didn't use any assembly language. However, GLSL is their replacement...

Especially in 64ks, assembly isn't particularly necessary - limited use of the standard API and a good exe packer will almost always get you under the limit (especially when a lot of your code is GLSL, as text compresses well).

Smaller intros like 4ks, on the other hand, will often use assembly (although completely shader-based ones are becoming more common).

I wonder how common GLSL is for demos, though; as far as I know you have to have the actual source text and send that to the driver at runtime for compilation. In contrast, shaders for DirectX are AOT-compiled, greatly minimising their size. An executable packer might mitigate that for the most part, although it probably depends.

In this particular case they noted that they weren't size-constrained anyway.

The article mentioned that the final executable was packed again, so the GLSL source code is also stored compressed.

Zipped GLSL (if you're using short variable names) is usually smaller than the corresponding DX byte code, so it turns out to actually be an advantage.

Both GLSL and HLSL are very popular, for both 64kB intros and 4kB intros. Even Elevated is storing the actual text in the binary (http://www.pouet.net/prod.php?which=52938). Compressed text can be quite small.

I wrote a minifier specifically for these use-cases and it has been used in many demoscene productions: https://github.com/laurentlb/Shader_Minifier On a 64kB intro like Guberniya, it can save a few kilobytes (but size was not an issue for them) - after compression.

Actually a better comparison for shader languages is doing DMA with the Blitters on the Amiga.

https://en.wikipedia.org/wiki/MOS_Technology_Agnus

Actually the interesting part in Angus is the Copper, a small "co-processor" (which can trace its roots to the Atari XL/XE series and its ANTIC processor) that could execute instructions triggered by the beam passing specific coordinates on screen.

The obvious advantage of this is that you do not need to interrupt the 68k CPU, which in the era of single digit Mhz speeds, was very nice.

The blitter (and other things) could be controlled by the Copper..

Yes, that is what I had in mind, but could not remember any more the details how it used to be.

Yes, the Copper is a very cool thing. I've done insane copper lists with up to 52 splits per rasterline(each split is 8 pixels wide), and then a unique new set of colors for each rasterline. The result is very mesmerizing. It can look like this: https://youtu.be/d1axngYxuuo?t=3m19s and this: https://www.youtube.com/watch?v=fFeHd5hoRyM

The Copper can also wait for the Blitter to be ready, and the Copper can give the Blitter new instructions and start a new blit. The circle would be complete if the Blitter could blit into the hardware registers for the Copper and other chips, but it cannot. :-( I think the Atari STe Blitter can do that though.

But you can use the Blitter to modify the Copper list, so perhaps they together are Turing complete?

Reply on news.ycombinator.com