home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.pascal.borland      Borland Pascal was actually pretty neat      2,978 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 2,908 of 2,978   
   Marco van de Voort to Jim Leonard   
   Re: Extending Turbo Vision with graphics   
   29 Dec 13 15:57:08   
   
   From: marcov@toad.stack.nl   
      
   On 2013-12-26, Jim Leonard  wrote:   
   > I know this is a longshot as this group is nearly dead, but I have to try   
   > asking: I will be writing a menu front-end that must run on any DOS-based   
   > PC (even 808x systems,   
      
   That kills a lot of options. You'll be spending most of your time fighting   
   memory idiosyncrasies of the 16-bit memory model. Specially if you add   
   memory hungry graphics.   
      
   > this is for a museum project) and would like to   
   > avoid writing an entire CUI framework from scratch.  Turbo Vision   
   > obviously comes to mind, however one of the requirements is that, while   
   > running in text mode is ok, on VGA/SVGA systems the front-end should also   
   > display a bitmap that changes as the user selects a new item.   
      
   The FPC TV clone (called FV) is based on a graphics vision (by Leon de   
   Boer, who afaik based himself on the PD C++ code), backported to textmode.   
      
   One of the major changes was reworking the codebase for changes to the   
   coordinate system (from pixels back to chars).  If you can keep the   
   coordinates in chars, you can probably reuse most of any TV clone, and write an   
   appropriate drivers unit for it (that paints to graph mode)   
      
   The result will be less integrated since you still emulate text for most   
   drawing, so no fancy window borders, and all coordinates would be in   
   characters still.   
      
   > Does anyone have any suggestions on how to (very simply) extend Turbo   
   > Vision to graphics mode?  Is it as simple as hooking where the 80x25/43/50   
   > raw screen data is and then redrawing that in graphics mode, or is that   
   > not feasible?   
      
   It might also read the screen. But I think you can intercept it already   
   earlier, in the place where TV decides where to draw which parts of the   
   screen. TV draws incrementally, iow only areas that are changed. Probably   
   not unimportant on a 8086 :-)   
      
   >Is there a prewritten library that I'm unaware of that fits   
   > the bill?   
      
   1) Create a drivers unit implementation for your graphics mode that emulates   
   the drawing of each widget. I don't know if the TV implementation really   
   only draws via drivers though.   
      
   2) For pixel graphics you could create a TView derivative that registers its   
   coordinates (on create/change/destroy) and the reference to the picture with   
   the (drivers/video) drawing backend (using a new interface)   
      
   The the drawing backend can use that knowledge to not paint character   
   emulation (the empty characters) to that tview area, and paint the picture   
   instead. (and e.g. use the tview background as fill colour for areas of the   
   tview that are not covered by the image.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca