A surprisingly fast 3D engine for the Commodore 64/128

[HEXdidnt]

Now this is pretty damned impressive - billed as a 'Doom'-like demo on the C128, it does run on the C64, albeit substantially slower and less smoothly:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

The kicker is that it was worked on by Andreas Larsson, who's currently developing a C64 conversion of Eye of the Beholder, which looks stunning given the limitations of the hardware. It seems as though this 3D engine might have been mothballed for the time being, but perhaps he'll pick it up again in future.

 

[Retro]

Interesting to see what can be done with modern techniques on classic hardware.

Also proves that the extra 64K on the C128 isn’t just a gimmick.

That heavy metal track at the end with the twiddly guitar cracked me up a bit. Very soundtrackeresque.

 

[HEXdidnt]

Yes - it's also another fine example of my astounding ignorance about coding: I understand how a more powerful processor can make these things faster, that's pretty obvious... but more memory? How does that work?

I guess it's something to do with buffering - as in, the more 'spare' memory there is, the more frames can be buffered, leading to a smoother, if not faster animation - but it's like sorcery to me. I wouldn't consider myself to be a C64 fan by a long shot, but the speed and fluidity of that 3D, even on the 64 rather than the 128, is way better than some of the best 3D - both solid and bare vector - I've seen on the Speccy.

More than that, though, it's substantially better than the C64 version of FreeScape which, at the time, was considered pretty impressive, despite being sluggish to the point where you might as well have been 'playing' a Powerpoint presentation...

 

[Retro]

Yes, you've pretty much got it as far as memory speeding up animation. Another way that it can do it is to have lots of lookup tables stored in there which can speed up calculations enormously, eg rendering angles.

Remember the FDIV bug on the original Pentium from 1995? That was a corrupted lookup table in the CPU. Intel put it in there to speed up division calculations, but somehow the last 5 values managed to be set to zero instead of their correct values, despite all the various development and quality control steps that it went through. I'd have loved to have been able to see what went on at those internal meetings when the shit hit the fan lol.

Pentium FDIV bug - Wikipedia

en.wikipedia.org

Also, the slowness of any kind of 2D animation on these classic computers shows you just how much more processing power is needed for it versus 2D. We take it for granted nowadays, but we quite literally have little supercomputers sitting on our desks, even laptops with integrated CPU graphics.

 

[Tobermory]

Yes - it's also another fine example of my astounding ignorance about coding: I understand how a more powerful processor can make these things faster, that's pretty obvious... but more memory? How does that work?

Ey up, long time listener, first time caller here... Using more memory translates pretty quickly into quicker code. You're right about the animation stuff, but 3D rendering doesn't animate in the way you'd think, it's more likely to be speeding up maths routines:

Firstly, you can 'unroll' loops so the CPU doesn't have to process the 'decrease counter, test for 0 and jump back if not 0' test each time. For short loops that can almost double the speed of your code.

Then, if you have something that's pretty general, you can make it a lot faster by precalculating values and storing big tables of answers. The bigger the table, the more accurate the result. You might think a multiplication table would do it, but with 3D, it might be s/(s+z) to calculate perspective quickly (in this case, S is the assumed distance of the viewer's eye to the screen which stays constant, and Z is the distance to an object in the 3D scene). You can see how the tables might get pretty big pretty quick!

Anyway, I must be pretty egotistical to be lecturing you all so quick right? Nah, I still didn't finish my 3D renderer yet - here's a video of my 3D raycaster that almost works. Would love to get a sector/portal renderer working before I draw my pension!

 

[Retro]

Hey @Tobermory great to hear from you and welcome to our forums!

I tried to learn about 3D graphics programming years ago, but couldn't get my head around it, so perhaps we can have a chat about the basics sometime in one of these forums?

Great site you've got there. Feel free to link to it in your siggy if you like.

 

[HEXdidnt]

That 3D engine of yours is really coming along... And it proves, yet again, that silky-smooth 50- or 60-frames-per-second is not absolutely necessary to make something work. I presume adding sprites in there would further reduce the frame rate, but if the end result still manages 12-16fps once it's all fully optimised, I'd call that a significant win.

Re: the fish eye effect, is that something that could be disguised by altering the crop of the active window? Or would it happen at the edges of the active window whatever size/shape it was drawn?

 

[Tobermory]

And it proves, yet again, that silky-smooth 50- or 60-frames-per-second is not absolutely necessary to make something work. I presume adding sprites in there would further reduce the frame rate, but if the end result still manages 12-16fps once it's all fully optimised, I'd call that a significant win.

Re: the fish eye effect, is that something that could be disguised by altering the crop of the active window? Or would it happen at the edges of the active window whatever size/shape it was drawn?

That's exactly what I'm hoping for! I wouldn't expect 16 frames per second but it should still feel responsive and fun.

The fish eye effect is usually fixed with a simple cosine look-up table, but this video was taken while I was realising I'd lost too much accuracy on previous steps, so it was adding more distortion than it was removing! There are several moments where you see flat walls broken up into several curved ones in error...

With the next iteration you were gonna see a much larger play area, and precisely straight lines, which would also run much faster, as the 'rooms' would be stored as polygons flipped inside-out, rather than storing the map as a giant bitmap in 32K or something! One thing that that C64 Andropolis demo does very well is using the same technique to vary the ceiling and floor heights, which you get almost as a by-product of making this switch. It certainly makes Wolfenstein look very flat in comparison to Doom or Duke Nukem

 

[Mort]

Certainly is something I'm looking forward to seeing develop more