Books about 3D graphics programming for the '80s home computers?

[ClearSky]

Do you know of any good books about 3D graphics programming for the '80s home computers (both 8-bit and 16-bit)?

[Justin Payne]

Good books? Well, how's your math? I had two back in the day. One was the one for the ST called, "3d Graphics Programming" as well as one for the PC called, Tricks of the Game-Programming Gurus Paperback (1994). I, in no way, was capable of grasping these concepts. I suspect this was my poor background in geometry so it's quite possible someone with a background in this area might succeed.

[ClearSky]

20 minutes ago, Justin Payne said:

One was the one for the ST called, "3d Graphics Programming"

This one looks good, judging by the table of contents.

[Justin Payne]

The author is Uwe Braun and if memories serves me, there were some editing issues with this book. I think Uwe is German and so I suspect his, or the editors, or both, English wasn't the best so expect some pages to be a bit confusing.
Since 3D programming was in it's infancy, I wonder if someone has revisited these techniques and have come up with more performant methods to produce 3d on these limited systems.

[+bob1200xl]

These seem to have some 3D subjects.

 

Bob

 

 

 

[ivop]

I have this one:

 

https://www.amazon.com/Computer-Graphics-Software-Construction-Language/dp/0131627937

 

The book is from '89 and handles everything up to 3D transformations and raytracing. It does assume some degree of knowledge about mathematics.

 

[gpounce]

The 400/800/XL systems had a port of the Apple library "Supergraphics", Paul Lutus on the Atari.   He implemented a driver 'G:' into which application software would write instructions for rendering of 3d vector shapes, rotation, translation etc and included a bunch of text coloring options too.   The demo it shipped with was pretty snazzy, in digging thru my old floppies I discovered a game I was working on which used a bit of it- never went anywhere but I'd sure like to hear of anyone using it on the Atari- or Apple for that matter.

 

[Gunstar]

I have the manual for 'Super 3D Graphics Plotter 2' by Elvin Magic, and it covers the 3D techniques and equations it uses, and put in as simple a manner as possible without being educated in higher math. This is for the 8-bit Atari with 48K, so the "world" is limited. I believe I found this manual as a PDF online, I'll look for the link.

 

There is also the manuals for Chroma CAD 3D I posted a zip file of the PDF's in a thread recently, a search of the title should bring that up. It of course uses math, but it uses a different "sculpting" approach, maybe not unlike 3D printer technology (guessing here, no experience) using layers to build a 3D image. I don't know how much of it might be translatable to 3D programming though, if that is what you have in mind, but maybe at least see a couple of different ways other's used it for their 3D CAD programs.

 

http://www.atarimania.com/utility-atari-400-800-xl-xe-super-3d-plotter-ii_30972.html

[Rybags]

I bought (2nd hand) the book "Fundamentals of Interactive Computer Graphics" by James D. Foley, Andries van Dam

about 20 years ago (original publication was 1982).

 

The target systems were more along the lines of high end workstations of the time, and the programming examples are more along the lines of psuedo-code and explaining the algorithm than any specific language.

There's colour plates with sample images and the Atari 800 even makes an appearance.

 

The thing about 3D graphics, and that's inclusive of wireframe all the way to bump-mapping, light sourcing and reflection, occlusion, z-buffer processing etc etc is that the techniques predate the modern hardware based equivalents by decades.  The shiny new nVidia is just doing the same thing that software was doing 40 years beforehand (though of course about 100,000 times or more faster).

[+Allan]

On 11/29/2019 at 3:51 PM, Gunstar said:

I have the manual for 'Super 3D Graphics Plotter 2' by Elvin Magic, and it covers the 3D techniques and equations it uses, and put in as simple a manner as possible without being educated in higher math. This is for the 8-bit Atari with 48K, so the "world" is limited. I believe I found this manual as a PDF online, I'll look for the link.

 

There is also the manuals for Chroma CAD 3D I posted a zip file of the PDF's in a thread recently, a search of the title should bring that up. It of course uses math, but it uses a different "sculpting" approach, maybe not unlike 3D printer technology (guessing here, no experience) using layers to build a 3D image. I don't know how much of it might be translatable to 3D programming though, if that is what you have in mind, but maybe at least see a couple of different ways other's used it for their 3D CAD programs.

 

