Most commonly a sprite is represented as a 2d array of pixels that you for X, for Y over and use math or branching to blend on to the screen. But, that's a lot of reading and writing, and a lot of the math ends up doing nothing because a lot of the pixels are intentionally invisible.
So, you could do some sort of visible/invisible RLE to skip over the invisible pixels. That's better, but it's still a complicated loop and still a lot of reading pixels.
So, many crazy democoders have decided to write "sprite compilers" that read the 2D color array of a sprite and spits out the assembly for the exact instructions needed to write each visible pixel one at a time as a linear instruction sequence with no branching. The sprites are then assembled and linked into the program code as individual functions. I believe they can even exclusively use immediate values encoded inside the instructions rather than reading the colors from a separate memory address. So, rather than read instruction, read data, write data; it becomes a read instruction, write data in two straight lines in memory.
So basically this kind of hack could not be used for a game, then, where interaction is needed?
What's harder is clipping against the sides of the screen. With no branching, there's no way to prevent the sprite from writing past the end of a line/screen (wrapping/mem-stomping). So, there does need to be a test per sprite to detect that case and fall back on a more complicated blitter.
The Allegro game framework had a compiled sprite jitter as a feature early on. So, that would be existence proof of them being used in games :) http://alleg.sourceforge.net/stabledocs/en/alleg016.html
However, modern games use GPU acceleration instead of plotting the pixels with the CPU, and most higher languages don't expose the sort of functionality you need to use this trick in the first place.
Some of the stuff would be completely at home as installation art in any top modern art museum. My favorite is https://www.youtube.com/watch?v=XF4SEVbxUdE done in 64kb!
Here's the results with links to productions (most of them have youtube videos by now)
I wonder if youngsters who didn't grow up thinking 1 MHz is a perfectly acceptable CPU speed and that 640 KB is a whole lot of RAM will understand what the fuss is about here...
They won't, and thus they don't understand the value of demos in the first place. But don't blame them, even back in the days I knew many people who could not appreciate demos either.
Edit: happily I'm wrong. Quoting ajenner below, "there are emulators (for other targets) which do emulate NTSC decoding properly, but until I did the research for this demo nobody understood how the CGA card generates composite signals well enough to be emulate it properly. I have some code which I hope to be adding to DOSBox (and any other emulators that want it) soon."
I don't feel the ethics of open-source apply here or to any works of art.
Programs like Microsoft Word, which have a near-monopoly on the work that literally billions of people do everyday to be productive and feed their families, when not distributed in a free manner, are tools of unjust power.
I don't feel this person's expressive work, a lifelong dream with no monetary gain, that might merely provide a few weeks of bliss and 15 minutes of internet fame a little inspiration for the rest of us, then become horribly forgotten to the sands of time, is a tool of unjust power.
> alpha-male thing going
I am sorry for whatever you've experienced that leads you to sexist comments like this. I hope that it's able to work its way through your life until you reach the point that you can simply share another person's joy without feeling entitled to have a piece of it yourself.
I can see that my words can be easily interpreted like you did but I was quite literal is stating that the culture is WONDERFUL. I have no hatred against them although I'm definitely an outsider.
Also, I was literal when I referred to the closed source of these creations. I don't demand or expect them to release any source code. I'm merely wondering whether these demos would be MORE interesting with the source code released as well. As always. In 2015 it seems slightly weird that they don't.
To be clear, I definitely share the joy the authors feel accomplishing these feats. Deep respect.
But I don't get your sexism comment. I maintain that the sub-culture involves some behavior that can be described as "alpha-male". Maybe I was inaccurate with the wording. Could have said "competitive" as well.
The main reasons, afaik, for demo sourcecode to not be released are mostly circumstantial. Either the democoder forgets about it, because a lot of the code is one-off stuff and the next demo is going to be fresh and new! The other reason is that their code is a terrible mess of glue, ducttape and kludges, hacked together moments before the compo deadline (see article ;-) ). The democoder intends to clean up the code (see elsewhere in this thread ;-) ) but then forgets about it because after-demoparty-crash. Occasionally, however, they rest up a bit and later on write a great article about the tricks they pulled (while promising to clean up the code and release it "soon") -- saying this with a great big ;-) of course.
And when something happens to be not released, I've always found just mailing the coder about it incredibly helpful, they're happy to explain, I've made great friends, and learned amazing stuff.
There are probably a bunch of weird limitations on the adjacent colours you can achieve, but it’s an impressive effect regardless!
(Here’s the obligatory wikipedia page: https://en.wikipedia.org/wiki/Composite_artifact_colors It sounds like the demo developers have taken this effect & turned it up to 11.)
"QPs 512 mode is pretty straightforward; its only color limitation being that it can display a maximum of 40 colors on a single scan line. Mode 4K uses a special technique called "interlacing" in order to display a supposed 4,096 "colors -- http://www.atarimagazines.com/startv3n2/quantumpaint.html see also http://www.atari-wiki.com/index.php/ST_Picture_Formats
[0] Example: https://www.youtube.com/watch?v=TfVe9l77zLU
I wonder how much you could improve the effect (i.e. the woman after the 4:00 minute mark) by making it move. From the way it's drawn I'm not sure if you could get even 2 fps though.
Probably a lot less tricks up the sleeve are possible (especially with 3D accelerators and dependency on a lot of proprietary AND very complex software)
Or maybe just drop to the framebuffer and push pixels like it has always been done
Sorry but doesn't that mean there are a LOT MORE tricks up the sleeve possible? They might be hard to find if you have to reverse a proprietary driver, but why not? :)
I see this demo as somewhat of a challenge to the emulator authors.
DOS is more something you run "on" than "in". It's just a filing and utility layer, no task scheduler, no memory protection.
