256 colors is enough for everyone

In this video I use source code as means to illustrate how stunning RGB graphics can be achieved on a 256-color screen, so much that you actually may doubt whether it is really only 256 colors.

Note: The animation does not look blurry because of dithering. Dithering does increase blurriness a little, but in a different way and most certainly not this much. The reason to blurriness is that the actual video is all about orbs that do not have a defined edge (they're just clouds of pure light). And then there's motion blur that is added to it. In other words, the _original_ video material is blurry. I created it this way to maximize the number of color mixtures shown.

[SPOILERS BELOW]
Disclaimer: The story behind this video is a fabrication to justify the fact that the code is too complex for QuickBASIC to run, and too heavy for today's computers even if translated to C, unless run on a multicore CPU. All the technical details are absolutely correct. I did indeed write the first revisions of this program in QB, but I then translated it to C++, with which I created the actual animations after refining the code a bit, and I backported the changes to QB to show how it _would_ be done, did QB not have those limits. The reason why it is slow is not because of dithering, but because of the really ineffective algorithm for rendering stars, dithering or not; what with doing some 25000 distance calculations tests _per pixel_.
[END SPOILERS]

Also, I am not advocating anyone to replace 24bpp with 8bpp. Rather, I am trying to educate programmers to utilize paletted resources better, and I illustrate some exact algorithms with which to achieve that. Stop using floyd-steinberg for GIF animations!
If you cannot get the program working, you are not yet part of the target audience.

Note: In this video, I used a copy of actual QuickBASIC 4.5 by Microsoft... well, Megasoft Corp. However, after creating and publishing this video, I discovered QB64, a modern free port of QB. I ported this program to QB64! It works, though minor changes. Here is a link to the QB64 version's source code: http://bisqwit.iki.fi/jutut/kuvat/pro...
Note that it still requires computers from a parallel universe to run smoothly...

• Category

  Education

[matsv201]

Well 25 000 calculations strings per pixel. Thats about 2 biljon loops per frame and probably 50 biljon per second, probobly neading about 4 cores of around 3Ghz (128bit simd) fully optmized code to make it run. Its probobly not that hard to make it optimized the pallet for every frame, then it probobly look as god as a 12 or 16 bit grapichs.

[Bisqwit]

Thanks for the analysis! :-) I double checked it and your math seems to match. But of course, it would be much smarter to optimize the actual algorithm, so that there won't be 25000 calculations per pixel, rather than to micro-optimize using SIMD and multithreading.

[zungaloca]

subs are really fast

[Rogue Packets]

If you wanted to, you could *give* the orbs defined boundaries by using Atkinson dithering.

[Bisqwit]

At least if you use BASIC. That's why I recommended the approach of porting it to the fastest compiler & language available to you. :-)

[intel386DX]

on I see now I run your source code with this windows version of QB an realized that I need probably an a super computer to run it properly like in your video :D

[Bisqwit]

The video also shows a QuickBASIC version 4.5 made by Megasoft Corp, not by Microsoft. Yours is no doubt made by Microsoft. Please read the subtitles! (Also, reading the video description may be wise.)

[intel386DX]

I see your link of source code is for QB64, but the video shows version QuickBASIC 4.5 can you post this source code , so I can try to run it ? :)

[Bisqwit]

To run it, you should port the program to the fastest language and compiler at your disposal.

[intel386DX]

ok then which version should I us to run the program?