home *** CD-ROM | disk | FTP | other *** search
/ Loadstar 236 / 236.d81 / t.bragz < prev    next >
Text File  |  2022-08-26  |  4KB  |  194 lines
  1. u
  2.       T H E   G E N I U S   O F
  3.          [S H P   2   F O N T]
  4.        A N D   [D O T B A S I C]
  5.  
  6.            by Dave Moorman
  7.  
  8.  
  9.     This utility took about two days
  10. to complete -- partly because of a
  11. certain madness on the part of the
  12. creator, but mostly because it was
  13. created with DotBASIC. DotBASIC
  14. requires a lot of overhead (everything
  15. below Page 64, plus the visually
  16. designed MED screen file). But the
  17. efficiency of the code and speed of
  18. development makes up for it. At least
  19. at this end!
  20.  
  21.     Since DotBASIC uses so much
  22. memory, I had to hunt down UNPACKER
  23. 2000, by Dennis Hildreth, to allow
  24. loading and unpacking of SHP bitmaps
  25. in a single go. This is why the bitmap
  26. has to reload when you choose 3. or 4.
  27.  
  28.     Drag-and-drop did not work
  29. well in this situation; the squares
  30. had to not exceed the given area of
  31. the block. So I used a "tag-along"
  32. technique:
  33.  
  34.  sp _ sprite number of square
  35.  .do:.ma
  36.  jx = cx%*8+24
  37.  jy = cy%*8+50
  38.  hx = int(jx/256)
  39.  jx = jx and 255
  40.  poke 53264,(peek(53264) and not 2^sp)
  41.     or (hx * 2^sp)
  42.  poke 53248 + sp*2,jx
  43.  poke 53249 + sp*2,jy
  44.  .un l2%
  45.  
  46.     CX% and CY% are generated by .MA
  47. -- the cell location of the mouse
  48. arrow. The business with HX handles
  49. moving the square to the right side of
  50. the screen. The squares are a little
  51. sluggish, but then again, I wrote this
  52. at two in the morning, so I was quite
  53. sluggish myself.
  54.  
  55.  
  56.     Several times, I wanted to use a
  57. <BACK ARROW> keypress to escape the
  58. current action. I tried:
  59.  
  60.  .do:.ma:.wb
  61.   -
  62.   -
  63.   -
  64.  .un e% or l2%:ifl2%=0then<escape>
  65.  
  66.     But using e% caused some confusion
  67. in the main loop. So I found a better
  68. way:
  69.  
  70.  .do:.ma:.kp,"_"
  71.   -
  72.   -
  73.   -
  74.  .un i% or l2%:ifl2%=0then <escape>
  75.  
  76.     .KP,STRING looks for a keypress in
  77. the following string. If it is there,
  78. I% holds the position of that
  79. character in the string.
  80.  
  81.     For the SHP file requester, I used
  82. methods outlined in the Cookbook
  83. elsewhere on this issue.
  84.  
  85.     For the creation of an FTS screen,
  86. I needed to compare 8-byte chunks of
  87. bitmap memory with 8-byte chunks of
  88. font memory. This would be painfully
  89. slow if we could not bring string
  90. variables into play.
  91.  
  92.     Early in the program, I create two
  93. string variables:
  94.  
  95.  a$=str$(peek(71)+256*peek(72))
  96.  a = val(a$)
  97.  b$=str$(peek(71)+256*peek(72))
  98.  b = val(b$)
  99.  
  100.     With this code, A holds the first
  101. location of the three byte string
  102. pointer for A$. B holds the pointer
  103. location for B$. The pointer bytes are
  104.  
  105.   LENGTH / LO ADDRESS / HI ADDRESS.
  106.  
  107. So the first thing is to make both A$
  108. and B$ 8-bytes long:
  109.  
  110.  poke a,8:poke b,8
  111.  
  112.     I also created two FuNctions to
  113. separate low and high bytes of
  114. addresses.
  115.  
  116.  deffnh(x)=int(x/256)
  117.  deffnl(x)=x-fnh(x)*256
  118.  
  119.     So, as I flipped through memory
  120. (with FOR-NEXT loops with STEP 8), I
  121. plugged the locations into the string
  122. pointers:
  123.  
  124.  poke a+1, fnl(x):poke a+2, fnh(x)
  125.  poke b+1, fnl(y):poke b+2, fnh(x)
  126.  
  127.     Now, A$ and B$ each "hold" eight
  128. bytes, one from the bitmap, the other
  129. from the font. All that is needed is
  130.  
  131.  if a$ = b$ then ....
  132.  
  133.     The code is still BASIC, so it
  134. gets bogged down toward the end. But
  135. it is about as fast as I needed for
  136. this special purpose utility.
  137.  
  138.  
  139.     Several times during design, I had
  140. to call up B.VDOT, the visual design
  141. program, to modify the screen. For
  142. instance, only as I began to write the
  143. documentation did I realize I needed a
  144. disk function. So VDOT let me easily
  145. change the items on the menu and add
  146. the extra Region. While this means
  147. jumping between programs, having the
  148. visual presentation right there on the
  149. screen makes corrections easy.
  150.  
  151.  
  152.     DotBASIC makes complex BASIC
  153. programs easy, clean, and efficient.
  154. Take a look at the DotBASIC/Mr.Mouse
  155. documentation elsewhere in this issue
  156. for command-by-command explanations.
  157. If you are an "almost intermediate"
  158. BASIC 2.0 programmer, DotBASIC will
  159. propel you into the realm of Wizard!
  160. Much of the monkeying with memory
  161. management is already done for you.
  162. You can lay out your screens and Event
  163. Regions quickly with VDOT. And the
  164. two-character commands are crisp and
  165. readable.
  166.  
  167.     DotBASIC has all the good stuff of
  168. BASIC 2.0 -- plus everything you need
  169. to create excellent programs.
  170.  
  171.  DMM
  172.  
  173. [LATER:] As I was editing this, I
  174. realized that DotBASIC HAS a command
  175. for punching two-byte values into two
  176. bytes of memory. Where I
  177.  
  178.  poke(a+1),fnl(x):pO(a+2),fnh(x)
  179.  
  180. I could have:
  181.  
  182.  .p2,a+1,x
  183.  
  184. and a+1/a+2 would hold the lo/hi data
  185. of x.
  186.  
  187. I might go back and change it, if I
  188. have time. You should take a look
  189. yourself and see if I "improved" the
  190. code!
  191.  
  192.  DMM
  193.  
  194.  
  195.