Animating Ellipses on a Vintage 386 Computer 

Thanks. I'm really glad you enjoyed it!

@@PCRetroTech also, using AI to enhance your content like this is not just smart, but fits into the tech aspect of the channel. I use AI to write routing tables when I don't have much time. Lets me do more work in a given amount of time.

@@Dinnye01 Indeed, it's a handy tool.

The display had a crazy high resolution too! 1024x1024 in 1959!

Wow! I'm really impressed to hear about that. You may or may not know that I have asm code for line drawing that sounds very similar to yours, though in my case only for CGA. I'm incredibly impressed that yours covered the other *GAs as well. I thought such a thing did not exist. One of the main issues with the general ellipse is dealing with narrow ellipses. The algorithms for scan conversion have a tendency to jump over the crossover points, leading to escape. The Da Silva algorithm solves this by computing one of the coordinates of each crossover point. There are still four problems with this however: 1) Da Silva got the maths wrong (he assumed the B coordinate could not be negative and that square roots could be negative, and he got one of the inequalities back-to-front), 2) one really needs to monitor both coordinates of the endpoint, due to possible accumulation of errors in the one being monitored (one checks whether one has reached the coordinate Da Silva computes, whilst checking if one will exceed the other), 3) for angles very close to certain ellipse orientations, the parameters he computes can go to infinity, exceeding the precision of the machine, 4) when converting to integer coordinates, rounding can cause overruns in very narrow ellipses (I found that truncation worked better, though didn't completely solve the issue for exceedingly narrow ellipses). It sounds as if you had a no-nonsense approach to the general ellipse. For the filled primitive, would you have simply used the equation of the ellipse to compute each coordinate in floating point, or did you use an integer algorithm for scan conversion? The former would work of course, but would be much slower without a maths coprocessor. The other approach that was common was to compute a small number of points on the boundary and draw lines between them. It sounds as if you might have been doing the latter for your outline routine? Anyway, thanks for stopping by and filling in some history!

@@PCRetroTech For the asm aligned ellipse (outline) drawing, I read the classic papers I could find (this was pre-Internet, remember), ignored the garbage in the "popular" books about PC graphics, and did my own scan conversion with asm (and my other features) in mind. It's like the lines, but the "step" factor (represents the slope) itself is changing, so it adds another stage. The general code: I don't remember if it used floating point just to calculate the points where I needed to split it up; FP hardware was still optional at that time. But, it's a constant-time overhead and not part of the drawing loop. The outline-finding code then worked just like anything else using the difference algorithm with some number of stages: add a constant to the last one, which updates the number added to the one above that, etc. until the top one is the real value of interest. I realized that, just like the famous _Difference Engine_ , it was general purpose and could compute any function just by presetting the initial values for the various derivatives. Oh, I just remembered how I did the square root, on a fixed-point integer: Newton's method! The previous result in the same spot was used as the initial guess, and one iteration is enough to nail the correct value. In ASM of that vintage, conditional branching is slow! Don't expect me to remember how many clocks it takes for a branch taken.

@@PCRetroTech Oh, hitting the registers on the card over the ISA bus (the IN and OUT statements) are also very slow. Running under a hypervisor might have settings that make them even slower.

@@JohnDlugosz Ah that sounds like it was pretty impressive. By the way, is there anything on the web about the ViewPoint graphics library? There seem to have been other things by that name, so I'm having trouble finding it. RU-vid will kill links, but feel free to email me (email address on the channel page) or tell me how I could find it. I don't suppose there was a shareware version that is still on some ancient FTP server or something?

The maths puts a lot of people off computer graphics I think. I certainly didn't understand it well enough as a kid. I have an advantage these days doing maths as my day job.

@@PCRetroTech The maths of ellipsoids was... challenging to me to say the least (I did A Level maths but failed due to a lack of revision, though I've learned a lot of what I should have learned then since). I had some very, very long equations although mostly they did gratifyingly collapse down to something simpler and more manageable!

There was this game, Ecstatica. It cheats a little doesn't it. I wonder how its renderer works.

@@SianaGearz Yes, as a result of my "project" I found the sequel Ecstatica II and played it. It looked very nice.

@@SianaGearz It doesn't seem to have cheated much. The ellipsoids are not just ovals coloured in, but there is a per pixel z-buffer. It does use a pseudo Gouraud shading, though I don't know the details. The game required a 486 SX-25 to run, but it is certainly a work of art. Apparently the game engine itself was mostly developed by one guy over a period of years. I wonder if he developed it on a 386!

It's not hard to get secondhand copies. A great book for sure.

That's great to hear. Of course a full description of everything could fill an entire course of videos. I mainly just wanted to give some intuition in this video.

@@PCRetroTech That would be an awesome entire course of videos though

Exactly. The way to do a scanline render of an ellipse is to first convert the rotated ellipse to a sheared ellipse. Another interesting thing is that a perspective projection of a sphere is always an ellipse. For nearly 40 years I've thought it would be fun to make a 3D game based on this principle using spheres as primitives. I suspect that any ellipsoid will become an ellipse under perspective projection too, but I'm not 100% certain since my maths is not good enough.

That's right. I keep as much as possible in the registers, but have to use memory locations for the rest. But fortunately that is not such a terrible problem on the 386.

Thanks!

Thanks.

Thanks!

I imagine you could use the decision variable to do antialiasing, though in the curve case, it doesn't quite measure how far you are from the curve. More like the square of how far if I recall correctly. Also, the distance is in one direction, not perpendicular to the line. But at least in principle you could do something. There are algorithms for anti-aliasing primitives in the Foley et al. book, but I didn't look into those in any detail at this point. My original goal was to get something working on CGA, until I discovered that was probably a fools errand (at least without cheating). Now that I'm on VGA, anti-aliasing becomes more of a consideration.

I appreciate the feedback. Thanks!

You can in fact do ellipses up to some size with just 16 bit registers. I forget exactly what size. Something like radii 32, 32.

Thanks for the tips on the EISA bus. I was unaware it was so slow! In 256 colour mode it is of course just doing one pixel per byte. So in some sense the number of bytes written to memory is minimized. At present I don't have enough registers to keep track of multiple bytes at once. But that is definitely a possibility if moving horizontally. As for the SVGA cards, I was aware they all had different methods for switching banks. I've been doing some programming recently on the channel with XGA and this already comes up. The books that describe XGA the best also describe all the SVGA adapters, so I've done a bit of reading around that issue. It will be interesting to play with those at some point. I've considered doing a TsengLabs ET4000 video for example.

@@PCRetroTech I'll see if I can find my* old code, if you're interested. I remember Tseung Labs now that you mention it. Also STB, which was local to me, was great to visit. You're following footsteps left >30 years ago -- I even have the same Folly, Van Dam, et al. book (I have both first and second editions actually). You should also look into Graphics Gems. * The assembly language portion was coded by my partner in ViewPoint, Mike Hoyt. His code has been described as "Wilton meets Abrash".

The video was produced for RU-vid, not somewhere else. There probably are places I could give a talk of this kind, but life is too busy to get involved with them. I've always talked while recording the screen, as I find it hard to sync the talking with what's going on. I'm not sure how other RU-vidrs do that so convincingly.

GPT4 has very little idea of how to do really optimised coding in 8088 assembly, unfortunately. It can do a few simple things, but that kind of deep analysis is impossible for it.

@@PCRetroTech You could ask GPT4 for a fast algorithm in C that can draw generic ellipses on a 32 bit or 16 bit machine without an FPU.

@OpenGL4ever I don't think it would manage that as there's nothing in its training data that would help it with that. The same circle algorithm is repeated hundreds of time online, plus a handful of standard ellipse algorithms, mostly incorrect, and that's it. GPT4 doesn't have the planning capability to come up with stuff it doesn't know. Instead it hallucinates, unless it is a fairly trivial generalisation of something it knows.

As I suspected, the result, though ingenious, is not useful. It first produced a standard ellipse. When that was pointed out it produced a rotated standard ellipse with the rasterisation done before the rotation. When that was pointed out it produced *pseudocode* for an algorithm that looped over every pixel in a rectangle and checked whether it was in the rotated ellipse or not. When that is pointed out it goes back to rasterising before rotation, but doesn't notice it has done so. There's just no answer in its training data.

@@PCRetroTech Thank you for trying it and your answer. Basically, this is still good news, because it means that GPT4 cannot yet replace programmers everywhere.

Glad you liked it. And pleased to have contributed to the view count of a Desire demo.

I have to agree about mouse cursor. Sadly. Double-sized red could work. As you might know, many followers are quite old 😭

Yes, technically I guess. Quite an impressive piece of tech for the era.

Sure, the 8 bit machines had sprite hardware, which made all the difference.

You can use DOS Extenders like DOS4G/W, DOS/32, CWSDPMI etc. to do this. That's at least the normal way to do it. You can also use a VCPI extender or use Unreal mode, but the latter two are not recommended, they are not compatible with Windows. Windows does provide its own DPMI host in Win9x/Me and inside a VM86 using NTVDM in 32 bit Windows NT like systems.

wait this didn't get nuked by spam deterrance? nice.

Drawing ellipses by joining lines doesn't result in pixel perfect ellipses and wouldn't be suitable for what I had in mind, as I mentioned at the beginning of the video. That's the way most people do it of course, but it doesn't result in a true ellipse.

@@PCRetroTech ...but what if those lines just so happen to be segments of an ellipse? That should be an ellipse!

The limit is actually +infinity. It's perfectly reasonable to say the slope is infinite. Or if you make use of the extended reals, +infinity.

Well, one can obviously do it with fixed point math that is high enough precision. But roughly speaking, that describes the issue.

That's great you found a solution. I'm a bit surprised no one had done it before or at least made the solution public. You should turn this into a published paper. @@PCRetroTech

@@Castaa It would simply be some corrections and implementation notes for Da Silva's thesis. Not really worthy of a publication.