Scali wrote:

Yea, that approach worked acceptably even on an 8088 at 4.77 MHz. You waste a small amount of processing time polling for vsync, but it's acceptable.
The best feature of this approach in 1991 Donut in my opinion is that I also ran the scroller from this routine. So the scroller always ran at full framerate, perfectly smooth, even if the donut was running at a lower framerate. This gave the same effect as early Amiga demos, such as Phenomena's Animotion, which inspired me: https://youtu.be/WJGraZ44EqA

Impressive! And the drum patches are good! \o/ Was the scrolly moved by copying chunks of a buffer around, or did you call the font routine for each character on the line? I'm still such a DOS coding newbie-- still trying to figure out the best way to do everything. I'm surprised you were able to get the timing down to do stable mid-frame palette changes on a variety of machines, too.

louisg wrote:

Impressive!

Thanks!

louisg wrote:

Was the scrolly moved by copying chunks of a buffer around, or did you call the font routine for each character on the line?

I just create a huge buffer at startup, and then just copy the correct chunks to screen at runtime (reading from video memory is relatively slow, so better to copy from system memory to video memory, a problem the Amiga doesn't have).

louisg wrote:

I'm surprised you were able to get the timing down to do stable mid-frame palette changes on a variety of machines, too.

Yea, it's not 100% perfect... If you really go down to a 4.77 MHz 8088, you'll see that the palette changes may be one or two scanlines too slow.
I put in a few black scanlines to create enough margin for most machines, but 286 was the target.
Mind you, this is from a few years ago. We've developed various new tricks during and after 8088 MPH which could make the timer interrupt handling a bit more efficient, so it would be more stable than it is now.
Also, this intro was made with Turbo C++ 3.1 and inline assembly. For 8088 MPH I switched to OpenWatcom 1.9, which turned out to generate considerably faster and smaller code. So there should be room for improvement there as well (the 3d part with the donut was actually based on the code I wrote for 1991 Donut, but stripped down for 8088. I deliberately used a blue flatshaded donut, as a reference to this).

Scali wrote:

louisg wrote:

Was the scrolly moved by copying chunks of a buffer around, or did you call the font routine for each character on the line?

I just create a huge buffer at startup, and then just copy the correct chunks to screen at runtime (reading from video memory is relatively slow, so better to copy from system memory to video memory, a problem the Amiga doesn't have).

It's funny how many things on this platform can be solved by throwing a ton of memory at it. That wavy Space Harrier-like effect in my music disk I finally optimized by rendering two static screens, and I blit the correct line out of the correct image. At first, I made this cool routine where it's all fixed point, shifts and masks to draw the checkerboard, and it still wasn't very fast. But exploiting the vast amount of PC memory makes me feel guilty when I think of all the custom-chip-harnessing solutions on consoles or Amigas! 😀 I actually added the waviness to show that I didn't just do it via palette rotation- hah!

Reading video memory.. yeah, I'm sad that if I switch to page flipping that I'll no longer want to blit sprites with bitops since you have to read to do that. I love how that kind of sprite blitting works-- it's a more beautiful solution than if-then, or compiled or RLE sprites. Though.. doesn't VGA have built-in bitops if you're in 16 color mode?

louisg wrote:

It's funny how many things on this platform can be solved by throwing a ton of memory at it.

Yea, I could have done the scroller more 'realtime', at little extra performance, but I wanted to get the best possible performance... the scroller is rendered directly on the frontbuffer, so you are racing the beam. I didn't want any flicker, even on 8088.

louisg wrote:

But exploiting the vast amount of PC memory makes me feel guilty when I think of all the custom-chip-harnessing solutions on consoles or Amigas! 😀

Yea well, I figure that the PC doesn't have all that fancy hardware, so the only thing it DOES have going for it is the extra memory (although compared to an Amiga, not even that... Amigas don't have segmented memory, and 1 MB Amigas were the standard in the later days).

louisg wrote:

Reading video memory.. yeah, I'm sad that if I switch to page flipping that I'll no longer want to blit sprites with bitops since you have to read to do that. I love how that kind of sprite blitting works-- it's a more beautiful solution than if-then, or compiled or RLE sprites. Though.. doesn't VGA have built-in bitops if you're in 16 color mode?

Yea, EGA introduced a reasonably powerful ALU with various bit-ops, which you can also use in VGA modes (even in 256-colour modes, like Mode X).
My scroller actually makes use of that... In 16-colour mode, you work with 4 bitplanes, so if you want a single-pixel scroller like the one I made, you need to shift the pixels 1 bit per frame.
My solution for that is to use the EGA ALU's rotate and mask functionality. I basically blit the entire scroll to the screen twice. This is because when you shift per-bit, there are 7 out of 8 cases where you have two source bytes partially covering each target byte on screen.
So with rotating and masking I extract the relevant pixels from both bytes, when copying to the screen.
Which also excuses the use of the precalced bitmap somewhat: I don't do everything bruteforce, I still use some ALU trickery 😀

I also use double-buffering by the way. The donut is always rendered to the backbuffer, and the buffers are flipped whenever it is done drawing, to avoid any flicker. As said, the scroller is always rendered to the frontbuffer, so the scroller always runs at full framerate, even though the donut may not.