http://www.atarimania.com/utility-atari-400-800-xl-xe-super-3d-plotter-ii_30972.html

I have these both and they are on the list to be scanned.

[+Allan]

https://archive.org/details/super3dplotter2elfinmagic

 

I just finished scanning this.

 

Hopefully somebody does some interesting demos with this.

[ivop]

It's a pity though that their advanced rotation routine is considered beyond the scope of this manual (page 49). But thanks for scanning this!

 

 

[+gnusto]

I missed this topic when it first appeared. If I understand the question correctly, I don't think you'll find this for Atari era computers, but you can find plenty of 3D math fundamentals books, the concepts are the same for any platform.

 

It's pretty rare on the 8bit that "3D graphics programming" resembled what we do today, that is, perspective correct, world and camera view, 3D projection into a 2D planar surface. This is because it's an enormously expensive computationally and very floating point math intensive. It required processors that were hyper optimized to float speed before it became very viable. Most of the 3D demos/games, impressive as they were, are actually various forms of approximations or pre-computed to the point they aren't actually real-time other than display.

 

A really good article on the fundamentals of 3D math and object draw that is applicable to any of the 8bit computers is this one: http://machinethink.net/blog/3d-rendering-without-shaders/

 

The code is unfortunately in a high level language, but easily translated into even machine language. The reason it's highly applicable is because it only has one fundamental OS ability it calls: setting a pixel at a point in space to a color. This is what was so different about 3D work on old computers versus modern; we had to do rasterization ourselves. It's literally the difference of the computer telling you "I know how to draw a point and a color" versus the now evolved modern "I know how to draw a triangle of arbitrary size and 3-space coordinates, and fill it, in either a color or with a texture mapped, and allowing for per-pixel or per-triangle special effects ". It's a little bit easier nowadays =).

 

This here is all of the fundamentals of a 3D projection system done in 6502 (particularly look in source/maths.asm). It has the common optimization of look up tables for the geo math and could probably be optimized further. Here is another 3D engine in 6502, but unfortunately (looking through the source) it is heavily optimized for the Apple II, and thus requires work to run anywhere else; the Apple II memory layout for graphics is affecting code ease of use.

 

 

[devwebcl]

5 hours ago, ivop said:

It's a pity though that their advanced rotation routine is considered beyond the scope of this manual (page 49). But thanks for scanning this!

 

 

what about Solid States from Analog magazine ?

https://web.archive.org/web/20180829180222/http://www.cyberroach.com/analog/an16/solid_states.htm

 

 

[devwebcl]

On 1/1/2020 at 1:45 PM, Allan said:

https://archive.org/details/super3dplotter2elfinmagic

 

I just finished scanning this.

 

Hopefully somebody does some interesting demos with this.

It can be compressed to be 8mb

 

[+Allan]

2 hours ago, devwebcl said:

It can be compressed to be 8mb

 

Yes it can but it would look like crap. By posting a larger scan it gives you (people) the option of using it as-is or compressing it to a smaller size/look that each person is OK with. You can't go the other way.

[kenjennings]

On 1/1/2020 at 5:24 PM, devwebcl said:

what about Solid States from Analog magazine ?

https://web.archive.org/web/20180829180222/http://www.cyberroach.com/analog/an16/solid_states.htm

 

 

That's the one I was thinking of.    I was bored at work and ported this to the PC and updated it to sort and draw filled triangles.  Pretty sure that disk is gone.  Then Turbo Silver came out on the Amiga and I stopped trying to write my own graphics software.

[+Allan]

https://archive.org/details/super3dplotter2elfinmagic/page/n57

 

Read page 56.

 

Allan

 

[ChrisChiesa]

Shoot, I've been doing 3D on the Atari 8-bit computers -- an 800, an 800XL, and a 130XE -- almost since I first set my hand to one in late 1981, and surely before buying my own first one in the summer of 1982.

