Blueberry
Member |
Some qualified guesswork about the scroller...
There are a couple of things to consider:
- The filling
- The vertical scaling
- The horizontal scaling
- The sinus movements
- The representation of the font
Filling: The text is filled using vertical blitter filling. This works by setting two blitter sources with xor combination. One source is set at the first rasterline, the other source and the destination is set at the second rasterline, and the blit proceeds in forward direction. Thus, the blitter will xor the result for each line into the next line, creating the same effect vertically as the normal blitter fill does horizontally.
What needs to be drawn prior to filling is then, for each x position, the upper and lower edges of the text at that position.
Vertical scaling: The y positions at which to plot must be scaled by a (non-integer) factor. Since all of the text has the same height at any one time, this factor is the same throughout a frame, so the multiplication table for the scaling can be calculated once per frame to avoid having the tables for all scale factors in memory at the same time. This table will of course do the screenwidth multiplication at the same time.
Horizontal scaling: For each x position, the information needed for that position is: The font glyph, the (unscaled) x position within that glyph, the screen pointer to the word column in which to plot, and a bitmask with one bit set at the bit position within that word to plot at. Since just one horizontal pass is needed, this code is not particularly time critical, so normal fixed point interpolation should do fine here.
Sinus movements: Just add some sinus-varying value to the screen pointer before plotting.
Font representation: For each (unscaled) x position in each glyph, there must be a pointer or offset indicating where the y positions to plot at can be found, along with the number of positions to plot at (always even). The actual positions can just be bytes, in which case the code to plot one pixel would look something like this:
; A0 = Font data
; A1 = Scaling table
; A2 = Screen pointer
; D2 = Bit mask
move.b (a0)+,d0 ; unscaled y position * 2
move.w (a1,d0.w),d1 ; Screen offset
eor.w d2,(a2,d1.w)
To gain some speed, the font could instead contain the actual plotting code, like this:
; A1 = Scaling table
; A2 = Screen pointer
; D2 = Bit mask
move.w position*2(a1),d1 ; Screen offset
eor.w d2,(a2,d1.w)
However, this would make the font data 8 times as big, and there is not exactly plenty of memory to use (remember, WOC runs with just 512k RAM). The indirect plotting loop is probably fast enough, as the average number of pixels to be plotted per x position seems to be about 3.
That's it, and it doesn't even need self-modifying code. :-D
|