home *** CD-ROM | disk | FTP | other *** search
/ ftp.xmission.com / 2014.06.ftp.xmission.com.tar / ftp.xmission.com / pub / lists / fractdev / archive / v01.n032 < prev    next >
Internet Message Format  |  2000-06-30  |  45KB
  1. From: owner-fractdev-digest@lists.xmission.com (fractdev-digest)
  2. To: fractdev-digest@lists.xmission.com
  3. Subject: fractdev-digest V1 #32
  4. Reply-To: fractdev-digest
  5. Sender: owner-fractdev-digest@lists.xmission.com
  6. Errors-To: owner-fractdev-digest@lists.xmission.com
  7. Precedence: bulk
  8.  
  9.  
  10. fractdev-digest         Friday, June 30 2000         Volume 01 : Number 032
  11.  
  12.  
  13.  
  14.  
  15. ----------------------------------------------------------------------
  16.  
  17. Date: Sun, 4 Jun 2000 16:28:43 -0500
  18. From: "Jonathan Osuch" <osuchj@uswest.net>
  19. Subject: Re: Bug fix in Xfractint 20.0.11
  20.  
  21. Scott,
  22.  
  23. > I have found the bug that kept '#' and 'F3' from selecting 3D Overlay
  24. while
  25. > at the Main Menu in Xfractint. I removed lines 1294 - 1295 in unixscr.c.
  26.  
  27. That is a routine I think I will change to be bypassed unless requested by a
  28. command line option.  It catches the control-e used by the evolver, also.
  29.  
  30. Jonathan
  31.  
  32.  
  33.  
  34. - --------------------------------------------------------------
  35. Thanks for using Fractdev, The Fractint Developer's Discussion List
  36. Post Message:   fractdev@lists.xmission.com
  37. Get Commands:   majordomo@lists.xmission.com "help"
  38. Administrator:  twegner@fractint.org
  39. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  40.  
  41. ------------------------------
  42.  
  43. Date: Tue, 27 Jun 2000 20:40:23 -0500
  44. From: "Jonathan Osuch" <osuchj@uswest.net>
  45. Subject: Allegro port status
  46.  
  47. Tim,
  48.  
  49. The latest set of source code available to you has all the menus working.
  50. The temporary messages still need a little work.
  51.  
  52. We need to work on the interface we want to use for the various graphics
  53. modes.  Currently, the built in Allegro function is used to provide a menu,
  54. but we don't need (or want?) to use it.  We could set up the command line
  55. such that something like: video=1024x768x24  would provide the resolution
  56. and the color depth.  Backwards compatibility needs to be worked out also.
  57. As does the results of pressing the function keys and what appears when the
  58. delete key is pressed.  Also, we need to consider how setting the disk video
  59. resolution will work.  We could have a menu like:
  60.  
  61. X Width           1078
  62. Y Depth           768
  63. Color Depth     24
  64.  
  65. I have a version where the palette editor (with 8 bit color) works to a
  66. certain extent.  There are sections of code that will need to be changed to
  67. get the alignment of the boxes and characters correct.
  68.  
  69. There is also a problem with displaying arrows (for which keys to use) on
  70. the screen.  This is due to using the default key mapping from Allegro.  I
  71. haven't tried to fix it yet.
  72.  
  73. Jonathan
  74.  
  75.  
  76.  
  77. - --------------------------------------------------------------
  78. Thanks for using Fractdev, The Fractint Developer's Discussion List
  79. Post Message:   fractdev@lists.xmission.com
  80. Get Commands:   majordomo@lists.xmission.com "help"
  81. Administrator:  twegner@fractint.org
  82. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  83.  
  84. ------------------------------
  85.  
  86. Date: Wed, 28 Jun 2000 13:48:33 -0600
  87. From: Phil McRevis <legalize@xmission.com>
  88. Subject: Re: Allegro port status 
  89.  
  90. In article <000d01bfe0a1$e329ff00$0100a8c0@bananasenior>,
  91.     "Jonathan Osuch" <osuchj@uswest.net>  writes:
  92.  
  93. > but we don't need (or want?) to use it.  We could set up the command line
  94. > such that something like: video=1024x768x24  would provide the resolution
  95. > and the color depth.
  96.  
  97. Specifying the depth alone isn't enough to identify various video
  98. modes of importance.  For instance, in 16-bit mode you have RGB 5:6:5
  99. and xRGB 1:5:5:5 and RGBA 5:5:5:1.
  100.  
  101. > Backwards compatibility needs to be worked out also.
  102.  
  103. Fractint currently only remembers the video mode from the function key
  104. definition.  This should be changed to specify the video mode
  105. explicitly rather than relying on the indirection through the video
  106. key mapping.
  107.  
  108. > As does the results of pressing the function keys and what appears when the
  109. > delete key is pressed.  Also, we need to consider how setting the disk video
  110. > resolution will work.
  111.  
  112. I envisioned that "disk video" mode would be just another device
  113. selected through the interface.  It can have an arbitrary pixel format
  114. for its output, since its all in software.  The larger vision was to
  115. enable the possibility of having Win32 modes and DirectX modes living
  116. side-by-side even though they are pretty different on the insides.
  117.  
  118. That's why the menuing, etc., code has to be in the driver interface
  119. - -- doing a menu under Win32 or DOS/Allegro is going to be very
  120. different from doing it under DirectX or the Mac, or Xlib, etc.
  121. - --
  122. <http://www.xmission.com/~legalize/>    Legalize Adulthood!
  123.     ``Ain't it funny that they all fire the pistol,     
  124.       at the wrong end of the race?''--PDBT     
  125. legalize@xmission.com    <http://www.xmission.com/~legalize/who/>
  126.  
  127. - --------------------------------------------------------------
  128. Thanks for using Fractdev, The Fractint Developer's Discussion List
  129. Post Message:   fractdev@lists.xmission.com
  130. Get Commands:   majordomo@lists.xmission.com "help"
  131. Administrator:  twegner@fractint.org
  132. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  133.  
  134. ------------------------------
  135.  
  136. Date: Thu, 29 Jun 2000 16:26:01 -0500
  137. From: "Jonathan Osuch" <osuchj@uswest.net>
  138. Subject: Re: Allegro port status 
  139.  
  140. Rich,
  141.  
  142. > Specifying the depth alone isn't enough to identify various video
  143. > modes of importance.  For instance, in 16-bit mode you have RGB 5:6:5
  144. > and xRGB 1:5:5:5 and RGBA 5:5:5:1.
  145.  
  146. We can certainly address this.  Since Allegro does this for us behind the
  147. scenes, your input will be invaluable in setting this up.  I take it you are
  148. suggesting something along the lines of: video=1024x768x5x6x5x0
  149.  
  150. Or, would it be cleaner to use a different command line, such as:
  151. video=1024x768 depth=5:6:5:0
  152.  
  153. > Fractint currently only remembers the video mode from the function key
  154. > definition.  This should be changed to specify the video mode
  155. > explicitly rather than relying on the indirection through the video
  156. > key mapping.
  157.  
  158. Yes, I agree.  But, in order to not break PAR's that use video=, we will
  159. still need to map those function keys to video modes.  OTOH, we could just
  160. ignore video= commands in PARs.  The problem that raises is that there are
  161. some images that are resolution dependent.
  162.  
  163. > I envisioned that "disk video" mode would be just another device
  164. > selected through the interface.  It can have an arbitrary pixel format
  165. > for its output, since its all in software.
  166.  
  167. Currently that is crudely done by recompiling.  I haven't taken a close look
  168. at how to switch from one device to another when both are memory resident.
  169.  
  170. It appears to me that the windows allowed by Allegro can also be arbitrarily
  171. sized.  Although you can run into a problem with the text being too small or
  172. off the edge of the window.
  173.  
  174. Jonathan
  175.  
  176. P.S.  If I don't respond to something you think is important it's probably
  177. because it went zinging over my head.  Please feel free to reiterate.
  178.  
  179.  
  180.  
  181. - --------------------------------------------------------------
  182. Thanks for using Fractdev, The Fractint Developer's Discussion List
  183. Post Message:   fractdev@lists.xmission.com
  184. Get Commands:   majordomo@lists.xmission.com "help"
  185. Administrator:  twegner@fractint.org
  186. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  187.  
  188. ------------------------------
  189.  
  190. Date: Thu, 29 Jun 2000 17:54:22 -0600
  191. From: Phil McRevis <legalize@xmission.com>
  192. Subject: Re: Allegro port status 
  193.  
  194. In article <000901bfe210$aaca4500$0100a8c0@bananasenior>,
  195.     "Jonathan Osuch" <osuchj@uswest.net>  writes:
  196.  
  197. > We can certainly address this.  Since Allegro does this for us behind the
  198. > scenes, your input will be invaluable in setting this up.  I take it you are
  199. > suggesting something along the lines of: video=1024x768x5x6x5x0
  200. > 
  201. > Or, would it be cleaner to use a different command line, such as:
  202. > video=1024x768 depth=5:6:5:0
  203.  
  204. I hadn't thought much about this recently.  On 29-Apr-1999, I wrote
  205. the following (which can be had from the archives at
  206. <ftp://ftp.xmission.com/pub/lists/fractdev/archive/>:
  207.  
  208. =====
  209.     Date: Thu, 29 Apr 1999 19:55:01 -0600
  210.       To: fractdev@lists.xmission.com
  211.     From: Phil McRevis <legalize@xmission.xmission.com>
  212. Reply-To: legalize@xmission.com
  213.    Organ: multi-cellular, biological
  214.  Subject: driver characteristics
  215. - ---------
  216. Since Humberto brought up some specifics of drivers, I'll say a little
  217. about how I'm implementing the driver harness.  Naturally we'll be
  218. able to change the harness later.  The point is not to design some
  219. end-all be-all graphics API.  The idea is just to get things going
  220. incrementally.  Feel free to kibitz, if its a big issue, something can
  221. be done now, but please consider this more of a 'status report' for
  222. your information on what I'm doing, more than a design review where
  223. I'm proposing the idea. :-)
  224.  
  225. Existing video mode glue logic in fractint is currently implemented in
  226. select_video_mode().  It walks through the table stored in memory and
  227. creates the scrollable display of available video modes.  When you
  228. select a mode from the list (or by some other means like video=), then
  229. the proper parameters are snatched out of the table and sent to the
  230. assembly routine setvideomode (video.asm), which issues the
  231. appropriate commands to the video card.
  232.  
  233. With the harness, select_video_mode() instead walks a list of drivers
  234. and queries each driver about the modes supported by the driver.  It
  235. then displays a scrolling list created from the driver responses.
  236. When the user selects an item on the list, select_video_mode() calls
  237. through the driver harness to set the video mode.
  238.  
  239. This means that when we get to the point of having all (or several) or
  240. the drivers I list below, under win98 you could have the choice of
  241. the same video modes supported by multiple drivers.  The video display
  242. list might look like this:
  243.  
  244. key...driver...name.................xdot.ydot.color.comment.............
  245. SF1   win32    GDI Surface          1024x768  5:6:5
  246. SF2   directx  Windowed             1024x768  5:6:5
  247. SF3   directx  Full Screen          1024x768  8     256 colors
  248. SF4   directx  Full Screen          1024x768  5:6:5 16-bit RGB
  249. SF5   directx  Full Screen          1024x768  5:5:5 15-bit RGB
  250. SF6   opengl   Full Screen          1024x768  8     256 color indexed
  251. SF7   opengl   Full Screen          1024x768  8:8:8 24-bit RGB
  252.  
  253. (This is an ASCII graphic mockup; not a screen dump.)
  254.  
  255. Xdot and ydot take on a subtle meaning in a windowed environment, but
  256. window systemless drivers still need to be able to report device
  257. dimensions.
  258.  
  259. The video parameter ('video=<key>') currently only specifies a function
  260. key which is bound to a video mode.  It doesn't force a particular
  261. video mode, just selects one from the key list.  If you want to write a
  262. script or parameter file that uses a particular video mode, you have to
  263. ensure the proper key assignment is setup first.  To set the function
  264. key assignment you have to get into the fractint.cfg file.  Icky!
  265.  
  266. With the harness, the video parameter is updated to specify both the
  267. driver and the desires video mode provided by the driver.  So you'd
  268. say something like "video=directx/1024x768/8".  A new method for
  269. binding the keys to video modes will have to be provided, as the old
  270. method depended on fractint.cfg which is now specific to the fractint
  271. driver.
  272.  
  273. But what about the stuff the fractint.cfg file did?  That's used by the
  274. "fractint" driver (see blow) as input to decide what video modes it
  275. lists when queried.
  276.  
  277. Some really random ideas:
  278.  
  279. should image and model formats (3D raytracing files, etc) be
  280.     supported as compile-time modules like drivers?
  281.  
  282. should drivers be allowed to invoke the engine distinct from
  283.     fractint's gui?  Is the engine a client of the driver, or is the
  284.     driver a client of the engine?  Fractint is currently architected
  285.     towards the latter.  Reversing the assumption would be difficult.
  286.  
  287. should 3D drivers subsume 2D functionality?
  288.     Is there any reason you'd want to use ogl for 3D, but x11 for 2D?
  289.     If not, then "x11" and "opengl" drivers will provide everything
  290.     you need.  Select an "x11' driver video mode for 2D stuff and an
  291.     "opengl" driver video mode for 3D stuff.  Fractint doesn't (yet)
  292.     mix 2D and 3D rendering together.
  293.  
  294. Drivers
  295. - -------
  296. display drivers I think should be done, in no particular order:
  297.     "curses"
  298.     possibly uses curses, but only has character I/O.
  299.     Displays "pixels" using characters as similar to XaoS.
  300.     Enumerate text vide modes (DOS) or screen sizes (curses?) to
  301.         form "video modes" table.
  302.     Works in DOS (pd curses) and unix (native curses).
  303.  
  304.     "fractint"
  305.     port existing fractint assembly code to 32-bit flat model.
  306.     Included is the native video and mouse support coded in
  307.     assembly.
  308.  
  309.     "allegro"
  310.     Uses Allegro library under DJGPP to enumerate video formats
  311.     and provide video/mouse/sound support.
  312.  
  313.     "disk"
  314.     Video modes contain list of standard image sizes and "custom",
  315.     letting you set the size.
  316.  
  317.     "win32"
  318.     text menus are displayed graphically somehow.
  319.     graphics display native to GDI presented as video mode.
  320.     Emulate other modes?  Only if someone desperate for it --
  321.     directx would be the preferred solution!
  322.  
  323.     "directx"
  324.     text menus are displayed using a regular win32 window on GDI
  325.         surface, or as graphic text on graphics screen (driver
  326.         option).
  327.     graphics display is done through full-screen with DirectDraw.
  328.     DirectDrawDevices enumerated by DDraw are the video modes.
  329.  
  330.     "direct3d"
  331.     Same as directx, but uses D3D for 3D effects.
  332.  
  333.     "x11"
  334.     Text menus are displayed graphically using X11.
  335.     Available visuals on the screen are the video modes.
  336.     
  337.     "opengl"
  338.     Same as X11, only OGL-capable visuals are video modes.
  339.     Uses OGL for all pixel I/O and 3D.
  340.  
  341. like XaoS, more that one driver can be available, but only one driver
  342. can be active at once in any given graphic window.
  343. =====
  344.  
  345. So I think I was expecting that the old video mode specifications
  346. would still be supported (they wouldn't contain /'s) and that the new
  347. video specification would be a driver/resolution/depth argument, where
  348. the depth would be stated to be sufficiently unique.  I think I prefer
  349. R:G:B:A, with the letters replaced by the number of bits dedicated to
  350. each color channel.  This disambiguates 5:5:5, 5:6:5, and 5:5:5:1
  351. pixel formats for 16-bit depth, i.e. "video=allegro/1024x768/5:5:5".
  352.  
  353. > Yes, I agree.  But, in order to not break PAR's that use video=, we will
  354. > still need to map those function keys to video modes.  OTOH, we could just
  355. > ignore video= commands in PARs.  The problem that raises is that there are
  356. > some images that are resolution dependent.
  357.  
  358. For the "video=SF5" case, we handle the existing mapping of function
  359. keys to video modes but only via the default key mapping.  I never
  360. liked the idea that someone else could customize their key mapping and
  361. I'd get a different resolution image because I didn't have their map
  362. of keys to video modes.  So just support the default key mapping for
  363. backwards compatability and don't read the mapping file (or ignore the
  364. mapping section of the fractint.cfg or wherever its stored, I forget).
  365. This will give people who customized the mapping file an incentive to
  366. use the new video format specification that isn't dependent on their
  367. key mappings.
  368.  
  369. > Currently that is crudely done by recompiling.  I haven't taken a close look
  370. > at how to switch from one device to another when both are memory resident.
  371.  
  372. I imagined that the total number of drivers available is decided at
  373. compile time.  Since I started by working on the X11 driver, I didn't
  374. get to the point where switching between drivers was something that I
  375. tried.  However, I think the driver structure that I put together can
  376. handle this.  In the code I wrote, you can see where I do a 'trick' of
  377. having the first N bytes of the driver structures identical across all
  378. drivers and drivers tack on their own private data at the end of this
  379. structure.  This lets all code outside the driver treat the all
  380. drivers the same, but inside each driver, a cast is used to make the
  381. driver private data visible inside the driver-related code.
  382.  
  383. For X11 this is where things like the Display * pointer, and so-on get
  384. stored.  I imagine that Allegro also has a few little bits of
  385. configuration data that the driver needs -- opaque handles to
  386. resources or whatnot.  The Allegro driver should follow a similar
  387. pattern to the X11 code in how it stores this data.
  388.  
  389. To switch from one driver to another dynamically, you ask the existing
  390. driver to shut itself down and clean up its private data.  (A
  391. full-screen DirectX driver here would release the exclusive access to
  392. the full-screen here, for instance.)  Then you ask the new driver to
  393. initialize itself and allocate its private data.  The you set the
  394. "current driver pointer" to point to the new driver's data block.
  395.  
  396. A driver can implement its driver+private data structure as a
  397. statically allocated file-scope struct, provided it is careful about
  398. how it uses the data block.  A driver could also implement things by
  399. dynamically allocating the structure.  Everyone outside the driver
  400. doesn't care because everything happens through a pointer no matter
  401. how the block of data was allocated.
  402.  
  403.  
  404. > It appears to me that the windows allowed by Allegro can also be arbitrarily
  405. > sized.  Although you can run into a problem with the text being too small or
  406. > off the edge of the window.
  407.  
  408. This could be useful.  I was wondering how to draw legible text in a
  409. tiny video mode like 320x200.  Fractint deals with it by having a
  410. hand-coded "font" bitmap that it copies into video memory, but when
  411. you move to a framework, you have to wonder how the framework will
  412. deal with these kinds of things.  Frankly I'm not too worried about
  413. 320x200 looking crappy :-)
  414.  
  415. > P.S.  If I don't respond to something you think is important it's probably
  416. > because it went zinging over my head.  Please feel free to reiterate.
  417.  
  418. OK, well its probably best for you to ask me to repeat things you
  419. don't understand, if any.  Otherwise if you don't comment on it I'll
  420. assume you understood it all :-).  I don't mind re-explaining
  421. something different or in more detail so don't be shy about asking.
  422. - --
  423. <http://www.xmission.com/~legalize/>    Legalize Adulthood!
  424.     ``Ain't it funny that they all fire the pistol,     
  425.       at the wrong end of the race?''--PDBT     
  426. legalize@xmission.com    <http://www.xmission.com/~legalize/who/>
  427.  
  428. - --------------------------------------------------------------
  429. Thanks for using Fractdev, The Fractint Developer's Discussion List
  430. Post Message:   fractdev@lists.xmission.com
  431. Get Commands:   majordomo@lists.xmission.com "help"
  432. Administrator:  twegner@fractint.org
  433. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  434.  
  435. ------------------------------
  436.  
  437. Date: Thu, 29 Jun 2000 17:54:22 -0600
  438. From: Phil McRevis <legalize@xmission.com>
  439. Subject: Re: Allegro port status 
  440.  
  441. In article <000901bfe210$aaca4500$0100a8c0@bananasenior>,
  442.     "Jonathan Osuch" <osuchj@uswest.net>  writes:
  443.  
  444. > We can certainly address this.  Since Allegro does this for us behind the
  445. > scenes, your input will be invaluable in setting this up.  I take it you are
  446. > suggesting something along the lines of: video=1024x768x5x6x5x0
  447. > 
  448. > Or, would it be cleaner to use a different command line, such as:
  449. > video=1024x768 depth=5:6:5:0
  450.  
  451. I hadn't thought much about this recently.  On 29-Apr-1999, I wrote
  452. the following (which can be had from the archives at
  453. <ftp://ftp.xmission.com/pub/lists/fractdev/archive/>:
  454.  
  455. =====
  456.     Date: Thu, 29 Apr 1999 19:55:01 -0600
  457.       To: fractdev@lists.xmission.com
  458.     From: Phil McRevis <legalize@xmission.xmission.com>
  459. Reply-To: legalize@xmission.com
  460.    Organ: multi-cellular, biological
  461.  Subject: driver characteristics
  462. - ---------
  463. Since Humberto brought up some specifics of drivers, I'll say a little
  464. about how I'm implementing the driver harness.  Naturally we'll be
  465. able to change the harness later.  The point is not to design some
  466. end-all be-all graphics API.  The idea is just to get things going
  467. incrementally.  Feel free to kibitz, if its a big issue, something can
  468. be done now, but please consider this more of a 'status report' for
  469. your information on what I'm doing, more than a design review where
  470. I'm proposing the idea. :-)
  471.  
  472. Existing video mode glue logic in fractint is currently implemented in
  473. select_video_mode().  It walks through the table stored in memory and
  474. creates the scrollable display of available video modes.  When you
  475. select a mode from the list (or by some other means like video=), then
  476. the proper parameters are snatched out of the table and sent to the
  477. assembly routine setvideomode (video.asm), which issues the
  478. appropriate commands to the video card.
  479.  
  480. With the harness, select_video_mode() instead walks a list of drivers
  481. and queries each driver about the modes supported by the driver.  It
  482. then displays a scrolling list created from the driver responses.
  483. When the user selects an item on the list, select_video_mode() calls
  484. through the driver harness to set the video mode.
  485.  
  486. This means that when we get to the point of having all (or several) or
  487. the drivers I list below, under win98 you could have the choice of
  488. the same video modes supported by multiple drivers.  The video display
  489. list might look like this:
  490.  
  491. key...driver...name.................xdot.ydot.color.comment.............
  492. SF1   win32    GDI Surface          1024x768  5:6:5
  493. SF2   directx  Windowed             1024x768  5:6:5
  494. SF3   directx  Full Screen          1024x768  8     256 colors
  495. SF4   directx  Full Screen          1024x768  5:6:5 16-bit RGB
  496. SF5   directx  Full Screen          1024x768  5:5:5 15-bit RGB
  497. SF6   opengl   Full Screen          1024x768  8     256 color indexed
  498. SF7   opengl   Full Screen          1024x768  8:8:8 24-bit RGB
  499.  
  500. (This is an ASCII graphic mockup; not a screen dump.)
  501.  
  502. Xdot and ydot take on a subtle meaning in a windowed environment, but
  503. window systemless drivers still need to be able to report device
  504. dimensions.
  505.  
  506. The video parameter ('video=<key>') currently only specifies a function
  507. key which is bound to a video mode.  It doesn't force a particular
  508. video mode, just selects one from the key list.  If you want to write a
  509. script or parameter file that uses a particular video mode, you have to
  510. ensure the proper key assignment is setup first.  To set the function
  511. key assignment you have to get into the fractint.cfg file.  Icky!
  512.  
  513. With the harness, the video parameter is updated to specify both the
  514. driver and the desires video mode provided by the driver.  So you'd
  515. say something like "video=directx/1024x768/8".  A new method for
  516. binding the keys to video modes will have to be provided, as the old
  517. method depended on fractint.cfg which is now specific to the fractint
  518. driver.
  519.  
  520. But what about the stuff the fractint.cfg file did?  That's used by the
  521. "fractint" driver (see blow) as input to decide what video modes it
  522. lists when queried.
  523.  
  524. Some really random ideas:
  525.  
  526. should image and model formats (3D raytracing files, etc) be
  527.     supported as compile-time modules like drivers?
  528.  
  529. should drivers be allowed to invoke the engine distinct from
  530.     fractint's gui?  Is the engine a client of the driver, or is the
  531.     driver a client of the engine?  Fractint is currently architected
  532.     towards the latter.  Reversing the assumption would be difficult.
  533.  
  534. should 3D drivers subsume 2D functionality?
  535.     Is there any reason you'd want to use ogl for 3D, but x11 for 2D?
  536.     If not, then "x11" and "opengl" drivers will provide everything
  537.     you need.  Select an "x11' driver video mode for 2D stuff and an
  538.     "opengl" driver video mode for 3D stuff.  Fractint doesn't (yet)
  539.     mix 2D and 3D rendering together.
  540.  
  541. Drivers
  542. - -------
  543. display drivers I think should be done, in no particular order:
  544.     "curses"
  545.     possibly uses curses, but only has character I/O.
  546.     Displays "pixels" using characters as similar to XaoS.
  547.     Enumerate text vide modes (DOS) or screen sizes (curses?) to
  548.         form "video modes" table.
  549.     Works in DOS (pd curses) and unix (native curses).
  550.  
  551.     "fractint"
  552.     port existing fractint assembly code to 32-bit flat model.
  553.     Included is the native video and mouse support coded in
  554.     assembly.
  555.  
  556.     "allegro"
  557.     Uses Allegro library under DJGPP to enumerate video formats
  558.     and provide video/mouse/sound support.
  559.  
  560.     "disk"
  561.     Video modes contain list of standard image sizes and "custom",
  562.     letting you set the size.
  563.  
  564.     "win32"
  565.     text menus are displayed graphically somehow.
  566.     graphics display native to GDI presented as video mode.
  567.     Emulate other modes?  Only if someone desperate for it --
  568.     directx would be the preferred solution!
  569.  
  570.     "directx"
  571.     text menus are displayed using a regular win32 window on GDI
  572.         surface, or as graphic text on graphics screen (driver
  573.         option).
  574.     graphics display is done through full-screen with DirectDraw.
  575.     DirectDrawDevices enumerated by DDraw are the video modes.
  576.  
  577.     "direct3d"
  578.     Same as directx, but uses D3D for 3D effects.
  579.  
  580.     "x11"
  581.     Text menus are displayed graphically using X11.
  582.     Available visuals on the screen are the video modes.
  583.     
  584.     "opengl"
  585.     Same as X11, only OGL-capable visuals are video modes.
  586.     Uses OGL for all pixel I/O and 3D.
  587.  
  588. like XaoS, more that one driver can be available, but only one driver
  589. can be active at once in any given graphic window.
  590. =====
  591.  
  592. So I think I was expecting that the old video mode specifications
  593. would still be supported (they wouldn't contain /'s) and that the new
  594. video specification would be a driver/resolution/depth argument, where
  595. the depth would be stated to be sufficiently unique.  I think I prefer
  596. R:G:B:A, with the letters replaced by the number of bits dedicated to
  597. each color channel.  This disambiguates 5:5:5, 5:6:5, and 5:5:5:1
  598. pixel formats for 16-bit depth, i.e. "video=allegro/1024x768/5:5:5".
  599.  
  600. > Yes, I agree.  But, in order to not break PAR's that use video=, we will
  601. > still need to map those function keys to video modes.  OTOH, we could just
  602. > ignore video= commands in PARs.  The problem that raises is that there are
  603. > some images that are resolution dependent.
  604.  
  605. For the "video=SF5" case, we handle the existing mapping of function
  606. keys to video modes but only via the default key mapping.  I never
  607. liked the idea that someone else could customize their key mapping and
  608. I'd get a different resolution image because I didn't have their map
  609. of keys to video modes.  So just support the default key mapping for
  610. backwards compatability and don't read the mapping file (or ignore the
  611. mapping section of the fractint.cfg or wherever its stored, I forget).
  612. This will give people who customized the mapping file an incentive to
  613. use the new video format specification that isn't dependent on their
  614. key mappings.
  615.  
  616. > Currently that is crudely done by recompiling.  I haven't taken a close look
  617. > at how to switch from one device to another when both are memory resident.
  618.  
  619. I imagined that the total number of drivers available is decided at
  620. compile time.  Since I started by working on the X11 driver, I didn't
  621. get to the point where switching between drivers was something that I
  622. tried.  However, I think the driver structure that I put together can
  623. handle this.  In the code I wrote, you can see where I do a 'trick' of
  624. having the first N bytes of the driver structures identical across all
  625. drivers and drivers tack on their own private data at the end of this
  626. structure.  This lets all code outside the driver treat the all
  627. drivers the same, but inside each driver, a cast is used to make the
  628. driver private data visible inside the driver-related code.
  629.  
  630. For X11 this is where things like the Display * pointer, and so-on get
  631. stored.  I imagine that Allegro also has a few little bits of
  632. configuration data that the driver needs -- opaque handles to
  633. resources or whatnot.  The Allegro driver should follow a similar
  634. pattern to the X11 code in how it stores this data.
  635.  
  636. To switch from one driver to another dynamically, you ask the existing
  637. driver to shut itself down and clean up its private data.  (A
  638. full-screen DirectX driver here would release the exclusive access to
  639. the full-screen here, for instance.)  Then you ask the new driver to
  640. initialize itself and allocate its private data.  The you set the
  641. "current driver pointer" to point to the new driver's data block.
  642.  
  643. A driver can implement its driver+private data structure as a
  644. statically allocated file-scope struct, provided it is careful about
  645. how it uses the data block.  A driver could also implement things by
  646. dynamically allocating the structure.  Everyone outside the driver
  647. doesn't care because everything happens through a pointer no matter
  648. how the block of data was allocated.
  649.  
  650.  
  651. > It appears to me that the windows allowed by Allegro can also be arbitrarily
  652. > sized.  Although you can run into a problem with the text being too small or
  653. > off the edge of the window.
  654.  
  655. This could be useful.  I was wondering how to draw legible text in a
  656. tiny video mode like 320x200.  Fractint deals with it by having a
  657. hand-coded "font" bitmap that it copies into video memory, but when
  658. you move to a framework, you have to wonder how the framework will
  659. deal with these kinds of things.  Frankly I'm not too worried about
  660. 320x200 looking crappy :-)
  661.  
  662. > P.S.  If I don't respond to something you think is important it's probably
  663. > because it went zinging over my head.  Please feel free to reiterate.
  664.  
  665. OK, well its probably best for you to ask me to repeat things you
  666. don't understand, if any.  Otherwise if you don't comment on it I'll
  667. assume you understood it all :-).  I don't mind re-explaining
  668. something different or in more detail so don't be shy about asking.
  669. - --
  670. <http://www.xmission.com/~legalize/>    Legalize Adulthood!
  671.     ``Ain't it funny that they all fire the pistol,     
  672.       at the wrong end of the race?''--PDBT     
  673. legalize@xmission.com    <http://www.xmission.com/~legalize/who/>
  674.  
  675. - --------------------------------------------------------------
  676. Thanks for using Fractdev, The Fractint Developer's Discussion List
  677. Post Message:   fractdev@lists.xmission.com
  678. Get Commands:   majordomo@lists.xmission.com "help"
  679. Administrator:  twegner@fractint.org
  680. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  681.  
  682. ------------------------------
  683.  
  684. Date: Thu, 29 Jun 2000 20:37:31 -0500
  685. From: "Jonathan Osuch" <osuchj@uswest.net>
  686. Subject: Re: Allegro port status 
  687.  
  688. Rich,
  689.  
  690. > The Allegro driver should follow a similar
  691. > pattern to the X11 code in how it stores this data.
  692.  
  693. Yes, it does.  I started by copying your X11 file and then changed things
  694. over to Allegro specific.  I still need to clean up the extra variables.  I
  695. believe, in my version, the disk video and X11 drivers are broken.  I'll fix
  696. them.
  697.  
  698. Now I see how we will switch between drivers.  However, what do we do on
  699. initial startup, ie. no video= statement in sstools.ini?  The program flow
  700. has been slightly altered in Xfractint because a video mode has to be
  701. selected (window opened) before text can be displayed.  We need to use a
  702. default driver to display the initial selection of drivers.  The disk video
  703. mode would be appropriate, but is it going to change from Allegro to W32,
  704. etc.?  Are we going to end up with multiple disk video drivers?
  705.  
  706. > OK, well its probably best for you to ask me to repeat things you
  707. > don't understand, if any.  Otherwise if you don't comment on it I'll
  708. > assume you understood it all :-).  I don't mind re-explaining
  709. > something different or in more detail so don't be shy about asking.
  710.  
  711. Okay, here goes.  Your description of how to implement an event-driven
  712. architecture has baffled me.  Not the basics, but how to use it in Fractint.
  713. What I would like to do, but don't know how, is to start up the event
  714. handler and then start the fractal engine and the plotting engine as
  715. children.  The data would be sent from the fractal engine to the plotting
  716. engine to be plotted on the screen.
  717.  
  718. Another thing that I'd like to know is the proper way to give time slices
  719. back to the operating system when the calculation is done.  This isn't from
  720. any of your comments, just something I'd like to know.
  721.  
  722. Jonathan
  723.  
  724.  
  725.  
  726. - --------------------------------------------------------------
  727. Thanks for using Fractdev, The Fractint Developer's Discussion List
  728. Post Message:   fractdev@lists.xmission.com
  729. Get Commands:   majordomo@lists.xmission.com "help"
  730. Administrator:  twegner@fractint.org
  731. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  732.  
  733. ------------------------------
  734.  
  735. Date: Fri, 30 Jun 2000 20:12:37 -0600
  736. From: Phil McRevis <legalize@xmission.com>
  737. Subject: Re: Allegro port status 
  738.  
  739. Did anyone else get two copies of my last message?  Sorry if I sent
  740. two by mistake, I seem to have received two.
  741.  
  742. In article <001b01bfe237$86805820$0100a8c0@bananasenior>,
  743.     "Jonathan Osuch" <osuchj@uswest.net>  writes:
  744.  
  745. > Now I see how we will switch between drivers.  However, what do we do on
  746. > initial startup, ie. no video= statement in sstools.ini?
  747.  
  748. My thoughts on this were: it depends on the platform.  Each "platform
  749. port" of fractint should select a lowest-common denominator video mode
  750. that is the most likely to be present or even better guaranteed to
  751. be present.  For X11 this means the default visual on the default
  752. display; for Win32 it means a Win32 GDI window on the desktop; I am
  753. not sure what Allegro would use for its default, but I'm betting that
  754. you do.
  755.  
  756. > [...] the initial selection of drivers.  The disk video
  757. > mode would be appropriate,
  758.  
  759. I was thinking that disk video mode would only be appropriate for the
  760. DOS code.  Here, "DOS" would be a platform distinct from Win32.  So
  761. the author of the "DOS" port would make the default driver the disk
  762. video mode driver.
  763.  
  764. > [The disk video mode] but is it going to change from Allegro to W32,
  765. > etc.?  Are we going to end up with multiple disk video drivers?
  766.  
  767. I think disk video mode should be platform and driver agnostic.  Disk
  768. video should be a portable software interface to a memory buffer as the
  769. video "device" and not depend on Win32 or any other driver or platform
  770. specific code.  The existing disk video mode code can be drawn into
  771. that driver.  (I think I did that for d_disk.c in the re-org of the
  772. code I put up).
  773.  
  774. That brings up the question of what a disk video mode uses for text I/O
  775. of menus and the like.  If you restrict yourself to the text I/O
  776. currently in fractint with its menu routines then everything will boil
  777. down to the few driver calls relating to text I/O.  From there the
  778. driver can take the text and display it using whatever method is
  779. appropriate for the platform.
  780.  
  781. I was thinking perhaps the most portable thing to do is to use curses.
  782. Curses libraries for MS-DOS exist and should be pretty well debugged at
  783. this point.  Curses is well supported for unix as well.  Is it on the
  784. mac?  Frankly, I can't see the point of making a curses-based disk
  785. video driver for the Mac; just use the Mac toolbox.  On the other
  786. hand, nothing fancier than a DMI DOS application that just used
  787. character I/O for status reporting could run on just about any old
  788. computer DOS-wise as a "dumb render farm".  It wouldn't even need
  789. VGA.
  790.  
  791. > Okay, here goes.  Your description of how to implement an event-driven
  792. > architecture has baffled me.  Not the basics, but how to use it in Fractint.
  793.  
  794. OK, I'm looking at ant.c right now.  I'll restructure ant.c according
  795. to the schema I advocated in an earlier message, that should make
  796. things concrete.  I'll post it in a separate message.
  797.  
  798. > What I would like to do, but don't know how, is to start up the event
  799. > handler and then start the fractal engine and the plotting engine as
  800. > children.
  801.  
  802. I see two choices here: threads or idle processing.
  803.  
  804. With threads, you can start a separate thread of control executing
  805. through the code which can simplify the implementation and readability
  806. of the code.  On Win32 and *nix both have threads, and so does the Mac
  807. I believe.  For threads, that leaves DOS as an unknown; I believe I've
  808. seen "thread" implementation libraries for DOS, but I've never
  809. investigated them in any great detail.  Perhaps someone else knows
  810. about thread support for DOS.  A Win32 console program can use threads,
  811. but that's not the same as a PMI DOS executable.
  812.  
  813. With idle processing, the program maintains a flag that it is doing
  814. background processing while also receiving input from the system.  In
  815. fractint currently, each local routine looking for input while doing
  816. processing has its own copy of the logic to look for input interspersed
  817. with doing bits of computation.  Each routine "polls" or checks the
  818. state of the input buffer for mouse and keyboard events while in the
  819. middle of a long processing loop.  (I think the mouse event code got
  820. hidden inside the keyboard checking code!)
  821.  
  822. Idle processing keeps everything going by checking for input while
  823. processing is occuring.  The processing continues so long as there is
  824. no input available.  When input does become available, the idle
  825. processing loop either stops (like when you press ESC) or switches to
  826. an input processing loop like that contained in the text menu code.
  827. Depending on the area of fractint, the idle processing may continue
  828. after the text menu returns control back to its caller.
  829.  
  830. > The data would be sent from the fractal engine to the plotting
  831. > engine to be plotted on the screen.
  832.  
  833. Or rather a pointer to the data, or an agreed upon global buffer.  No
  834. need to copy around lots of data :-).
  835.  
  836. > Another thing that I'd like to know is the proper way to give time slices
  837. > back to the operating system when the calculation is done.
  838.  
  839. With threads, the one or more computation threads go into a wait state,
  840. waiting to be woken up and signalled that there is more work to do
  841. (points to plot with the fractal function, pixels to draw).
  842.  
  843. With idle processing you simply toggle the flag that indicates work to
  844. be done during idle states when the program would otherwise be blocked
  845. waiting for a key press or mouse event.  Since there is no background
  846. work to be done, the idle processing variation can just issue the
  847. blocking I/O call since fractint's data processing is always driven by
  848. input, whether from the keyboard or a file.
  849.  
  850. - --
  851. <http://www.xmission.com/~legalize/>    Legalize Adulthood!
  852.     ``Ain't it funny that they all fire the pistol,     
  853.       at the wrong end of the race?''--PDBT     
  854. legalize@xmission.com    <http://www.xmission.com/~legalize/who/>
  855.  
  856. - --------------------------------------------------------------
  857. Thanks for using Fractdev, The Fractint Developer's Discussion List
  858. Post Message:   fractdev@lists.xmission.com
  859. Get Commands:   majordomo@lists.xmission.com "help"
  860. Administrator:  twegner@fractint.org
  861. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  862.  
  863. ------------------------------
  864.  
  865. Date: Fri, 30 Jun 2000 21:12:07 -0600
  866. From: Phil McRevis <legalize@xmission.com>
  867. Subject: ant.c example
  868.  
  869. Existing ant.c routine TurkMite1 which does ant simulation processing
  870. until ESC is pressed or the number of desired points are plotted.
  871. TurkMite1 is called by ant(), which is called by the main input
  872. processing loop in framain2.c. (look for case 1: /* ^a Ant */)
  873.  
  874. =====================================================================
  875.  
  876. void
  877. TurkMite1(int maxtur, int rule_len, char *ru, long maxpts, long wait)
  878. {
  879.    int color, ix, iy, idir, pixel, i;
  880.    int kbdchar, step, antwrap;
  881.    int x[MAX_ANTS + 1], y[MAX_ANTS + 1];
  882.    int next_col[MAX_ANTS + 1], rule[MAX_ANTS + 1], dir[MAX_ANTS + 1];
  883.    long count;
  884.  
  885.    /*-=-=-=-=- long block of setup code elided -=-=-=-=-*/
  886.  
  887.    maxpts = maxpts / (long) INNER_LOOP;
  888.    for (count = 0; count < maxpts; count++)
  889.    {
  890.       /* check for a key only every inner_loop times */
  891.       kbdchar = keypressed();
  892.       if (kbdchar || step)
  893.       {
  894.          int done = 0;
  895.          if (kbdchar == 0)
  896.             kbdchar = getakey();
  897.          switch (kbdchar)
  898.          {
  899.          case SPACE:
  900.             step = 1 - step;
  901.             break;
  902.          case ESC:
  903.             done = 1;
  904.             break;
  905.          case RIGHT_ARROW:    case UP_ARROW:
  906.      case DOWN_ARROW:    case LEFT_ARROW:
  907.      case RIGHT_ARROW_2:    case UP_ARROW_2:
  908.          case DOWN_ARROW_2:    case LEFT_ARROW_2:
  909.        setwait(&wait);
  910.             break;
  911.          default:
  912.             done = 1;
  913.             break;
  914.          }
  915.          if (done)
  916.             goto exit_ant;
  917.          if (keypressed())
  918.             getakey();
  919.       }
  920.       for (i = INNER_LOOP; i; i--)
  921.       {
  922.     /* -=-=- inner loop of ant processing omitted; no I/O here -=-=- */
  923.       }
  924.    }
  925. exit_ant:
  926.    return;
  927. }
  928.  
  929. =====================================================================
  930.  
  931.  
  932. so what we have here in pseudocode is:
  933.  
  934. big_while_loop():
  935. initializes big while loop state
  936. loops forever
  937.     get input and call main_menu_switch()
  938.  
  939.     main_menu_switch():
  940.     parses input and calls ant()
  941.  
  942.         ant():
  943.         ant() calls TurkMite1()
  944.  
  945.         TurkMite1():
  946.         initialize local ant state
  947.         for each point to be plotted
  948.             if key pressed
  949.             if ESC pressed
  950.                 return
  951.             else
  952.                 process input locally
  953.             endif
  954.             endif
  955.             do increment of work using ant state
  956.         endfor
  957. done
  958. cleanup
  959.  
  960. So what we have inside this "calculation" is some exit logic (if ESC
  961. pressed), some input processing logic, and some incrmental work to be
  962. done.
  963.  
  964. Every routine that handles keyboard input in fractint is like this,
  965. except that some of them don't have incremental background processing
  966. they could do while waiting for input, so they just block waiting for
  967. input.  The text menu routines are an example of that kind of input
  968. processing.
  969.  
  970. Most "background processing" routines continue working until a key is
  971. pressed and then they return control to a menu or their caller (such
  972. as what TurkMite1 does when you are running the ant simulation and
  973. press ESC, returning control to the main fractal routine which
  974. processes the ESC as a signal to throw up the main menu).
  975.  
  976. Under an event processing organization, you would localize all the
  977. event processing to the main routine.  In Win32 this is the main
  978. message pump loop implemented with the usual GetMessage() and
  979. DispatchMessage().  In X11 its the event loop implemented around
  980. XNextEvent() and XtNextEvent().  The Mac has its own event loop
  981. processing routines as well.  In pseudocode, it looks more like this:
  982.  
  983. "idle processing style"
  984. big_while_loop():
  985. initializes
  986. quit = false
  987. while (!quit)
  988.     if (event)
  989.     get event
  990.     if (quit event)
  991.         quit = true
  992.     else
  993.         dispatch event to input sink:
  994.         if (keymap[input key])
  995.             call handler through (*keymap[input key])()
  996.  
  997.             handler for ^A on main menu (evolution of
  998.             main_menu_switch):
  999.             set idle routine to ant idle routine
  1000.             set idle state data to new ant idle state
  1001.  
  1002.         endif
  1003.     endif
  1004.     else if (idle routine)
  1005.     call idle routine with idle state data
  1006.     if (idle routine done processing)
  1007.         reset idle routine
  1008.         reset idle state data
  1009.     endif
  1010.     endif
  1011. done
  1012. cleanup
  1013.  
  1014. "threads style"
  1015.  
  1016. GUI thread:                    worker thread:
  1017.  
  1018. big_while_loop():                initialize
  1019. initializes                    while (!quit)
  1020. create worker thread                    obtain work item
  1021.                             do incremental work
  1022. quit = false                    done
  1023. while (!quit)                    cleanup
  1024.     if (event)
  1025.     get event
  1026.     if (quit event)
  1027.         quit = true
  1028.     else
  1029.         dispatch event to input sink
  1030.     endif
  1031.     endif
  1032. done
  1033. wait for worker threads
  1034. cleanup
  1035.  
  1036. The big difference between the two styles is that the single event
  1037. loop construction means you have to store intermediate data that is
  1038. communicated from one incremental work step to the next available
  1039. through a pointer or global variable.  So that means that the local
  1040. variables and local state initialized in TurkMite1() would have to be
  1041. stored in a piece of memory to be passed to each successive invocation
  1042. of the incremental work procedure that replaces TurkMite1 in the event
  1043. scheme.
  1044.  
  1045. By localizing the event mechanism to one place it becomes reasonable
  1046. to replace it with other event mechanisms such as event dispatching
  1047. under MFC, Win32 dialogs with their own message procs, Motif/Xt event
  1048. dispatching, and so-on.  This will allow fractint to eventually evolve
  1049. in the direction of a professional "Mac look and feel" interface
  1050. coexisting on the same code base as a professional "Win2000 look and
  1051. feel" interface.
  1052.  
  1053. This is my hope for fractint -- that it can evolve to having
  1054. professional looking interfaces native to the platform.  It may or may
  1055. not be possible.  Or it may be too much work and it may be easier to
  1056. evolve the current event processing in the keyboard code.  For now its
  1057. probably easier to just get the existing stuff working with the driver
  1058. interface rather than undertake so large a code change.  The driver
  1059. was a big enough change as it was and that already consumed my time
  1060. and passed on to someone else :-)
  1061. - --
  1062. <http://www.xmission.com/~legalize/>    Legalize Adulthood!
  1063.     ``Ain't it funny that they all fire the pistol, 
  1064.       at the wrong end of the race?''--PDBT
  1065.       <http://www.xmission.com/~legalize/who/>
  1066.  
  1067. - --------------------------------------------------------------
  1068. Thanks for using Fractdev, The Fractint Developer's Discussion List
  1069. Post Message:   fractdev@lists.xmission.com
  1070. Get Commands:   majordomo@lists.xmission.com "help"
  1071. Administrator:  twegner@fractint.org
  1072. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  1073.  
  1074. ------------------------------
  1075.  
  1076. End of fractdev-digest V1 #32
  1077. *****************************
  1078.  
  1079.