Unlike today's technology where you build a model and map textures to it, I worked with mathematically-defined surfaces whose properties -- surface height above a "ground plane," and slope at that point -- could be computed as functions of a given (X, Y) position on said ground plane: Z = f(X, Y).  A simple circular ripple centered at the origin (0, 0), defined by Z = cos(R), where R is the Cartesian distance from the origin (which I can't easily express, here, because I can't type a square root symbol) became my subject of choice for many years: first, wireframe drawings, in orthogonal perspective, on the Atari 800 and then on the VAX/VMS mainframe at school (with rendering handled first by a VT241 serial terminal with ReGIS graphics, and later a pen plotter).  Drawing two versions of the same wireframe, side by side, with a slight shift in perspective, produced a "stereo pair" that can be viewed in true 3D -- like a View-Master toy in the 1970s, or a VR headset today -- just by crossing your eyes in a certain manner. 

Sometime in the early-to-mid 1980s I ran across a remark to the effect that a point's perceived brightness is a function of the s cosine of the angle between the light coming off that point, and the angle of the viewer's line-of-sight.  This gave me the idea to use vector algebra and vector calculus, recently picked up in one of my college classes, to compute the reflection of an illumination ray off that circular ripple, and the resulting angle between that reflected ray and a viewer's eye (or camera), and to plot the resulting brightness using the GTIA 16-level-grayscale graphics mode of the Atari.  A ten-line BASIC program produced a surprisingly convincing image -- and combining nine such images, illuminated from each of the nine possible positions of an Atari joystick, loading them all into RAM at the same time, and arranging to flip among them in response to joystick manipulation, so that you could "steer the light source around," made the effect even more convincing. 

Unfortunately, it took 56 minutes to render each half-screen-sized square image, on the Atari.  

The VAX/VMS mainframe at school, by contrast, could render one such frame -- and save it to a file that could then be downloaded and viewed on the Atari  -- in six seconds.  Unfortunately the graphics terminals on the VAX only had four colors -- including the black background -- and, although I experimented briefly with the use of halftoning and dithering to simulate a larger palette to preview those images at the same place-and-time I generated them, , those experiments didn't go very far, and I never made large-scale use of the VAX for Atari purposes.

