This is still every bit as interesting as the first time I watched this video one year ago. I can only wish you will eventually do the same for Stunt Car Racer. 😉 (I kinda recall seeing something about it on Twitter but my memory is hazy.)
How did you create this slow-motion rendering of a frame? Also, the cars come in as if they're sprites/bitmaps being drawn; are the rendered in main memory before being blitted? If that's faster than just drawing them directly into the buffer, how?
This rendering is generated in Hatari (the emulator) with the help of a few rudimentary scripts which I hope to put onto Github today. In short, I set a breakpoint on the debugger to wait for the front and back buffers, then set another breakpoint on the HBL, then run the game for several thousand HBLs, capturing the data for the back buffer at each HBL. Each of the captures is then converted to a gif and then sequenced into a video for playback. I'm as bemused as you by the rendering of the cars - I was expecting to see individual polygons being drawn, followed by scaled bitmaps for the wheels. Not what I expected at all and I can't make any sense of it!
@@gridleaderretro Thanks for the explanation; I wish I had the same ability with other emulators. As for the car rendering, that's just crazy, how can rendering to main RAM and THEN blitting to display RAM be just as fast or faster?! I wish Crammond were online so we could ask him. I did notice the tires were bitmaps, they get chunky when close, but there are too many frames of animation to assume that all cars are prerendered, so I'm stumped. Also, why are the bitmaps rendering bottom-to-top? Is there a 68000 "blit via pop" or other stack-based blitting going on? Next time, I'd use no dithering, as that confused me as well (I thought the dithering was part of the rendering :-)
@@JimLeonard Yeah the offscreen rendering of the cars remains a mystery. Sir Geoff doesn't seem to be the social media type so I guess it'll remain a mystery until somebody reverse engineers it! I agree about the dithering being misleading - I'm going to try to figure out a way to get rid of it.
Oh, so the dithering is not part of the actual render? Then I do not understand why he is not using a more efficient method to green-clear the floor instead of the multi passes he seems to be doing. Also, if I remember correctly the horizon is always horizontal so he could have gone with a simple blue/green mid screen color raster split for sky/ground which would have simplified clearing quite a bit.
Yep, although I suspect it would have been both less computationally expensive (not to mention less memory-intensive) to use a naive painters algorithm back in those days, rather than attempting any kind of non-trivial occlusion technique.
@@gridleaderretro yep. I am not a programmer but we know unofficial coder contests for the maximum number of rendered sprites per frame on Amiga and Atari ST. I've read something about it and the optimizations for rendering, deleting, masking sprites there are amazing.
That's true. Although it's also necessary to acknowledge that this was a ludicrously ambitious game for 1991, and the fact that Crammond was able to fit in an accurate recreation of every F1 circuit in the calendar was nothing short of a miracle! Chances are that adding further visibility-based culling logic would have further delayed the game or tipped the memory requirements over the edge!
@@gridleaderretro … or possibly even have been slower. The cost-benefit of limiting occlusion versus overdrawing for relatively low-resolution filled polygons is very different from that for anything textured or beyond.
@@thomasharte500 Yep, totally agree. Brute force was often the best approach on these old fpu-less machines, unless the occlusion calculation was very quick to perform!
@@thomasharte500 Occlusion detection may have been too costly relative to the very simple geometry but even a very simple 16 pixels granularity depth buffer and drawing front to back may have prevented quite a lot of unneeded drawing. Something like storing one 16 bit depth value every 16 pixels would have needed only 1/4th of the screen memory for quite a benefit when drawing. I suppose even a single depth value for every 16x16 bloc would have been enough to avoid a large amount of overdraw.
A lot of calculation and painting for our poor old ST! A miracle it runs at playable framerates
It just about runs at a playable framerate, although it was considered quite jerky even at the time!
I spent hundreds hours on ST F1GP... it was super slow even back then but I enjoy it a lot! It was like a strategy racing game... Č0
This is still every bit as interesting as the first time I watched this video one year ago.
I can only wish you will eventually do the same for Stunt Car Racer. 😉 (I kinda recall seeing something about it on Twitter but my memory is hazy.)
Love things like this. I bet games like star ray , xenon 2 or blood money make good viewing too
Cool!
Thanks - these are quite interesting so I'll probably do more of them!
How did you create this slow-motion rendering of a frame? Also, the cars come in as if they're sprites/bitmaps being drawn; are the rendered in main memory before being blitted? If that's faster than just drawing them directly into the buffer, how?
This rendering is generated in Hatari (the emulator) with the help of a few rudimentary scripts which I hope to put onto Github today. In short, I set a breakpoint on the debugger to wait for the front and back buffers, then set another breakpoint on the HBL, then run the game for several thousand HBLs, capturing the data for the back buffer at each HBL. Each of the captures is then converted to a gif and then sequenced into a video for playback.
I'm as bemused as you by the rendering of the cars - I was expecting to see individual polygons being drawn, followed by scaled bitmaps for the wheels. Not what I expected at all and I can't make any sense of it!
@@gridleaderretro Thanks for the explanation; I wish I had the same ability with other emulators. As for the car rendering, that's just crazy, how can rendering to main RAM and THEN blitting to display RAM be just as fast or faster?! I wish Crammond were online so we could ask him. I did notice the tires were bitmaps, they get chunky when close, but there are too many frames of animation to assume that all cars are prerendered, so I'm stumped.
Also, why are the bitmaps rendering bottom-to-top? Is there a 68000 "blit via pop" or other stack-based blitting going on?
Next time, I'd use no dithering, as that confused me as well (I thought the dithering was part of the rendering :-)
@@JimLeonard Yeah the offscreen rendering of the cars remains a mystery. Sir Geoff doesn't seem to be the social media type so I guess it'll remain a mystery until somebody reverse engineers it!
I agree about the dithering being misleading - I'm going to try to figure out a way to get rid of it.
Oh, so the dithering is not part of the actual render?
Then I do not understand why he is not using a more efficient method to green-clear the floor instead of the multi passes he seems to be doing.
Also, if I remember correctly the horizon is always horizontal so he could have gone with a simple blue/green mid screen color raster split for sky/ground which would have simplified clearing quite a bit.
I wonder if the cars are rendered as voxels?
the engine renders a large number of pixels that are not visible in the final image, a naive approach to rendering from today's point of view.
Yep, although I suspect it would have been both less computationally expensive (not to mention less memory-intensive) to use a naive painters algorithm back in those days, rather than attempting any kind of non-trivial occlusion technique.
@@gridleaderretro yep. I am not a programmer but we know unofficial coder contests for the maximum number of rendered sprites per frame on Amiga and Atari ST. I've read something about it and the optimizations for rendering, deleting, masking sprites there are amazing.
So much wasted drawing!
That's true.
Although it's also necessary to acknowledge that this was a ludicrously ambitious game for 1991, and the fact that Crammond was able to fit in an accurate recreation of every F1 circuit in the calendar was nothing short of a miracle! Chances are that adding further visibility-based culling logic would have further delayed the game or tipped the memory requirements over the edge!
@@gridleaderretro true! I loved playing it at the time regardless. Just interesting to see behind the curtain.
@@gridleaderretro … or possibly even have been slower. The cost-benefit of limiting occlusion versus overdrawing for relatively low-resolution filled polygons is very different from that for anything textured or beyond.
@@thomasharte500 Yep, totally agree. Brute force was often the best approach on these old fpu-less machines, unless the occlusion calculation was very quick to perform!
@@thomasharte500 Occlusion detection may have been too costly relative to the very simple geometry but even a very simple 16 pixels granularity depth buffer and drawing front to back may have prevented quite a lot of unneeded drawing. Something like storing one 16 bit depth value every 16 pixels would have needed only 1/4th of the screen memory for quite a benefit when drawing.
I suppose even a single depth value for every 16x16 bloc would have been enough to avoid a large amount of overdraw.