4 ms·

>Jazz Jackrabbit employs some really unique VGA programming to do fast blitting Isn't this similar(identical?) to the tricks John Carmack used to get side scro

• bonzini 2y ago
  No, it's not. Keen 1 was a 16 color game; 16 color games pack 8 pixels in a byte and spread the color information across 4 planes. Accessing the different planes requires programming the video card's registers and there isn't really a way to change the representation of the pixels in memory, what Carmack did was write fast blitting routines and use the hardware's smooth scrolling capabilities. All these were hiding in plane sight in the EGA/VGA manuals, they are exactly how the hardware was supposed to be used even though nobody had done it before Keen. 256 color modes are a different beast. The VGA can only load four bytes at a time but those four bytes must have the same address and come from the four planes. So whereas the 16 color mode split the color information across planes, 256 color modes put a whole pixel in a byte and four adjacent pixels go into four planes. Normally you want 1 byte per pixel and ignore planes completely, so the hardware is programmed to remap bits 0-1 of the address to the planes and do some magic so that reads also work as intended. You can still do smooth scrolling in this mode, but double buffering requires more expensive copies from VRAM to main memory. Michael Abrash then noticed that this is absolutely not necessary and you can use planes in 256 colors mode. Unlike Carmack's Keen, this was completely undocumented. In retrospect it's quite obvious: the VGA was composed of two completely independent pieces of hardware dealing respectively with CPU accesses to VRAM and creating the video output from VRAM contents, and as long as the two are programmed in a compatibile manner things just work. But still it's not how you were supposed to do 256 color graphics on the VGA. This was called "mode X" and it gives you several benefits: VRAM to VRAM copies are cheaper, which you can use for both blitting and double buffering, and you have access to 256K of memory which enables higher resolutions (theoretically up to 360x480, in practice everybody used 320x240). This worked well for games like DOOM or Wolfenstein 3D that redrew the whole screen at once, however the wins for blitting were a lot less clear because dealing with the 4 planes meant more complicated routines and a lot of writing to the card's registers. So what Jazz does is use a middle ground mode where you have bit 0 of the address used to pick 2 planes and the other 2 are picked through the video card's registers. Normally this is used in text mode so that even bytes describe characters and odd bytes describe colors, hence odd/even mode. Jazz applies it to 256 color mode and then it only addresses pairs of pixels at once, so that it doesn't have to program the video card registers as much as in 4-plane mode X. Essentially the graphics mode is a 160x200 matrix where each of the 160 horizontal cells is composed of two pixels.
  • phire 2y ago
    > All these were hiding in plane sight in the EGA/VGA manuals, they are exactly how the hardware was supposed to be used Well... Keen 1-3 only scrolled by a maximum of 16 pixels. After that, it would reset the scroll and copy the entire screen over by 16 pixels (one tile). In order to reduce the amount of copying, the levels were all designed with repeating patterns to minimise the number of changed tiles on each scroll. Why? Because the documentation didn't say what happened if the hardware scrolling wrapped around, and Carmack carefully designed the engine to avoid this potential edge case. They named the technique "Adaptive tile refresh". For episodes 4-6, Carmack was confident enough in the wrapping behaviour of hardware scrolling, and the engine was redesigned to take advantage of this. I guess they had tested enough 3rd party EGA cards to be sure they all behaved in the same way. This removed the need for repeating patterns in the level, allowing for much improved graphics. Though they did need to add a compatibly mode that avoided wrapping across the 64KB boundaries, as some SVGA cards did the wrong thing. So the scrolling was documented, but perhaps not well enough.
    • bonzini 2y ago
      Indeed, wrapping around the end of VRAM is another thing that I had to fix in QEMU[1]. :) > So the scrolling was documented, but perhaps not well enough. That's certainly possible - 10% inspiration and 90% perspiration, as they say. However, the same video card features were present on a lot of 80s hardware and the basic techniques were used for side scroller games on other platforms as well, especially the Amiga with its excellent offloading of VRAM copies. For example, Turrican II[2] was released around the same time as Keen. http://uridiumauthor.blogspot.com/2017/12/scrolling-on-amiga.html http://uridiumauthor.blogspot.com/2017/12/scrolling-on-amiga... says: "to get the screen scrolling sideways [...] all we had to do was allocate a few extra bytes at the end of our buffer, as many as we wanted to scroll one pixel row sideways from one side of the map to the other, in fact, say 20x2x10 bytes, i.e. 400 bytes per buffer, not much at all." "So, starting from top left, we start smooth scrolling by 1 pixel to the right. This is done with the hardware scroll X register. What it's really doing is throwing away the number of pixels you tell it, from 0 to 15, before it starts displaying the screen picture. Our screen buffers always support one more character wide and high than the screen is; because in 15 out of 16 cases that extra character row or column is partially visible." "When you get to 16 pixels across you reset the Scroll X position to 0, and add one word (16 bits/pixels to the pointers to the start of the buffer display [...] At this point we need to build the incoming column of characters to the right" [1] https://lore.kernel.org/all/20231231093918.239549-4-pbonzini@redhat.com/ https://lore.kernel.org/all/20231231093918.239549-4-pbonzini... [2] https://en.wikipedia.org/wiki/Turrican_II:_The_Final_Fight https://en.wikipedia.org/wiki/Turrican_II:_The_Final_Fight