I still have some of the printouts from those days, including the large-format pen plot of the wireframe stereo pair, and a crappy halftone of the grayscale ripple, from the VAX, and several saved Atari screens of the wireframe versions of the ripple and another one or two functions (the definitions of which I no longer remember, which disappoints me today.... but I'm getting ahead of myself).

I later went on to implement the same program on every computer I used in my professional career: VAX/VMS again in my first job, including producing a 16-by-20-inch photographic print; then Sun/Solaris (where it first became possible to render an image with several hundred times as many pixels as the Atari version, in a fraction of a second, such that I could recalculate and render a whole new image, over and over again, fast enough to animate a "moving light source" at video frame rates), and eventually on the PC in Perl/Tk.  At that point, it became too easy -- the challenge was gone, or so I thought -- and the Shaded Plate project, as I thought of it, languished for many years.

Oh, I had plenty of ideas -- I wanted to try rendering some other functions, in particular maybe a spiral rather than a ripple -- but just never took the time to bother with them; that 56-minute render time was just too onerous.  If I was running my Atari, I wanted to be doing things -- not sitting there watching pixels creep verryyy slooowwwly across a screen.  I guess I could have launched a multiple-render version at bedtime at night, and viewed the results in the morning -- but on the Atari even that was slow, and an Atari floppy disk couldn't hold many screenfuls, anyway!  Oh, I pulled it out from time to time, to look at or to show someone.  I even put up the "steer the light source around" demo on YouTube as part of applying for a job, once.  But, by and large, the project languished.

Until 2022.  For some reason, in early 2022 my brain lit up with Shaded Plate fever.  I dug out the original 10-line BASIC program from 1986 and started making all sorts of changes to it.  First I switched the (X, Y) iteration from "one column at a time" to "one row at a time," which made visual progress faster due to the 4:1 shape of 16-level-grayscale GTIA pixels.  Then I implemented an interleave scheme so that the program first drew every fourth scanline, then the scanlines between those, and finally filled in the remaining every-other lines.  This, as anybody knows who downloaded "art photos" via dialup in the 1980s, lets you preview the image, well enough to decide whether to continue or cancel, by the time maybe only about 25% of it has been rendered.  This sped up trial-and-error experiments, considerably.  I made up other Z = f(X, Y) functions and -- sometimes by design, other times by mistake -- produced some startling images, some of which I do not yet understand even today.  (TBD!)  Two ripples side-by-side, interfering with each other.  A weird spiky thing while tring to recreate one of those forgotten functions I'd rendered in wireframe on the Atari circa 1985.  At one point I semi-accidentally produced a convincing representation of the front face of a sphere, which has come in handy in a bunch of other side projects.  I experimented with coloring the ripple surface with a checkerboard of bright-and-dark squares; results were okayyy.  (TBD!  TBD!)  I even tracked down -- using the powers of the Internet, which are much greater than they were in 1986! -- the long-sought spiral function.  But my most favorite, most spectacular, results came when I decided to revisit my roots and try rendering these shaded surfaces in orthogonal 3D perspective, just like those wireframes 'way back in the beginning.
  
I actually found three different ways to do it: a screen-high "diamond" that represents a perspective view of a square in the Cartesian plane; two different versions of a screen-high "parallelogram, in diamond orientation" that represents the entire Atari screen lying flat in orthogonal-perspective space; and a so-simple-it's-stupid-and-I-should-have-thought-of-it-in-1986 technique of simply skewing each horizontal line of the image "N pixels to the right" in the top half of the screen, and/or "N pixels to the left" in the bottom half, depending on distance from the midpoint.  "Duh."  All I had to do then was draw a four- or five-pixel high "line segment" instead of an individual pixel, to avoid gaps in the rendered surface, and -- wow.  This method of combining my vector-calculus shading computations with orthogonal perspective really did the trick.  Talk about some great images.  If I were typing this on a different computer I'd attach some to show you right now.

One other cool thing about -- indeed, quite possibly the single factor most responsible for -- my revisiting all this in 2022 is that we now have Atari 8-bit computer emulators, that not only save lugging around heavy hardware but can also run at many times the speed of the original hardware.  Speeds of between 30 and 50 times "realtime" are not uncommon.  This makes it easier than ever to perform trial-and-error experiments, because you only have to wait a few minutes for an image, rather than most of an hour like in 1986. This makes the wait time, even for full-screen-sized images, bearable at last, and makes it practical to automate things like "rendering ten versions of the same image, each with the light source in a slightly different position" -- not least because you can now store them in a single "disk" that's really a folder on the host system and thus has plenty of room for them -- , and then write a program to load each file back into screen RAM, one at a time, in order, and then run that program fast enough that you end up with animation.  I have a wonderful animation of the aforementioned "two adjacent ripples interfering," in which one of them oscillates up and down, sending ripples outward.  I also have a few slightly-less-impressive animations of the original ripple, and of an egg-crate-like matrix of hills-and-valleys, as the illumination source circles around and around them. 

In mid-2022 I became aware of a "10-Line BASIC Programming Contest" run by the German Atari club ABBUC, and while it turned out that it's mostly a 10-line game programming contest, there's also a "demo" category because, well, you know how we computer nerds are.   I missed the contest in 2022, but in 2023 I submitted my original 1986 program -- with just the every-four, every-two, etc. line iteration, easy-previewing, modification -- and won the "demo" category.  I also had so much other material that I included a whole second "bonus disk."   (Note: I may be misremembering the years.  It's possible that the stuff I've said happened in 2022 may have happened in 2021, and that I entered that programming contest in 2022, not 2023.  Time flies when you're old and retired.  Bottom line -- if you go looking for my stuff in the ABBUC contest archive, check both years, 2022 and 2023.)

Other experiments have involved inserting a little 2x2 matrix multiplication between the X-Y iteration over screen pixels, and the conversion to Cartesian-plane coordinates, to rotate the surface being rendered, relative to the Atari screen.  That has no effect on a symmetrical circular ripple, of course, but you should see that spiral spin.  "I hear and obey..."  Woooh....  :-)   I also tried to "colorize" images of the circular ripple, and of the spiral, by using what Atari calls a Display List Interrupt to interleave three separate renderings of each surface, one each in Red, Green, and Blue tints, to try to make it look like three differently-colored light sources were illuminating the surface from three different directions -- but the GTIA grayscale palette doesn't lend itself to that.  I intend eventually to experiment with the "APAC" ("Any Point Any Color") and other color-fakery schemes shared on Usenet in the 90s by Jeff Potter and others and commercialized in at least one drawing program whose name escapes me.  (TBD! TBD!)  There's still so much more to try.  Maybe an animation where there are three different colors of illumination but they rotate separately and differently.  An animation that alternates between rotation of the surface and rotation of the light.  A joystick-controllable demo that lets you control both, maybe using two joysticks.  A tool that lets me quickly convert separate joystick-direction-illuminated images into the corresponding joystick-controllable demo.  So much more.  So much more.

In between all of this I have also experimented with "classical raytracing," in which you imagine backtracking a ray of light from the viewer's eye, or camera, to each pixel on the computer screen, through the screen into a 3D world beyond, until that ray hits an object, and calculating the brightness-and-color that screen pixel would take on, to represent the light coming from that point on that object.  I've generated lots and lots of images of the classic black-and-white-checkerboard ground plane, and have made some progress on rippling that ground plane according to the same old equation, but truly striking, really recognizable, rippling remains elusive because I have not yet incorporated the vector-calculus calculation of "perceived brightness as a function of surface tilt direction," from the Shaded Plate project.  And if I'm going to add that, it occurs to me, am I not simply closing the loop and winding up right back at the same rippled-surface images I've already been producing, in less-computationally-expensive ways, for years now?  It may be worth pursuing, just to find out.  And this way also lies the possibility of making more complex images by introducing objects other than just the checkerboard "ground," for rays to strike.  Some floating spheres would be nice.

At some point, I have to expect I may run into the machine's limits.  The bookkeeping for the raytracer-producing-checkered-groundplane is already intense enough that I've had to switch from BASIC to Pascal just so that I can use "record" datatypes to keep track of, and callable named functions to operate on, all the rays and vectors and coordinate systems involved.  (Ever tried intersecting a ray of a specified origin-and-direction with a surface basically parallel to the XY plane but rippled sinusoidally in Z?  It's tricky, even a little bit trial-and-errory.  I'm using something I came up with based loosely on Newton's Method.)  So, a lot more to explore here, too.  (TBD!  TBD!)

And of course, in the process of investigating the math for these things, you find that other people have already been there, sometimes decades earlier.  Somewhere online I found a beautiful halftone black-and-white image of "my" checkerboard groundplane with reflective spheres floating above it, supposedly generated on the Atari ages ago   No word on how, and I'm not sure I want to know.  (It's possible that by "the Atari," they might have meant the 16-bit Atari ST, which is a whole other realm not related to what I'm doing.)  So far, the existence of that image hasn't "taken the fun out of it" for me, but I have to be careful to avoid that fate.

What really threatened to take the fun out of some of this was that about four years ago I discovered a Windows port of Blitz BASIC, which includes "Blitz3D," a model-mesh-and-texture -based facility for 3D graphics directly from BASIC.  It apparently originated on the Amiga, in the 90s, but I never knew about it back when I had an Amiga, in the 90s.  (Another thing TBD under (Amiga) emulation, "one of these days." :-) ) I started modeling dominoes with the intent to produce a domino game my friends and I could play interactively over the Internet during COVID lockdown, but it's getting hard to find people who still run actual Windows PCs or even laptops, and I've just never developed a taste for mobile-device and/or Internet app development.  I am immensely grateful, and somewhat amazed, that Blitz3D still works on Windows 10, but I've been running into subtle but sometimes showstopping diferences in feature/function behavior in the Windows 10 version of DirectX (DirectX 11 maybe?) as opposed to that in, say, Windows XP (7? 9?)...  Fortunately, though, this all proves to be sufficiently different a realm that it really doesn't interfere with my Atari 8-bit endeavors.

But I digress.

3D is definitely possible on the Atari 8-bit; you just have to be able to squeeze the code into the machine, and be willing to wait for the results.

[+CharlieChaplin]

22 hours ago, ChrisChiesa said:

3D is definitely possible on the Atari 8-bit; you just have to be able to squeeze the code into the machine, and be willing to wait for the results.

Found your stuff in the 2023 edition of the Tenliner Contest. Impatient Atarians like me can simply use an emulator at full speed to get faster results... 

 

https://bunsen.itch.io/rippled-shaded-plate-by-chris-chiesa

 

 

[ClausB]

A little 3D wireframe animation:

 

 

[+CharlieChaplin]

In the mid-80s we had these nice 3D demos...

 

Not to forget Battlezone, Assault Force 3D, Mercenary, Universe, Blaster and others.

 

 

DEMOS3D.ATR