Can modern AI be used to program impressive graphics effects on very low performance home-retrocomputers, in particular 'A 3D-rotating-cube'

Question

Can modern AI be used to program impressive graphics effects on very low performance home-retrocomputers, in particular 'A 3D-rotating-cube', effects that would be too difficult for a human to program on the cheapest machines

( The time-range of the home-retrocomputers I'm refering to is approximately from 1975-1985 )

NOTE : So I'm using 'A 3D-rotating-cube', rotating / displaying, satisfactorily, as a type of benchmark of achievement to be achieved on very low performance home-retrocomputers( from 1975-1985 ), on many of these machines it seems impossible to satisfactorily achieve this effect on, so therefore I am wondering if modern AI could succeed in the challenge( where humans have failed )

Answer 1

Modern AI on its own is not really advanced enough to be able to make a meaningful difference in this sense. However, there are many situations where the massive asymmetry between computational capabilities of modern computers and computational capabilities of the old computers can be exploited in ways that were not feasible decades ago.

For example, some types of modern AI are driven by, effectively, optimization algorithms (genetic algorithms etc). So, what if you use some vastly inefficient rendering strategies on old computers, but guide them by optimizing the results of their rendering by a modern computer? This gives you a vastly non-symmetric compression schemes, which were for example exploited by demoscener ilmenit who got his Atari XL/XE to generate this image

using 128 bytes of data and less then 128 bytes of code. (You can read more about this, as well as find a link to the video recording, on Pouet.) I personally was so inspired by this demo that I created my own kind of a similar asymmetric compression scheme; you can, if you want, have a look at it here.

So, my answer is yes, people do exploit the difference in processing power to create programs for retrocomputers that were not feasible before. However, I think that although the computational techniques to achieve this are often not dissimilar from the methods used for AI, most of the people doing asymmetric schemes of this kind would probably refuse to call them AI (and rightly so).

Answer 2

This is perhaps obvious, but AI isn’t magic. This has two relevant consequences here: it can’t add new hardware capabilities, and it can’t find techniques which humans absolutely couldn’t.

What “AI” is good at is trying lots of things, fast, without getting bored. So it can try lots of different ways of implementing an algorithm, in the hope of finding one which is better than anything we’ve come up with so far (this is called super-optimisation). It can also try to find simplifications of a given algorithm or implementation which don’t have too bad effects on the result; this might be the most useful approach to find ways of doing “impossible” tasks on a retro-computer.

In both cases the typical technique we’d use is known as genetic programming, or genetic algorithms: you view algorithms as a sort of DNA, and mutate and combine different DNA strands (algorithm implementations) to try to find one which has a lower “cost” (in this case, runs faster) while still producing the desired output. Evaluating the output could involve machine vision, although using humans would likely produce more pleasing results (albeit with the speed and boredom issues alluded to above).

However, don’t expect miracles — you won’t go from Alley Cat to 8088 MPH using AI...

Answer 3

Cynically, the modern usage of "AI" is little more than marketing fluff, like "cloud" and "blockchain". Doing a heavy handwave, it is the name that has been used for a lot of not-quite-there (or never-will-be-there) data-analysis techniques that attempt to get a useful answer in a timely manner from a large database of facts that would be prohibitive to do a brute-force search on. They tend to lose the "AI" moniker once they work and are routinely used. For example, most programs are too large for a compiler to brute-force search the optimal set of instructions, but it can certainly use tricks like simulated annealing to get close.

They very much can be used for throwing lots of modern CPU at optimisation for a very small machine. It is too extensive a field to list everything here, but I rather like the O'Reilly book Programming Collective Intelligence which is a nice introduction to a number of techniques which should give you plenty of ideas.

In your specific query, "AI" can (and is) used to heavily-optimise demos by throwing a lot of modern CPU at a relatively small problem. I've already given the compiler example, and in a similar vein one can skip writing the program in the first place and search for a suitable AST to generate the desired effect. It can also be used to perform extreme compression to get an image or video to fit in small hardware.

As to the likes of a 3D rotating cube, that is a simple problem which doesn't need AI. 3D games were not exactly uncommon in the early 1980s, with Battlezone and Elite being just two famous examples of the genre. The mathematics are not too strenuous on the CPU if one keeps the number of vertices down—a cube has just eight—and most of the time is spent drawing lines. Sometimes, you just need to sit down and really understand the hardware and have a good hard think about the code you need to write rather than hope a computer can be convinced to write it for you.

Answer 4

hmm why AI I think that might be much more work to code an learn AI to do something like that than write it on your own...

I usually use different approach. If the stuff I need to code gets hideous then I simply write a a small program that will create the source code for me. The same goes for data tables etc. For example this was coded by C++ on PC but runs on AVR32:

The MCU simply generate VGA image signal by using SDRAM interface and DMA the circuit consist just from MCU few resistors capacitors and diodes stabilizator and crystal. The image is hard-coded as C++ source generated by the script I mentioned before (some of you can recognize it as a loading screen from one ZX game).

Another example of this approach is auto generated code/templates I use for GLSL code running on CPU (also coded on CPU). Here vec2 template example:

template <class T> class _vec2
    {
public:
    T dat[2];
    _vec2(T _x,T _y) { x=_x; y=_y; }
    _vec2() { for (int i=0;i<2;i++) dat[i]=0; }
    _vec2(const _vec2& a) { *this=a; }
    ~_vec2() {}
    // 1D
    T get_x() { return dat[0]; } void set_x(T q) { dat[0]=q; }
    T get_y() { return dat[1]; } void set_y(T q) { dat[1]=q; }
    __declspec( property (get=get_x, put=set_x) ) T x;
    __declspec( property (get=get_y, put=set_y) ) T y;
    __declspec( property (get=get_x, put=set_x) ) T r;
    __declspec( property (get=get_y, put=set_y) ) T g;
    __declspec( property (get=get_x, put=set_x) ) T s;
    __declspec( property (get=get_y, put=set_y) ) T t;
    // 2D
    _vec2<T> get_xy() { return _vec2<T>(x,y); } void set_xy(_vec2<T> q) { x=q.x; y=q.y; }
    _vec2<T> get_yx() { return _vec2<T>(y,x); } void set_yx(_vec2<T> q) { y=q.x; x=q.y; }
    __declspec( property (get=get_xy, put=set_xy) ) _vec2<T> xy;
    __declspec( property (get=get_xy, put=set_xy) ) _vec2<T> xg;
    __declspec( property (get=get_xy, put=set_xy) ) _vec2<T> xt;
    __declspec( property (get=get_yx, put=set_yx) ) _vec2<T> yx;
    __declspec( property (get=get_yx, put=set_yx) ) _vec2<T> yr;
    __declspec( property (get=get_yx, put=set_yx) ) _vec2<T> ys;
    __declspec( property (get=get_xy, put=set_xy) ) _vec2<T> ry;
    __declspec( property (get=get_xy, put=set_xy) ) _vec2<T> rg;
    __declspec( property (get=get_xy, put=set_xy) ) _vec2<T> rt;
    __declspec( property (get=get_yx, put=set_yx) ) _vec2<T> gx;
    __declspec( property (get=get_yx, put=set_yx) ) _vec2<T> gr;
    __declspec( property (get=get_yx, put=set_yx) ) _vec2<T> gs;
    __declspec( property (get=get_xy, put=set_xy) ) _vec2<T> sy;
    __declspec( property (get=get_xy, put=set_xy) ) _vec2<T> sg;
    __declspec( property (get=get_xy, put=set_xy) ) _vec2<T> st;
    __declspec( property (get=get_yx, put=set_yx) ) _vec2<T> tx;
    __declspec( property (get=get_yx, put=set_yx) ) _vec2<T> tr;
    __declspec( property (get=get_yx, put=set_yx) ) _vec2<T> ts;
    // operators
    _vec2* operator = (const _vec2 &a) { for (int i=0;i<2;i++) dat[i]=a.dat[i]; return this; }                              // =a
    T& operator [](const int i)     { return dat[i]; }                                                                      // a[i]
    _vec2<T> operator + ()          { return *this; }                                                                       // +a
    _vec2<T> operator - ()          { _vec2<T> q;       for (int i=0;i<2;i++) q.dat[i]=      -dat[i];           return q; } // -a
    _vec2<T> operator ++ ()         {                   for (int i=0;i<2;i++)                 dat[i]++;     return *this; } // ++a
    _vec2<T> operator -- ()         {                   for (int i=0;i<2;i++)                 dat[i]--;     return *this; } // --a
    _vec2<T> operator ++ (int)      { _vec2<T> q=*this; for (int i=0;i<2;i++)                 dat[i]++;         return q; } // a++
    _vec2<T> operator -- (int)      { _vec2<T> q=*this; for (int i=0;i<2;i++)                 dat[i]--;         return q; } // a--

    _vec2<T> operator + (_vec2<T>&v){ _vec2<T> q;       for (int i=0;i<2;i++) q.dat[i]=       dat[i]+v.dat[i];  return q; } // a+b
    _vec2<T> operator - (_vec2<T>&v){ _vec2<T> q;       for (int i=0;i<2;i++) q.dat[i]=       dat[i]-v.dat[i];  return q; } // a-b
    _vec2<T> operator * (_vec2<T>&v){ _vec2<T> q;       for (int i=0;i<2;i++) q.dat[i]=       dat[i]*v.dat[i];  return q; } // a*b
    _vec2<T> operator / (_vec2<T>&v){ _vec2<T> q;       for (int i=0;i<2;i++) q.dat[i]=divide(dat[i],v.dat[i]); return q; } // a/b

    _vec2<T> operator + (const T &c){ _vec2<T> q;       for (int i=0;i<2;i++) q.dat[i]=dat[i]+c;                return q; } // a+c
    _vec2<T> operator - (const T &c){ _vec2<T> q;       for (int i=0;i<2;i++) q.dat[i]=dat[i]-c;                return q; } // a-c
    _vec2<T> operator * (const T &c){ _vec2<T> q;       for (int i=0;i<2;i++) q.dat[i]=dat[i]*c;                return q; } // a*c
    _vec2<T> operator / (const T &c){ _vec2<T> q;       for (int i=0;i<2;i++) q.dat[i]=divide(dat[i],c);        return q; } // a/c

    _vec2<T> operator +=(_vec2<T>&v){ this[0]=this[0]+v; return *this; };
    _vec2<T> operator -=(_vec2<T>&v){ this[0]=this[0]-v; return *this; };
    _vec2<T> operator *=(_vec2<T>&v){ this[0]=this[0]*v; return *this; };
    _vec2<T> operator /=(_vec2<T>&v){ this[0]=this[0]/v; return *this; };

    _vec2<T> operator +=(const T &c){ this[0]=this[0]+c; return *this; };
    _vec2<T> operator -=(const T &c){ this[0]=this[0]-c; return *this; };
    _vec2<T> operator *=(const T &c){ this[0]=this[0]*c; return *this; };
    _vec2<T> operator /=(const T &c){ this[0]=this[0]/c; return *this; };
    // members
    int length() { return 2; }  // dimensions
    };

As you can see the getters setters tend to be hideous to code so (this is just 2D now imagine 4D) the full code for vec is around 228 KByte of source. Here the script that I generated it with:

void _vec_generate(AnsiString &txt,const int n) // generate _vec(n)<T> get/set source code n>=2
    {
    int i,j,k,l;
    int i3,j3,k3,l3;
    const int n3=12;
    const char x[n3]="xyzwrgbastpq";
    txt+="template <class T> class _vec"+AnsiString(n)+"\r\n";
    txt+="\t{\r\n";
    for (;;)
        {
        if (n<1) break;
        txt+="\t// 1D\r\n";
        for (i=0;i<n;i++) txt+=AnsiString().sprintf("\tT get_%c() { return dat[%i]; } void set_%c(T q) { dat[%i]=q; }\r\n",x[i],i,x[i],i);
        for (j=0;j<12;j+=4) for (i=0;i<n;i++) txt+=AnsiString().sprintf("\t__declspec( property (get=get_%c, put=set_%c) ) T %c;\r\n",x[i],x[i],x[i+j]);
        if (n<2) break;
        txt+="\t// 2D\r\n";
        for (i=0;i<n;i++)
         for (j=0;j<n;j++) if (i!=j)
            {
            txt+=AnsiString().sprintf("\t_vec2<T> get_%c%c() { return _vec2<T>(%c,%c); } ",x[i],x[j],x[i],x[j]);
            txt+=AnsiString().sprintf("void set_%c%c(_vec2<T> q) { %c=q.%c; %c=q.%c; }\r\n",x[i],x[j],x[i],x[0],x[j],x[1]);
            }
        for (i=i3=0;i3<n3;i3++,i=i3&3) if (i<n)
         for (j=j3=0;j3<n3;j3++,j=j3&3) if (j<n) if (i!=j)
            {
            txt+=AnsiString().sprintf("\t__declspec( property (get=get_%c%c, put=set_%c%c) ) _vec2<T> %c%c;\r\n",x[i],x[j],x[i],x[j],x[i3],x[j3]);
            }
        if (n<3) break;
        txt+="\t// 3D\r\n";
        for (i=0;i<n;i++)
         for (j=0;j<n;j++) if (i!=j)
          for (k=0;k<n;k++) if ((i!=k)&&(j!=k))
            {
            txt+=AnsiString().sprintf("\t_vec3<T> get_%c%c%c() { return _vec3<T>(%c,%c,%c); } ",x[i],x[j],x[k],x[i],x[j],x[k]);
            txt+=AnsiString().sprintf("void set_%c%c%c(_vec3<T> q) { %c=q.%c; %c=q.%c; %c=q.%c; }\r\n",x[i],x[j],x[k],x[i],x[0],x[j],x[1],x[k],x[2]);
            }
        for (i=i3=0;i3<n3;i3++,i=i3&3) if (i<n)
         for (j=j3=0;j3<n3;j3++,j=j3&3) if (j<n) if (i!=j)
          for (k=k3=0;k3<n3;k3++,k=k3&3) if (k<n) if ((i!=k)&&(j!=k))
            {
            txt+=AnsiString().sprintf("\t__declspec( property (get=get_%c%c%c, put=set_%c%c%c) ) _vec3<T> %c%c%c;\r\n",x[i],x[j],x[k],x[i],x[j],x[k],x[i3],x[j3],x[k3]);
            }
        if (n<4) break;
        txt+="\t// 4D\r\n";
        for (i=0;i<n;i++)
         for (j=0;j<n;j++) if (i!=j)
          for (k=0;k<n;k++) if ((i!=k)&&(j!=k))
           for (l=0;l<n;l++) if ((i!=l)&&(j!=l)&&(k!=l))
            {
            txt+=AnsiString().sprintf("\t_vec4<T> get_%c%c%c%c() { return _vec4<T>(%c,%c,%c,%c); } ",x[i],x[j],x[k],x[l],x[i],x[j],x[k],x[l]);
            txt+=AnsiString().sprintf("void set_%c%c%c%c(_vec4<T> q) { %c=q.%c; %c=q.%c; %c=q.%c; %c=q.%c; }\r\n",x[i],x[j],x[k],x[l],x[i],x[0],x[j],x[1],x[k],x[2],x[l],x[3]);
            }
        for (i=i3=0;i3<n3;i3++,i=i3&3) if (i<n)
         for (j=j3=0;j3<n3;j3++,j=j3&3) if (j<n) if (i!=j)
          for (k=k3=0;k3<n3;k3++,k=k3&3) if (k<n) if ((i!=k)&&(j!=k))
           for (l=l3=0;l3<n3;l3++,l=l3&3) if (l<n) if ((i!=l)&&(j!=l)&&(k!=l))
            {
            txt+=AnsiString().sprintf("\t__declspec( property (get=get_%c%c%c%c, put=set_%c%c%c%c) ) _vec4<T> %c%c%c%c;\r\n",x[i],x[j],x[k],x[l],x[i],x[j],x[k],x[l],x[i3],x[j3],x[k3],x[l3]);
            }
        break;
        }
    txt+="\t};\r\n";
    }

Half of the core of my Z80 CPU emulator code is auto-generated this way and is fully configurable from MySQL database dumped to text file.

In demo scene was usual to code some effects on better computer or in advance and encode the result so it can be "played" instead of generated in RT on target platform.

So as you can see there are more easier ways than AI to overcome brick-wall ...

Answer 5

Your timeframe is huge

The increase in home computer capability from 1975 to 1985 is massive - at least as much as the increase in capability in cell phones from 2000 to 2010, if not even greater.

In 1975 I don't think there were any home computers that had any bitmapped graphics capability at all, and even if they had, they wouldn't have had enough memory for the image anyway. In 1985, on the other hand, you could buy an Amiga with a megabyte of RAM and near-VGA graphics which would be capable of a lighted, shaded rotating cube without any heroic effort.

Computers of the early 80s typically had limitations in their CPU and graphics that would make full-color 3D rendering impractical. Realtime 3D lighting requires per-pixel calculations that just can't be done fast enough on 8-bit CPUs. Without lighting, 3D rendering looks better in wireframe.

Wireframe rendering is much easier, as you need only a few calculations to project the vertices of the polygons you are rendering, and then you connect them with lines. Line drawing is easily handled on all common 8-bit systems.

In the early 80s many computers were capable of realtime animation of wire-frame 3D. The classic game "Elite," released in 1984 and ported to the majority of common 8-bit platforms, demonstrated this. This game could have theoretically existed in 1979 or so (the earliest you could get a 64K Apple), but most of the platforms it would be developed for would not exist until 1981 or later. A simple wireframe rotating cube could have probably been made for a 16K Apple, available (if expensive) in 1977.

There are many demos for the Commodore 64 that appear to have full-color 3D elements, although I bet dollars to donuts they are done with various tricks rather than a true rasterizing renderer, OpenGL style. A quick search for "C64 demo" will turn up several.

In the 2D category, introspec's answer shows something good for Atari, but here's one for Apple II: BMP2DHR This is closer to what you're asking, since it uses a modern PC's processing power to run advanced dithering algorithms in order to get high quality color (at the cost of contrast). To the human eye, low contrast and high color just looks better than high contrast but inaccurate color. GIF viewers for the Apple II were available, they took a significant amount of time to display an image, and they did not look that good.

Answer 6

Nope.

All early home computers were fundamentally limited on graphics performance by their video outputs. Pixel resolutions were generally low. The ZX Spectrum managed 256x192, and the Commodore 64 managed 320x200. Worse than that though, their colour depth was tiny. 6-bit colour (i.e. a palette of up to 64 colours) was normal, but graphics were often also limited to how many colours could be present in any given group of pixels.

It was certainly possible to draw wireframe 3D, and many games did. However "filled" 3D graphics were completely beyond these machines, because they did not have the colour palette to shade different faces of a shape accurately enough. It was not until the Acorn Archimedes, Commodore Amiga and Atari ST that regular home computers gained access to 16-bit and 24-bit colour which made this possible. (Specialist graphics cards did exist for PCs - at enormous cost.)

So it doesn't matter what processing you use - or even if you hooked up a hybrid old-school home computer with a modern processor. The video hardware on all old home computers simply was not up to the job. Even the kind of images you'd get from an early-90s 486 with a basic graphics card were far beyond what an early/mid-80s home computer could manage.

Answer 7

I'm not satisfied by the answers above. They either all assume that there's absolutly no room for optimization (either because the target CPU i too simple) or they present automated tools to produce better code, but leave out the AI part. Or they just state that AI is not magic. They're all leaving a part of the question out.

If the question is : "Could you use AI to achieve this goal?", then the answer would be: Probably not. As an individual you would never have acces to the resources and knowledge to set up a complex AI able to achieve this incredible complex task for an AI. And even if you owned the resources, you'd be better off using your brain instead, or at worst you'd be better off using semi-automated tools to optimize the code -- which doesn't count as an AI.

But, if the question is : "What if Google or any heavyweight company suddenly decided that they want to produce the best possible code for a 1980 machine, and use AI to achieve this? Could they do it, would it help, would it work?", then the answer is probably yes.

The resulting code might only help moving from an "almost completely optimized code" to a "completely optimized code" (hence making the execution only 5% faster if you're extremely lucky -- maybe), but it's still a "yes, probably".

Let me explain how :

• we know how automated tools can be used to produce extremely optimized code for old hardware. For example, there are tools to produce some extremely optimized compression ratios for hardware with tiny storage capability. Or compilers that produce the best assembly code for a given CPU.

• the core of these techniques is that the machine producing the optimized code has huge memory or comptation capabilities compared to the target machine. But it's not enough. It all relies on someone who perfectly understood how the target machine works, and was able to provide the tool with some specialized pieces of code --templates if you will-- that are the best in a given context. That person created algorithms that are abstracting what's really needed in the end, doing the calculation on some inflated temporary data aiming at this goal, and in the last moment filling all the templates and keeping only the core of what's needed.

In a way, they're "rendering" the template just like you would render 3D, but instead you're "rendering" assembly or data.

The thing to understand is that the person who created those tools provided to things: the so-called templates and the ways of using them. In other words, they spotted patterns in what they think is the most optimized code or data, and then they created rules to insert them in the right places with the right parameters.

Now, the question is : *"Would an AI be able to spot those patterns and create the rules to inject the patterns?"*

Well, with machine learning, it certainly would. You have a very simple heuristics at the end to evaluate the quality of the result : its execution speed.

The machine would need to learn to spot the coding patterns. That it can do by feeding it lots and lots of well-optimizied existing code for the target machine, that you'd take from the software from back then. Then if you introduce mechanisms of randomness and genetic algorithms, the AI can try variations and find even better optimizations that no one had thought about.

Then the machine would need to create its own rules to wire all the patterns together and achieve the goal that you have set (by the way, you'd need a language to tell the AI what the goal actually is, in abstract terms that it can "understand" and toy around. It's hard to tell a machine "do me a rotating cube" without actually doing it yourself -- but then again machine learning to the rescue to learn to recognize abstract concepts).

Finally you'd end up with a code that a human would hardly understand, and that would be litrally impossible to maintain without breaking everything. Bout it would work -- you'd have the fastest code possible for this one specific task.

Answer 8

It's not that we couldn't do it. It's that we couldn't do it in real time. I have had 8-bit processors grinding for 12 hours to precompute graphic elements, data then used to "do the impossible".

As far as exceeding hardware ability, we did a lot of stuff the designers never conceived, 4-way fine scrolling on VIC-20 for instance. That was half the fun. Now they don't let you play with bare metal anymore.

Not seeing how "AI" would have helped though.

Answer 9

A genetic algorithm paired with machine vision for feedback should be able to do the job.