The Apple II series including the IIgs did not have hardware sprite handling, though the IIgs did have high resolution graphics (compared to other Apple II machines). However people did manage to implement a number of high resolution sprite based games on the IIgs, including LemmingsGS, Rastan, and an unofficial port of Super Mario Brothers. These games manage full screen scrolling and numerous moving objects. What sprite handling libraries exist for the IIgs that can match the capabilities of those games?
2
-
2FWIW, "give me a list of" questions aren't ideal for stackexchange. A better question might be, "how were sprites handled on the Apple IIgs?", with a request for examples of sprite libraries in the body of the question.– faddenCommented Jan 3 at 16:19
-
1The question is already answered, but it could be extended to other simple computers, like the ZX Spectrum, which didn't even have shadow memory. But fine graphical games were written for it (one of my favorites is Underworlde).– chthonCommented Jan 10 at 16:02
Add a comment
|
2 Answers
There are two basic elements:
- Using "compiled" shapes, where the shape is stored as a series of drawing instructions rather than as data
- Taking advantage of the IIgs shadow RAM, as described in detail in this post
Compiling shapes was a popular technique on machines that didn't have a CPU that cached instructions and data separately. Instead of looping over a bitmap, you just call a function that explicitly draws every pixel, given an X/Y screen offset. This uses a lot of memory but avoids loop overhead, and lets you use faster immediate-mode instructions instead of indexed loads.
One sprite library example is "Mr. Sprite" from Brutal Deluxe. The software is available here, and there's a detailed explanation of the technology here.
That's assuming you want super hi-res graphics. If you'd like to use double lo-res graphics instead, try "Dolores" by 8-Bit-Shack; software here, tech discussion here. You get lower fidelity but considerably more speed.
You can also find the source code to Rastan GS online, e.g. here.
-
1The Mr Sprite explanation is very interesting and detailed, but while it explains how to draw a sprite at a chosen position, hardware-based sprites also keep the background, so that when you hide the sprite or move it to a new position, the background is automagically restored. How was that handled in software? Copying the background of the sprite before drawing it? Redrawing the background each time before drawing sprites on top?– jcaronCommented Jan 5 at 10:58
-
1@jcaron: you can blit to save/restore the rect covered by the sprite, or define the play area so that the background obscured by sprites is a simple pattern and can be erased quickly. It's also possible to skip the erase in some situations; for example, if I know the player's sprite can move no more than two pixels per frame and is always on a green background, I can add a two-pixel green border around the player and let it erase its own trail. I don't think there's a single correct answer for all situations.– faddenCommented Jan 5 at 17:22
There were multiple approaches possible, depending on the type of game. Many games used a combination of tricks to accomplish these techniques.
One approach was to disable the shadow memory, writing the the super-high-res buffer in bank 0, then reenable memory shadowing and run a fast copy function to read and write the SHR bank 0 memory to itself (with shadowing on, this would also write the screen data to the actual graphics buffer in bank $E0). Clever software could even copy only the bytes in bank 0 that changed, for faster update time. (Note that mvp/mvn memory copy opcodes would typically not be used, because they perform false reads of the destination address which is the slow, bank $E0 video RAM. Mapping the zero page or stack to the shadow region of bank 0 allowed faster opcodes to be used for this "blitting" logic.) Many side scrollers would use tiling, so that they could quickly avoid updating any tile which didn't change during a frame update. Animation/"video" players would often use frame deltas to speed up the frame rate (again, only updating video-memory bytes that changed).
Some animations in games were accomplished by manipulating the color palette, since there were 16 palettes of 16 colors individually selectable per scan line. By setting some colors to be the same, simple 2-frame animations can be accomplished just by swapping the palettes used on selected scan lines. Fades and vertical wipes can be accomplished the same way.
The 3200 color "mode" uses palette-modification tricks along with ray-gun synchronization to give the appearance of more colors or even simple animations. Using the vertical-blanking interrupt (or disabling interrupts and monitoring the VGC registers directly), smoother animations can be accomplished with reduced "tearing", because the screen updates are happening on a different part of the screen than the CRT is redrawing.
Some games (e.g. Tunnels of Armageddon) would use the IIgs fill-mode, which sacrifices one color in exchange for a repeat of the previous color used on that scan line; in this mode, the software just draws outlines of the shapes, and the hardware fills in the solids in between.
Since with 16 colors, there are two horizontal pixels per byte (in 320 mode), many games would limit onscreen movement to even-pixel boundaries and widths, so that no read-modify-write operations would be needed.
Because the horizontal resolution (320 or 640 pixels), palette, and fill mode is selectable per scanline, it's possible to use some combination of the techniques above to create the illusion of better/faster/higher-resolution graphics across the display, even though individual scanlines are limited in what they can display. The primary objective was always to limit the amount of the screen memory being rewritten per frame, approximately 25%-33% if I recall correctly.
Softdisk's publically-released GSLib/GTLib contained functions utilizing some of these techniques (including a library for handling 3200-graphics display and transitions). There used to be a version of Burgerlib for the IIgs, that handled blitting and some other sprite techniques, which was used in the port of Wolfenstein 3D (and Out of This World I believe, as well as other GS games). The demo culture in Europe produced some libraries as well. But most IIgs games seemingly used one-off or hand-crafted code, or at least proprietary libraries, for handling their sprites.
