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.