In 1996 I started work on a 2D rendering engine in ARM assembler which did alpha-blending and vector antialiasing. Substantial parts of it were later rewritten in C, but the core pixel-blitting loops are still there in ARM as far as I know. It shipped hundreds of millions of units and was at one point present on the majority of mobile phones manufactured in Japan, Korea and Taiwan in the mid 2000s. It is still going, and some software products are still being shipped today which contain that code.
We were just coming out of the age of assembler. The background blitting is all assembler, but the characters are Direct3D. When I put the 3D engine in there it was a 3D software renderer I had written when I was 13 in C++ and x86 and I just pasted it into the game engine, but I think we took the software renderer out and just used Direct3D's renderer. GPUs were just coming onto the market, and I think the hope was that it would get a boost from a GPU, although I don't remember ever testing it on one. (I do remember going to gaming expos and the card manufacturers would just hand out GPUs to every dev that went to their booths...)
I was 21 or so when I discovered this paper and re-implemented Phong shading for a combination of a an early i386 (1986 iirc), combined with a co-processor board that had a DSP32 on it, which - amazingly - would do some pretty impressive float calculations. It was a tricky combo to program for, the bus was a limiting factor but when it worked it was quite fast. I later also ported the vector math section of a small ray tracer to that DSP32. The main application the designers of the board had in mind was real time filtering of telephone voice data streams (the board had two RJ11 jacks) so it wasn't an ideal match for graphics work but it worked quite well in spite of that.
Given the resolution limitations of the display hardware I had access to at the time computing the images was actually easier than displaying them, in the end I resorted to all kinds of very fancy dithering schemes and palette hacks to output the images, some so faint that you had to view them in a darkened room (but they looked pretty good, they were faint because I used interlocking RGR/BGB groups of pixels (6 pixels to display two true color pixels) so you'd lose a lot of light output. Fun times!
Thanks, that is nice to hear. Lots of custom 16 bit blitters made that happen. I made one that blended between (I think) 16 bit patterns to interpolate between two images, plus some RGB blending if I remember right. PowerPC had some wonderful functions for all of that but in the switch to Intel, computers were fast enough that I used a regular loop since it was waiting around for ram anyway. We got pretty far on an OpenGL port but ran into issues with needing to draw the scene in a handful of passes instead of piece by piece. My partner had the vision for artwork and special FX and I just made it happen on the back end.
Nice! I tried doing a bit of demo scene stuff too (joined a group briefly) but never made anything worth releasing (the group “amour” had 4 productions but not with anything I made). I did write some fast graphics subroutines that were called from a C program. For instance, quickly put a bitmap on the screen with arbitrary x and y scaling, using fixed point numbers in assembly language. I made a scene with 3D vector balls but I had used 8 bit values for their positions so it ended up being jittery. Rewriting it was going to be too much work. Shows you the value of C where you can just change the data types and recompile. :) That book was a good foundation, and then stuff like the Michael Abrash black book later on for graphics.
Yeah, I remember messing around with Mode-X and SVGA video modes, then writing code to plot lines, circles, Wu pixels, Anti-aliased lines and all that stuff.
Years later at different jobs I was able to use the accumulation method used in Bresenham's line drawing algorithm to do some neat integer based graph drawing and scaling.
Aaah, it brings so many fantastic memories. I still remember the excitement and awe when watching the new stuff released on Assembly. The pure fan admiration for guys from Orange, CNCD, Nooon, Complex, Halcyon and many others.
I wonder if it's still as exciting today? Nowadays, when there's abundance of productions, effects, impressive games, wonderful animations, powerful hardware to run all this stuff, I think it's harder to impress people. Especially when they can instantly find 10 tutorials and 5 code examples helping to achieve something similar and as the result everyone immediately depreciate other people's work.
Software matrix multiplication is a perfectly reasonable way of doing 3D graphics, when you don't have a GPU. They were just starting to become a consumer product at that time: https://fabiensanglard.net/3dfx_sst1/
I quite enjoyed that. It really does amaze me how far computer graphics software/hardware has come since those days. I'd love to know what the guys who worked on that bit of kit went on to do.
Chris Hecker's articles on building a perspective correct texture mapper were awesome. In the late 90s, I used these articles to build a software renderer from the ground up in assembler and then added bilinear filtering at no additional charge.
It was dancing on a Nintendo 64 at the time. Sadly, while it went on to get used in a couple obscure games, the HW company for which I created this went belly-up.
Check out the RC Simulator the creator programmed many years ago in assembler. It's all pixel pushing, no OpenGL, and no texture mapping, but still incredible. I posted about it on HN a year ago too [1,2].
Work has been done to run it on bare metal too - a sort of LISP Machine in PicoLisp!
I wrote a primitive 3D engine in high school, in qbasic. But this was before I knew linear algebra or the idea of z-buffers so it worked based on the math I knew at the time, which ended up being fairly convoluted and a little buggy. And it achieved texture occlusion through drawing the closest shapes last. Also, it didn't have a buffer at all it just drew directly on the screen. It actually worked though, which I thought was pretty cool, but I can only imagine how I would judge the code today.
Not quite what you want, but Michael Abrash’s Graphics Programming Black Book is available for free online, and covers the software rendering side of computer graphics in the early-mid 90s, ending at Quake, just before 3d accelerators hit the scene.
There are a few anecdotes from hardware designers of 2d graphics cards mixed in, but the bulk of the book is about writing optimised x86 assembly (don't follow the any of it's advice these days) and writing fast polygon rasterisers.
Yes, it's amazing how many game development techniques appeared and faded out in the 90s, in that window of time between fast-enough CPUs and affordable GPUs. I have a copy of the Black Art of 3D Game Programming on my shelf and it's full of awesome tidbits.
I recently browsed flipcode.com and sadly parts of it are broken and only available thanks to the Internet Archive.
reply