MrD wrote on 2020-09-11, 15:06:
VGA also allows a horizontal screen split, which explains the status bar.
I can assure you that this is most definitely how the status bar was implemented in Vinyl Goddess From Mars. I have an old laptop that doesn't support the split screen feature in hardware, and VGFM is one of the games that doesn't display correctly on that machine. Other games that have similar problems on that machine include Hovertank and the whole Catacomb 3-D series, whose source code has been made available to the public. That's how I was able to track this display problem down and found out it was a hardware incompatibility.
I can't say anything specific about VGFM and its code, but I know that using EGA/VGA hardware to allow smooth scrolling was a thing back in the early 90's and maybe even in the late 80's. John Carmack created the smooth scrolling code for the Commander Keen games based on these hardware capabilites. And once you discard the MCGA compatibilty of mode 13h (320x200 at 256 colors) and enter planar VGA mode ("Mode Y" or whatever you want to call it), you have enough video memory for more than 4 full screens and smoothly "scrolling" around (i.e. displaying different parts of the video memory) becomes easy and requires almost no CPU activity at all.
For a game, you'd of course need to update moving sprites and draw new parts of the level as they get "scrolled" onto the screen. That means the game needs to keep track of what has and what hasn't changed, which can get complicated. But even with all that housekeeping, this method is usually a lot faster than redrawing the entire screen for every frame.
Jill of the Jungle was actually taking a different approach. If you look closely, you'll notice that the viewport in Jill only scrolls left and right in multiples of 8 pixels (or 4 pixels on the overhead map). That's because Jill doesn't use hardware scrolling, and instead moves the existing image in the viewport around when it is time to "scroll". And due to the memory layout of VGA, EGA and CGA, it is a lot faster to do that when copying multiples of 8 (or 4) pixels at a time, reading from and writing to positions that are aligned on 8 (or 4) pixel boundaries horizontally. This means that Jill technically has to redraw the entire viewport every time it scrolls, but this scrolling/redrawing is relatively fast, since it can use other hardware features to move data around within the video memory relatively quickly.
One of the reasons why Jill might run more smoothly than VGFM might be that the sprites in Jill are a lot smaller than the sprites in VGFM. Sprites obviously need to be redrawn when they move or animate, which means that the game has to erase the old sprite (by drawing the level tiles or other background graphics where the sprite used to be) and then draw the new sprite. Bigger sprites mean that both of these tasks will take longer. There might be other things going on in the background, like the games redrawing sprites even if they haven't changed, but I don't know enough about these games to tell if this is the case or not.
Hocus Pocus uses yet another approach. The game uses parallax scrolling, so it wouldn't be possible to use hardware scrolling tricks, since the game would have to draw the background image differently depenting on the current position of the screen/"camera" in the level. Hocus takes advantage of the full VGA memory (4 full screens, see above) in a different way, setting 2 screens aside for a double-buffered display and using the remaining 2 screens to store all of the level's graphics in video memory. Hocus Pocus literally redraws the entire screen (minus the status bar) every single frame. There is absolutely no adaptive refresh going on in Hocus Pocus, just a complete redraw of the entire viewport (using heavily optimized assembly code, of course). But since all the graphics are already in video memory, it's still fast enough on a 386 (and maybe also on a fast 286). Since the image data has to be aligned on 4 pixel boundaries for this to work and since the parallax background needs to scroll at half the speed of the other level graphics, this means that the whole viewport has to scroll in 8 pixel steps horizontally. This may make the game seem less smooth than other games that can use true pixel-perfect scrolling, but it works well, even with this limitation.