C PROGRAMMING SECTION - PROJECTS. JJB TEMPLAR 1) graphics hack suggestions 2) using the WB screen as a background >> 1 Graphics hack suggestions. The most impressive set of graphics effects I have seen to date on the Amiga are the Wild Copper demos. I make a distinction between these sorts of graphics demos and things like NewTek's demo disks or the Killer demo on one of the Fish disks, in that: o The Wild Copper (and similar) demos display one or sometimes two fancy effects, combined with a text display. And essentially the only thing that really changes are the words. o The NewTek type of demo uses more straightforward graphics effects, but has a much wider range of imagery. These are more dynamic than a few fancy graphics effects. However, graphics effects are very nice, particularly from a programming point of view, because they provide something to do, are fairly simple to implement, and don't require much concern as to how elements of the demo interact. When I say simple to implement, I mean project-wise. The code isn't necessarily simple, but it is certainly easier to code a single specific effect than it is to code a group of effects together coherently. Of the Wild Copper effects, several stand out as very good: 1) The rotating characters in the Wild Copper demo. Is there some way to rotate images more efficiently than with the brute force method of rotating each pixel ? 2) The spinning cylinders in said demo. In particular, the fact that shadows from the rotating text are also offset properly. 3) The loader demo, where image-pixels are magnified in varying amounts depending on where they fall beneath the lenses. Is there some trick to magnifying pixels quickly ? 4) After having tried it myself, how does the wbdemo avoid having its text flicker ? There are two sorts of flicker possible in my cop program. The first and current one is edge flicker, caused by image persistence, or whatever, and physiological in origin. This can be remedied by briefly displaying a blank area between frames of text movement, which introduces the second sort of flicker, which is like very bad interlace. Since the latter is much worse than edge flicker, I left the edge flicker in. If you can implement these effects, or suggest how they were done, without disassembling the Wild Copper code, than why not do so? >> 2 Using the WB screen as a background. The Wild Copper demo "wbdemo" is in my opinion the easiest to recreate. It involves scrolling (with vertical movement) text across a copy of the WB screen. As I see it, this is achieved as follows: A 4-plane display is created, with the WB's two planes as two of the four. The text is drawn into one of the other two, with the second extra one used as a shadow of the first. That is, it actually overlaps with the first in such a way that it looks like a shadow. It runs at a priority of 127, so it must have Wait()s or Delay()s to allow other programs to multitask. In the projects directory should be a program db, that demonstrates how the extra two planes can be used. It creates the 4-plane display by allocating two new planes, adding them to the WB screen's BitMap, then rebuilding the WB viewport and reloading the view, and then resetting the BitMap depth to 2 so the system drawing routines leave the extra planes alone. It would be more efficient to use a custom copper list, which means the 4-plane display need not be active over the entire screen. Remember, a 4-plane 640-pixel wide display consumes 100% of the bus cycles during the display, locking out both the blitter and the 68000. So the smaller the height of the active 4-plane display,the better. I tried to set up a complete copper list, with an interrupt to reset the copper list every vertical blank period. While adding the interrupt was easy, the whole effort was a failure. I lost the pointer, often lost or hashed the display, and seemed to be contending with a system VBLANK interrupt. The last point is due to the fact that adding my interrupt at different priorities had different results. Instead, I set up a user copper list, and tag it onto the WB screen's viewport. The program cop shows this in operation. There are a number of points to note regarding the coding of cop: - Display: the 4-plane display is activated somewhere down the screen, and turned off further down. - Double buffering: this is done by searching the LOFCopList for the code to load BPL3PTH, BPL3PTL, BPL4PTH and BPL4PTL, and replacing the immediate operands as appropriate. The reason I do a search rather than precalculate the correct offsets within the list is because I am not sure that the offsets will always be the same. - Shadowing: the shadow is formed by defining the shadow plane as the display plane - 1602. That is, 20 lines (1600 bytes) vertical + 16 pixels (2 bytes) horizontal for the shadow displacement. - Code: is 100% mine and Lattice's. The only assembler code is a function clipblit() to drive the system's BltBitMap function, and an input handler to intercept a Left-Alt-Escape, which sets a termination flag. I don't know if the wbdemo is stoppable like that. - Text: there are several problems with the text scrolling. 1) Scrolling in jumps of greater than 2 results in flickering at the left and right edges of the characters. This is a visual problem, caused by the quick displacement of the imagery. I don't know how to fix this, other than by reducing the jump speed to 2 or less, though the wbdemo program doesn't exhibit this problem. The worst example of this is the words "AND TO", that jump 16 pixels at a time. 2) If the number of characters to be displayed exceeds about 13, the display slows down in what I call the "speed wobbles". The solution (I think) to this is to speed up the drawing of the characters by writing a custom Blitter routine. For various reasons, I have postponed doing this. BTW: does anyone have a concrete example of how to use the blitter shift registers ? Or, perhaps, to design a wider character set. I had a wider one, but created this 32 bit wide one to make a custom blitter function easier to write.